Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libexpr: Use int64_t for NixInt #2378

Merged
merged 1 commit into from
Aug 29, 2018
Merged

libexpr: Use int64_t for NixInt #2378

merged 1 commit into from
Aug 29, 2018

Commits on Aug 28, 2018

  1. libexpr: Use int64_t for NixInt

    Using a 64bit integer on 32bit systems will come with a bit of a
    performance overhead, but given that Nix doesn't use a lot of integers
    compared to other types, I think the overhead is negligible also
    considering that 32bit systems are in decline.
    
    The biggest advantage however is that when we use a consistent integer
    size across all platforms it's less likely that we miss things that we
    break due to that. One example would be:
    
    NixOS/nixpkgs#44233
    
    On Hydra it will evaluate, because the evaluator runs on a 64bit
    machine, but when evaluating the same on a 32bit machine it will fail,
    so using 64bit integers should make that consistent.
    
    While the change of the type in value.hh is rather easy to do, we have a
    few more options available for doing the conversion in the lexer:
    
      * Via an #ifdef on the architecture and using strtol() or strtoll()
        accordingly depending on which architecture we are. For the #ifdef
        we would need another AX_COMPILE_CHECK_SIZEOF in configure.ac.
      * Using istringstream, which would involve copying the value.
      * As we're already using boost, lexical_cast might be a good idea.
    
    Spoiler: I went for the latter, first of all because lexical_cast does
    have an overload for const char* and second of all, because it doesn't
    involve copying around the input string. Also, because istringstream
    seems to come with a bigger overhead than boost::lexical_cast:
    
    https://www.boost.org/doc/libs/release/doc/html/boost_lexical_cast/performance.html
    
    The first method (still using strtol/strtoll) also wasn't something I
    pursued further, because it is also locale-aware which I doubt is what
    we want, given that the regex for int is [0-9]+.
    
    Signed-off-by: aszlig <aszlig@nix.build>
    Fixes: NixOS#2339
    aszlig committed Aug 28, 2018
    Configuration menu
    Copy the full SHA
    0ad643e View commit details
    Browse the repository at this point in the history