[cfe-dev] Enabling strong enum extensions under C

[Saleem Abdulrasool via cfe-dev]

On Tue, Feb 23, 2016 at 6:42 PM, Richard Smith <richard at metafoo.co.uk>
wrote:

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

This sounds like a great idea to me.


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

I think that another option is having an option that is enabled by default
to enable these extensions to permit users to force a strict compilation
mode.

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.


Sure, but I don't think that the changes being discussed here really impact
our choice of defaults outside of what the mapping of flags would be.


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



-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160226/d102f575/attachment.html>