> Doesn't C99 compiler produce the same machine code for ANSI C source code?
Only if a C99 compiler is available. As the post points out:
> The slowest of the “big compilers” to adopt C99 was the Microsoft Visual C++ compiler, which did not adopt it properly until 2015 and added more compliance in 2019. A large number of our users/developers are still stuck on older MSVC versions so not even all users of this compiler suite can build C99 programs even today, in late 2022.
And that's just the "big compilers" supporting the "big platforms". If you're shipping some bespoke embedded platform where the toolchain/OS integration was custom work, you might very well never upgrade the compiler and just pick a new one when you're forced to define a new platform due to the hardware going EOL.
I'm mixed on this personally, on one hand... I get it. Having curl on the XYZ micro controller you're using for a project is good. At the same time the only reason MSVC added c99 support was community pressure because major projects said "we don't care about MSVC anymore we're moving on"[1]. So clearly there is a correlation between vendors and versions. If the vendors don't feel pressure to support newer versions then they'll just continue to ship the garbage they've been shipping for years. I personally don't have a good answer for this. Daniel very clearly has made his decision and I'll respect that as it's not my project.
[1] Also because the C++ committee ignored Herb and just forced it into later C++ revs from a library perspective.
Only if a C99 compiler is available. As the post points out:
> The slowest of the “big compilers” to adopt C99 was the Microsoft Visual C++ compiler, which did not adopt it properly until 2015 and added more compliance in 2019. A large number of our users/developers are still stuck on older MSVC versions so not even all users of this compiler suite can build C99 programs even today, in late 2022.
(emphasis mine)