Issue: headers may use non-reserved identifiers

[Brian Inglis]

On 2022-04-20 20:48, Richard Damon wrote:
> On 4/20/22 6:11 PM, C Howland wrote:
>> On Wednesday, April 20, 2022 4:35 PM, Pavel Morozkin wrote:
>>> Issue: headers may use non-reserved identifiers.
>>> Example:
>>> #define _reent 0
>>> #include <stdio.h>
>>> $ gcc t567.c -std=c11
>>> t567.c:1:16: error: expected ‘{’ before numeric constant
>>>      1 | #define _reent 0
>>>        |                ^
>>> t567.c:1:16: error: expected ‘{’ before numeric constant
>>>      1 | #define _reent 0
>>>        |                ^
>>> and so on...
>>> Per C11 _reent, _on_exit_args, etc. are non-reserved identifiers.
>>> Consider fixing.
>>> P.S. Good if it leads to compile time errors, not good if it
>>> doesn't (wrong translation unit produced => wrong code generated
>>> => wrong runtime behavior).
>> No, the headers do not use non-reserved identifiers. Look at the 
>> standard
>> again, as the second dash item in section 7.1.3 Reserved Identifiers
>> reserves all identifiers that start with underscore.  The example program
>> violates the standard.  In short, user programs may not use identifiers
>> that start with underscore.  (More precisely there are some very-limited
>> cases in which they can, but preprocessor identifiers is not one of 
>> them.)
> 
> Slight correction, identifies that begin with an underscore and followed 
> by a lowercase letter or a number are reserved only at 'file scope' 
> level, so user programs CAN use them as local variable names inside some 
> scope (at least those that don't match the previous cluase of an 
> underscore followed by an uppercase letter or another underscore as 
> those are reserved in all conditions).
> 
> Now, in the example, the user program used it for a preprocessor symbol 
> which conflicts with the reservation for that identifier for the 
> implementations use.

C202X WD (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2731.pdf) 
7.1.3 expands and simplifies it somewhat to all identifiers defined and 
all *potentially* reserved (including future library directions - see 
7.31) provided by the implementation are reserved for any use, but not 
if not provided, with conditions on header inclusion, namespace, and scope.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]