[cfe-dev] [libcxx] Policy with respect to language extensions

Hal Finkel via cfe-dev cfe-dev at lists.llvm.org
Wed Aug 12 18:04:59 PDT 2015


----- Original Message -----
> From: "Hal Finkel via cfe-dev" <cfe-dev at lists.llvm.org>
> To: "Richard Smith" <richard at metafoo.co.uk>
> Cc: "Marshall Clow" <mclow.lists at gmail.com>, "Gonzalo BG" <gonzalobg88 at gmail.com>, "clang developer list"
> <cfe-dev at lists.llvm.org>
> Sent: Wednesday, August 12, 2015 7:23:30 PM
> Subject: Re: [cfe-dev] [libcxx] Policy with respect to language extensions
> 
> ----- Original Message -----
> > From: "Richard Smith" <richard at metafoo.co.uk>
> > To: "Hal Finkel" <hfinkel at anl.gov>
> > Cc: "Marshall Clow" <mclow.lists at gmail.com>, "clang developer list"
> > <cfe-dev at lists.llvm.org>, "Gonzalo BG"
> > <gonzalobg88 at gmail.com>, "David Majnemer"
> > <david.majnemer at gmail.com>
> > Sent: Wednesday, August 12, 2015 7:09:22 PM
> > Subject: Re: [cfe-dev] [libcxx] Policy with respect to language
> > extensions
> >  
> > On Wed, Aug 12, 2015 at 4:01 PM, Hal Finkel < hfinkel at anl.gov >
> > wrote:
> >  
> > ----- Original Message -----
> > > From: "Marshall Clow" < mclow.lists at gmail.com >
> > > To: "David Majnemer" < david.majnemer at gmail.com >
> > > Cc: "Richard Smith" < richard at metafoo.co.uk >, "clang developer
> > > list" < cfe-dev at lists.llvm.org >, "Gonzalo BG"
> > > < gonzalobg88 at gmail.com >
> > > Sent: Wednesday, August 12, 2015 5:05:05 PM
> > > Subject: Re: [cfe-dev] [libcxx] Policy with respect to language
> > > extensions
> > > 
> > > On Wed, Aug 12, 2015 at 11:32 AM, David Majnemer <
> > > david.majnemer at gmail.com > wrote:
> > > 
> > > 
> > > On Wed, Aug 12, 2015 at 2:05 PM, Richard Smith <
> > > richard at metafoo.co.uk > wrote:
> > > 
> > > 
> > > 
> > > I think it would also be useful to have a "strictly conforming"
> > > (or
> > > as close as we can reasonably get) mode, controlled by a macro.
> > > 
> > > 
> > > Wouldn't we have to be extra careful or we could get ODR
> > > violations
> > > across object/shared object boundaries if one wanted extra
> > > conformance but another did not?
> > > 
> > > Yes.
> > > 
> > > 
> > > -- Marshall
> > 
> > Having a macro to control this seems like a recipe for bad things
> > (ODR violation being only one problem).
> > 
> > 
> > 
> > What sort of actual bad things do you envisage? People will, of
> > course, be able to shoot themselves in the foot by having an
> > inconsistent definition in different translation units, but we
> > don't
> > necessarily need to support that. And it seems like we should be
> > able to avoid this having an ABI impact on sane code.

Also, a few questions:

 1. Are these all confirming extensions?

 2. Would this be an opt-in or opt-out macro?

Having thought about this for an additional few minutes, I think the relevant question is: Is there any sane code that would need to turn these things off in order to function properly? If not, then the header-file library issue won't arise in practice, and the macro is likely harmless. If so, it is not good. Regardless, I think being able to issue a warning would be better.

 -Hal

> 
> For these particular extensions, I can't say. However, I tend to find
> the general technique problematic. The issue generally arises for
> header-only libraries that define (or undefined) these kinds of
> macros, causing very odd interactions (because such things don't
> compose). Tracking down why including one library header breaks some
> other library header because of conflicting desires to define
> _XOPEN_SOURCE, _GNU_SOURCE, etc. is annoying. Doing the same for
> features of the C++ standard library that could affect uses of
> SFINAE, etc., I suspect, would be especially annoying.
> 
>  -Hal
> 
> > 
> > I think the best we can do at this point is have the compiler issue
> > a
> > warning in pedantic mode. Maybe we could add some kind of extension
> > attribute for this purpose (although we'd need to think carefully
> > about when to actually generate the warning - every time some
> > extension participates in some overload set might be problematic).
> > 
> > -Hal
> > 
> > 
> > 
> > > 
> > > _______________________________________________
> > > cfe-dev mailing list
> > > cfe-dev at lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> > > 
> > 
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
> > 
> > 
> 
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory



More information about the cfe-dev mailing list