3 ms·

C23 has C++14-compatible separators in numbers, as in 1'000'000. (Not sure why they didn’t use underscores.) Unfortunately, strtol and friends haven’t been exte

C23 has C++14-compatible separators in numbers, as in 1'000'000. (Not sure why they didn’t use underscores.) Unfortunately, strtol and friends haven’t been extended accordingly.

boxed 3y ago
In python the int parser was quietly changed to accept underscores as valid ints. This has bitten me very bad in production. Imo this was a very bad idea.
- 9dev 3y ago
  How did this cause problems for you?
  - boxed 3y ago
    One system checked if it was a valid int by running `int(x)`, deciding that it was, and passing it to the other system. The second system ran a python version BEFORE this change, while the first system was a newer version. BOOM. That was the first issue. But this made me extremely fearful in the general case, as parsing a number incorrectly can have quite dire consequences when dealing with money for example. So suddenly accept any random string of numbers interspersed at random places with underscores is a Bad Thing, and not a tiny little implementation detail to push through the most popular programming language in the world without any discussion.
    - kragen 3y ago
      it seems like, the way you designed your system, literally any backward-compatible change to integer syntax in python would cause the same parser-differential denial of service vulnerability?
- jonhohle 3y ago
  Yeah, literal int representation in source is one thing, changing int parsing string methods is something else and probably should require explicit inclusion.
devnullbrain 3y ago
C23 features won't help many C users because it's a community that takes an uncommonly long time to move to new versions. Linux only recently moved from C89 to C11.
- flohofwoe 3y ago
  TBF it makes little sense to change the language standard of an existing project because then you end up with large areas in the old standard and some areas in the new standard. And bringing the entire code base to the new standard is just pointless busywork and might actually introduce new bugs. As long as Linux doesn't prevent user space code to be written in more recent C standards (which it obviously does) it's fine. Apart from that, there's also the Visual Studio compiler team to blame because they didn't manage to catch up with C99 until around 2015 (and even then only an incomplete implementation), and only in 2019 decided to 'officially' support the latest C standards again. In general it makes a lot more sense today to start new C projects in more recent standard versions then it was 5..10 years ago.
  - devnullbrain 3y ago
    Strong agree on all points. The gains from bumping e.g. a C++ version are much higher.
    - uecker 3y ago
      The cost of pumping a C++ version is also much higher. For C, you lose support for older compilers and minor platforms that haven't catched up, but if this isn't a problem, then only very minor (or no) modifications to the source should be required. Newer features can then be used gradually where it makes sense.
cmovq 3y ago
The original C++ proposal [1] discusses some alternative syntaxes, including underscores. Underscores would conflict with C++ user defined literals, for example in 0xAA_BB it is unclear whether _BB is a literal suffix for 0xAA since it’s a valid identifier. [1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3499.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n34...

C23 has C++14-compatible separators in numbers, as in 1'000'000. (Not sure why they didn’t use underscores.) Unfortunately, strtol and friends haven’t been extended accordingly.

boxed 3y ago

In python the int parser was quietly changed to accept underscores as valid ints. This has bitten me very bad in production. Imo this was a very bad idea.

9dev 3y ago
How did this cause problems for you?
- boxed 3y ago
  One system checked if it was a valid int by running `int(x)`, deciding that it was, and passing it to the other system. The second system ran a python version BEFORE this change, while the first system was a newer version. BOOM. That was the first issue. But this made me extremely fearful in the general case, as parsing a number incorrectly can have quite dire consequences when dealing with money for example. So suddenly accept any random string of numbers interspersed at random places with underscores is a Bad Thing, and not a tiny little implementation detail to push through the most popular programming language in the world without any discussion.
  - kragen 3y ago
    it seems like, the way you designed your system, literally any backward-compatible change to integer syntax in python would cause the same parser-differential denial of service vulnerability?
jonhohle 3y ago
Yeah, literal int representation in source is one thing, changing int parsing string methods is something else and probably should require explicit inclusion.

devnullbrain 3y ago

C23 features won't help many C users because it's a community that takes an uncommonly long time to move to new versions. Linux only recently moved from C89 to C11.

flohofwoe 3y ago
TBF it makes little sense to change the language standard of an existing project because then you end up with large areas in the old standard and some areas in the new standard. And bringing the entire code base to the new standard is just pointless busywork and might actually introduce new bugs. As long as Linux doesn't prevent user space code to be written in more recent C standards (which it obviously does) it's fine. Apart from that, there's also the Visual Studio compiler team to blame because they didn't manage to catch up with C99 until around 2015 (and even then only an incomplete implementation), and only in 2019 decided to 'officially' support the latest C standards again. In general it makes a lot more sense today to start new C projects in more recent standard versions then it was 5..10 years ago.
- devnullbrain 3y ago
  Strong agree on all points. The gains from bumping e.g. a C++ version are much higher.
  - uecker 3y ago
    The cost of pumping a C++ version is also much higher. For C, you lose support for older compilers and minor platforms that haven't catched up, but if this isn't a problem, then only very minor (or no) modifications to the source should be required. Newer features can then be used gradually where it makes sense.

cmovq 3y ago

The original C++ proposal [1] discusses some alternative syntaxes, including underscores. Underscores would conflict with C++ user defined literals, for example in 0xAA_BB it is unclear whether _BB is a literal suffix for 0xAA since it’s a valid identifier. [1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3499.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n34...