Hacker News Reader

Comment by mananaysiempre | Hacker News Reader

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.

View on HN

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/n34...

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.

Yeah, literal int representation in source is one thing, changing int parsing string methods is something else and probably should require explicit inclusion.

How did this cause problems for you?

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.

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?

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.

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.

Strong agree on all points. The gains from bumping e.g. a C++ version are much higher.

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.

Reply on news.ycombinator.com