Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96867
Return-Path: <dclarke@blastwave.org>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 42084 invoked from network); 12 Nov 2016 20:35:41 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 12 Nov 2016 20:35:41 -0000
Authentication-Results: pb1.pair.com header.from=dclarke@blastwave.org; sender-id=unknown
Authentication-Results: pb1.pair.com smtp.mail=dclarke@blastwave.org; spf=permerror; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain blastwave.org from 209.17.115.110 cause and error)
X-PHP-List-Original-Sender: dclarke@blastwave.org
X-Host-Fingerprint: 209.17.115.110 atl4mhob17.myregisteredsite.com  
Received: from [209.17.115.110] ([209.17.115.110:52144] helo=atl4mhob17.myregisteredsite.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 0F/D1-31581-C1D77285 for <internals@lists.php.net>; Sat, 12 Nov 2016 15:35:41 -0500
Received: from mailpod.hostingplatform.com ([10.30.77.35])
	by atl4mhob17.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id uACKZYB6040454
	for <internals@lists.php.net>; Sat, 12 Nov 2016 15:35:34 -0500
Received: (qmail 27334 invoked by uid 0); 12 Nov 2016 20:35:34 -0000
X-TCPREMOTEIP: 99.253.103.29
X-Authenticated-UID: dclarke@blastwave.org
Received: from unknown (HELO ?172.16.35.41?) (dclarke@blastwave.org@99.253.103.29)
  by 0 with ESMTPA; 12 Nov 2016 20:35:34 -0000
To: internals@lists.php.net
References: <d04510ff-0624-c3a4-f53b-9cfe9027dee3@fleshgrinder.com>
 <CAF+90c-aJL94r4b7S7oKQw3AWbPBO+V_Lctv2JZpHvXnL9c4=Q@mail.gmail.com>
 <0ca001d23d21$e033ec40$a09bc4c0$@belski.net>
Message-ID: <f882884b-e5c3-0d0e-65b8-eea7ed743211@blastwave.org>
Date: Sat, 12 Nov 2016 15:35:33 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <0ca001d23d21$e033ec40$a09bc4c0$@belski.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] C89 vs. C99
From: dclarke@blastwave.org (Dennis Clarke)

<snip>
>
> IMHO, if we decide to move to C99, we should do it the strict way

At risk of sounding bitter there really is no other way other than
"compliant" or "non-compliant" with very little grey area.

> unlike we do now with C89. VC++ enables C99 the way it can't be
 > turned off, but some parts are still missing.

This is the case with gcc also.

see https://gcc.gnu.org/c99status.html

However one can attempt to use -std=iso9899:1999 with -pedantic-errors
as well but you need to know that assumptions are being made for " a
recent version of the GNU C Library" being in use. This is a poor
assumption.

This may explain why I still prefer to use the obscenely strict and
compliant Oracle Studio compilers on a Solaris system where the level
of SUSv3 and POSIX rules are assured.

 > In case of GCC and other compilers, the -std=c99 should be enforced.

Along with -D_POSIX_PTHREAD_SEMANTICS and -D_XOPEN_SOURCE=600 where with
a very crisp c99 compiler. Most of these tools exist no where but on a
classic UNIX commercial grade implementation. Sadly.

Dennis Clarke