Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: [ On topic, amazingtly ]: labels and declarations Date: Sat, 23 Mar 2019 13:36:13 -0700 Organization: A noiseless patient Spider Lines: 52 Message-ID: <8636ndnxaa.fsf@mailhub.linuxsc.com> References: <8gAjE.142392$tK1.4950@fx28.am4> <7164203b-a47f-4120-a6d0-c3a6b659a738@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="bc700592370338fe101a639d6651fadd"; logging-data="8519"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18PBshJOkgPbMJhDR3NB0ePS1L/hGYx6OA=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:upuZMYV0tCxUNmiRYmnz6u1j5ZA= sha1:pLOiy+SxKuIHt/XP4zPQOSyOoFk= Xref: csiph.com comp.lang.c:142313 Manfred writes: > On 3/22/2019 7:31 PM, Keith Thompson wrote: > >> Manfred writes: >> [...] >> >>> The standard allows for some optional features, enabled by preprocessor >>> definitions. This implies that functionality provided by the standard >>> library can be made optional, but features of the language itself cannot. >>> So, for this case, the semantics of a C label, this would not work. >> >> [...] >> >> No, language features can be and are made optional. In C11, complex >> numbers, atomic types, complex types, and VLAs, among other things, >> are optional, and each has a corresponding predefined macro that >> indicates whether the implementation supports it. See C11/N1570 >> 6.10.8.3. > > That's not what I meant: the macros you refer to are defined by the > implementation to indicate whether the implementation supports such > language features. They are not meant for the programmer to #define or > #undef to switch such features on/off. > > Instead, when I wrote the post I had in mind macros like > _USE_MATH_DEFINES that enables #define's of stuff like M_PI, but later > I realized that this is not part of the ISO standard, so I was > probably wrong with the part of the standard allowing for such > customization via preprocessor definitions (selectable by the > programmer, not the implementation). ISO C does have a standard mechanism whereby programs can direct an implementation to alter the source language in some way, and which could be used to cause preprocessor changes like #define'ing M_PI, or other things. The mechanism is #pragma. In current C there are, IIRC, only three standardized #pragma's (those being CX_LIMITED_RANGE, FENV_ACCESS, and FP_CONTRACT, all under #pragma STDC), but others could be added to control code behavior semantics, what symbols are defined by which standard header files, or even what source language constructs are allowed. So an option to allow labels on declarations could be provided, as for example #pragma STDC DECLARATIONS_MAY_HAVE_LABELS ON which would fit easily into the existing ISO standard. Of course, implementing such things might be a nightmare, but there is an "ISO C normal" way of specifying them. (Please note that I am not suggesting that this /should/ be done, only that it /could/ be done.)