svn commit: r268137 - head/sys/sys

[Pedro Giffuni]

On 06/21/15 11:48, Bruce Evans wrote:
> 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.
>

We have plenty of C++-style comments and C99 initializers in the tree.
We also use gcc constructor and destructor attributes. We can pretend
we are supporting a lot of stuff, including the intel C compiler, which
AFAICT was hacked to produce FreeBSD binaries but was never really
native, but the truth is 100% portability has never been there.
We just support what ever compiler was used to build FreeBSD at the time.

> 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 mean really old gnuisms. We accommodate just fine for gcc 4.x and
clang drew the line in gcc-4.2. Anything before that we should just
deprecate, Anything after that we can work out relatively easy.

>> 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).
>

I agree it would not be impossible to support older compilers and
leave space for bare standard ones, but perhaps it would be more
realistic to draw a line somewhere and have a list of supported
compilers.

And if some FreeBSD consumers need a specific compiler it would
be great to have them involved in the project.

Pedro.