[cfe-dev] Enabling strong enum extensions under C

[Richard Smith via cfe-dev]

On Fri, Feb 19, 2016 at 4:33 PM, Saleem Abdulrasool via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> On Fri, Feb 19, 2016 at 1:17 PM, Martin J. O'Riordan via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
>>
>> I have the same kind of dilemma - I really like having a "strictly
>> conforming" option because I love Standards, but realistically I need them
>> to be supplemented by a relaxed mode that permits extensions.
>>
>> What I think would be the right thing for Clang, would be for '-std=XXX'
>> to enforce the ISO definition of XXX, but to be able to supplement it with
>> an additional option or options that enabled the extensions or relaxed the
>> ISO rules (warnings of divergence are still good).  Normally when I use
>> '-std=XXX', I also find I have to use at least ' -U__STRICT_ANSI__' because
>> the extended or non-Standard behaviour is what I often want; and sometimes
>> other additional options.  But having '-std=XXX' mean exactly the ISO
>> definition is really useful, and cool.
>>
>> Ironically, having '-std=XXX' be really strict about ISO compliance is
>> almost certainly the wrong thing for my code; for example it means enabling
>> exceptions which are simply too expensive for embedded; but I would still
>> like to tell the compiler to enforce strict ISO conformance rules - unless I
>> have supplemented it with options to relax particular constraints.
>> Sometimes we use '-std=XXX' to select a dialect (e.g. C++11 versus C++14),
>> but then have to supplement it by a bunch of other options that tune it to
>> our actual non-Standard needs.  But I still need warnings and error
>> messages, they tell me where I need to be very specific about what and why I
>> am doing something that strays outside the ISO interpretation.
>>
>> An alternative would to be to add something like '-fstrict-iso' to make
>> '-std=XXX' be strict, but my own feeling is that strict should be the
>> default, and relaxed should be the deliberately selected alternative.
>
>
> It seems that there is some interest in keeping the default be standards
> conforming.  It would be nice to get a consensus on this issue so that we
> can move forward.

I would be very happy with us adding -fgnu-compatibility, and making
-std=gnuX be a synonym for -std=cX -fgnu-compatibility. This would
just cover the non-conforming GNU extensions (in particular, the GNU
keywords), in the same way that -fms-compatibility covers only the
non-conforming MS behavior.

That would leave us with a collection of GNU extensions (and Clang
extensions and Embarcadero extensions and probably others) that are
enabled with no explicit opt-out flag (such as __attribute__, folding
of non-constant array bounds). Some of the GNU extensions are at this
point Clang extensions as well (we have our own __attribute__s that
use GNU syntax), some of them are essential for the correct
functioning of system headers or for the compilation of widespread
code patterns, and some of them are things we could reasonably hide
behind a "GNU extensions" flag (etc). Unpicking the differences seems
like a significant challenge -- there's no point adding a flag for
these things that causes (in practice) all non-trivial compilations to
fail -- and we already have -pedantic-errors for cases where there is
a desire for errors on code that uses such an extension (we may miss
some extension diagnostics today; those are easy bugs to fix). I think
what we need here is for someone to come up with a proposal for a good
end state here.

There's a separate question of what the default -std= value should be,
for each language. Right now, we use -std=gnu11 for C and -std=gnu++98
for C++, although we should aim to bump the latter to -std=gnu++14 for
Clang 3.9. Changing these from -std=gnuX to -std=cX seems likely to
break a fair amount of real code, so we should be cautious about that.

>>         MartinO
>>
>> -----Original Message-----
>> From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Joerg
>> Sonnenberger via cfe-dev
>> Sent: 19 February 2016 15:20
>> To: cfe-dev at lists.llvm.org
>> Subject: Re: [cfe-dev] Enabling strong enum extensions under C
>>
>> On Tue, Feb 16, 2016 at 09:46:27AM -0500, Nico Weber via cfe-dev wrote:
>> > Personally, I'd like if -std=c11 would give you C11 without extensions.
>>
>> Speaking with OS developer hat, it is not practical to disable all
>> extensions like the protected versions of keywords or attributes.
>>
>> Joerg
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>