Lua C standard, especially C90 versus C99...

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Lua C standard, especially C90 versus C99...

sur-behoffski
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].

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.

cheers,

sur-behoffski (Brenton Hoff)
Programmer, Grouse Software

[1] I acknowledge that some of the key users of Lua are on more
restricted platforms (e.g. microcontrollers), where the C99 support
(compilers and/or libraries) may be much more uneven.

Reply | Threaded
Open this post in threaded view
|

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

Adrian Perez de Castro
Hi there,

Quoting sur-behoffski (2016-09-09 04:04:12)

> [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.
My feeling is also that many C projects have been slowly moving to C99 in the
last few years — even the ones wanting so support obscure architectures or
eperating systems. My understanding is that one of the reasons for many of the
projects is that compilers and runtimes provided by Microsoft didn't support
C99 at all until recently.

Personally, I have been writing C99 for my personal projects for the last ~5
years and I haven't found any issues. Truth be told, they are Unix-only :-)
Compiler support in GCC and Clang has been complete and very stable for even
longer.

Cheers,

--
 ☛ Adrián

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

William Ahern
In reply to this post by sur-behoffski
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.


Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
> 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.

The C99 standard does not leave much room for new integer
representations, as it explicitly lists the allowed representations:
sign and magnitude, two's complement, and one's complement
(ISO/IEC 9899:1999 (E), 6.2.6.2: Integer types).

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

William Ahern
On Fri, Sep 09, 2016 at 05:03:17PM -0300, Roberto Ierusalimschy wrote:

> > 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.
>
> The C99 standard does not leave much room for new integer
> representations, as it explicitly lists the allowed representations:
> sign and magnitude, two's complement, and one's complement
> (ISO/IEC 9899:1999 (E), 6.2.6.2: Integer types).
>

I had in mind padding bits. I was thinking about a comment I stumbled across
several months ago related to signed integers. Now that I thought about it
more, it might have concerned a proposal to make signed overflow
implementation defined. That's not a representation issue. Or maybe it is if
it involves the state of padding bits and possible trap representations.

In my recollection the comment was made by a C or maybe C++ committee
member, but I can't find any such comment Googling the committees' websites
and documents for topics related to signed integers. And definitely no
mention of unums. Maybe it's just my imagination.