Re: Lua C standard, especially C90 versus C99...

[William Ahern <william@...>]

On Fri, Sep 09, 2016 at 11:34:12AM +0930, sur-behoffski wrote:
> G'day,
> 
> [Sorry for the non-threaded message; I read lua-l via the digest.]
> 
> Up until a few weeks ago, I tried to keep my code completely clean
> with the C90 standard enforced (all warnings forced to errors).
> 
> I am on the GNU Grep list, with crossovers into other GNU projects,
> especially gawk and glibc, and have noticed that they have decided
> (I'm not sure when) to move from C90 to C99 as their standards
> base, but are making the change slowly and evolving the code
> carefully.
> 
> Part of their rationale for this change appears to be that C99
> support is now sufficiently mature in all the mainstream
> environments to be trustworthy [1].

I think it was C11 that was the watershed moment, and it's C11 that is
seeing adoption, not C99.

Many vendors never bothered with C99 because it required implementing
variable length arrays (VLAs). VLAs in function declarators were especially
difficult, and even GCC's implementation was problematic for many years.
Most vendors had no desire to implement VLAs, effectively rejecting C99
compliance. That made it easier to ignore the rest of C99.

The same story unfolded with the _Complex type. Implementing _Complex was
non-trivial and most vendors rejected it. (C++ also ended up rejecting
_Complex and instead standardized on std::complex, intentionally designed to
avoid any need for direct compiler support.)

At the urging of almost everybody C11 made both VLAs and _Complex optional.
And while C11 added specifications for threading and atomics, they were also
made optional. C11 requires anonymous structures and unions, but this was
already a widely supported extension. (Visual Studio supports anonymous
unions, but I don't know if they support C11-compliant anonymous structures
in addition to their proprietary extension for anonymous structures.)

These changes made compliance with a modern C standard much more realistic,
and I think it's why we're seeing more momentum beyond GCC and clang. If an
updated standard is going to be adopted, C11 is arguably the better choice.

That said, there's a glaring flaw in my logic: _Generic. It's a mandatory
addition to C11 and non-trivial to implement. But _Generic or something like
it is necessary for implementing <tgmath.h>, so C99 compliance isn't easier
in that respect.

> This caused me to re-evaluate my C90 standard selection.  I've
> decided to start adopting C99, still writing C90-conformant code
> for 95+% of cases, but rely on C99 where there is a difference.
> 
> The main reason for this is better IEEE 754-1985 floating-point
> support.  While I'm not that flash on maths, I have enough snippets
> of knowledge to respect the numerical-methods expertise of others
> in this area, such that I believe that the change is worthwhile.

There's a small but quickly growing movement around a new floating point
format, Unums.

  https://en.wikipedia.org/wiki/Unum_(number_format)
  https://amazon.com/End-Error-Computing-Chapman-Computational/dp/1482239868

This is one reason why (IIRC) the C working group recently rejected making
IEEE floating point mandatory. And it's also why they're still reticient to
more strictly define integer representations and arithmetic behavior--you
never know what advancements might come around the corner.