public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
To: newlib@sourceware.org
Subject: Re: Issue: headers may use non-reserved identifiers
Date: Wed, 20 Apr 2022 22:56:46 -0600	[thread overview]
Message-ID: <43656224-9f4e-1443-df56-a7611468eea5@SystematicSw.ab.ca> (raw)
In-Reply-To: <bcafbce6-3de0-c87f-1d18-fde5a9c8f0ea@Damon-Family.org>

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

      reply	other threads:[~2022-04-21  4:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20 20:35 Pavel M
     [not found] ` <BN2P110MB1544D7B44A9377983D6ADC2C9AF59@BN2P110MB1544.NAMP110.PROD.OUTLOOK.COM>
2022-04-20 22:11   ` Fw: " C Howland
2022-04-21  2:48     ` Richard Damon
2022-04-21  4:56       ` Brian Inglis [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43656224-9f4e-1443-df56-a7611468eea5@SystematicSw.ab.ca \
    --to=brian.inglis@systematicsw.ab.ca \
    --cc=newlib@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).