Re: gcc 4.3: when will it become standard compiler?

Roman Divacky schrieb:
> On Fri, Jan 09, 2009 at 03:56:24PM +0100, Christoph Mallon wrote:
>> Roman Divacky schrieb:
>>> On Fri, Jan 09, 2009 at 03:28:20PM +0100, Christoph Mallon wrote:
>>>> Roman Divacky schrieb:
>>>>> On Fri, Jan 09, 2009 at 02:32:01PM +0100, Christoph Mallon wrote:
>>>>>> Roman Divacky schrieb:
>>>>>>>> I'm not saying it's wrong to look for alternatives, but you cannot 
>>>>>>>> just change your system compiler like you change underwear.
>>>>>>> well... the first step is imho starting to compile world with C99...
>>>>>>> that might reveal some bugs, note that as of a few months ago
>>>>>>> 8-current compiles cleanly with C99, that does not mean that it's
>>>>>>> working when you run those programs correctly :)
>>>>>> One step in the right direction is embracing the nice features modern C 
>>>>>> offers you. For example declaring a variable right were you need it 
>>>>>> instead of dozens of lines away is one such nice thing which improves 
>>>>>> readability. Designated initializers improve readability, too.
>>>>>> But I'm not exactly sure what you mean by "compile world with C99". C99 
>>>>>> is pretty much backwards compatible to C89.
>>>>> sorry for the bad wording - I meant to turn C99 compilation on default.
>>>>> We compile in gnu89 mode now.
>>>> I still have no idea what you mean. Sure, you can specify -std=c99 (or 
>>>> more likely gnu99), but an int is still an int - what do you expect? In 
>>>> fact default mode of GCC accepts many C99 constructs like // comments 
>>>> and mixed declarations and code, which are not valid C89.
>>> for example __restricted is C99 thing and there are others, I want this
>> __restrict (not __restricted) is a GCC extension. The C99 spelling is 
>> restrict. GCC also accepts __restrict__. Further, you should be *very* 
>> careful with the restrict qualifier, because its exact semantic is 
>> non-trivial (?6.7.3.1, it's one page of standardese speak).
>> But I see no problem for existing code in this respect. C99 mostly only 
>> adds new language constructs. Only very few were removed. E.g. implicit 
>> int was removed, but GCC still accepts it (and I guess clang too, 
>> cpareser does).
>  
> my point is that in C89 mode *restrict* (in whatever spelling) got expanded
> to nothing. we had a bug (typo in fact) related to *restrict* and we didnt
> catch it because of C89 compilation mode...

Ah, you mean a simple syntax error like char __restrict* a instead of 
char* __restrict a. I thought you meant something serious like different 
behaviour between the standards. Why somebody would #define away 
__restrict (or #define away any other extension, which GCC accepts 
anyway) is beyond me. If the source code already contains distinctions 
between C89 and C99 then, imo, somebody did something wrong.

> thats my point (and the *restrict* thing is just an example)
> 
>>> because clang for example defaults to C99 (in fact gnu99 as they support
>>> gnu extensions on default). By switching to default compilation in C99
>>> mode we can be sure we stay compatible with clang and others.... 
>> I'm pretty sure clang also accepts __restrict.
>> A compiler, which does not support most GCC extensions (inline assembler 
>> being the most important) has no chance anyway.
> 
> yes.... the problem is (was?) that clang is C99 on default while gcc is C89
> on default.
> 
>>> for example opensolaris seems to use C99 features which are not enabled
>>> in our world because of this (I found same assert() related stuff) etc.
>> assert() predates C99. The only C99 specific aspect about assert(), that 
>> I'm aware of, is, that C99 guarantees that the name of the function is 
>> printed.
> 
> they had code like 
> 
> <pseudocode>
> #if C99
> #define __assert(..) something
> #else
> #define __assert(..) something_else
> #endif
> </pseudocode>

This is probably, as mentioned above, because C89 does not have __func__.

> my point is that we might have bugs in the C99 code that other (non-gcc) compilers
> expose and it's a good thing to unite on one standard. ie. C99 :)

In general I agree: C99 should be used as language standard for 
compilation. style(9) needs some updates for this, too.