Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #167355 > unrolled thread

invalid universal character gives error even after #if 0

Back to article view | Back to comp.lang.c

Contents

  invalid universal character gives error even after #if 0 Philipp Klaus Krause <pkk@spth.de> - 2022-08-31 08:28 +0200
    Re: invalid universal character gives error even after #if 0 Kaz Kylheku <480-992-1380@kylheku.com> - 2022-08-31 06:52 +0000
      Re: invalid universal character gives error even after #if 0 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 07:52 -0700
    Re: invalid universal character gives error even after #if 0 Siri Cruise <chine.bleu@yahoo.com> - 2022-08-31 02:13 -0700
      Re: invalid universal character gives error even after #if 0 Kaz Kylheku <480-992-1380@kylheku.com> - 2022-08-31 16:51 +0000
        Re: invalid universal character gives error even after #if 0 Siri Cruise <chine.bleu@yahoo.com> - 2022-08-31 10:57 -0700
    Re: invalid universal character gives error even after #if 0 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 07:54 -0700

#167355 — invalid universal character gives error even after #if 0

I noticed that current gcc and clang give an error on the following:

#if 0
\u003a
#endif

but not on

/*
\u003a
*/

While I see that \u003a is a constraint violation, I do not see how it 
follows from the standard that this is a constraint violation even 
inside #if 0.

By a quick look at the standard it seems to me that the constraint on 
universal character names would be treated the same as e.g. the 
constraint on constants having a type and the value being in the 
representable range. But I don't think anyone would expect an error on a 
long sequence of digits inside an #if 0.

[toc] | [next] | [standalone]

#167356

On 2022-08-31, Philipp Klaus Krause <pkk@spth.de> wrote:
> I noticed that current gcc and clang give an error on the following:
>
> #if 0
> \u003a
> #endif
>
> but not on
>
> /*
> \u003a
> */
>
> While I see that \u003a is a constraint violation, I do not see how it 
> follows from the standard that this is a constraint violation even 
> inside #if 0.

#if 0 isn't a commenting mechanism. The material excluded by #if 0
has to consist of valid preprocessor tokens, so any token-level
constraint violations apply. E.g. you can't have an unterminated
literal in there:

#if 0
"unterminated
#endif

A universal characcter name is a constituent of an identifier,
and an identifier is a kind of preprocessing-token (in the
early translation stages) which later becomes a token.

> By a quick look at the standard it seems to me that the constraint on 
> universal character names would be treated the same as e.g. the 
> constraint on constants having a type and the value being in the 
> representable range. But I don't think anyone would expect an error on a 
> long sequence of digits inside an #if 0.

Inside an #if 0, a sequence of digits is a pp-number. This is a special
category. It doesn't have any constraints on its number of digits and
such. C99 said that "A preprocessing number does not have type or a
value; it acquires both after a successful conversion (as part of
translation phase 7) to a floating constant token or an integer constant
token."

The situation is different with identifiers. The identifier grammar
symbol is shared by preprocessor-token and token. So any constraints
that apply to some constituent of an identifier apply whether
it is part of an identifier that is either preprocesor-token or a token.

When it comes to numbers, the preprocessor-token category has the
pp-number, and token has the constant. Only when a pp-number becomes
a constant is there are problem with the range of its content.

Or something like that.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

[toc] | [prev] | [next] | [standalone]

#167673

Kaz Kylheku <480-992-1380@kylheku.com> writes:

> On 2022-08-31, Philipp Klaus Krause <pkk@spth.de> wrote:
>
>> I noticed that current gcc and clang give an error on the following:
>>
>> #if 0
>> \u003a
>> #endif
>>
>> but not on
>>
>> /*
>> \u003a
>> */
>>
>> While I see that \u003a is a constraint violation, I do not see how it
>> follows from the standard that this is a constraint violation even
>> inside #if 0.
>
> #if 0 isn't a commenting mechanism.  The material excluded by #if 0
> has to consist of valid preprocessor tokens, so any token-level
> constraint violations apply.  E.g. you can't have an unterminated
> literal in there:
>
> #if 0
> "unterminated
> #endif
>
> A universal characcter name is a constituent of an identifier,
> and an identifier is a kind of preprocessing-token (in the
> early translation stages) which later becomes a token.

A universal character name _may_ be a constituent of an
identifier, but it doesn't have to be.  Since the universal
character name \u003a does not fall into one of the ranges
specified in Annex D.1, it is not allowed in an identifier and
therefore is not part of an identifier.  Hence it must be treated
by the preprocessor on a character-by-character basis, which
means the leading \ is a "non-white-space character that cannot
be one of the above".

Note also that n3047 adds the case

    each universal-character-name that cannot be one of the above

to 6.4 p1 under preprocessing-token, which strengthens the
argument.

[toc] | [prev] | [next] | [standalone]

#167361

In article <temv38$kie6$1@solani.org>,
 Philipp Klaus Krause <pkk@spth.de> wrote:

> By a quick look at the standard it seems to me that the constraint on 
> universal character names would be treated the same as e.g. the 
> constraint on constants having a type and the value being in the 
> representable range. But I don't think anyone would expect an error on a 
> long sequence of digits inside an #if 0.

Doctor! Doctor! It hurts when I do this.

Then stop doing it.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.    @
'I desire mercy, not sacrifice.'                                    /|\
Discordia: not just a religion but also a parody. This post         / \
I am an Andrea Chen sockpuppet.                  insults Islam.  Mohammed

[toc] | [prev] | [next] | [standalone]

#167388

On 2022-08-31, Siri Cruise <chine.bleu@yahoo.com> wrote:
> In article <temv38$kie6$1@solani.org>,
>  Philipp Klaus Krause <pkk@spth.de> wrote:
>
>> By a quick look at the standard it seems to me that the constraint on 
>> universal character names would be treated the same as e.g. the 
>> constraint on constants having a type and the value being in the 
>> representable range. But I don't think anyone would expect an error on a 
>> long sequence of digits inside an #if 0.
>
> Doctor! Doctor! It hurts when I do this.
>
> Then stop doing it.

Indeed.

I believe that universal characters in identifiers are akin to ANSI
trigraphs. You're not supposed to code with them.

If you're using internationalzed identifiers, use UTF-8
and a compiler which handles that:

  int 倍(int 引)
  {
     return 引 * 2;
  }

What universal character names allow you to do is encode the above
UTF-8 program into 7 bit ASCII. Just like trigraphs allow a 7 bit
ASCII program to be encoded into 6 bit ISO-646.

If you're doing this automatic encoding, you would never generate
a bad universal character name.

It would hurt when you do that, so you would fix your encoder
not to do it.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

[toc] | [prev] | [next] | [standalone]

#167394

In article <20220831094050.208@kylheku.com>,
 Kaz Kylheku <480-992-1380@kylheku.com> wrote:

> I believe that universal characters in identifiers are akin to ANSI
> trigraphs. You're not supposed to code with them.
> 
> If you're using internationalzed identifiers, use UTF-8
> and a compiler which handles that:

You can use something sed, tr, awk, etc, to transliterate 
nonascii characters into like _UUUUU, It pretty easy to encode/
decode unicode to strict ascii. I like the idea of using extended 
characters to make meaningful identifiers, and then you can 
preprocess to ascii without worrying about the compiler.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.    @
'I desire mercy, not sacrifice.'                                    /|¥
Discordia: not just a religion but also a parody. This post         / ¥
I am an Andrea Chen sockpuppet.                  insults Islam.  Mohammed

[toc] | [prev] | [next] | [standalone]

#167674

Philipp Klaus Krause <pkk@spth.de> writes:

> I noticed that current gcc and clang give an error on the following:
>
> #if 0
> \u003a
> #endif
>
> but not on
>
> /*
> \u003a
> */
>
> While I see that \u003a is a constraint violation, I do not see how it
> follows from the standard that this is a constraint violation even
> inside #if 0.

I believe this behavior is a misdiagnosis on the part of these
compilers.  Please see also my response to Kaz Kylheku in this
thread.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web