Re: gcc-10 toolchain does not include string to numeric conversion functions like std::stoull

[Ludovic Courtès]

Hi,

Erik Garrison <erik.garrison@gmail.com> skribis:

> I've run into a quirk in the various gcc toolchains that seems somewhat
> unique to guix builds of them. I'd like to understand if this is
> intentional.
>
> Initially, I found that string to numeric conversion functions that are
> enabled by _GLIBCXX_USE_C99_STDLIB are not available on guix gcc toolchains
> for gcc 8, 9, and 10.
>
> This is a minimal test case to reproduce the problem:
>
> Code:
>
> #include <iostream>
> #include <string>
>
> uint64_t _parse_number(std::string::const_iterator& c, const
> std::string::const_iterator& end) {
>     std::string::const_iterator s = c;
>     while (c != end and isdigit(*c)) ++c;
>     if (c > s) {
>         return std::stoull(std::string(s,c));
>     } else {
>         return 0;
>     }
> }
>
> int main(int argc, char** argv) {
>     std::string s(argv[1]);
>     std::string::const_iterator b = s.begin();
>     std::string::const_iterator e = s.end();
>     std::cout << _parse_number(b, e) << std::endl;
>     return 0;
> }
>
> Compiling with (g++ --version == 10.1.0),
> /gnu/store/3kvnslc16sy7kwi2c5r7r5k6bbv2p03f-gcc-toolchain-10.1.0/bin/g++
>
> g++ test-stoull.cpp -o test-stoull

I can reproduce it:

--8<---------------cut here---------------start------------->8---
$ guix describe
Generacio 147   Jun 08 2020 00:30:31    (nuna)
  guix e782756
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: e78275608065ef073775fabb9f1a757da65851f2
$ guix environment  --ad-hoc gcc-toolchain -C -- g++ num.cpp
num.cpp: In function 'uint64_t 
_parse_number(std::__cxx11::basic_string<char>::const_iterator&, const 
const_iterator&)':
num.cpp:9:33: error: invalid initialization of reference of type 'const 
wstring&' {aka 'const std::__cxx11::basic_string<wchar_t>&'} from expression of 
type 'std::string' {aka 'std::__cxx11::basic_string<char>'}   
    9 |         return std::stoull(std::string(s,c));
      |                                 ^~~~~~~~~~~
--8<---------------cut here---------------end--------------->8---

This is indeed fixed with:

  guix environment  --ad-hoc gcc-toolchain@9 -C -- g++ 
-D_GLIBCXX_USE_C99_STDLIB=1 num.cpp

> This behavior appears to be similar to this issue:
> http://freebsd.1045724.x6.nabble.com/base-gcc-and-GLIBCXX-USE-C99-td5781697.html.
> It's also similar to this report,
> https://stackoverflow.com/questions/40779611/g-compile-error-invalid-initialization-of-reference-of-type-stdstod
> .
>
> It may be more correct to require wstring in these kinds of conversions.
> However, I'm concerned that if gcc is built differently in guix than it
> typically is in other distributions, we will need to patch many libraries
> when building them on guix. It's probably better to match typical
> expectations of developers about the behavior of gcc.

I agree, it seems we have a misconfiguration issue leading to  this in
our c++config.h:

--8<---------------cut here---------------start------------->8---
/* Define if C99 functions or macros in <stdlib.h> should be imported in
   <cstdlib> in namespace std for C++11. */
/* #undef _GLIBCXX11_USE_C99_STDLIB */
--8<---------------cut here---------------end--------------->8---

The check appears to be this:

--8<---------------cut here---------------start------------->8---
    # Check for the existence in <stdlib.h> of lldiv_t, et. al.
    AC_MSG_CHECKING([for ISO C99 support in <stdlib.h> for C++11])
    AC_CACHE_VAL(glibcxx_cv_c99_stdlib_cxx11, [
      GCC_TRY_COMPILE_OR_LINK(
        [#include <stdlib.h>
         volatile float f;
         volatile long double ld;
         volatile unsigned long long ll;
         lldiv_t mydivt;],
        [char* tmp;
         f = strtof("gnu", &tmp);
         ld = strtold("gnu", &tmp);
         ll = strtoll("gnu", &tmp, 10);
         ll = strtoull("gnu", &tmp, 10);
         ll = llabs(10);
         mydivt = lldiv(10,1);
         ll = mydivt.quot;
         ll = mydivt.rem;
         ll = atoll("10");
         _Exit(0);
        ], [glibcxx_cv_c99_stdlib_cxx11=yes], [glibcxx_cv_c99_stdlib_cxx11=no])
    ])
    AC_MSG_RESULT($glibcxx_cv_c99_stdlib_cxx11)
    if test x"$glibcxx_cv_c99_stdlib_cxx11" = x"yes"; then
      AC_DEFINE(_GLIBCXX11_USE_C99_STDLIB, 1,
        [Define if C99 functions or macros in <stdlib.h> should be imported
        in <cstdlib> in namespace std for C++11.])
    fi
--8<---------------cut here---------------end--------------->8---

We should check what’s going on!

Thanks,
Ludo’.