From: Keith.S.Thompson+u@gmail.com
Tim Rentsch writes:
> antispam@fricas.org (Waldek Hebisch) writes:
>> Tim Rentsch wrote:
>>> James Kuyper writes:
[...]
>>>> Note: in C2023, the [predefined macro names] section says: "Any other
>>>> predefined macro names: shall begin with a leading underscore
>>>> followed by an uppercase letter; or, a second underscore...". For
>>>> earlier versions of the standard, user code should avoid using such
>>>> identifiers because they were reserved for all purposes, but that's no
>>>> longer the case. Now, they should be avoided because they may be
>>>> pre-defined by the implementation, which means that any attempt to use
>>>> them might have unpredictable results.
>>>
>>> That's right in the sense that if the implementation is unknown then
>>> unexpected results may occur. However, if the implementation is
>>> known, then we can find out what results are expected by consulting
>>> the implementation's documentation for extensions, since any such
>>> macro name must qualify as an extension, and so much be documented.
>>
>> Hmm, looking at '/usr/include/string.h' on my machine I see definitions
>> of things like
>>
>> __GLIBC_INTERNAL_STARTING_HEADER_IMPLEMENTATION
>> __need_size_t
>>
>> and lot of similar things. I do not recall seeing any user
>> documentation listing them. Does this mean that gcc+glibc
>> is noncompilant in this aspect?
>
> I think it's reasonable to say that the appearance of a macro
> name being #define'd in a standard header qualifies as
> documenting the name being #define'd.
I disagree. I don't think it's reasonable to say that.
Headers are not documentation. They're often barely human-readable,
and the system headers aren't necessarily even files.
> As long as the #define is
> readable in an ordinary source file, there isn't any mystery
> about the name being used or what its definition is.
System headers can be arbitrarily complex, with #includes for other
system-specific headers, nests of #ifs and #ifdefs, and so on.
> I suppose
> that to satisfy the letter of the C standard, the accompanying
> document would need to incorporate the system header files by
> reference, but surely the header files satisfy the spirit of
> providing the required documentation. Implementation-defined
> values for things like CHAR_BIT and INT_MAX fall under the same
> rule for documentation as do extensions, yet as far as I know
> these values are defined only in system header files, and not in
> any separate document.
gcc's documentation does have a "C Implementation-Defined Behavior"
section. It doesn't mention CHAR_BIT by name, but it does document
"The number of bits in a byte" as "Determined by ABI". I didn't
find anything similar for INT_MAX.
I find it implausible that the standard intended to require
implementations to document all macros defined in standard headers,
for example _STDIO_H, the include guard macro for in glibc.
C17 says:
All identifiers that begin with an underscore and either an
uppercase letter or another under- score are always reserved for
any use, except those identifiers which are lexically identical
to keywords.
C23 dropped that wording. I'm not convinced that all the
implications of that change were resolved properly (but I haven't
studied it thoroughly).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
