RE: [PHP-DEV] C89 vs. C99
| From: | Anatol Belski | Date: | Sun, 13 Nov 2016 19:20:02 +0000 |
| Subject: | RE: [PHP-DEV] C89 vs. C99 | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-96876@lists.php.net to get a copy of this message | ||
Hi,
> -----Original Message-----
> From: morrison.levi@gmail.com [mailto:morrison.levi@gmail.com] On Behalf
> Of Levi Morrison
> Sent: Saturday, November 12, 2016 9:47 PM
> To: Dennis Clarke <dclarke@blastwave.org>
> Cc: internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] C89 vs. C99
>
> On Sat, Nov 12, 2016 at 1:37 PM, Dennis Clarke <dclarke@blastwave.org>
> wrote:
> >
> >> IMHO, if we decide to move to C99, we should do it the strict way
> >
> >
> > I forgot to add that GNU GCC allows a lot of non-standard extensions
> > to slip right through. Unless some CFLAGS are set to warn or error on them.
> >
> >
> > https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/C-Extensions.html#C-Exten
> > sions
> >
> > Dennis
> >
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> > visit: http://www.php.net/unsub.php
>
> We are actually much closer to C99 than we are to C90. As proof of this try
> compiling with GCC with
-std=c90 -pedantic-errors and then try
> it with `-
> std=c99 -pedantic-errors`. You have to make significantly fewer changes to get
> the C99 version working (or at least this was the case when it was last brought
> up). Also, ISO C90 and ANSI (C89) are essentially the same thing in case anyone is
> not aware.
>
Even without that - we already use inline, datatypes and macros, other things that don't belong
to C89. We also use _declspec(thread) aka __thread which is not standardized at all. The GNU
extensions, or VS features, or any other compiler specifics, are same as before. What matters, is
the core C99 standard, or at least the part implemented in any known compiler, as some #ifdefs for
platform/compiler specific non C99 features will always exist. While at the start, it'll
probably be only to make the current source to rock with C99 compilers and to be able to use some
syntax/semantic sugar, later contributions indeed using any possible other C99 features will appear.
That's the point I actually wanted to make - moving to C99, we enable a set of new features not
available with the ANSI C, that we need to internalize and accept.
Regards
Anatol