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

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

Unicode in C Sources

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

Contents

  Unicode in C Sources F Russell <fr@random.info> - 2020-02-01 17:12 +0000
    Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-01 17:37 +0000
      Re: Unicode in C Sources Anton Shepelev <anton.txt@gmail.com> - 2020-02-01 20:43 +0300
        Re: Unicode in C Sources Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-02-01 10:57 -0800
          Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-02 16:58 +0100
            Re: Unicode in C Sources F Russell <fr@random.info> - 2020-02-02 17:05 +0000
              Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-02 19:52 +0100
                Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-02 19:20 +0000
              Re: Unicode in C Sources Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-03 12:38 +0000
                Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 09:16 -0500
                  Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-03 15:32 +0100
                    Re: Unicode in C Sources Öö Tiib <ootiib@hot.ee> - 2020-02-03 09:01 -0800
                    Re: Unicode in C Sources Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-03 21:15 +0000
                Re: Unicode in C Sources F Russell <fr@random.info> - 2020-02-04 02:06 +0000
                Re: Unicode in C Sources F Russell <fr@random.info> - 2020-02-04 02:19 +0000
                  Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-04 02:50 +0000
                  Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-04 08:16 +0100
      Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-01 18:10 +0000
        Re: Unicode in C Sources Richard Damon <Richard@Damon-Family.org> - 2020-02-01 15:19 -0500
          Re: Unicode in C Sources Manfred <invalid@add.invalid> - 2020-02-02 00:13 +0100
            Re: Unicode in C Sources Manfred <invalid@add.invalid> - 2020-02-02 00:46 +0100
              Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-02 00:24 +0000
            Re: Unicode in C Sources Richard Damon <Richard@Damon-Family.org> - 2020-02-02 08:14 -0500
              Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-02 17:59 +0100
                Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-02 14:44 -0500
                  Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-02 21:49 +0100
                    Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-02 16:58 -0500
                      Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-03 15:33 +0100
                        Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-03 15:38 +0100
                        Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 10:25 -0500
                          Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-03 19:11 +0100
                            Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 15:59 -0500
                              Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-04 16:51 +0100
                                Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-04 16:05 -0500
                                Re: Unicode in C Sources Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-19 12:17 -0800
        Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-02 17:09 +0100
          Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-02 14:46 -0500
            Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-02 21:39 +0100
              Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-02 17:07 -0500
                Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-03 13:12 +0100
                  Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-03 16:46 +0100
                  Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-03 16:47 +0000
                    Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 13:36 -0800
                      Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-03 23:56 +0100
                  Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 13:06 -0500
                    Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-03 22:25 +0100
                      Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 13:29 -0800
                        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
                      Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-03 22:33 +0000
                      Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 23:05 -0500
                      Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 23:10 -0500
                    Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-04 18:05 +0100
                      Re: Unicode in C Sources already5chosen@yahoo.com - 2020-02-04 09:38 -0800
                        Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-04 18:46 +0100
                      Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-04 16:07 -0500
              Re: Unicode in C Sources Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-02 14:54 -0800
        Re: Unicode in C Sources Siri Cruise <chine.bleu@yahoo.com> - 2020-02-03 15:10 -0800
    Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-03 07:47 +0100
      Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-03 14:00 +0100
        Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-03 16:45 +0100
          Re: Unicode in C Sources Guillaume <message@bottle.org> - 2020-02-03 17:54 +0100
          Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-03 22:36 +0100
            Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-04 16:33 +0100
              Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-04 16:45 +0100
                Re: Unicode in C Sources Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-04 13:02 -0800
                  Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-04 23:18 +0100
                    Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-05 11:07 +0100
                      Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-05 14:49 +0100
                        Re: Unicode in C Sources Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 06:23 -0800
                  Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-05 10:54 +0100
                Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-05 14:51 +0100
                  Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-05 14:03 +0000
                    Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-05 16:31 +0100
                      Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-05 15:59 +0000
                        Re: Unicode in C Sources scott@slp53.sl.home (Scott Lurndal) - 2020-02-05 16:02 +0000
                          Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-05 16:59 +0000
                            Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-05 18:02 +0000
                              Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-05 19:37 +0100
                              Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-05 19:37 +0100
                                Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-05 21:02 +0100
                                  Re: Unicode in C Sources Ian Collins <ian-news@hotmail.com> - 2020-02-06 10:34 +1300
                                  Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-05 23:10 +0000
                                    Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-06 13:53 +0100
                                      Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-06 13:26 +0000
                                  Re: Unicode in C Sources Richard Damon <Richard@Damon-Family.org> - 2020-02-06 07:27 -0500
                                Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-05 23:03 +0000
                                  Re: Unicode in C Sources Mikko Rauhala <mjr@iki.fi> - 2020-02-06 10:46 +0000
                              Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-05 21:47 +0100
                              Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-05 22:50 +0000
                            Re: Unicode in C Sources scott@slp53.sl.home (Scott Lurndal) - 2020-02-07 00:25 +0000
                              Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-07 02:07 +0000
                  Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-05 16:26 +0100
        Re: Unicode in C Sources antispam@math.uni.wroc.pl - 2020-04-18 03:58 +0000

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#149679

Le 03/02/2020 à 13:12, David Brown a écrit :
> It is when code is shared or re-used amongst a wider audience that
> problems will occur.  You'll get people who are annoyed because someone
> wrote π and they can't type it sensibly, or because they can't figure
> out which "beta" to use from βꞵ𝛽𝜷ß (yes, the last one is not actually
> a beta), or because capital beta Β looks a lot like B to the reader, but
> is completely different to the compiler.

That is the argument I was mentioning in my other message David.

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

#149683

On 03/02/2020 12:12, David Brown wrote:

> 
> It is when code is shared or re-used amongst a wider audience that
> problems will occur.  You'll get people who are annoyed because someone
> wrote π and they can't type it sensibly, or because they can't figure
> out which "beta" to use from βꞵ𝛽𝜷ß (yes, the last one is not actually
> a beta), or because capital beta Β looks a lot like B to the reader, but
> is completely different to the compiler.

On Windows 7 (and virtual Ubuntu under Windows 7), that second beta 
isn't shown properly.

On Android, none of those 3 middle betas is shown properly.

Only on Windows 10 do all 5 display correctly (or at least look like 
betas). (This is running Google Groups except Windows 7 where 
Thunderbird gives the same display.)

So this is yet another problem, varying levels of support for Unicode.

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

#149698

All five of those characters display on my Ubuntu desktop system, and only the second one fails to display properly on my Andoid phone. It's not just a matter of which OS you're using, it also depends upon how your system is configured.

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

#149700

On 03/02/2020 22:36, James Kuyper wrote:
> All five of those characters display on my Ubuntu desktop system, and
> only the second one fails to display properly on my Andoid phone.
> It's not just a matter of which OS you're using, it also depends upon
> how your system is configured.
> 

In particular, it depends on the fonts you have installed - and the 
fonts you have chosen (or left as default) for the application.  All of 
these characters are fine on my office machine (Linux Mint with Mate), 
but the second one is missing on my home machine (Linux Mint with 
Cinnamon).  I think it is just coincidence of the fonts used, which I 
have not bothered to change for Thunderbird.

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

#149689

On 2/3/20 7:12 AM, David Brown wrote:
> On 02/02/2020 23:07, James Kuyper wrote:
>> On 2/2/20 3:39 PM, David Brown wrote:
...
>>> Basically, you had to use \u1234 or \U12345678 syntax for your Unicode 
>>> letters in identifiers.  So if you wanted "const double π = 3.14;", 
>>> you'd have to write "const double \u03C0 = 3.14;".  That is with the 
>>> "-fextended-identifiers" on to enable the feature.
>>
>> That's not an example of "support for extended identifiers" - it doesn't
>> involve the use of a single extended character. That's simply of meeting
>> the standard's requirements for the handling of UCN's, while failing to
>> support extended characters in identifiers. I was expecting, from your
>> comment, something much more bizarre than that.
> 
> Now I'm confused.  This "π" identifier /is/ an example of an extended
> identifier.

No, on an implementation which supports it, 'π' is an extended
character, and an identifier containing it, such as "aππle" would be an
extended identifier. However, \u03C0 is an UCN, not an extended character.

Since C99, the C standard requires a conforming implementation to accept
UCNs, regardless of whether or not they support any extended characters.
In character constants and string literals, what it requires is quite
minimal - during translation phase 5, they are "converted to the
corresponding member of the execution character set; if there is no
corresponding member, it is converted to an implementation-defined
member other than the null (wide) character." (5.1.1.2p5). Note, in
particular, that a conforming implementation could convert all UCNs to
the same "implementation-defined member".

No such conversion is described for UCNs in identifiers. I believe that
implementations should treat extended characters in identifiers as
equivalent to the implementation-defined UCNs that those characters are
mapped to - but I'm having trouble locating the text in the standard
that says so.

For members of the extended character set, "An implementation may allow
multibyte characters that are not part of the basic source character set
to appear in identifiers; which characters and their correspondence to
universal character names is implementation-defined."  (6.4.2.1p3).
Note, in particular, that an implementation need not allow any character
that's not in the basic source character set.

>  My point is that gcc supports extended identifiers with
> Unicode characters in their names (following the rules in Annex D, which
> I believe allows π).

No, the rules in Annex D mandate support for \u03C0, which is a UCN, not
an extended character. They don't cover 'π', which (if supported) would
have to be an extended character, but is not a UCN. gcc is allowed to
decide whether 'π' is in its extended character set, and if it is in
that set, is permitted to choose which UCN it considers π equivalent to.
It would be crazy to consider it equivalent to anything other than
\u03C0, but being crazy in that sense wouldn't render an implementation
non-conforming.

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

#149695

On 03/02/2020 19:06, James Kuyper wrote:
> On 2/3/20 7:12 AM, David Brown wrote:
>> On 02/02/2020 23:07, James Kuyper wrote:
>>> On 2/2/20 3:39 PM, David Brown wrote:
> ...
>>>> Basically, you had to use \u1234 or \U12345678 syntax for your Unicode
>>>> letters in identifiers.  So if you wanted "const double π = 3.14;",
>>>> you'd have to write "const double \u03C0 = 3.14;".  That is with the
>>>> "-fextended-identifiers" on to enable the feature.
>>>
>>> That's not an example of "support for extended identifiers" - it doesn't
>>> involve the use of a single extended character. That's simply of meeting
>>> the standard's requirements for the handling of UCN's, while failing to
>>> support extended characters in identifiers. I was expecting, from your
>>> comment, something much more bizarre than that.
>>
>> Now I'm confused.  This "π" identifier /is/ an example of an extended
>> identifier.
> 
> No, on an implementation which supports it, 'π' is an extended
> character, and an identifier containing it, such as "aππle" would be an
> extended identifier. However, \u03C0 is an UCN, not an extended character.
> 

Yes, \u03C0 is a UCN - "Universal character name", described in 6.4.3

The term "extended identifier" is not actually defined in the standard, 
as far as I can see - the phrase "extended identifier" is only found in 
the list of major changes to C99.  But the section on identifiers, 
6.4.2.1, says that an identifier is made up of digits (except for the 
first character), non-digits (a-z, A-Z, _), universal character names, 
and other implementation-defined characters.

An "extended identifier" must, I think, mean an identifier which has a 
UCN or an identifier which has an additional implementation-defined 
character (which must map to UCN's).

Basically, \u and \U sequences are source code character set independent 
ways to write additional Unicode characters that can be used in 
identifiers.  They play a somewhat similar role to trigraphs, in that 
they let you have extended identifiers in the source code without 
needing to express the characters directly.

Or are you saying that "extended identifier" is only about UCN's in 
identifier names?

To me, this is about user convenience and compatibility.  UCN's in 
identifiers, on their own, is clearly a useless concept.  If you have to 
use them, they add nothing but obfuscation to the code - they only make 
sense in combination with editors or pre-processors that let you use 
Unicode characters.  They are a back-stop, to let you access extended 
identifiers even if you can't use an extended character set.


> Since C99, the C standard requires a conforming implementation to accept
> UCNs, regardless of whether or not they support any extended characters.
> In character constants and string literals, what it requires is quite
> minimal - during translation phase 5, they are "converted to the
> corresponding member of the execution character set; if there is no
> corresponding member, it is converted to an implementation-defined
> member other than the null (wide) character." (5.1.1.2p5). Note, in
> particular, that a conforming implementation could convert all UCNs to
> the same "implementation-defined member".
> 
> No such conversion is described for UCNs in identifiers. I believe that
> implementations should treat extended characters in identifiers as
> equivalent to the implementation-defined UCNs that those characters are
> mapped to - but I'm having trouble locating the text in the standard
> that says so.
> 
> For members of the extended character set, "An implementation may allow
> multibyte characters that are not part of the basic source character set
> to appear in identifiers; which characters and their correspondence to
> universal character names is implementation-defined."  (6.4.2.1p3).
> Note, in particular, that an implementation need not allow any character
> that's not in the basic source character set.
> 
>>   My point is that gcc supports extended identifiers with
>> Unicode characters in their names (following the rules in Annex D, which
>> I believe allows π).
> 
> No, the rules in Annex D mandate support for \u03C0, which is a UCN, not
> an extended character. They don't cover 'π', which (if supported) would
> have to be an extended character, but is not a UCN. gcc is allowed to
> decide whether 'π' is in its extended character set, and if it is in
> that set, is permitted to choose which UCN it considers π equivalent to.
> It would be crazy to consider it equivalent to anything other than
> \u03C0, but being crazy in that sense wouldn't render an implementation
> non-conforming.
> 

I haven't suggested that gcc is non-conforming here.  It (up to gcc 10) 
appears to support extended identifiers in a fully conforming way while 
managing to be close to useless in practice due to the lack of support 
for extended characters i identifiers.  Really, that is all I meant be 
"interesting" support - technically correct and practically useless.

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

#149696

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

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

#150085

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] | [prev] | [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] | [next] | [standalone]

#149699

On 03/02/2020 21:25, David Brown wrote:

> To me, this is about user convenience and compatibility.  UCN's in 
> identifiers, on their own, is clearly a useless concept.  If you have to 
> use them, they add nothing but obfuscation to the code - they only make 
> sense in combination with editors or pre-processors that let you use 
> Unicode characters.  They are a back-stop, to let you access extended 
> identifiers even if you can't use an extended character set.

They would appear to be useless. But they might be needed to make use of 
such an identifier exported from an external library. Although you would 
need your own declaration; you can't use a supplied header if that 
header has those extended characters as text rather than \u sequences.

In that case you'd probably create a more keyboard-friendly alias via a 
macro, but that must be defined using \u.

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

#149706

On 2/3/20 4:25 PM, David Brown wrote:
...
> To me, this is about user convenience and compatibility.  UCN's in 
> identifiers, on their own, is clearly a useless concept.  If you have to 
> use them, they add nothing but obfuscation to the code - they only make 
> sense in combination with editors or pre-processors that let you use 
> Unicode characters.  They are a back-stop, to let you access extended 
> identifiers even if you can't use an extended character set.

During the discussions in this newsgroup, while UCNs were still a
proposal and not yet an approved addition to C99, the concept was
frequently brought up of editors that were UCN aware - if a file was
edited on a platform where a given character was displayable, the
corresponding UCN would be displayed using that character. This would,
necessarily, be behavior that could be turned off, so you could see the
actual UCN instead of the character, if you wanted to.

Depending upon the editor mode, for any character that has a
corresponding UCN, either typing that character and saving the file
would result in a file containing the corresponding UCN, or typing a UCN
and saving the file would result in a file containing the extended char.

I've no idea whether any such editor has ever been created - my jobs
have never required me to worry about extended characters. However, it
sounds to me like something that wouldn't be very hard to implement.
Compared to some of the features I've heard about in real-world editors
(such as inserting English text from left to right, while inserting
Arabic text from right to left, in the same mixed-language document), it
should be positively trivial.

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

#149707

On 2/3/20 11:05 PM, James Kuyper wrote:
> During the discussions in this newsgroup, while UCNs were still a
> proposal and not yet an approved addition to C99, 
Actually, now that I think about it, the discussions I'm thinking about
occurred in comp.std.c; I wasn't monitoring comp.lang.c at that time, so
I can't vouch for whether or not similar discussions occurred here.
Sorry for the misdirection.

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

#149729

On 2/3/2020 7:06 PM, James Kuyper wrote:
>> Now I'm confused.  This "π" identifier/is/  an example of an extended
>> identifier.
> No, on an implementation which supports it, 'π' is an extended
> character, and an identifier containing it, such as "aππle" would be an
> extended identifier. However, \u03C0 is an UCN, not an extended character.

"αππλε"

https://youtu.be/BPsFxRUlHIw

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

#149730

On Tuesday, February 4, 2020 at 7:05:59 PM UTC+2, Manfred wrote:
> On 2/3/2020 7:06 PM, James Kuyper wrote:
> >> Now I'm confused.  This "π" identifier/is/  an example of an extended
> >> identifier.
> > No, on an implementation which supports it, 'π' is an extended
> > character, and an identifier containing it, such as "aππle" would be an
> > extended identifier. However, \u03C0 is an UCN, not an extended character.
> 
> "αππλε"
> 
> https://youtu.be/BPsFxRUlHIw

μῆλον

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

#149731

On 2/4/2020 6:38 PM, already5chosen@yahoo.com wrote:
> On Tuesday, February 4, 2020 at 7:05:59 PM UTC+2, Manfred wrote:
>> On 2/3/2020 7:06 PM, James Kuyper wrote:
>>>> Now I'm confused.  This "π" identifier/is/  an example of an extended
>>>> identifier.
>>> No, on an implementation which supports it, 'π' is an extended
>>> character, and an identifier containing it, such as "aππle" would be an
>>> extended identifier. However, \u03C0 is an UCN, not an extended character.
>>
>> "αππλε"
>>
>> https://youtu.be/BPsFxRUlHIw
> 
> μῆλον
> 

λολ!

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

#149740

On 2/4/20 12:05 PM, Manfred wrote:
> On 2/3/2020 7:06 PM, James Kuyper wrote:
>>> Now I'm confused.  This "π" identifier/is/  an example of an extended
>>> identifier.
>> No, on an implementation which supports it, 'π' is an extended
>> character, and an identifier containing it, such as "aππle" would be an
>> extended identifier. However, \u03C0 is an UCN, not an extended character.
> 
> "αππλε"

I deliberately created an example using extended characters mixed in
with basic characters - but your example also works.

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

#149660

David Brown <david.brown@hesbynett.no> writes:
[...]
> Basically, you had to use \u1234 or \U12345678 syntax for your Unicode
> letters in identifiers.  So if you wanted "const double π = 3.14;",
> you'd have to write "const double \u03C0 = 3.14;".  That is with the
> "-fextended-identifiers" on to enable the feature.  It might be
> technically correct to say gcc supports Unicode extended identifiers,
> but in practice it is not particularly convenient.
>
> However, I gather that gcc 10 should support them properly, which will
> be interesting.

Yes, gcc 10 supports them; for example, it allows π (GREEK SMALL
LETTER PI) as an identifer.  gcc 10 hasn't been released, but
building from the latest version in the git repo yields a gcc that
identifies itself as version 10 and supports Unicode identifiers.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#149701

In article <5ajZF.602301$CO7.252756@fx36.am4>,
 Bart <bc@freeuk.com> wrote:

> Doesn't C restrict identifier names to [A-Z a-z 0-9 _] ?
> 
> If not, then what /is/ allowed, as there could be hundreds of thousands 
> of allowable characters?

The unicode database gives each character a category like lower 
case letter or decimal digit. A compiler can define an identifer 
as an L, Pc, or Sc character followed by zero or more L, Pc, Sc, 
and Nd characters. As characters are added to unicode, the 
complier just reads in the latest unicode database.

Normative Categories
Abbr.
Description
Lu
Letter, Uppercase
Ll
Letter, Lowercase
Lt
Letter, Titlecase
Mn
Mark, Non-Spacing
Mc
Mark, Spacing Combining
Me
Mark, Enclosing
Nd
Number, Decimal Digit
Nl
Number, Letter
No
Number, Other
Zs
Separator, Space
Zl
Separator, Line
Zp
Separator, Paragraph
Cc
Other, Control
Cf
Other, Format
Cs
Other, Surrogate
Co
Other, Private Use
Cn
Other, Not Assigned (no characters in the file have this property)
Informative Categories
Abbr.
Description
Lm
Letter, Modifier
Lo
Letter, Other
Pc
Punctuation, Connector
Pd
Punctuation, Dash
Ps
Punctuation, Open
Pe
Punctuation, Close
Pi
Punctuation, Initial quote (may behave like Ps or Pe depending on 
usage)
Pf
Punctuation, Final quote (may behave like Ps or Pe depending on 
usage)
Po
Punctuation, Other
Sm
Symbol, Math
Sc
Symbol, Currency
Sk
Symbol, Modifier
So
Symbol, Other

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.    @
'I desire mercy, not sacrifice.'                                    /|¥
The first law of discordiamism: The more energy   This post         / ¥
to make order is nore energy made into entropy.   insults Islam.  Mohammed

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

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

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

csiph-web