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

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

Re: Unicode in C Sources

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Unicode in C Sources Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-19 12:30 -0800
    Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-19 14:19 -0800
      Re: Unicode in C Sources Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:50 -0700
        Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-02 08:16 -0700

#150085 — Re: Unicode in C Sources

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> No, it seems clear to me that "extended identifier" refers to
> identifiers containing members of the extended character set - NOT
> UCNs.

That is highly unlikely.  Extended characters in identifiers are not
required in any implementation, and what's more, implementations
have always been allowed to use extended characters in identifiers,
because in C89/C90 any character (outside of a string constant, etc)
not in the basic character set implies undefined behavior.  There is
no point in calling something out as an addition if nothing has been
added.  What C99 added, with the syntax for identifiers requiring
UCNs to be supported, is a way of using characters outside the basic
character set in a way that is /guaranteed to be portable/.  It is
thus much more likely that the phrase "extended identifiers" used in
the Standard refers to UCNs in idenfiers, not extended characters.

[toc] | [next] | [standalone]

#150086

In C90, the set of extended characters was implementation-defined, both
in the source and execution character sets. They therefore could not be 
used by code that needs to be maximally portable,  but not all code
needs to be that portable.
However, the only places where the syntax allowed for extended
characters was character constants, string literals, and header names.

C99 changed that, by also allowing an implementation-defined set of
extended characters to appear in identifiers. Of course,  maximally
portable code cannot take advantage of that fact, but as I said above,
not all code needs to be that portable.

It seems quite reasonable to me to, in a short summary of the changes
from C90, refer to that change using the phrase "extended
identifiers". It also seems reasonable to me to assume that that phrase
refers to that change. It might also refer to the change you refer to,
though that seems unlikely to me. I consider it even less likely that
it refers only to the change that you mentioned. The term "extended"
plays a key role in the text that's relevant to the change I was
talking about, it plays no such role in the text describing the change
that you're talking about. 

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

#150953

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> In C90, the set of extended characters was implementation-defined, both
> in the source and execution character sets.  They therefore could not be
> used by code that needs to be maximally portable,  but not all code
> needs to be that portable.
> However, the only places where the syntax allowed for extended
> characters was character constants, string literals, and header names.
>
> C99 changed that, by also allowing an implementation-defined set of
> extended characters to appear in identifiers.  Of course,  maximally
> portable code cannot take advantage of that fact, but as I said above,
> not all code needs to be that portable.
>
> It seems quite reasonable to me to, in a short summary of the changes
> from C90, refer to that change using the phrase "extended
> identifiers".  It also seems reasonable to me to assume that that phrase
> refers to that change.  It might also refer to the change you refer to,
> though that seems unlikely to me.  I consider it even less likely that
> it refers only to the change that you mentioned.  The term "extended"
> plays a key role in the text that's relevant to the change I was
> talking about, it plays no such role in the text describing the change
> that you're talking about.

Is there some reason you didn't quote the remark you're
responding to?

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

#150957

On Thursday, April 2, 2020 at 10:50:42 AM UTC-4, Tim Rentsch wrote:
...
> Is there some reason you didn't quote the remark you're
> responding to?

Yes, and it's nothing nefarious. I was posting that using Google Groups
from FireFox on my Android smart phone. It's difficult enough even to
type a long message under those circumstances, and a big hassle to
incorporate quotes from the message I was responding to. If I'd known in
advance that you weren't going to bother responding for five weeks, I
would have waited until I got home so I could use my desktop machine.

[toc] | [prev] | [standalone]

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

csiph-web