Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #77503 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2015-12-01 12:52 +0000 |
| Last post | 2015-12-01 12:24 -0800 |
| Articles | 20 on this page of 151 — 24 participants |
Back to article view | Back to comp.lang.c
// comments and \ BartC <bc@freeuk.com> - 2015-12-01 12:52 +0000
Re: // comments and \ me <self@example.org> - 2015-12-01 13:08 +0000
Re: // comments and \ Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-01 08:20 -0500
Re: // comments and \ me <self@example.org> - 2015-12-01 13:36 +0000
Re: // comments and \ Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-01 09:03 -0500
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 14:14 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-01 07:40 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 08:55 -0800
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 17:15 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-01 09:58 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 18:11 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-01 10:18 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 18:20 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 11:07 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-01 11:39 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 12:33 -0800
Re: // comments and \ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-02 01:05 +0000
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 19:30 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-01 20:59 +0100
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-01 15:22 -0500
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 20:37 +0000
Re: // comments and \ Robert Wessel <robertwessel2@yahoo.com> - 2015-12-01 14:56 -0600
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-01 22:11 +0100
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 03:01 -0800
Re: // comments and \ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-02 00:45 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 07:52 -0700
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 15:19 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 08:29 -0700
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 15:35 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 09:21 -0700
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 16:41 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 10:15 -0700
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 17:24 +0000
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 17:43 +0000
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 03:05 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-02 11:40 +0000
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-02 04:29 -0800
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-01 19:11 +0000
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-01 20:43 +0000
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-01 21:04 +0000
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-01 21:16 +0000
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 03:12 -0800
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-02 11:52 +0000
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-02 04:40 -0800
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-02 13:55 +0100
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-02 13:56 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-02 15:24 +0100
Re: // comments and \ supercat@casperkitty.com - 2015-12-02 06:54 -0800
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-02 16:40 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-02 18:24 +0000
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-02 20:27 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-02 23:22 -0800
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-03 00:57 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-03 23:44 +0000
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-03 21:17 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 00:43 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-04 20:32 -0600
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 16:06 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-05 13:10 -0600
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 10:18 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-06 14:26 -0600
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-03 12:45 +0100
Re: // comments and \ raltbos@xs4all.nl (Richard Bos) - 2015-12-04 11:45 +0000
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-04 04:20 -0800
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-04 14:20 +0100
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-04 10:05 -0500
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-04 17:31 +0100
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-04 17:24 -0600
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-04 18:50 -0500
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-04 20:34 -0600
Re: // comments and \ raltbos@xs4all.nl (Richard Bos) - 2015-12-10 20:40 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-04 09:36 -0800
Re: // comments and \ Richard Damon <Richard@Damon-Family.org> - 2015-12-05 09:05 -0500
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 17:42 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-06 22:23 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-07 21:59 +0000
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 15:50 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-05 18:17 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 10:01 +0000
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-06 03:05 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-06 04:07 -0800
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-06 04:37 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-06 05:05 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-06 12:19 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 13:59 +0000
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-06 06:09 -0800
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-06 07:30 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 18:55 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-06 12:23 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-06 12:22 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 21:06 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-05 13:14 -0600
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 10:09 +0000
Re: // comments and \ mark.bluemel@gmail.com - 2015-12-03 06:15 -0800
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-02 08:28 -0700
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-02 09:01 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-02 21:52 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-02 16:55 -0800
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-03 13:11 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-03 23:21 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-04 11:22 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 01:12 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-04 20:39 -0600
Re: // comments and \ raltbos@xs4all.nl (Richard Bos) - 2015-12-04 11:14 +0000
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-04 12:25 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-04 14:23 +0100
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 09:00 -0800
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 19:46 +0000
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 20:36 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 20:37 -0700
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-01 14:26 +0000
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 14:32 +0000
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-01 14:52 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-01 16:15 +0100
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 15:28 +0000
Re: // comments and \ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-02 01:26 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 09:12 -0800
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 19:17 +0000
Re: // comments and \ Robert Wessel <robertwessel2@yahoo.com> - 2015-12-01 12:32 -0600
Re: // comments and \ Nobody <nobody@nowhere.invalid> - 2015-12-02 00:01 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-02 07:08 -0800
Re: // comments and \ Nobody <nobody@nowhere.invalid> - 2015-12-02 21:05 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-02 14:22 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-02 14:48 -0800
Re: // comments and \ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-02 23:37 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-02 17:10 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-02 19:24 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-03 04:10 +0000
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 21:49 -0800
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-03 07:28 -0700
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 09:12 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 06:53 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 15:41 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-03 15:56 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 16:44 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-03 17:29 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 19:10 -0800
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 21:59 -0800
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 07:52 -0700
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 09:21 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 17:26 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 10:50 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 10:49 -0800
Re: // comments and \ Geoff <geoff@invalid.invalid> - 2015-12-01 11:34 -0800
Re: // comments and \ David Thompson <dave.thompson2@verizon.net> - 2015-12-22 06:44 -0500
Re: // comments and \ "Charles Richmond" <numerist@aquaporin4.com> - 2015-12-23 14:35 -0600
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-23 13:00 -0800
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-23 16:58 -0500
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-23 14:21 -0800
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-23 16:55 -0500
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-01 12:24 -0800
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-02 07:08 -0800 |
| Message-ID | <46229a54-c99c-4682-9536-387bdff39d88@googlegroups.com> |
| In reply to | #77580 |
On Tuesday, December 1, 2015 at 6:01:08 PM UTC-6, Nobody wrote: > So e.g. a code generator or VCS client which needs to write files on a > system which limits lines to 80 characters only needs to undertand > encodings and trigraphs (so that it doesn't try to break a line in the > middle of one). With that knowledge, it can just insert backslash-newline > pairs as necessary to stay within the 80-character limit. It doesn't need > to know about any higher-level syntax, because that doesn't come into play > until line continuations have been processed. I still fail to see the need for such things to be part of the language specification. One could define the language in terms a newline-delimited file containing members of the C character set, and any additional characters that an implementation may see fit to provide within literals and constants, and then say that implementations may then define whatever means they see fit to map their file storage to that form. An implementation which uses fixed 80-character records would then be free to e.g. use fixed 80-character records but say that the system will treat every record after the first as though it had a preceding newline unless it starts with two dollar sign characters, and will ignore any trailing blanks, or a trailing dollar sign in other contexts. In case code might want to use dollar signs within string literals or comments, they would need to be written as $D$. Given such a rule, C source files for other systems could be converted to C source files for the aforementioned system, and vice versa. No need to pollute the language specification with such a thing.
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.invalid> |
|---|---|
| Date | 2015-12-02 21:05 +0000 |
| Message-ID | <pan.2015.12.02.21.05.51.291000@nowhere.invalid> |
| In reply to | #77621 |
On Wed, 02 Dec 2015 07:08:28 -0800, supercat wrote: > I still fail to see the need for such things to be part of the language > specification. Well, they don't strictly *need* to be part of the language specification, but putting them there avoids the situation where everyone rolls their own solution. I'll just point out that platform-specific issues relating to text files were enough of a problem for enough people that digraphs made it into C99 and trigraphs have survived a number of attempts at removing them (although it appears that they will become an implementation-dependent option in C++17).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-02 14:22 -0800 |
| Message-ID | <ln7fkwsd7z.fsf@kst-u.example.com> |
| In reply to | #77663 |
Nobody <nobody@nowhere.invalid> writes:
> On Wed, 02 Dec 2015 07:08:28 -0800, supercat wrote:
>> I still fail to see the need for such things to be part of the language
>> specification.
>
> Well, they don't strictly *need* to be part of the language specification,
> but putting them there avoids the situation where everyone rolls their own
> solution.
>
> I'll just point out that platform-specific issues relating to text files
> were enough of a problem for enough people that digraphs made it into C99
> and trigraphs have survived a number of attempts at removing them
> (although it appears that they will become an implementation-dependent
> option in C++17).
Trigraphs were introduced in ANSI C89. Digraphs were added by the 1995
amendment.
--
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]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-02 14:48 -0800 |
| Message-ID | <b0b51219-f457-4fe3-9e72-e511b61dc262@googlegroups.com> |
| In reply to | #77663 |
On Wednesday, December 2, 2015 at 3:05:51 PM UTC-6, Nobody wrote: > Well, they don't strictly *need* to be part of the language specification, > but putting them there avoids the situation where everyone rolls their own > solution. Or else the makers of various platforms offer recommended approaches for use with those platforms. Trigraphs are so nasty and ugly that I can't imagine anyone wanting to actually type or read them. One might plausibly have a program which translates some platform-specific alternate characters to trigraphs, but I don't really see any advantage to that versus translating platform-specific alternate characters to characters a compiler will accept directly. I don't think trigraphs relieve a compiler of a requirement to designate a unique character code for every character in the C character set, since char foo = '??/??/`; has to set foo to some positive number. I suppose it might be possible to have a cross-compiler whose host character set doesn't have any character code that behaves as backslash, but whose target character set does have a code designated as one, but that would seem rather weird.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-12-02 23:37 +0000 |
| Message-ID | <n3nvbl$45t$1@speranza.aioe.org> |
| In reply to | #77678 |
supercat@casperkitty.com wrote: (snip, mostly previously snipped, on // comments) > Trigraphs are so nasty and ugly that I can't imagine anyone wanting to > actually type or read them. One might plausibly have a program which > translates some platform-specific alternate characters to trigraphs, but I > don't really see any advantage to that versus translating platform-specific > alternate characters to characters a compiler will accept directly. I > don't think trigraphs relieve a compiler of a requirement to designate a > unique character code for every character in the C character set, since > char foo = '??/??/`; > has to set foo to some positive number. I suppose it might be possible to > have a cross-compiler whose host character set doesn't have any character > code that behaves as backslash, but whose target character set does have a > code designated as one, but that would seem rather weird. In the 1960's, many computers used six bit codes for character data. C requires an 8 bit (or more) char, but doesn't, as far as I know, have a requirement on the source (compiler input) character set. And even with 8 bit char, the input data might allow for a smaller character set, converted on input and output. I should look at the PDP-10 systems, which store ASCII text five characters in a 36 bit word. There are C compilers that know what to do with it. -- glen
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-02 17:10 -0800 |
| Message-ID | <b184160d-44ed-44d9-a93a-507e37d1096d@googlegroups.com> |
| In reply to | #77680 |
On Wednesday, December 2, 2015 at 5:37:40 PM UTC-6, glen herrmannsfeldt wrote: > C requires an 8 bit (or more) char, but doesn't, as far as I know, > have a requirement on the source (compiler input) character set. I don't know that all 52 letters of the alphabet are used by identifiers defined by the C Standard, but I can't imagine that a conforming implementation would not be required to include at minimum the 52 letters of the alphabet, ten digits, plus sign, minus sign, and a white space, but that's already more than will fit in a 6 bit character. On the other hand, one could practically use C on a platform which only had 64 characters available if the implementation specified that letters or sequences thereof would be interpreted as uppercase or lowercase depending upon the existence of nearby dollar signs.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-12-02 19:24 -0800 |
| Message-ID | <d38f8172-6080-46a3-8e1e-e3a8aa06a350@googlegroups.com> |
| In reply to | #77689 |
On Thursday, December 3, 2015 at 1:10:56 AM UTC, supe...@casperkitty.com wrote: > On Wednesday, December 2, 2015 at 5:37:40 PM UTC-6, glen herrmannsfeldt wrote: > > C requires an 8 bit (or more) char, but doesn't, as far as I know, > > have a requirement on the source (compiler input) character set. > > I don't know that all 52 letters of the alphabet are used by identifiers > defined by the C Standard, but I can't imagine that a conforming > implementation would not be required to include at minimum the 52 letters > of the alphabet, ten digits, plus sign, minus sign, and a white space, but > that's already more than will fit in a 6 bit character. On the other hand, > one could practically use C on a platform which only had 64 characters > available if the implementation specified that letters or sequences thereof > would be interpreted as uppercase or lowercase depending upon the existence > of nearby dollar signs. > In days of yore, it was thought that there wasn't much point building computers to support lower case letters. The ZX81 was probably the last popular computer not to support lower case, in order to save ROM the lower case ASCII slots were used for graphics characters, whilst everything from 128 on was reverse video. You could build up some nice displays. So if you were implementing C, you'd simply translate library calls to upper case. The dollar escape method is unusable, except for computer-to-computer transmission.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-12-03 04:10 +0000 |
| Message-ID | <n3of77$qlk$1@dont-email.me> |
| In reply to | #77699 |
On 03/12/15 03:24, Malcolm McLean wrote: <snip> > In days of yore, it was thought that there wasn't much point building > computers to support lower case letters. That kind of depends on who was doing the thinking. It is so long ago that I read this, that I can no longer remember the source, so I'm going to have to start with "Apparently", which is unfortunate because, when other people use that word, I mentally translate it to "A bloke down the pub told me..." And so, *apparently*, when a paucity of bits per byte (or holes per card, or whatever) meant that a decision had to be made about whether to choose upper case or lower case, a considerable amount of time, effort, and money went into studying the relative readability of the two cases. (The studies /are/ a matter of record and references to them are not difficult to find online: for example, Tinker and Paterson published articles on the subject in 1928, 1932, and 1946.) Lower case won, hands down. And thus the engineers made their recommendation to senior management that lower case should be chosen. Senior management responded that in lower case it is not possible to represent the name of the deity correctly, and so the decision was therefore made in favour of upper case. Of course, it might not be true. Nevertheless it is somehow very, very believable. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-12-02 21:49 -0800 |
| Message-ID | <MPG.30c977df46286032bb@news.eternal-september.org> |
| In reply to | #77700 |
Richard Heathfield wrote: > > On 03/12/15 03:24, Malcolm McLean wrote: > > <snip> > > > In days of yore, it was thought that there wasn't much point building > > computers to support lower case letters. > > That kind of depends on who was doing the thinking. > > It is so long ago that I read this, that I can no longer remember the > source, so I'm going to have to start with "Apparently", which is > unfortunate because, when other people use that word, I mentally > translate it to "A bloke down the pub told me..." > > And so, *apparently*, when a paucity of bits per byte (or holes per > card, or whatever) meant that a decision had to be made about whether to > choose upper case or lower case, a considerable amount of time, effort, > and money went into studying the relative readability of the two cases. > (The studies /are/ a matter of record and references to them are not > difficult to find online: for example, Tinker and Paterson published > articles on the subject in 1928, 1932, and 1946.) Lower case won, hands > down. And thus the engineers made their recommendation to senior > management that lower case should be chosen. Senior management responded > that in lower case it is not possible to represent the name of the deity > correctly, and so the decision was therefore made in favour of upper case. > > Of course, it might not be true. Nevertheless it is somehow very, very > believable. I would find it more believable that senior management responded that in lower case it is not possible to represent *their* names correctly.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2015-12-03 07:28 -0700 |
| Message-ID | <1bsi3j61yk.fsf@pfeifferfamily.net> |
| In reply to | #77705 |
Philip Lantz <prl@canterey.us> writes: > Richard Heathfield wrote: >> >> On 03/12/15 03:24, Malcolm McLean wrote: >> >> <snip> >> >> > In days of yore, it was thought that there wasn't much point building >> > computers to support lower case letters. >> >> That kind of depends on who was doing the thinking. >> >> It is so long ago that I read this, that I can no longer remember the >> source, so I'm going to have to start with "Apparently", which is >> unfortunate because, when other people use that word, I mentally >> translate it to "A bloke down the pub told me..." >> >> And so, *apparently*, when a paucity of bits per byte (or holes per >> card, or whatever) meant that a decision had to be made about whether to >> choose upper case or lower case, a considerable amount of time, effort, >> and money went into studying the relative readability of the two cases. >> (The studies /are/ a matter of record and references to them are not >> difficult to find online: for example, Tinker and Paterson published >> articles on the subject in 1928, 1932, and 1946.) Lower case won, hands >> down. And thus the engineers made their recommendation to senior >> management that lower case should be chosen. Senior management responded >> that in lower case it is not possible to represent the name of the deity >> correctly, and so the decision was therefore made in favour of upper case. >> >> Of course, it might not be true. Nevertheless it is somehow very, very >> believable. > > I would find it more believable that senior management responded that > in lower case it is not possible to represent *their* names correctly. In the case of many senior management members, that could well be the same statement :)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-03 09:12 -0800 |
| Message-ID | <e7de1349-913f-4fdc-b0aa-ad2b45588e02@googlegroups.com> |
| In reply to | #77700 |
On Wednesday, December 2, 2015 at 10:10:54 PM UTC-6, Richard Heathfield wrote: > And so, *apparently*, when a paucity of bits per byte (or holes per > card, or whatever) meant that a decision had to be made about whether to > choose upper case or lower case, a considerable amount of time, effort, > and money went into studying the relative readability of the two cases. Uppercase letters are generally more recognizable as individual glyphs; strings of consecutive lowercase letters are more recognizable as words. The same is true of upper and lowercase numbers (which, for some reason, computers have never supported nearly as well as upper and lowercase letters even though PL/I and COBOL allowed a number in the range -9999 to +9999 to be represented in four columns by punching a - on top of a digit. While the effect of overpunching a - on a 1-9 was to produce a letter J-R, having a second set of digits would have made it possible to print out such numbers in a four-digit field in human-readable form (to avoid adding ten more items to the chain, a chain printer could have an over-bar character and make the alternate digit characters print with an overbar).
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-03 06:53 -0800 |
| Message-ID | <d04a422b-5c15-4974-8948-fb6dd3b20a9f@googlegroups.com> |
| In reply to | #77699 |
On Wednesday, December 2, 2015 at 9:24:48 PM UTC-6, Malcolm McLean wrote: > In days of yore, it was thought that there wasn't much point building > computers to support lower case letters. The ZX81 was probably the last > popular computer not to support lower case, in order to save ROM > the lower case ASCII slots were used for graphics characters, > whilst everything from 128 on was reverse video. You could build > up some nice displays. I don't know that it would have been an issue of "saving ROM"; I think the real goal was to be able to have a rish set of graphics characters and reverse video, using 8-bit memory to select characters and reversed-ness. The Commodore VIC-20 and C-64 (not sure about the PET) had two character sets--one with more graphics characters, and one with upper/lower case, though the set with lower case placed the lowercase characters where the uppercase ones had been and placed the uppercase characters where 26 of the graphics characters had been. It also changed around a few of the other characters for reasons I don't quite understand (e.g. the pi character in "graphics" mode became a 4x4 checkerboard pattern in "upper/lowercase mode"). A 4Kx8 ROM was used to hold both regular and reverse versions of all characters of all sets; there was no effort to e.g. use a smaller ROM and an XOR gate to handle reverse characters.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-03 15:41 -0800 |
| Message-ID | <0fd366e1-efcc-478b-bb6c-4fcda46d484b@googlegroups.com> |
| In reply to | #77699 |
On Wednesday, December 2, 2015 at 9:24:48 PM UTC-6, Malcolm McLean wrote:
> The dollar escape method is unusable, except for
> computer-to-computer transmission.
Would a rule saying that regarded dollar signs as an extension of the C
character set which was alphanumeric but must appear an even number of times
within an identifier or string literal, and which would serve as an uppercase
toggle therein, be any less workable than the horrid trigraph sequences of
C89?
To my mind, something like:
#INCLUDE <STDIO.H>
#DEFINE $FILENAME$ "MAGIC.TXT"
INT MAIN(VOID)
{
$FILE$ *MY_FILE;
MY_FILE = FOPEN($FILENAME$, "RB");
FPRINTF(MY_FILE, "THIS IS NOMINALLY LOWERCASE $AND THIS IS UPPERCASE$.");
}
would seem pretty reasonable. If code is running on something like an Apple
II where codes 97 to 122 appear like codes 33-58, it might have to do
something like set the MSB for uppercase letters and filter it out when
writing to the console, but setting the MSB would allow things like "printf"
to distinguish between "%$L$d" and "%ld".
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-12-03 15:56 -0800 |
| Message-ID | <b8e94f04-11ee-458b-ab28-a275eca16da1@googlegroups.com> |
| In reply to | #77784 |
On Thursday, December 3, 2015 at 11:41:23 PM UTC, supe...@casperkitty.com wrote:
> On Wednesday, December 2, 2015 at 9:24:48 PM UTC-6, Malcolm McLean wrote:
> > The dollar escape method is unusable, except for
> > computer-to-computer transmission.
>
> Would a rule saying that regarded dollar signs as an extension of the C
> character set which was alphanumeric but must appear an even number of times
> within an identifier or string literal, and which would serve as an uppercase
> toggle therein, be any less workable than the horrid trigraph sequences of
> C89?
>
> To my mind, something like:
>
> #INCLUDE <STDIO.H>
>
> #DEFINE $FILENAME$ "MAGIC.TXT"
>
> INT MAIN(VOID)
> {
> $FILE$ *MY_FILE;
> MY_FILE = FOPEN($FILENAME$, "RB");
> FPRINTF(MY_FILE, "THIS IS NOMINALLY LOWERCASE $AND THIS IS UPPERCASE$.");
> }
>
> would seem pretty reasonable. If code is running on something like an Apple
> II where codes 97 to 122 appear like codes 33-58, it might have to do
> something like set the MSB for uppercase letters and filter it out when
> writing to the console, but setting the MSB would allow things like "printf"
> to distinguish between "%$L$d" and "%ld".
>
It's certainly more usable than escaping every upper case letter.
Presumably a filter that converts between escaped and ascii is
trivial to write.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-03 16:44 -0800 |
| Message-ID | <ad0dc4ef-bcc7-48f0-a465-3bf7a3eda13c@googlegroups.com> |
| In reply to | #77786 |
On Thursday, December 3, 2015 at 5:56:44 PM UTC-6, Malcolm McLean wrote: > It's certainly more usable than escaping every upper case letter. > Presumably a filter that converts between escaped and ascii is > trivial to write. Not only that; I'd expect the natural behavior for a C compiler on such a system would be to perform such processing automatically on text-mode streams. If one regards an "uppercase" at-sign as being ASCII code 0x24, then one could say that on input a dollar sign switches between uppercase and lowercase mode (probably resetting every newline), and outputting a character whose case doesn't match the previous one will output a dollar sign first; some characters will allow the output to remain in "uppercase" mode, but most would force it to lowercase first. If one took that approach, a utility which opened an input file in text mode and an output file in binary mode and simply copied data from one to the other would convert uppercase text with escapes to upper/lowercase text (which the system might not be able to display or edit correctly); reversing the roles of text and binary files would convert a file with upper/lowercase text to one with uppercase text and escapes. BTW, are trigraphs intended to be used by humans or machines? They seem to nasty-looking for use by humans, but if humans can type characters which machines can turn into trigraphs, why not have the machines simply output the proper characters to begin with?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-12-03 17:29 -0800 |
| Message-ID | <de8ef75c-4699-490b-9615-ad5376b128dc@googlegroups.com> |
| In reply to | #77792 |
On Friday, December 4, 2015 at 12:44:19 AM UTC, supe...@casperkitty.com wrote: > > BTW, are trigraphs intended to be used by humans or machines? They seem > to nasty-looking for use by humans, but if humans can type characters which > machines can turn into trigraphs, why not have the machines simply output > the proper characters to begin with? > People used to talk of "ASCII" or "EBCDIC" machines. That was because screens were character-mapped, and file systems were very specific to the operating system. If you didn't have a character in ROM, there was essentially no way of processing it, other than undesireable workarounds like trigraphs. Often you didn't even have a character-mapped screen. You had a printer with a daisywheel containing your characters. The idea survives in C with the concept of the "execution character set". However nowadays we are far less likely to think like that. We think of EBCDIC data, and it's not especially problematic, just another format. The display is raster mapped, it's not possible that the machine cannot display a character, only that the software it happens to be running doesn't contain that graphic.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-03 19:10 -0800 |
| Message-ID | <9dfe36f5-5e16-4347-92ef-a5aa30090386@googlegroups.com> |
| In reply to | #77794 |
On Thursday, December 3, 2015 at 7:29:50 PM UTC-6, Malcolm McLean wrote:
> People used to talk of "ASCII" or "EBCDIC" machines. That was because
> screens were character-mapped, and file systems were very specific
> to the operating system. If you didn't have a character in ROM, there
> was essentially no way of processing it, other than undesireable
> workarounds like trigraphs.
What matters is not whether there is are characters that looks like a
particular member of the C character set, but rather whether there's one
that will act like such a member. If one is using a terminal which mostly
uses ASCII, but whose rendering of 0x23 looks like a British pound sign,
0x5C looks like a Japanese yen sign, and 0x5F looks like a back-arrow,
then one might have to type code as:
£define SCALE←FACTOR 2.54
int main(void)
{
printf("The number is %f¥n", SCALE←FACTOR * dimension);
}
but so what? One would simply have to learn that certain characters look
weird, but they're still no worse than the trigraph replacements.
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-12-02 21:59 -0800 |
| Message-ID | <MPG.30c97a244aa8769abc@news.eternal-september.org> |
| In reply to | #77621 |
supercat@casperkitty.com wrote: > I still fail to see the need for such things to be part of the language > specification. They needed to be, because back in the mid-1980s, it was far from clear that the C language specification would be widely accepted, and in order to help ensure that it was, the standard's authors added features that were suggested/requested/demanded by various groups of people to gain their support. In other words, it was political. In some cases, the groups of people were C users in non-English speaking countries that had developed various ways to deal with the character set issues. In other cases, the groups of people were vendors of certain types of computer systems, that stored text files in ways very unlike they were stored on Unix. Now that they're in there, they're way harder to get rid of than you could possibly imagine.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2015-12-01 07:52 -0700 |
| Message-ID | <1b37vmfch5.fsf@pfeifferfamily.net> |
| In reply to | #77503 |
BartC <bc@freeuk.com> writes:
> This is a problem I came across with an assembler, which caused me
> some trouble to sort out.
>
> Then I thought I'd try it with C, convinced it couldn't be as silly,
> but apparently it was!
>
> Here:
>
> // this is a comment ... \
> puts("Hi!");
>
> the continuation character at the end of the comment means the
> following line isn't compiled (which can give puzzling results as you
> can imagine).
>
> But, is there any reason for it to behave this way?
>
> A // comment you would expect to ignore everything to the end of the
> line, especially when it occupies the whole line. Where there are
> statements at the start, then the \ is best placed before the //
> comment IMO as it is part of the actual code.
>
> (You shouldn't have to be aware of the content of a comment. Maybe
> someone else wrote it. Maybe the end of it extends beyond the right
> edge of the screen and you can't see the \ without scrolling; why
> would you? In my case, the comment was automatically placed and it
> happened to have \ at the end.)
The behavior you're describing is what I'd expect, both intuitively (why
did you put a line continuation at the end of a line you didn't want to
continue?) and according to the definition of the second translation
phase in section 5.1.1.2 of the standard:
2. Each instance of a backslash character (\) immediately followed by a new-line
character is deleted, splicing physical source lines to form logical source lines.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-01 09:21 -0800 |
| Message-ID | <lnfuzmultj.fsf@kst-u.example.com> |
| In reply to | #77503 |
BartC <bc@freeuk.com> writes:
> This is a problem I came across with an assembler, which caused me some
> trouble to sort out.
>
> Then I thought I'd try it with C, convinced it couldn't be as silly, but
> apparently it was!
>
> Here:
>
> // this is a comment ... \
> puts("Hi!");
>
> the continuation character at the end of the comment means the following
> line isn't compiled (which can give puzzling results as you can imagine).
[...]
It's actually a bit worse than that. Consider this program:
#include <stdio.h>
int main(void) {
// \
puts("This is a comment");
puts("This is not a comment");
}
You can't see it, but there's a space after the backslash on line 3
(assuming it's not stripped by somebody's news software). Because the
line doesn't end with a backslash, it's not a continuation line, so the
output *should* be:
This is not a comment
tcc produces that output, but both gcc and clang ignore the trailing
blank and produce this output:
This is a comment
This is not a comment
(clang warns about the trailing space.)
I prefer the gcc/clang behavior, but it's not consistent with the
standard -- though I suppose you could argue that the trailing blanks
could be removed in translation phase 1.
In any case, the solution is straightforward: Don't Do That.
--
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]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web