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.
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
