forked from lix-project/lix
jade
917c9bdee7
This also bans various sneaking of negative numbers from the language
into unsuspecting builtins as was exposed while auditing the
consequences of changing the Nix language integer type to a newtype.
It's unlikely that this change comprehensively ensures correctness when
passing integers out of the Nix language and we should probably add a
checked-narrowing function or something similar, but that's out of scope
for the immediate change.
During the development of this I found a few fun facts about the
language:
- You could overflow integers by converting from unsigned JSON values.
- You could overflow unsigned integers by converting negative numbers
into them when going into Nix config, into fetchTree, and into flake
inputs.
The flake inputs and Nix config cannot actually be tested properly
since they both ban thunks, however, we put in checks anyway because
it's possible these could somehow be used to do such shenanigans some
other way.
Note that Lix has banned Nix language integer overflows since the very
first public beta, but threw a SIGILL about them because we run with
-fsanitize=signed-overflow -fsanitize-undefined-trap-on-error in
production builds. Since the Nix language uses signed integers, overflow
was simply undefined behaviour, and since we defined that to trap, it
did.
Trapping on it was a bad UX, but we didn't even entirely notice
that we had done this at all until it was reported as a bug a couple of
months later (which is, to be fair, that flag working as intended), and
it's got enough production time that, aside from code that is IMHO buggy
(and which is, in any case, not in nixpkgs) such as
lix-project/lix#445, we don't think
anyone doing anything reasonable actually depends on wrapping overflow.
Even for weird use cases such as doing funny bit crimes, it doesn't make
sense IMO to have wrapping behaviour, since two's complement arithmetic
overflow behaviour is so *aggressively* not what you want for *any* kind
of mathematics/algorithms. The Nix language exists for package
management, a domain where bit crimes are already only dubiously in
scope to begin with, and it makes a lot more sense for that domain for
the integers to never lose precision, either by throwing errors if they
would, or by being arbitrary-precision.
This change will be ported to CppNix as well, to maintain language
consistency.
Fixes: lix-project/lix#423
Change-Id: I51f253840c4af2ea5422b8a420aa5fafbf8fae75
122 lines
3.2 KiB
C++
122 lines
3.2 KiB
C++
#pragma once
|
|
///@file
|
|
|
|
#include "installables.hh"
|
|
#include "flake/flake.hh"
|
|
|
|
namespace nix {
|
|
|
|
struct DrvInfo;
|
|
struct SourceExprCommand;
|
|
|
|
namespace eval_cache { class EvalCache; class AttrCursor; }
|
|
|
|
struct App
|
|
{
|
|
std::vector<DerivedPath> context;
|
|
Path program;
|
|
// FIXME: add args, sandbox settings, metadata, ...
|
|
};
|
|
|
|
struct UnresolvedApp
|
|
{
|
|
App unresolved;
|
|
App resolve(ref<Store> evalStore, ref<Store> store);
|
|
};
|
|
|
|
/**
|
|
* Extra info about a \ref DerivedPath "derived path" that ultimately
|
|
* come from a Nix language value.
|
|
*
|
|
* Invariant: every ExtraPathInfo gotten from an InstallableValue should
|
|
* be possible to downcast to an ExtraPathInfoValue.
|
|
*/
|
|
struct ExtraPathInfoValue : ExtraPathInfo
|
|
{
|
|
/**
|
|
* Extra struct to get around C++ designated initializer limitations
|
|
*/
|
|
struct Value {
|
|
/**
|
|
* An optional priority for use with "build envs". See Package
|
|
*/
|
|
std::optional<NixInt::Inner> priority;
|
|
|
|
/**
|
|
* The attribute path associated with this value. The idea is
|
|
* that an installable referring to a value typically refers to
|
|
* a larger value, from which we project a smaller value out
|
|
* with this.
|
|
*/
|
|
std::string attrPath;
|
|
|
|
/**
|
|
* \todo merge with DerivedPath's 'outputs' field?
|
|
*/
|
|
ExtendedOutputsSpec extendedOutputsSpec;
|
|
};
|
|
|
|
Value value;
|
|
|
|
ExtraPathInfoValue(Value && v)
|
|
: value(v)
|
|
{ }
|
|
|
|
virtual ~ExtraPathInfoValue() = default;
|
|
};
|
|
|
|
/**
|
|
* An Installable which corresponds a Nix langauge value, in addition to
|
|
* a collection of \ref DerivedPath "derived paths".
|
|
*/
|
|
struct InstallableValue : Installable
|
|
{
|
|
ref<EvalState> state;
|
|
|
|
InstallableValue(ref<EvalState> state) : state(state) {}
|
|
|
|
virtual ~InstallableValue() { }
|
|
|
|
virtual std::pair<Value *, PosIdx> toValue(EvalState & state) = 0;
|
|
|
|
/**
|
|
* Get a cursor to each value this Installable could refer to.
|
|
* However if none exists, throw exception instead of returning
|
|
* empty vector.
|
|
*/
|
|
virtual std::vector<ref<eval_cache::AttrCursor>>
|
|
getCursors(EvalState & state);
|
|
|
|
/**
|
|
* Get the first and most preferred cursor this Installable could
|
|
* refer to, or throw an exception if none exists.
|
|
*/
|
|
virtual ref<eval_cache::AttrCursor>
|
|
getCursor(EvalState & state);
|
|
|
|
UnresolvedApp toApp(EvalState & state);
|
|
|
|
static InstallableValue & require(Installable & installable);
|
|
static ref<InstallableValue> require(ref<Installable> installable);
|
|
|
|
protected:
|
|
|
|
/**
|
|
* Handles either a plain path, or a string with a single string
|
|
* context elem in the right format. The latter case is handled by
|
|
* `EvalState::coerceToDerivedPath()`; see it for details.
|
|
*
|
|
* @param v Value that is hopefully a string or path per the above.
|
|
*
|
|
* @param pos Position of value to aid with diagnostics.
|
|
*
|
|
* @param errorCtx Arbitrary message for use in potential error message when something is wrong with `v`.
|
|
*
|
|
* @result A derived path (with empty info, for now) if the value
|
|
* matched the above criteria.
|
|
*/
|
|
std::optional<DerivedPathWithInfo> trySinglePathToDerivedPaths(Value & v, const PosIdx pos, std::string_view errorCtx);
|
|
};
|
|
|
|
}
|