svn commit: r268137 - head/sys/sys

[Bruce Evans]

On Sun, 21 Jun 2015, Pedro Giffuni wrote:

> On 06/21/15 10:41, Bruce Evans wrote:
>> On Sun, 21 Jun 2015, Pedro Giffuni wrote:
>> 
>>> On 06/21/15 01:09, Bruce Evans wrote:
>>>> On Sat, 20 Jun 2015, Pedro Giffuni wrote:
>>> * ...
>>>>> With the patch we would use:
>>>>> 
>>>>> __Noreturn void
>>>>>   foo(void) _dead2;
>>>>> 
>>>>> Which is still ugly but C11-ish.
>>>> 
>>>> That asks for the same problems as defining __weak.
>>>> 
>>>> Why not just don't use _Noreturn?  It is an unimprovement on the gcc
>>>> attribute.  The attribute works at the beginning or end, while Noreturn
>>>> only works at the end.
>>> 
>>> As I see it, newer (C11) software is likely to use _Noreturn in their
>>> headers
>> 
>> We can define _Noreturn to support this (but possibly shouldn't).
>> 
>> The newer software many be pure C11.  Then it doesn't need any definition,
>> and just doesn't compile with non-C11 compilers.
>
> Well, the fact this we just do this in the tree and no one has bothered to
> "clean" the situation for older compilers just indicates that no one *cares*
> about older compilers.

No, we don't do this with older compilers, except for for a couple of
pre-C90 cases.  We are careful to only define names in our namespace,
e.g., __signed but not the C90 keyword 'signed'.  This is still fragile.
__signed is a keyword for gcc, and it is confusing that some of our use
of it require it to have the gcc meaning.  __signed is in the implementation
namespace so we don't own it completely.  This is what is now causing problems
with defining __weak.

The situation with older compilers has not been cleaned because it either
works or is not used.  Since it did work with older compilers when it was
written, the only way it can not still work is because of "cleaning" it
combined with null testing and null use so that bugs in the "cleaning"
are not detected.

>> If we defined _Noreturn, it would be to use it in non-C11 software, like
>> we do in stdlib.h.  This is a fragile compatibility hack so it should
>> be avoided if possible.  We can easily avoid it in our own headers by
>> not changing anything.  Just use the old declaration, with __dead2 placed
>> at the end.  Any reasonable implementation of __attribute__() must be able
>> to support any new attribute that a new standard might add.
>
> The thing is, why bother with gnuisms at all?

There is no other way to declare necessary attributes that __attribute__(()).
Not even __attribute__() like I wrote above -- that is just a syntax error
since it is missing parentheses.  __attribute__(()) is now a de-facto
standard for gnuish compilers, but it is not in any C standard and has
little chance of working with Microsoft compilers.  It must be wrapped
in a #define like we do.

> I am personally OK with making it easier for everyone to use more
> modern constructs but I am not going out of my way to support
> gcc-1 or gcc-2.

>From there, it is only a small step to not supporting any compiler
except the current version of gcc (not even clang).

Bruce