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

High quality resources for learning modern C?

Started by	Leon Taylor <leontaylor476@gmail.com>
First post	2017-06-03 04:44 -0700
Last post	2017-06-11 15:54 -0700
Articles	20 on this page of 93 — 23 participants

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

High quality resources for learning modern C? Leon Taylor <leontaylor476@gmail.com> - 2017-06-03 04:44 -0700
Re: High quality resources for learning modern C? gazelle@shell.xmission.com (Kenny McCormack) - 2017-06-03 11:49 +0000
Re: High quality resources for learning modern C? Leon Taylor <leontaylor476@gmail.com> - 2017-06-03 05:17 -0700
Re: High quality resources for learning modern C? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-03 05:45 -0700
Re: High quality resources for learning modern C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-03 14:43 +0200
Re: High quality resources for learning modern C? Noob <root@127.0.0.1> - 2017-06-03 17:21 +0200
Re: High quality resources for learning modern C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-03 18:15 +0200
Re: High quality resources for learning modern C? jacobnavia <jacob@jacob.remcomp.fr> - 2017-06-03 21:16 +0200
Re: High quality resources for learning modern C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-03 22:56 +0200
Re: High quality resources for learning modern C? Philipp Klaus Krause <pkk@spth.de> - 2017-06-03 23:32 +0200
Re: High quality resources for learning modern C? Noob <root@127.0.0.1> - 2017-06-03 22:20 +0200
Re: High quality resources for learning modern C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-03 23:00 +0200
Re: High quality resources for learning modern C? Noob <root@127.0.0.1> - 2017-06-04 00:03 +0200
Re: High quality resources for learning modern C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-04 00:08 +0200
Re: High quality resources for learning modern C? Philipp Klaus Krause <pkk@spth.de> - 2017-06-03 18:32 +0200
Re: High quality resources for learning modern C? Leon Taylor <leontaylor476@gmail.com> - 2017-06-03 17:05 -0700
Re: High quality resources for learning modern C? Real Troll <real.troll@trolls.com> - 2017-06-03 13:30 -0400
Re: High quality resources for learning modern C? bartc <bc@freeuk.com> - 2017-06-03 18:59 +0100
Re: High quality resources for learning modern C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-03 20:49 +0200
Re: High quality resources for learning modern C? jacobnavia <jacob@jacob.remcomp.fr> - 2017-06-03 21:12 +0200
Re: High quality resources for learning modern C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-03 23:13 +0200
Re: High quality resources for learning modern C? jacobnavia <jacob@jacob.remcomp.fr> - 2017-06-03 23:37 +0200
Re: High quality resources for learning modern C? Thiago Adams <thiago.adams@gmail.com> - 2017-06-03 15:12 -0700
Re: High quality resources for learning modern C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-04 00:16 +0200
Re: High quality resources for learning modern C? jacobnavia <jacob@jacob.remcomp.fr> - 2017-06-03 21:08 +0200
Re: High quality resources for learning modern C? bartc <bc@freeuk.com> - 2017-06-03 21:08 +0100
Re: High quality resources for learning modern C? bartc <bc@freeuk.com> - 2017-06-06 19:29 +0100
Re: High quality resources for learning modern C? Real Troll <Real.Troll@Trolls.com> - 2017-06-03 17:15 -0400
Re: High quality resources for learning modern C? bartc <bc@freeuk.com> - 2017-06-05 22:58 +0100
Re: High quality resources for learning modern C? Keith Thompson <kst-u@mib.org> - 2017-06-05 15:51 -0700
Re: High quality resources for learning modern C? bartc <bc@freeuk.com> - 2017-06-06 00:22 +0100
Re: High quality resources for learning modern C? supercat@casperkitty.com - 2017-06-05 17:05 -0700
Re: High quality resources for learning modern C? Keith Thompson <kst-u@mib.org> - 2017-06-05 17:57 -0700
Re: High quality resources for learning modern C? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 18:13 +0000
Re: High quality resources for learning modern C? Leon Taylor <leontaylor476@gmail.com> - 2017-06-03 17:07 -0700
Re: High quality resources for learning modern C? Keith Thompson <kst-u@mib.org> - 2017-06-03 18:20 -0700
Re: High quality resources for learning modern C? Leon Taylor <leontaylor476@gmail.com> - 2017-06-03 19:59 -0700
Re: High quality resources for learning modern C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-03 20:39 +0200
Re: High quality resources for learning modern C? Barry Schwarz <schwarzb@dqel.com> - 2017-06-03 14:01 -0700
Re: High quality resources for learning modern C? Leon Taylor <leontaylor476@gmail.com> - 2017-06-03 17:08 -0700
Re: High quality resources for learning modern C? David Brown <david.brown@hesbynett.no> - 2017-06-04 16:53 +0200
Re: High quality resources for learning modern C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-04 17:04 +0200
Re: High quality resources for learning modern C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-04 22:03 +0100
Re: High quality resources for learning modern C? Leon Taylor <leontaylor476@gmail.com> - 2017-06-04 16:11 -0700
Re: High quality resources for learning modern C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-05 00:43 +0100
Re: High quality resources for learning modern C? David Brown <david.brown@hesbynett.no> - 2017-06-05 11:56 +0200
Re: High quality resources for learning modern C? Leon Taylor <leontaylor476@gmail.com> - 2017-06-05 03:28 -0700
Re: High quality resources for learning modern C? David Brown <david.brown@hesbynett.no> - 2017-06-05 12:39 +0200
Re: High quality resources for learning modern C? Leon Taylor <leontaylor476@gmail.com> - 2017-06-04 16:06 -0700
Re: High quality resources for learning modern C? Ian Collins <ian-news@hotmail.com> - 2017-06-05 14:09 +1200
Re: High quality resources for learning modern C? raltbos@xs4all.nl (Richard Bos) - 2017-06-05 08:43 +0000
Re: High quality resources for learning modern C? David Brown <david.brown@hesbynett.no> - 2017-06-05 12:08 +0200
Re: High quality resources for learning modern C? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-05 03:49 -0700
Re: High quality resources for learning modern C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-05 14:53 +0200
Re: High quality resources for learning modern C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-05 11:48 +0100
Re: High quality resources for learning modern C? supercat@casperkitty.com - 2017-06-05 07:28 -0700
Re: High quality resources for learning modern C? David Kleinecke <dkleinecke@gmail.com> - 2017-06-05 11:52 -0700
Re: High quality resources for learning modern C? Keith Thompson <kst-u@mib.org> - 2017-06-05 12:23 -0700
Re: High quality resources for learning modern C? jameskuyper@verizon.net - 2017-06-05 12:46 -0700
Re: High quality resources for learning modern C? David Kleinecke <dkleinecke@gmail.com> - 2017-06-05 17:46 -0700
Re: High quality resources for learning modern C? bartc <bc@freeuk.com> - 2017-06-06 01:58 +0100
Re: High quality resources for learning modern C? jameskuyper@verizon.net - 2017-06-05 20:09 -0700
Re: High quality resources for learning modern C? jameskuyper@verizon.net - 2017-06-05 20:16 -0700
Re: High quality resources for learning modern C? David Kleinecke <dkleinecke@gmail.com> - 2017-06-05 21:57 -0700
Re: High quality resources for learning modern C? jameskuyper@verizon.net - 2017-06-06 07:36 -0700
Re: High quality resources for learning modern C? supercat@casperkitty.com - 2017-06-06 09:29 -0700
Re: High quality resources for learning modern C? jameskuyper@verizon.net - 2017-06-06 10:13 -0700
Re: High quality resources for learning modern C? supercat@casperkitty.com - 2017-06-06 13:37 -0700
Re: High quality resources for learning modern C? jameskuyper@verizon.net - 2017-06-06 15:23 -0700
Re: High quality resources for learning modern C? supercat@casperkitty.com - 2017-06-06 16:32 -0700
Re: High quality resources for learning modern C? David Kleinecke <dkleinecke@gmail.com> - 2017-06-06 19:02 -0700
Re: High quality resources for learning modern C? jameskuyper@verizon.net - 2017-06-06 20:20 -0700
Re: High quality resources for learning modern C? David Kleinecke <dkleinecke@gmail.com> - 2017-06-07 18:36 -0700
Re: High quality resources for learning modern C? Keith Thompson <kst-u@mib.org> - 2017-06-07 19:25 -0700
Re: High quality resources for learning modern C? David Kleinecke <dkleinecke@gmail.com> - 2017-06-07 20:09 -0700
Re: High quality resources for learning modern C? jameskuyper@verizon.net - 2017-06-07 20:56 -0700
Re: High quality resources for learning modern C? Keith Thompson <kst-u@mib.org> - 2017-06-08 09:03 -0700
Re: High quality resources for learning modern C? James Kuyper <jameskuyper@verizon.net> - 2017-06-07 23:14 -0400
Re: High quality resources for learning modern C? jameskuyper@verizon.net - 2017-06-07 20:42 -0700
Re: High quality resources for learning modern C? jameskuyper@verizon.net - 2017-06-06 20:08 -0700
Re: High quality resources for learning modern C? supercat@casperkitty.com - 2017-06-07 07:46 -0700
Re: High quality resources for learning modern C? jameskuyper@verizon.net - 2017-06-07 09:02 -0700
Re: High quality resources for learning modern C? supercat@casperkitty.com - 2017-06-07 15:14 -0700
Re: High quality resources for learning modern C? jameskuyper@verizon.net - 2017-06-07 16:36 -0700
Re: High quality resources for learning modern C? supercat@casperkitty.com - 2017-06-08 08:10 -0700
Re: High quality resources for learning modern C? jameskuyper@verizon.net - 2017-06-08 10:43 -0700
Re: High quality resources for learning modern C? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-08 12:37 -0400
Re: High quality resources for learning modern C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-09 10:36 -0700
Re: High quality resources for learning modern C? jameskuyper@verizon.net - 2017-06-09 11:09 -0700
Re: High quality resources for learning modern C? supercat@casperkitty.com - 2017-06-09 12:00 -0700
Re: High quality resources for learning modern C? jameskuyper@verizon.net - 2017-06-09 12:45 -0700
Re: High quality resources for learning modern C? jameskuyper@verizon.net - 2017-06-09 14:11 -0700
Re: High quality resources for learning modern C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-11 15:54 -0700

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

#111603

From	bartc <bc@freeuk.com>
Date	2017-06-06 01:58 +0100
Message-ID	<H6nZA.215720$R12.171081@fx16.am4>
In reply to	#111600

On 06/06/2017 01:46, David Kleinecke wrote:

> How does C cope with source code in UTF-8 etc when the source
> uses more characters than exist in the "source character set"?

A compiler might report an error if there were stray unicode characters 
in the source. Unless they were in string or char constants, or in comments.

-- 
bartc

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

#111605

From	jameskuyper@verizon.net
Date	2017-06-05 20:09 -0700
Message-ID	<1a4b1a92-f899-47d0-a80d-c528b4b16907@googlegroups.com>
In reply to	#111600

On Monday, June 5, 2017 at 8:46:34 PM UTC-4, David Kleinecke wrote:
...
> How does C cope with source code in UTF-8 etc when the source
> uses more characters than exist in the "source character set"?

That's a wierd way to put it. If it uses more characters than exist in the source character set, then by definition, it must use at least one character that doesn't exist in the source character set. The problem created by such source depends only upon that fact; it doesn't depend upon how many other different characters the source contains. A source containing only a single character is problematic, if that character is not in the source character set.

A more reasonable question would be "How does C cope with source code in UTF-8 etc when the source contains characters that do not exist in the source character set".

The answer is that it doesn't cope with such characters, leaving the behavior undefined; there's nothing about that answer that's specific to UTF-8, it applies equally well to any other encoding, including 7-bit ASCII, if the source code includes characters with the high bit set.

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

#111606

From	jameskuyper@verizon.net
Date	2017-06-05 20:16 -0700
Message-ID	<9e782571-4f2e-412e-b13e-e17dcbf2e6fc@googlegroups.com>
In reply to	#111600

On Monday, June 5, 2017 at 8:46:34 PM UTC-4, David Kleinecke wrote:
> On Monday, June 5, 2017 at 12:46:15 PM UTC-7, james...@verizon.net wrote:
> > On Monday, June 5, 2017 at 2:52:54 PM UTC-4, David Kleinecke wrote:
> > ...
> > > The standard, as written, seems too strict about what character
> > > means what.
> > 
> > The standard, as written, requires that '+' be used for addition, but imposes
> > almost no requirements on how '+' is represented in the source code file, beyond
> > making the source character set implementation-defined. How can it be "too
> > strict", when, by default, it imposes almost no requirements on the matter?
> > 
> > It requires that each member of the basic character set be represented by a
> > single byte. Given that there are more than twice as many values that can be
> > stored in an 8-bit byte than there are members of the basic character set,
> > that's not a particularly onerous requirement. It also requires that '0'-'9' be
> > consecutive characters in that order (5.2.1p3). The source character set is NOT
> > required to contain any of the following characters: "\a\b\r\n\0", those are
> > only required in the execution character set. The standard imposes some
> > requirements on the encoding of multi-byte characters (5.2.1.2p1), but nothing
> > particularly onerous.
> > Those are the only requirements the standard imposes on the encoding used.
> > 
> > > But anyone could write a pre-pre-processor that 
> > > converts any set of "tokens" into C form provided the two sets
> > > of token corresponded one-to-one.
> > 
> > True - in particular, any translation that can be put into that form could be performed by a fully conforming implementation of C during translation phase 1: 
> > 
> > "Physical source file multibyte characters are mapped, in an implementation-
> > defined manner, to the source character set (introducing new-line characters for
> > end-of-line indicators) if necessary." (5.1.1.2p1).
> > 
> > "Implementation-defined" gives you all of the freedom you need to perform an arbitrary translation of that type.
> 
> How does C cope with source code in UTF-8 etc when the source
> uses more characters than exist in the "source character set"?

Bart's response made me wonder: are you confusing the "source character set", which would contain 1,112,064 characters on a system that uses UTF-8, with the "basic source character set", which contains fewer than 100 characters?

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

#111610

From	David Kleinecke <dkleinecke@gmail.com>
Date	2017-06-05 21:57 -0700
Message-ID	<46fdf0f4-2b97-49b6-9dd3-193009d72756@googlegroups.com>
In reply to	#111606

On Monday, June 5, 2017 at 8:16:12 PM UTC-7, james...@verizon.net wrote:
> On Monday, June 5, 2017 at 8:46:34 PM UTC-4, David Kleinecke wrote:
> > On Monday, June 5, 2017 at 12:46:15 PM UTC-7, james...@verizon.net wrote:
> > > On Monday, June 5, 2017 at 2:52:54 PM UTC-4, David Kleinecke wrote:
> > > ...
> > > > The standard, as written, seems too strict about what character
> > > > means what.
> > > 
> > > The standard, as written, requires that '+' be used for addition, but imposes
> > > almost no requirements on how '+' is represented in the source code file, beyond
> > > making the source character set implementation-defined. How can it be "too
> > > strict", when, by default, it imposes almost no requirements on the matter?
> > > 
> > > It requires that each member of the basic character set be represented by a
> > > single byte. Given that there are more than twice as many values that can be
> > > stored in an 8-bit byte than there are members of the basic character set,
> > > that's not a particularly onerous requirement. It also requires that '0'-'9' be
> > > consecutive characters in that order (5.2.1p3). The source character set is NOT
> > > required to contain any of the following characters: "\a\b\r\n\0", those are
> > > only required in the execution character set. The standard imposes some
> > > requirements on the encoding of multi-byte characters (5.2.1.2p1), but nothing
> > > particularly onerous.
> > > Those are the only requirements the standard imposes on the encoding used.
> > > 
> > > > But anyone could write a pre-pre-processor that 
> > > > converts any set of "tokens" into C form provided the two sets
> > > > of token corresponded one-to-one.
> > > 
> > > True - in particular, any translation that can be put into that form could be performed by a fully conforming implementation of C during translation phase 1: 
> > > 
> > > "Physical source file multibyte characters are mapped, in an implementation-
> > > defined manner, to the source character set (introducing new-line characters for
> > > end-of-line indicators) if necessary." (5.1.1.2p1).
> > > 
> > > "Implementation-defined" gives you all of the freedom you need to perform an arbitrary translation of that type.
> > 
> > How does C cope with source code in UTF-8 etc when the source
> > uses more characters than exist in the "source character set"?
> 
> Bart's response made me wonder: are you confusing the "source character set", which would contain 1,112,064 characters on a system that uses UTF-8, with the "basic source character set", which contains fewer than 100 characters?

I'm asking on the basis of phase 1 in section 5.1.1.2 of the
C89 standard (and similar places in the other standards) where
the standard says:
   Physical source file characters are mapped to the source
   character set (introducing new-line characters for 
   end-of-line indicators) if necessary.
The character sets are described in 5.2.1 and two sets 
differentiated - (1) the set in which files are written and
(2) the set interpreted in the execution environment. It is
the set (1) that I assume corresponds to the "source character
set" of 5.1.1.2 and my comments. 

5.2.1 goes on to specify 26+26+10+29+5=96 characters and says
the source set "shall have at least the following" and there
is provision for multibyte characters. I don't know whether any
existing compliers actually take advantage of these allowed
extension to the source character set.

So, if one has a compiler with adequate extensions one can handle
UTF-8 or anything else like that then all is well. But if one has
a usual compiler with only 96 source characters and one tries to
use the phase one mapping of a physical source file that uses some
more exotic UTF-8 characters it appears one must fail.

This is the sense in which I felt the standard was too strict.

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

#111631

From	jameskuyper@verizon.net
Date	2017-06-06 07:36 -0700
Message-ID	<b084e4d3-d26f-4146-b1ce-4155bead6cbd@googlegroups.com>
In reply to	#111610

On Tuesday, June 6, 2017 at 12:58:00 AM UTC-4, David Kleinecke wrote:
> On Monday, June 5, 2017 at 8:16:12 PM UTC-7, james...@verizon.net wrote:
...
> > Bart's response made me wonder: are you confusing the "source character
> > set", which would contain 1,112,064 characters on a system that uses UTF-8,
> > with the "basic source character set", which contains fewer than 100
> > characters?
> 
> I'm asking on the basis of phase 1 in section 5.1.1.2 of the
> C89 standard (and similar places in the other standards) where
> the standard says:
>    Physical source file characters are mapped to the source
>    character set (introducing new-line characters for 
>    end-of-line indicators) if necessary.
> The character sets are described in 5.2.1 and two sets 
> differentiated - (1) the set in which files are written and
> (2) the set interpreted in the execution environment. It is
> the set (1) that I assume corresponds to the "source character
> set" of 5.1.1.2 and my comments. 
> 
> 5.2.1 goes on to specify 26+26+10+29+5=96 characters and says
> the source set "shall have at least the following" and there
> is provision for multibyte characters. I don't know whether any
> existing compliers actually take advantage of these allowed
> extension to the source character set.

There's actually four character sets defined. The 96 characters you refer to
above are the "basic source character set". Those 96 characters plus
"\a\b\r\n\0" are the "basic execution character set". These are subsets of the
"source character set" and the "execution character set", respectively. The
difference between those subsets and the full set are referred to as the
"extended source characters" and the "extended execution characters".

So, it's not precisely the case that you're confusing the "source character
set" with the "basic source character set". More precisely, you're thinking
that the difference between those character sets is rarely anything other than
the empty set.

Well, you're WAY off with that assumption. A conforming implementation of C
could have a source character set that was the same as the basic source
character set, but I've never heard of any such implementation. That doesn't
mean none exist; I don't claim to come anywhere close to knowing everything
about every existing implementation. However, I would expect that they're rare.

At one time, it was commonplace for programs to support only 7-bit ASCII, which
has 128 characters, and I would guess that there were probably C compilers that
did so, but I'm not positive whether I've ever read anything about any
particular C compiler being that limited. I might even have used such a
compiler - I've seldom written code that used anything other than the basic
source character set, so I might never have noticed that a given compiler
didn't support 8-bit extended ASCII. If I have used a 7-bit ASCII compiler,
that would make it the one with the most restricted source character set that
I'm familiar with.

I'm positive I've used compilers for which the source character set was 8-bit
extended ASCII, with 256 characters. It's been a long time since I've used
Windows, but I gather that for a while (long after I stopped programming for
it), the standard encoding was UCS-2, with 65536 characters. Then they changed
that to what they called UTF-16, but many Windows programs are still restricted
to UCS-2. I'm fairly sure that there have been Windows compilers where UCS-2 was
the source character set - but since I've never used them, I can't vouch for
that personally.

Nowadays, most compilers targeted for Unix-like systems use UTF-8, with
1,112,064 characters, as the source character set.

> So, if one has a compiler with adequate extensions one can handle
> UTF-8 or anything else like that then all is well. But if one has

The source character set is implementation-defined. Selecting UTF-8 as that
character set is no more of an extension than selecting 2's complement as the
representation for signed int.

> a usual compiler with only 96 source characters and one tries to

Such compilers are NOT usual; I think they may even be non-existent, though I
certainly wouldn't bet on it.

> use the phase one mapping of a physical source file that uses some
> more exotic UTF-8 characters it appears one must fail.

It's hard for me to consider the standard character set on the machines I use
most often to be exotic.

> This is the sense in which I felt the standard was too strict.

The standard is extremely lenient with regards to the character set. Even if
you were right about most compilers failing to take advantage of the freedom
that the standard gives them, that would be their implementors' fault, not a
matter of the standard being too strict.

Now, a strictly conforming program must be restricted to the basic source
character set, because those are the only characters guaranteed to be supported
- but notice the word "strictly" in that term. If the standard mandated support
for a larger basic source character set, that would make it stricter, not less
strict, so that shouldn't be the issue you're talking about (though I suspect
that it is).

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

#111638

From	supercat@casperkitty.com
Date	2017-06-06 09:29 -0700
Message-ID	<1e83d4df-a8cd-482c-8465-94619396cb7e@googlegroups.com>
In reply to	#111631

On Tuesday, June 6, 2017 at 9:37:00 AM UTC-5, james...@verizon.net wrote:
> Well, you're WAY off with that assumption. A conforming implementation of C
> could have a source character set that was the same as the basic source
> character set, but I've never heard of any such implementation. That doesn't
> mean none exist; I don't claim to come anywhere close to knowing everything
> about every existing implementation. However, I would expect that they're rare.

For every member of the source character set, a conforming C implementation
must designate a positive number that is representable as 'char', and any
character literal containing that character must yield that number.  There
is no requirement that that number have any particular relationship to the
representation in the source file.  It would be entirely legitimate and
useful, for example, to have a C cross compiler that processed source files
in EBCDIC, where the digit '5' is represented with bit pattern 0xF5, but
generated code for an ASCII target, where '5' is bit pattern 0x35.  In
such a compiler, the value of the character literal expression '5' should
be 0x35.

The Standard doesn't specify what a compiler should do if the target
platform's character set doesn't have a glyph that matches a character of
the source character set, but unless the intention is to make it impossible
for such platforms to have conforming C implementations the only logical
interpretation would be to say that implementations may substitute any
character code that make sense, provided that each source character is
mapped to a different code.

If a source file contains bit patterns that don't map to values in the
Source Character Set, an implementation would be allowed to do anything
it likes with such values.  In the common case where the source file is
encoded using the target character set, interpreting every character as
the bit pattern used to represent it in the source file would obviously
be logical and convenient, but the Standard would not forbid implementations
from doing otherwise.

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

#111641

From	jameskuyper@verizon.net
Date	2017-06-06 10:13 -0700
Message-ID	<ed09d869-560c-4191-bb5e-8f6a9c0ec9f1@googlegroups.com>
In reply to	#111638

On Tuesday, June 6, 2017 at 12:29:48 PM UTC-4, supe...@casperkitty.com wrote:
> On Tuesday, June 6, 2017 at 9:37:00 AM UTC-5, james...@verizon.net wrote:
> > Well, you're WAY off with that assumption. A conforming implementation of C
> > could have a source character set that was the same as the basic source
> > character set, but I've never heard of any such implementation. That doesn't
> > mean none exist; I don't claim to come anywhere close to knowing everything
> > about every existing implementation. However, I would expect that they're rare.
> 
> For every member of the source character set, a conforming C implementation
> must designate a positive number

That restriction to positive numbers applies only to the basic execution
character set (6.2.5p3), it doesn't apply to the source character set, nor to
extended characters.

> that is representable as 'char', and any

That requirement applies only to the basic character sets (5.2.1p3), not to
extended characters.

> The Standard doesn't specify what a compiler should do if the target
> platform's character set doesn't have a glyph ...

Keep in mind that the members of a character set are characters, not glyphs. I
your platform's character set has 10 different fonts available, there can be as
many as 10 different glyphs for each character. Note also that on many
platforms, the font used to display text on screen may be quite different from
the font used when printing that same text. So it's a serious mistake to think
of character sets as collections of glyphs.

> ... that matches a character of
> the source character set, ...

The standard says nothing whatsoever about glyphs, permitting a completely
arbitrary relationship between the values of the source character set and the
glyphs that are displayed for the platform's character set when using any
particular font.

> ... but unless the intention is to make it impossible
> for such platforms to have conforming C implementations the only logical
> interpretation would be to say that implementations may substitute any
> character code that make sense, provided that each source character is
> mapped to a different code.

Since the standard doesn't even discuss the matter, that's certainly permitted.

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

#111660

From	supercat@casperkitty.com
Date	2017-06-06 13:37 -0700
Message-ID	<ee094f4f-7f20-48f5-882d-93af07910842@googlegroups.com>
In reply to	#111641

On Tuesday, June 6, 2017 at 12:13:24 PM UTC-5, james wrote:
> On Tuesday, June 6, 2017 at 12:29:48 PM UTC-4, supercat wrote:
> > For every member of the source character set, a conforming C implementation
> > must designate a positive number
> 
> That restriction to positive numbers applies only to the basic execution
> character set (6.2.5p3), it doesn't apply to the source character set, nor to
> extended characters.

If a source file contains characters that are in the execution set but not
the source set, I don't think the Standard says anything about how those
should be processed so long as there exists some means of separating lines.

> > that is representable as 'char', and any
> 
> That requirement applies only to the basic character sets (5.2.1p3), not to
> extended characters.

Correct; I don't think the Standard imposes *any* requirements on characters
outside the basic sets.  The appearance of any character outside the basic
source character set would invoke Undefined Behavior, though of course
an implementation which processes printf("`hey`"); by outputting `hey`
should probably be regarded as being of higher quality than one which uses
such code as an excuse to negate the laws of time and causality.

> > The Standard doesn't specify what a compiler should do if the target
> > platform's character set doesn't have a glyph ...
> 
> Keep in mind that the members of a character set are characters, not glyphs. I
> your platform's character set has 10 different fonts available, there can be as
> many as 10 different glyphs for each character. Note also that on many
> platforms, the font used to display text on screen may be quite different from
> the font used when printing that same text. So it's a serious mistake to think
> of character sets as collections of glyphs.

What meaning can be attached to the fact that character code 0x36 is a
a digit six in the execution character set, beyond the fact that keyboards
using that set are expected to produce 0x36 when someone presses a key
whose legend looks like a 6, and displays or printers would be expected
to produce glyphs that looks like a 6 when they receives that code?

> > ... that matches a character of
> > the source character set, ...
> 
> The standard says nothing whatsoever about glyphs, permitting a completely
> arbitrary relationship between the values of the source character set and the
> glyphs that are displayed for the platform's character set when using any
> particular font.

Nothing would forbid an implementation from defining character code 0x41 in
the execution set as a letter "Z", even though it looks like an "A", and
character code 0x5A in the execution set as an "A" even though it looks like
a "Z".

> > ... but unless the intention is to make it impossible
> > for such platforms to have conforming C implementations the only logical
> > interpretation would be to say that implementations may substitute any
> > character code that make sense, provided that each source character is
> > mapped to a different code.
> 
> Since the standard doesn't even discuss the matter, that's certainly permitted.

That does raise the question as to whether trigraphs are needed, though.
Something like a Commodore 64 doesn't have a backslash character, but code
0x5C (which is backslash in ASCII) is generated by a key with a UK-pound
symbol on it, and outputting that code shows a character that looks like a
UK pound symbol.  If I were typing code on that platform, I would regard
printf("Hello£n"); as more legible than printf("Hello??/n");

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

#111663

From	jameskuyper@verizon.net
Date	2017-06-06 15:23 -0700
Message-ID	<c5711242-9641-4d88-8991-46c6226721bf@googlegroups.com>
In reply to	#111660

On Tuesday, June 6, 2017 at 4:38:19 PM UTC-4, supe...@casperkitty.com wrote:
> On Tuesday, June 6, 2017 at 12:13:24 PM UTC-5, james wrote:
> > On Tuesday, June 6, 2017 at 12:29:48 PM UTC-4, supercat wrote:
...
> > > For every member of the source character set, a conforming C implementation
> > > must designate a positive number
> > 
> > That restriction to positive numbers applies only to the basic execution
> > character set (6.2.5p3), it doesn't apply to the source character set, nor to
> > extended characters.
> 
> If a source file contains characters that are in the execution set but not
> the source set, I don't think the Standard says anything about how those
> should be processed so long as there exists some means of separating lines.

What do "characters that are in the execution set but not the source set" have to do with what I said? I'm talking about that fact that characters which ARE in the source character set are allowed to have negative values, in conflict with your claim that they have to be positive. That's true even if they're in the basic source character set.

> > > that is representable as 'char', and any
> > 
> > That requirement applies only to the basic character sets (5.2.1p3), not to
> > extended characters.
> 
> Correct; I don't think the Standard imposes *any* requirements on characters
> outside the basic sets. ...

In conflict with David's claim that the standard is far too strict, it doesn't impose many requirements on those characters other than that the implementation define them. However, it does impose at least one:

"The source character set may contain multibyte characters, used to represent
members of the extended character set. ... A byte with all bits zero shall be
interpreted as a null character independent of shift state. Such a byte shall
not occur as part of any other multibyte character." (5.2.1.2p1)

> ... The appearance of any character outside the basic
> source character set would invoke Undefined Behavior,

Citation, please? It's certainly not undefined "by the omission of any explicit
definition of behavior" (4p6), because everything that the standard says about
the "source character set" without prefixing that term with "basic" is, by
definition, behavior that is defined for members of the extended source character set. This includes:

    5.1.1.2p1, translation phases 1 and 5.
    6.4.4.4p1, character constants
    6.4.5p11, string literals
    6.4.7p1, header names

...
> > Keep in mind that the members of a character set are characters, not
> > glyphs. If your platform's character set has 10 different fonts available,
> > there can be as many as 10 different glyphs for each character. Note also
> > that on many platforms, the font used to display text on screen may be
> > quite different from the font used when printing that same text. So it's a
> > serious mistake to think of character sets as collections of glyphs.
> 
> What meaning can be attached to the fact that character code 0x36 is a
> a digit six in the execution character set, beyond the fact that keyboards
> using that set are expected to produce 0x36 when someone presses a key
> whose legend looks like a 6, and displays or printers would be expected
> to produce glyphs that looks like a 6 when they receives that code?

The glyphs that are presented are irrelevant to conformance with the C standard, which is pretty important, really, because the glyph for 6 that appears on the keyboard, the glyph for 6 that appears on the screen, and the
glyph for 6 that appears on the printout may be quite different, but they all
represent the same exact character. If they were all required to be the same glyph, that would greatly restrict the implementibility of C. If they were
allowed to differ, in any way other than by being different glyphs representing
the same character (which is precisely what is implied by the standard's
insistence on using "character" in locations where you insist on using
"glyph"), then specifying the rules for how they could differ would greatly
complicate the standard. It's the characters that that those glyphs represent,
and not the glyphs themselves, which are relevant to C conformance.

...
> > The standard says nothing whatsoever about glyphs, permitting a completely
> > arbitrary relationship between the values of the source character set and the
> > glyphs that are displayed for the platform's character set when using any
> > particular font.
> 
> Nothing would forbid an implementation from defining character code 0x41 in
> the execution set as a letter "Z", even though it looks like an "A", and
> character code 0x5A in the execution set as an "A" even though it looks like
> a "Z".

Except for the fact that those glyphs are not glyphs for those characters - a
fact which lies outside the scope of the standard, but is still quite relevant.

...
> That does raise the question as to whether trigraphs are needed, though.
> Something like a Commodore 64 doesn't have a backslash character, but code
> 0x5C (which is backslash in ASCII) is generated by a key with a UK-pound
> symbol on it, and outputting that code shows a character that looks like a
> UK pound symbol.  If I were typing code on that platform, I would regard
> printf("Hello£n"); as more legible than printf("Hello??/n");

Many people got used to seeing code displayed using a glyph for the wrong
character, which was, in fact, one of the reasons that trigraphs were an
unpopular solution. However, the character sets in question did NOT have a
backslash character, and they did have something else in the position that
meant a backslash in ASCII. £ is a glyph for the pound symbol; it is NOT a
glyph for the backslash. Treating it as if was a glyph for a backslash was a
necessity borne of misusing tools that weren't quite appropriate for the work
being done; it was not in any way the official meaning of the relevant character sets or the relevant fonts.

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

#111666

From	supercat@casperkitty.com
Date	2017-06-06 16:32 -0700
Message-ID	<2234306d-5ddd-4adf-8548-b0c50665623f@googlegroups.com>
In reply to	#111663

On Tuesday, June 6, 2017 at 5:23:49 PM UTC-5, james...@verizon.net wrote:
> In conflict with David's claim that the standard is far too strict, it doesn't impose many requirements on those characters other than that the implementation define them. However, it does impose at least one:
> 
> "The source character set may contain multibyte characters, used to represent
> members of the extended character set. ... A byte with all bits zero shall be
> interpreted as a null character independent of shift state. Such a byte shall
> not occur as part of any other multibyte character." (5.2.1.2p1)

I'm not sure why the Standard should care about how source characters are
represented?  It is certainly reasonable to say that a string literal
should not contain any bytes with value zero unless produced via backslash
escape, but I would regard that as a property of the execution character
set, rather than the source set.  For the common case where the execution
character set and source character set are one and the same except for the
lack of newline characters in the latter, restrictions on the former would
imply restrictions on the latter.  If the encodings are totally different,
however, I know of no way that a program could determine anything whatsoever
about the source character set.

> > ... The appearance of any character outside the basic
> > source character set would invoke Undefined Behavior,
> 
> Citation, please? It's certainly not undefined "by the omission of any explicit
> definition of behavior" (4p6), because everything that the standard says about
> the "source character set" without prefixing that term with "basic" is, by
> definition, behavior that is defined for members of the extended source character set. This includes:
> 
>     5.1.1.2p1, translation phases 1 and 5.
>     6.4.4.4p1, character constants
>     6.4.5p11, string literals
>     6.4.7p1, header names

The Standard does not so far as I can tell require that every bit pattern
that could appear within a source medium represents a character of any
recognized character set, nor does it say anything about what will happen
if a compiler encounters a bit pattern that does not represent any
character of any character set.  Some bit patterns may trigger inconsistent
behaviors in some implementations.  For example, an implementation might
stop scanning if it encounters a byte value of 0x1A when reading from disk,
but ignore such a byte value if it appears within a loaded editor document.

> > That does raise the question as to whether trigraphs are needed, though.
> > Something like a Commodore 64 doesn't have a backslash character, but code
> > 0x5C (which is backslash in ASCII) is generated by a key with a UK-pound
> > symbol on it, and outputting that code shows a character that looks like a
> > UK pound symbol.  If I were typing code on that platform, I would regard
> > printf("Hello£n"); as more legible than printf("Hello??/n");
> 
> Many people got used to seeing code displayed using a glyph for the wrong
> character, which was, in fact, one of the reasons that trigraphs were an
> unpopular solution. However, the character sets in question did NOT have a
> backslash character, and they did have something else in the position that
> meant a backslash in ASCII. £ is a glyph for the pound symbol; it is NOT a
> glyph for the backslash. Treating it as if was a glyph for a backslash was a
> necessity borne of misusing tools that weren't quite appropriate for the work
> being done; it was not in any way the official meaning of the relevant character sets or the relevant fonts.

What code should a Commodore compiler output for printf("'??/??/'??/n");

The only way I can see to have a conforming implementation for a platform
which does not have a backslash in its character set would be to declare
that some other character is "really" a very funny-looking backslash.  I
would regard that as more useful than either saying that C cannot be
implemented on the Commodore, or requiring that all C implementations on
the Commodore must reprogram the character set to include a backslash
(which would clobber any efforts by user code to reprogram the character
set--in whole or in part--for other purposes).

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

#111670

From	David Kleinecke <dkleinecke@gmail.com>
Date	2017-06-06 19:02 -0700
Message-ID	<60670cc9-e5fd-4c05-8764-f09ba39afab5@googlegroups.com>
In reply to	#111666

On Tuesday, June 6, 2017 at 4:32:38 PM UTC-7, supe...@casperkitty.com wrote:
> On Tuesday, June 6, 2017 at 5:23:49 PM UTC-5, james...@verizon.net wrote:
> > In conflict with David's claim that the standard is far too strict, it doesn't impose many requirements on those characters other than that the implementation define them. However, it does impose at least one:
> > 
> > "The source character set may contain multibyte characters, used to represent
> > members of the extended character set. ... A byte with all bits zero shall be
> > interpreted as a null character independent of shift state. Such a byte shall
> > not occur as part of any other multibyte character." (5.2.1.2p1)
> 
> I'm not sure why the Standard should care about how source characters are
> represented?  It is certainly reasonable to say that a string literal
> should not contain any bytes with value zero unless produced via backslash
> escape, but I would regard that as a property of the execution character
> set, rather than the source set.  For the common case where the execution
> character set and source character set are one and the same except for the
> lack of newline characters in the latter, restrictions on the former would
> imply restrictions on the latter.  If the encodings are totally different,
> however, I know of no way that a program could determine anything whatsoever
> about the source character set.
> 
> > > ... The appearance of any character outside the basic
> > > source character set would invoke Undefined Behavior,
> > 
> > Citation, please? It's certainly not undefined "by the omission of any explicit
> > definition of behavior" (4p6), because everything that the standard says about
> > the "source character set" without prefixing that term with "basic" is, by
> > definition, behavior that is defined for members of the extended source character set. This includes:
> > 
> >     5.1.1.2p1, translation phases 1 and 5.
> >     6.4.4.4p1, character constants
> >     6.4.5p11, string literals
> >     6.4.7p1, header names
> 
> The Standard does not so far as I can tell require that every bit pattern
> that could appear within a source medium represents a character of any
> recognized character set, nor does it say anything about what will happen
> if a compiler encounters a bit pattern that does not represent any
> character of any character set.  Some bit patterns may trigger inconsistent
> behaviors in some implementations.  For example, an implementation might
> stop scanning if it encounters a byte value of 0x1A when reading from disk,
> but ignore such a byte value if it appears within a loaded editor document.
> 
> > > That does raise the question as to whether trigraphs are needed, though.
> > > Something like a Commodore 64 doesn't have a backslash character, but code
> > > 0x5C (which is backslash in ASCII) is generated by a key with a UK-pound
> > > symbol on it, and outputting that code shows a character that looks like a
> > > UK pound symbol.  If I were typing code on that platform, I would regard
> > > printf("Hello£n"); as more legible than printf("Hello??/n");
> > 
> > Many people got used to seeing code displayed using a glyph for the wrong
> > character, which was, in fact, one of the reasons that trigraphs were an
> > unpopular solution. However, the character sets in question did NOT have a
> > backslash character, and they did have something else in the position that
> > meant a backslash in ASCII. £ is a glyph for the pound symbol; it is NOT a
> > glyph for the backslash. Treating it as if was a glyph for a backslash was a
> > necessity borne of misusing tools that weren't quite appropriate for the work
> > being done; it was not in any way the official meaning of the relevant character sets or the relevant fonts.
> 
> What code should a Commodore compiler output for printf("'??/??/'??/n");
> 
> The only way I can see to have a conforming implementation for a platform
> which does not have a backslash in its character set would be to declare
> that some other character is "really" a very funny-looking backslash.  I
> would regard that as more useful than either saying that C cannot be
> implemented on the Commodore, or requiring that all C implementations on
> the Commodore must reprogram the character set to include a backslash
> (which would clobber any efforts by user code to reprogram the character
> set--in whole or in part--for other purposes).

Disagreeing with myself somewhat I want to focus on identifiers.
In 6.1.2 (C89 standard) an identifier is defined as a nondigit
followed by digits and nondigits. There are 53 nondigits and 10
digits. That means (assuming digits are digits everywhere) one
can write a C pre-source in any set of characters with no more 
than 53 members reserved as nondigits. The pre-preprocessor
mapping these exotic identifiers into legal C identifiers,

If one wanted to write the source identifiers in Chinese, for
example, one would probably map single Chinese characters into
more than one C source character. 

If one wants to make small additions to the English source set
- for example ñ - the easiest way would be to map ñ to nh or
some other digraph that does not occur in Spanish. This would
cause no confusion because the digraph never appears outside
the compiler. (Possible error messages would map it back to ñ.)

The tokenizer, of course, can accept any "identifier" as a 
keyword and map it to the correct token.

So much for the source characters. The execution set is a very
different matter.
characters and use the pre-

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

#111672

From	jameskuyper@verizon.net
Date	2017-06-06 20:20 -0700
Message-ID	<25a64c0c-8065-4626-a5de-a380cbff4cba@googlegroups.com>
In reply to	#111670

On Tuesday, June 6, 2017 at 10:03:03 PM UTC-4, David Kleinecke wrote:
...
> Disagreeing with myself somewhat I want to focus on identifiers.
> In 6.1.2 (C89 standard) an identifier is defined as a nondigit
> followed by digits and nondigits. There are 53 nondigits and 10
> digits.

Starting in C99, there's a LOT more than 53 non-digits. Non-digits now include
UCNs and an implementation-defined set of additional characters that may include
members of the extended source character set, some of which might be treated as
equivalent to corresponding UCNs.

I don't remember: are you one of the two or three people who regularly criticize
C here for it's faults, but refuse to pay attention to any version of the
standard other than the first one? If so, what in the world do you want anyone
to do about your criticism? In the unlikely event that a new version of the
standard were to be issued addressing your criticisms, you'd presumably continue
refusing to pay attention to it, because it's not C89.

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

#111779

From	David Kleinecke <dkleinecke@gmail.com>
Date	2017-06-07 18:36 -0700
Message-ID	<10bcff7e-54ca-49e7-aeb4-f715bd268056@googlegroups.com>
In reply to	#111672

On Tuesday, June 6, 2017 at 8:20:34 PM UTC-7, james...@verizon.net wrote:
> On Tuesday, June 6, 2017 at 10:03:03 PM UTC-4, David Kleinecke wrote:
> ...
> > Disagreeing with myself somewhat I want to focus on identifiers.
> > In 6.1.2 (C89 standard) an identifier is defined as a nondigit
> > followed by digits and nondigits. There are 53 nondigits and 10
> > digits.
> 
> Starting in C99, there's a LOT more than 53 non-digits. Non-digits now include
> UCNs and an implementation-defined set of additional characters that may include
> members of the extended source character set, some of which might be treated as
> equivalent to corresponding UCNs.
> 
> I don't remember: are you one of the two or three people who regularly criticize
> C here for it's faults, but refuse to pay attention to any version of the
> standard other than the first one? If so, what in the world do you want anyone
> to do about your criticism? In the unlikely event that a new version of the
> standard were to be issued addressing your criticisms, you'd presumably continue
> refusing to pay attention to it, because it's not C89.

I am indeed one of those people who think C means C89 but I
rarely spend much time bitching about its faults. Rather I
spend time clarifying them and working around them. 

I seem to have forgotten how to find the C99 standard online.
The summaries of C99 changes do imply the source character
set has been extended. I don't remember actually seeing any
extended character set being used so I wonder exactly what the
C99 extension was. 

I made yet another mistake elsewhere when explaining how to
match alphabets with more characters. I wanted to add 'ñ' (assumed
Spanish) to the source characters. I suggested the wrong encoding.  
The right one is to select some little used character - say 'k' -
and map external 'k' to internal 'kk' and external 'ñ' to 'kn'.

This way all kinds of odd ball letters can be mapped by the
pre-pre-processor into standard source character sequences.

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

#111781

From	Keith Thompson <kst-u@mib.org>
Date	2017-06-07 19:25 -0700
Message-ID	<lna85jjjw2.fsf@kst-u.example.com>
In reply to	#111779

David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> I am indeed one of those people who think C means C89 but I
> rarely spend much time bitching about its faults. Rather I
> spend time clarifying them and working around them. 
>
> I seem to have forgotten how to find the C99 standard online.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

is not the actual C99 standard, but it's more than close enough.

A draft of the current C11 standard is
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

> The summaries of C99 changes do imply the source character
> set has been extended. I don't remember actually seeing any
> extended character set being used so I wonder exactly what the
> C99 extension was. 

The basic source and execution character sets have not changed across
C89/C90, C99, and C11.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#111782

From	David Kleinecke <dkleinecke@gmail.com>
Date	2017-06-07 20:09 -0700
Message-ID	<d382e429-38bc-4ab2-95e5-76e20f20c893@googlegroups.com>
In reply to	#111781

On Wednesday, June 7, 2017 at 7:25:24 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> [...]
> > I am indeed one of those people who think C means C89 but I
> > rarely spend much time bitching about its faults. Rather I
> > spend time clarifying them and working around them. 
> >
> > I seem to have forgotten how to find the C99 standard online.
> 
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
> 
> is not the actual C99 standard, but it's more than close enough.
> 
> A draft of the current C11 standard is
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
> 
> > The summaries of C99 changes do imply the source character
> > set has been extended. I don't remember actually seeing any
> > extended character set being used so I wonder exactly what the
> > C99 extension was. 
> 
> The basic source and execution character sets have not changed across
> C89/C90, C99, and C11.
 
I don't know what you mean by "basic source" character set. If
one looks at the definition of "identifier" one sees a great many
more nondigit characters allowed than the 53 of C90. The standard
is not expressed in UTF-8 but that should be easy reinterpret. I
find it odd that I have never seen this extension of the source
character set used,

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

#111789

From	jameskuyper@verizon.net
Date	2017-06-07 20:56 -0700
Message-ID	<bfacf812-315e-4324-98f8-08be3e61682e@googlegroups.com>
In reply to	#111782

On Wednesday, June 7, 2017 at 11:09:40 PM UTC-4, David Kleinecke wrote:
> On Wednesday, June 7, 2017 at 7:25:24 PM UTC-7, Keith Thompson wrote:
...
> > The basic source and execution character sets have not changed across
> > C89/C90, C99, and C11.
>  
> I don't know what you mean by "basic source" character set

"basic source character set" is a term precisely defined by section 5.2.1p3 of
the current standard, and 2.2.1p3 of C89. It's unfortunately written is such a
way that a search for that term won't catch it: "... the basic source and
execution characters sets ...". 

> If
> one looks at the definition of "identifier" one sees a great many
> more nondigit characters allowed than the 53 of C90. The standard
> is not expressed in UTF-8 but that should be easy reinterpret. I
> find it odd that I have never seen this extension of the source
> character set used,

Possibly because it's not portable: the basis source character set is supported
by any conforming implementation of C; extended source characters may be
different on different implementations of C.

It also depends upon where you do most of your programming. Use of extended
characters is more popular in countries where the native language cannot be
written using only the basic source character set. I've personally never seen it
done, which is understandable because my code is written exclusively by and for
speakers of English, most of them native speakers. What little text it produces is mostly error messages and file metadata, and all of that is in English.

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

#111827

From	Keith Thompson <kst-u@mib.org>
Date	2017-06-08 09:03 -0700
Message-ID	<ln37bajwki.fsf@kst-u.example.com>
In reply to	#111782

David Kleinecke <dkleinecke@gmail.com> writes:
> On Wednesday, June 7, 2017 at 7:25:24 PM UTC-7, Keith Thompson wrote:
[...]
>> The basic source and execution character sets have not changed across
>> C89/C90, C99, and C11.
>  
> I don't know what you mean by "basic source" character set.

James Kuyper explained that.

>                                                             If
> one looks at the definition of "identifier" one sees a great many
> more nondigit characters allowed than the 53 of C90.

The definition of "identifier" doesn't affect the basic or extended
source or execution character sets.

In C90, the permitted characters in identifiers are the 10 digits,
the 26 uppercase letters, the 26 lowercase letters, and underscore.

C99 added universal character names and "other implementation-defined
characters"; there might not be any.  A universal character
name consists of \u or \U followed by 4 or 8 hexadecimal digits,
all of which were already within the basic source and execution
character sets.  I don't believe C11 made any changes in this area.

For example, x\u1234y is a valid identifier in C99 and C11, but
not in C89/C90.  (\u1234 designates the ETHIOPIC SYLLABLE SEE character,
but it appears in source code as a 6-character sequence starting with a
backslash.  Displaying that sequence using an appropriate glyph is
outside the scope of the standard.)

x$y *can* be a valid identifier if $ is one of the "other
implementation-defined characters", but it's not portable.

>                                                      The standard
> is not expressed in UTF-8 but that should be easy reinterpret. I
> find it odd that I have never seen this extension of the source
> character set used,

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#111783

From	James Kuyper <jameskuyper@verizon.net>
Date	2017-06-07 23:14 -0400
Message-ID	<ohaf76$5a1$1@dont-email.me>
In reply to	#111781

On 06/07/2017 10:25 PM, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
...
>> The summaries of C99 changes do imply the source character
>> set has been extended. I don't remember actually seeing any
>> extended character set being used so I wonder exactly what the
>> C99 extension was. 
> 
> The basic source and execution character sets have not changed across
> C89/C90, C99, and C11.

He might be referring to "extended identifiers", from section 7 of the
Forward, which refers to a change that was made in C99: identifiers can
now contain UCNs and characters that are not members of the basic source
character set to appear in identifiers.

The introduction also say "With the introduction of new devices and
extended character sets, new features may be added to this International
Standard." That wording seems to have been substantially unchanged since
C89, where it appeared in section 1.8. Someone seeing such wording for
the first time in C99 might be forgiven for thinking that the
introduction that it refers to occurred in C99.

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

#111787

From	jameskuyper@verizon.net
Date	2017-06-07 20:42 -0700
Message-ID	<e06b986c-b9e0-4190-a505-08987ed8b41e@googlegroups.com>
In reply to	#111779

On Wednesday, June 7, 2017 at 9:36:29 PM UTC-4, David Kleinecke wrote:
...
> I seem to have forgotten how to find the C99 standard online.

<www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>

> The summaries of C99 changes do imply the source character
> set has been extended. I don't remember actually seeing any
> extended character set being used ...

Have you actually tried it? Find a sufficiently flexible text editor, and try
putting characters other than the 96 basic source characters in a comment, a
character constant, a string literal, or a header name (remember to create a
header file whose name contains that same character). If your compiler processes
such code without problems, it implies that those characters are in the source
character set.

> ... so I wonder exactly what the
> C99 extension was. 

Extended characters can now appear in identifiers.

> I made yet another mistake elsewhere when explaining how to
> match alphabets with more characters. I wanted to add 'ñ' (assumed
> Spanish) to the source characters. I suggested the wrong encoding.  
> The right one is to select some little used character - say 'k' -
> and map external 'k' to internal 'kk' and external 'ñ' to 'kn'.
> 
> This way all kinds of odd ball letters can be mapped by the
> pre-pre-processor into standard source character sequences.

Most compilers that I've used within the past couple of decades will accept
those characters directly, with no need to map them.

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

#111671

From	jameskuyper@verizon.net
Date	2017-06-06 20:08 -0700
Message-ID	<37843cf1-1d70-4b9e-b3ed-10e5ffb11f55@googlegroups.com>
In reply to	#111666

On Tuesday, June 6, 2017 at 7:32:38 PM UTC-4, supe...@casperkitty.com wrote:
> On Tuesday, June 6, 2017 at 5:23:49 PM UTC-5, james...@verizon.net wrote:
...
> > "The source character set may contain multibyte characters, used to represent
> > members of the extended character set. ... A byte with all bits zero shall be
> > interpreted as a null character independent of shift state. Such a byte shall
> > not occur as part of any other multibyte character." (5.2.1.2p1)
> 
> I'm not sure why the Standard should care about how source characters are
> represented?

I agree - it doesn't need to care. That representation is very important to the
compiler, and to the text editor used to create the source code, but it is of no
relevance to the C programmer, so the standard has no need to impose such a
requirement.

I clipped everything out of that citation that I didn't need to make my point. I
used an ellipsis to mark one clip. The clipped text starts out with a statement
about the extended character set, parallel to the one i did show about the
source character set. As a result, the text above after the ellipsis applies to
both the source and execution character sets. Possibly they didn't think through
the fact that it need only be applied to the execution character set.

...
> > > ... The appearance of any character outside the basic
> > > source character set would invoke Undefined Behavior,
> > 
> > Citation, please? It's certainly not undefined "by the omission of any explicit
> > definition of behavior" (4p6), because everything that the standard says about
> > the "source character set" without prefixing that term with "basic" is, by
> > definition, behavior that is defined for members of the extended source character set. This includes:
> > 
> >     5.1.1.2p1, translation phases 1 and 5.
> >     6.4.4.4p1, character constants
> >     6.4.5p11, string literals
> >     6.4.7p1, header names
> 
> The Standard does not so far as I can tell require that every bit pattern
> that could appear within a source medium represents a character of any
> recognized character set,

Agreed. But I asked for a citation supporting your assertion that source code
containing any character outside the basic source character set has undefined
behavior. Many of the characters that are outside the basic source character set
are inside the source character set, and are therefore not covered by your
[non]response. That is, in fact, the definition of the extended source
characters.

According to your claim above, source code containing any member of the extended
source character set has undefined behavior (since they are outside the basic
source character set). According to the the clauses I cited above, members of
the extended source character set must, since they are members of the source
character set, be accepted in identifiers, header names, character constants and
string literals. Furthermore, they must also be translated during translation
phase 5 into the corresponding member of the execution character set, or if
there is no such member, into an implementation-defined non-null member of that
set. That seems like defined behavior to me.

...
> > glyph for the backslash. Treating it as if was a glyph for a backslash was a
> > necessity borne of misusing tools that weren't quite appropriate for the work
> > being done; it was not in any way the official meaning of the relevant character sets or the relevant fonts.
> 
> What code should a Commodore compiler output for printf("'??/??/'??/n");

Since it had no way to display a glyph for the correct character, this is an
example of what I was talking about above: misusing tools that weren't quite
appropriate for the work being done.

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

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

csiph-web

High quality resources for learning modern C?

Contents

#111603

#111605

#111606

#111610

#111631

#111638

#111641

#111660

#111663

#111666

#111670

#111672

#111779

#111781

#111782

#111789

#111827

#111783

#111787

#111671