Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #67230 > unrolled thread
| Started by | fl <rxjwg98@gmail.com> |
|---|---|
| First post | 2015-08-12 15:28 -0700 |
| Last post | 2015-08-14 09:03 -0700 |
| Articles | 20 on this page of 164 — 27 participants |
Back to article view | Back to comp.lang.c
How to read a data file whose size is unknown in C? fl <rxjwg98@gmail.com> - 2015-08-12 15:28 -0700
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-12 23:52 +0100
Re: How to read a data file whose size is unknown in C? fl <rxjwg98@gmail.com> - 2015-08-12 16:13 -0700
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-13 00:33 +0100
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-13 00:06 +0000
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-13 20:50 +0000
Re: How to read a data file whose size is unknown in C? Stephen Sprunk <stephen@sprunk.org> - 2015-08-17 13:38 -0500
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-17 14:48 -0400
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-18 11:10 +0100
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-18 15:01 +0100
Re: How to read a data file whose size is unknown in C? gordonb.8n5lc@burditt.org (Gordon Burditt) - 2015-08-14 02:33 -0500
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-14 10:06 +0200
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-14 09:14 +0100
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-14 21:27 +0000
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 09:52 +0200
Re: How to read a data file whose size is unknown in C? Nobody <nobody@nowhere.invalid> - 2015-08-15 01:17 +0100
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 10:27 +0200
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-15 18:09 +0000
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 22:05 +0200
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 19:17 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 13:50 -0700
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-15 21:37 +0100
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 23:33 +0200
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-15 22:58 +0100
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-16 00:08 +0200
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-16 00:40 +0100
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-16 02:23 +0200
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 19:37 -0700
Re: How to read a data file whose size is unknown in C? gazelle@shell.xmission.com (Kenny McCormack) - 2015-08-16 15:35 +0000
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-16 10:31 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 19:21 -0700
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 23:31 +0200
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-16 03:38 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-16 17:29 -0700
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-17 01:46 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-17 09:03 -0700
Re: How to read a data file whose size is unknown in C? Nobody <nobody@nowhere.invalid> - 2015-08-16 03:23 +0100
Re: How to read a data file whose size is unknown in C? Philip Lantz <prl@canterey.us> - 2015-08-17 00:56 -0700
Re: How to read a data file whose size is unknown in C? Philip Lantz <prl@canterey.us> - 2015-08-17 01:08 -0700
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-17 10:20 +0200
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-17 09:01 -0700
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-15 11:31 +0100
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 14:01 -0700
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-15 22:28 +0100
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 19:29 -0700
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-16 10:50 +0100
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-16 17:40 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-16 20:22 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-16 21:27 -0700
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-17 01:31 -0700
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-17 20:25 +0000
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-17 16:29 -0700
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-17 23:43 +0000
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-17 18:20 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-17 19:10 -0700
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-18 05:26 +0000
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:23 +0000
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-18 04:23 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-18 17:39 -0700
Re: How to read a data file whose size is unknown in C? Ike Naar <ike@iceland.freeshell.org> - 2015-08-18 16:49 +0000
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-18 17:42 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-18 19:57 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-19 16:12 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-19 18:04 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-20 16:52 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-20 18:18 -0700
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-21 20:39 +0000
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-21 17:17 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-21 19:35 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-22 18:28 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-22 22:43 -0700
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-22 00:07 -0400
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-22 18:59 -0700
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-22 23:22 -0400
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-23 19:17 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-23 21:35 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-24 16:59 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-24 17:57 -0700
Re: How to read a data file whose size is unknown in C? Philip Lantz <prl@canterey.us> - 2015-08-25 01:09 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-25 19:03 -0700
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-25 22:16 -0400
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-26 14:29 -0700
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-26 18:28 -0400
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-26 19:25 -0700
Re: How to read a data file whose size is unknown in C? David Brown <david.brown@hesbynett.no> - 2015-08-27 10:07 +0200
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-27 09:18 -0700
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-27 18:04 +0000
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-27 11:15 -0700
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-27 21:10 +0000
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-27 15:54 -0700
Re: How to read a data file whose size is unknown in C? David Brown <david.brown@hesbynett.no> - 2015-08-28 09:28 +0200
Re: How to read a data file whose size is unknown in C? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-08-27 13:12 -0600
Re: How to read a data file whose size is unknown in C? David Brown <david.brown@hesbynett.no> - 2015-08-28 09:35 +0200
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-25 04:28 -0700
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-24 00:19 -0400
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-24 00:31 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-24 17:06 -0700
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:25 +0000
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-22 10:45 -0400
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-21 17:40 -0400
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-19 00:40 -0400
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-19 05:38 +0000
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-19 10:20 -0400
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:22 +0000
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:21 +0000
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-14 08:48 -0400
Re: How to read a data file whose size is unknown in C? fl <rxjwg98@gmail.com> - 2015-08-12 16:21 -0700
Re: How to read a data file whose size is unknown in C? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-08-12 19:44 -0600
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-12 22:04 -0400
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-13 00:44 +0100
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-13 01:04 +0100
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-13 11:31 +0100
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-13 11:51 +0100
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-13 08:49 -0700
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-13 17:45 +0100
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-14 11:11 +0100
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-14 11:34 +0100
Re: How to read a data file whose size is unknown in C? Robert Wessel <robertwessel2@yahoo.com> - 2015-08-14 12:21 -0500
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-14 19:07 +0100
Re: How to read a data file whose size is unknown in C? Robert Wessel <robertwessel2@yahoo.com> - 2015-08-14 16:08 -0500
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 09:51 +0200
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-15 12:36 -0700
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 22:26 +0200
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:26 +0000
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-22 08:11 -0700
Re: How to read a data file whose size is unknown in C? Robert Wessel <robertwessel2@yahoo.com> - 2015-08-16 00:05 -0500
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-16 09:08 -0400
Re: How to read a data file whose size is unknown in C? gazelle@shell.xmission.com (Kenny McCormack) - 2015-08-16 15:22 +0000
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-16 17:28 -0700
Re: How to read a data file whose size is unknown in C? Tonton Th <tTh@nowhere.invalid> - 2015-08-14 11:06 +0000
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-14 09:28 -0700
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-13 18:56 +0000
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-13 13:39 -0700
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-14 00:21 +0100
Re: How to read a data file whose size is unknown in C? Ian Collins <ian-news@hotmail.com> - 2015-08-14 12:26 +1200
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-14 11:00 +0100
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-14 11:30 +0100
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-14 12:31 +0100
Re: How to read a data file whose size is unknown in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 04:51 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-14 09:21 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-14 09:23 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-14 16:57 -0700
Re: How to read a data file whose size is unknown in C? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-08-15 14:49 -0600
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 19:31 -0700
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-14 00:35 +0100
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-14 08:57 -0700
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-14 17:28 +0100
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-13 00:12 +0000
Re: How to read a data file whose size is unknown in C? Lőrinczy Zsigmond <nospam@for.me> - 2015-08-13 07:03 +0200
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-13 12:38 +0200
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 13:32 +0100
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-13 14:49 +0200
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-13 14:05 +0100
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 14:50 +0100
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-13 09:14 -0700
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-13 12:42 -0400
Re: How to read a data file whose size is unknown in C? Ken Brody <kenbrody@spamcop.net> - 2015-08-13 10:56 -0400
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-13 09:16 -0700
Re: How to read a data file whose size is unknown in C? Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-08-13 18:12 +0200
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-13 12:50 -0400
Re: How to read a data file whose size is unknown in C? Lőrinczy Zsigmond <nospam@for.me> - 2015-08-13 20:07 +0200
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-13 14:38 -0400
Re: How to read a data file whose size is unknown in C? John Bode <jfbode1029@gmail.com> - 2015-08-13 09:30 -0700
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-14 09:03 -0700
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-18 17:42 -0700 |
| Message-ID | <271c85af-1480-4ee9-9102-9cab995c69a8@googlegroups.com> |
| In reply to | #67735 |
On Tuesday, August 18, 2015 at 9:51:00 AM UTC-7, Ike Naar wrote: > On 2015-08-18, David Kleinecke <dkleinecke@gmail.com> wrote: > > Alternativly I could some other non-ASCII character (CTRL-Z, for example > > for soft EOL. > > CTRL-Z *is* an ASCII character (SUB, code point 26(decimal) or 1A(hex)). As elsewhere - a bag of tells. What's your name for the letters we actually use (hint: not printable)?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-18 19:57 -0700 |
| Message-ID | <lnzj1o2deq.fsf@kst-u.example.com> |
| In reply to | #67777 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Tuesday, August 18, 2015 at 9:51:00 AM UTC-7, Ike Naar wrote:
>> On 2015-08-18, David Kleinecke <dkleinecke@gmail.com> wrote:
>> > Alternativly I could some other non-ASCII character (CTRL-Z, for example
>> > for soft EOL.
>>
>> CTRL-Z *is* an ASCII character (SUB, code point 26(decimal) or 1A(hex)).
>
> As elsewhere - a bag of tells. What's your name for the letters we
> actually use (hint: not printable)?
The *letters* we actually use are called letters. If you mean the
characters we actually use, you'll have to be more specific.
Perhaps you're referring to C's basic execution character set?
--
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 | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-19 16:12 -0700 |
| Message-ID | <629d31c7-2c94-48d3-b567-81fc041f7a5c@googlegroups.com> |
| In reply to | #67780 |
On Tuesday, August 18, 2015 at 7:14:06 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > On Tuesday, August 18, 2015 at 9:51:00 AM UTC-7, Ike Naar wrote: > >> On 2015-08-18, David Kleinecke <dkleinecke@gmail.com> wrote: > >> > Alternativly I could some other non-ASCII character (CTRL-Z, for example > >> > for soft EOL. > >> > >> CTRL-Z *is* an ASCII character (SUB, code point 26(decimal) or 1A(hex)). > > > > As elsewhere - a bag of tells. What's your name for the letters we > > actually use (hint: not printable)? > > The *letters* we actually use are called letters. If you mean the > characters we actually use, you'll have to be more specific. > Perhaps you're referring to C's basic execution character set? > > -- > 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" I was thinking in terms of a text. A text is written in an alphabet. The alphabets I am contemplating use some of the 256 different bytes. The most familiar one in the C alphabet which would be the 5.2.1 or perhaps also the 5.2.2 set. I don't care. I don't mcuh care which character is used for which purpose so long as the map one-to-one. A text IMO needs at least two distinguished bytes in its alphabet - a null to mark the end (I find 0 quite satisfactory) and an internal separator (and end-of-line, a C \n). I find it rather amazing that only one internal separator is enough the format some rather complex texts but we've that most of a half century testing the idea and it seems to work. Of course, for elegant presentations more machinery is needed - like the whole SGML family - but that is a not matter for C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-19 18:04 -0700 |
| Message-ID | <lnr3my3h49.fsf@kst-u.example.com> |
| In reply to | #67857 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Tuesday, August 18, 2015 at 7:14:06 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> > On Tuesday, August 18, 2015 at 9:51:00 AM UTC-7, Ike Naar wrote:
>> >> On 2015-08-18, David Kleinecke <dkleinecke@gmail.com> wrote:
>> >> > Alternativly I could some other non-ASCII character (CTRL-Z, for example
>> >> > for soft EOL.
>> >>
>> >> CTRL-Z *is* an ASCII character (SUB, code point 26(decimal) or 1A(hex)).
>> >
>> > As elsewhere - a bag of tells. What's your name for the letters we
>> > actually use (hint: not printable)?
>>
>> The *letters* we actually use are called letters. If you mean the
>> characters we actually use, you'll have to be more specific.
>> Perhaps you're referring to C's basic execution character set?
>
> I was thinking in terms of a text. A text is written in an alphabet. The
> alphabets I am contemplating use some of the 256 different bytes. The
> most familiar one in the C alphabet which would be the 5.2.1 or perhaps
> also the 5.2.2 set. I don't care. I don't mcuh care which character is
> used for which purpose so long as the map one-to-one.
The word "alphabet" is perhaps not the best choice for what you're
trying to say. The word often refers to just letters; see for example,
the isalpha() function.
> A text IMO needs at least two distinguished bytes in its alphabet - a
> null to mark the end (I find 0 quite satisfactory) and an internal
> separator (and end-of-line, a C \n). I find it rather amazing that only
> one internal separator is enough the format some rather complex texts
> but we've that most of a half century testing the idea and it seems to
> work. Of course, for elegant presentations more machinery is needed -
> like the whole SGML family - but that is a not matter for C.
Text stored in a file does not need an end marker on most operating
systems. Typically the file system just records the length. In memory,
a *string* of course requires a '\0' terminator, but text can be stored
in other formats than strings.
I still don't understand your question.
--
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 | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-20 16:52 -0700 |
| Message-ID | <b809090b-1964-48f9-8b8e-a8e78d17b934@googlegroups.com> |
| In reply to | #67861 |
On Wednesday, August 19, 2015 at 5:13:07 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > On Tuesday, August 18, 2015 at 7:14:06 PM UTC-7, Keith Thompson wrote: > >> David Kleinecke <dkleinecke@gmail.com> writes: > >> > On Tuesday, August 18, 2015 at 9:51:00 AM UTC-7, Ike Naar wrote: > >> >> On 2015-08-18, David Kleinecke <dkleinecke@gmail.com> wrote: > >> >> > Alternativly I could some other non-ASCII character (CTRL-Z, for example > >> >> > for soft EOL. > >> >> > >> >> CTRL-Z *is* an ASCII character (SUB, code point 26(decimal) or 1A(hex)). > >> > > >> > As elsewhere - a bag of tells. What's your name for the letters we > >> > actually use (hint: not printable)? > >> > >> The *letters* we actually use are called letters. If you mean the > >> characters we actually use, you'll have to be more specific. > >> Perhaps you're referring to C's basic execution character set? > > > > I was thinking in terms of a text. A text is written in an alphabet. The > > alphabets I am contemplating use some of the 256 different bytes. The > > most familiar one in the C alphabet which would be the 5.2.1 or perhaps > > also the 5.2.2 set. I don't care. I don't mcuh care which character is > > used for which purpose so long as the map one-to-one. > > The word "alphabet" is perhaps not the best choice for what you're > trying to say. The word often refers to just letters; see for example, > the isalpha() function. Alphabet is the usual word for whatever character ste a text is using. > > A text IMO needs at least two distinguished bytes in its alphabet - a > > null to mark the end (I find 0 quite satisfactory) and an internal > > separator (and end-of-line, a C \n). I find it rather amazing that only > > one internal separator is enough the format some rather complex texts > > but we've that most of a half century testing the idea and it seems to > > work. Of course, for elegant presentations more machinery is needed - > > like the whole SGML family - but that is a not matter for C. > > Text stored in a file does not need an end marker on most operating > systems. Typically the file system just records the length. In memory, > a *string* of course requires a '\0' terminator, but text can be stored > in other formats than strings. Of course, any representation of a text that can differentiate between all the letters of the alphabet has the same content. I do not consider compressed versions - even lossless ones - the same text. If I am reading through a text it usually easier to detect a sentinel than count. If I thought there was any alphabet that couldn't add a null I would take a different point of view. But I don't so I just assume a sentinel (end-of-file) character and call it null. I don't see what's bothering you.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-20 18:18 -0700 |
| Message-ID | <lnoai11lry.fsf@kst-u.example.com> |
| In reply to | #67918 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Wednesday, August 19, 2015 at 5:13:07 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> > On Tuesday, August 18, 2015 at 7:14:06 PM UTC-7, Keith Thompson wrote:
>> >> David Kleinecke <dkleinecke@gmail.com> writes:
>> >> > On Tuesday, August 18, 2015 at 9:51:00 AM UTC-7, Ike Naar wrote:
>> >> >> On 2015-08-18, David Kleinecke <dkleinecke@gmail.com> wrote:
>> >> >> > Alternativly I could some other non-ASCII character (CTRL-Z, for example
>> >> >> > for soft EOL.
>> >> >>
>> >> >> CTRL-Z *is* an ASCII character (SUB, code point 26(decimal) or 1A(hex)).
>> >> >
>> >> > As elsewhere - a bag of tells. What's your name for the letters we
>> >> > actually use (hint: not printable)?
>> >>
>> >> The *letters* we actually use are called letters. If you mean the
>> >> characters we actually use, you'll have to be more specific.
>> >> Perhaps you're referring to C's basic execution character set?
>> >
>> > I was thinking in terms of a text. A text is written in an alphabet. The
>> > alphabets I am contemplating use some of the 256 different bytes. The
>> > most familiar one in the C alphabet which would be the 5.2.1 or perhaps
>> > also the 5.2.2 set. I don't care. I don't mcuh care which character is
>> > used for which purpose so long as the map one-to-one.
>>
>> The word "alphabet" is perhaps not the best choice for what you're
>> trying to say. The word often refers to just letters; see for example,
>> the isalpha() function.
>
> Alphabet is the usual word for whatever character ste a text is using.
It's *a* word for it. It's also a word for the a set of letters. But
ok, by "alphabet" you mean "character set".
>> > A text IMO needs at least two distinguished bytes in its alphabet - a
>> > null to mark the end (I find 0 quite satisfactory) and an internal
>> > separator (and end-of-line, a C \n). I find it rather amazing that only
>> > one internal separator is enough the format some rather complex texts
>> > but we've that most of a half century testing the idea and it seems to
>> > work. Of course, for elegant presentations more machinery is needed -
>> > like the whole SGML family - but that is a not matter for C.
>>
>> Text stored in a file does not need an end marker on most operating
>> systems. Typically the file system just records the length. In memory,
>> a *string* of course requires a '\0' terminator, but text can be stored
>> in other formats than strings.
>
> Of course, any representation of a text that can differentiate
> between all the letters of the alphabet has the same content. I do not
> consider compressed versions - even lossless ones - the same text.
>
> If I am reading through a text it usually easier to detect a sentinel
> than count. If I thought there was any alphabet that couldn't add a
> null I would take a different point of view. But I don't so I just
> assume a sentinel (end-of-file) character and call it null.
>
> I don't see what's bothering you.
Let's go back to your question from upthread:
>> >> David Kleinecke <dkleinecke@gmail.com> writes:
>> >> > On Tuesday, August 18, 2015 at 9:51:00 AM UTC-7, Ike Naar wrote:
>> >> >> On 2015-08-18, David Kleinecke <dkleinecke@gmail.com> wrote:
>> >> >> > Alternativly I could some other non-ASCII character (CTRL-Z, for example
>> >> >> > for soft EOL.
>> >> >>
>> >> >> CTRL-Z *is* an ASCII character (SUB, code point 26(decimal) or 1A(hex)).
>> >> >
>> >> > As elsewhere - a bag of tells. What's your name for the letters we
>> >> > actually use (hint: not printable)?
I still don't know what you were asking. Would you care to rephrase the
question? Or we can just drop it and move on to other things.
--
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 | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-08-21 20:39 +0000 |
| Message-ID | <55d78c72.14914812@news.xs4all.nl> |
| In reply to | #67918 |
David Kleinecke <dkleinecke@gmail.com> wrote:
> On Wednesday, August 19, 2015 at 5:13:07 PM UTC-7, Keith Thompson wrote:
> > The word "alphabet" is perhaps not the best choice for what you're
> > trying to say. The word often refers to just letters; see for example,
> > the isalpha() function.
>
> Alphabet is the usual word for whatever character ste a text is using.
'.' and '(' are in your alphabet?
Richard
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-21 17:17 -0700 |
| Message-ID | <19583d3f-fb29-496b-8f45-df750bc222ac@googlegroups.com> |
| In reply to | #67963 |
On Friday, August 21, 2015 at 1:39:57 PM UTC-7, Richard Bos wrote:
> David Kleinecke <dkleinecke@gmail.com> wrote:
>
> > On Wednesday, August 19, 2015 at 5:13:07 PM UTC-7, Keith Thompson wrote:
>
> > > The word "alphabet" is perhaps not the best choice for what you're
> > > trying to say. The word often refers to just letters; see for example,
> > > the isalpha() function.
> >
> > Alphabet is the usual word for whatever character ste a text is using.
>
> '.' and '(' are in your alphabet?
>
> Richard
Be careful here "text" includes a lot of things like Chinese writing
and Sumerian and Egyptian (see Unicode - they may even include the
figures on an Easter Island taking biard by now).
The crucial attribute of a text is that it is a sequence of glyphs -
written in a book, carved on a rock, you name it). If presented with
a text I haven't seen before I count the different glyphs (not always
easy). The set of all different glyphs is the alphabet of the text.
The alphabet the C standard is thinking of contains the 91 glyphs
listed in 5.2.1 plus the space character. These 92 glyphs are encoded
as byte values in a way the standard leaves us to guess is what is
called the ANSII character set. The standard adds some byte values that
that are encoded by glyph pairs.
My question was - is there a generally agree-upon name for these 92
glyphs (incuding the blank glyph)?
Note C would remain C if all the alphabet glyphs were re-arranged or
changed into diferent shapes.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-21 19:35 -0700 |
| Message-ID | <ln7foo124v.fsf@kst-u.example.com> |
| In reply to | #67970 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Friday, August 21, 2015 at 1:39:57 PM UTC-7, Richard Bos wrote:
>> David Kleinecke <dkleinecke@gmail.com> wrote:
>>
>> > On Wednesday, August 19, 2015 at 5:13:07 PM UTC-7, Keith Thompson wrote:
>>
>> > > The word "alphabet" is perhaps not the best choice for what you're
>> > > trying to say. The word often refers to just letters; see for example,
>> > > the isalpha() function.
>> >
>> > Alphabet is the usual word for whatever character ste a text is using.
>>
>> '.' and '(' are in your alphabet?
>
> Be careful here "text" includes a lot of things like Chinese writing
> and Sumerian and Egyptian (see Unicode - they may even include the
> figures on an Easter Island taking biard by now).
I can guess that "taking biard" is a typo for something, but I have no
idea for what. Moving on ...
> The crucial attribute of a text is that it is a sequence of glyphs -
> written in a book, carved on a rock, you name it). If presented with
> a text I haven't seen before I count the different glyphs (not always
> easy). The set of all different glyphs is the alphabet of the text.
> The alphabet the C standard is thinking of contains the 91 glyphs
> listed in 5.2.1 plus the space character. These 92 glyphs are encoded
> as byte values in a way the standard leaves us to guess is what is
> called the ANSII character set. The standard adds some byte values that
> that are encoded by glyph pairs.
>
> My question was - is there a generally agree-upon name for these 92
> glyphs (incuding the blank glyph)?
>
> Note C would remain C if all the alphabet glyphs were re-arranged or
> changed into diferent shapes.
Your original question from upthread was:
As elsewhere - a bag of tells. What's your name for the letters
we actually use (hint: not printable)?
I'll ignore the phrase "a bag of tells"; freel free to explain
it if you like, but either way be aware I have no clue what it's
supposed to mean.
Your question, as stated, was absolutely unclear. Many of the
characters it turns out you were referring to are not "letters",
and I could only guess what you meant by letters "we actually use".
I'm surprised it took you so long to clarify the question, which
turns out to be a fairly simple one.
The 92 characters in question are a subset of the "basic character
set", specifically the printable characters (those for which
isprint() would return a true value). I suppose you could call
them something like the "printable basic character set". I know
of no standard name for this set of characters, probably because
there hasn't been much of a need for such a name.
And I remind you again that your use of "alphabet" is potentially
confusing, since the primary meaning of that word excludes digits
and punctuation characters. The phrase "character set" seems to
be exactly what you're referring to; why not use 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]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-22 18:28 -0700 |
| Message-ID | <35ce7a2f-8ffa-4473-ab35-1399218d2888@googlegroups.com> |
| In reply to | #67973 |
On Friday, August 21, 2015 at 6:26:39 PM UTC-7, Keith Thompson wrote: > > Be careful here "text" includes a lot of things like Chinese writing > > and Sumerian and Egyptian (see Unicode - they may even include the > > figures on an Easter Island taking biard by now). > > I can guess that "taking biard" is a typo for something, but I have no > idea for what. Moving on ... "talking board" - a double typo (I go too fast). But it is just an example. Nothing serious. A mere bagatelle > > The crucial attribute of a text is that it is a sequence of glyphs - > > written in a book, carved on a rock, you name it). If presented with > > a text I haven't seen before I count the different glyphs (not always > > easy). The set of all different glyphs is the alphabet of the text. > > The alphabet the C standard is thinking of contains the 91 glyphs > > listed in 5.2.1 plus the space character. These 92 glyphs are encoded > > as byte values in a way the standard leaves us to guess is what is > > called the ANSII character set. The standard adds some byte values that > > that are encoded by glyph pairs. > > > > My question was - is there a generally agree-upon name for these 92 > > glyphs (incuding the blank glyph)? > > > > Note C would remain C if all the alphabet glyphs were re-arranged or > > changed into diferent shapes. > > Your original question from upthread was: > > As elsewhere - a bag of tells. What's your name for the letters > we actually use (hint: not printable)? > > I'll ignore the phrase "a bag of tells"; freel free to explain > it if you like, but either way be aware I have no clue what it's > supposed to mean. > > Your question, as stated, was absolutely unclear. Many of the > characters it turns out you were referring to are not "letters", > and I could only guess what you meant by letters "we actually use". > I'm surprised it took you so long to clarify the question, which > turns out to be a fairly simple one. > > The 92 characters in question are a subset of the "basic character > set", specifically the printable characters (those for which > isprint() would return a true value). I suppose you could call > them something like the "printable basic character set". I know > of no standard name for this set of characters, probably because > there hasn't been much of a need for such a name. > > And I remind you again that your use of "alphabet" is potentially > confusing, since the primary meaning of that word excludes digits > and punctuation characters. The phrase "character set" seems to > be exactly what you're referring to; why not use 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]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-22 22:43 -0700 |
| Message-ID | <lntwrqzhj7.fsf@kst-u.example.com> |
| In reply to | #68079 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Friday, August 21, 2015 at 6:26:39 PM UTC-7, Keith Thompson wrote:
>> > Be careful here "text" includes a lot of things like Chinese writing
>> > and Sumerian and Egyptian (see Unicode - they may even include the
>> > figures on an Easter Island taking biard by now).
>>
>> I can guess that "taking biard" is a typo for something, but I have no
>> idea for what. Moving on ...
>
> "talking board" - a double typo (I go too fast). But it is just an
> example. Nothing serious. A mere bagatelle
[55 lines deleted]
David, can you please trim quoted text that you're not actually replying
to?
--
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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-22 00:07 -0400 |
| Message-ID | <mr8se9$d72$1@dont-email.me> |
| In reply to | #67970 |
On 08/21/2015 08:17 PM, David Kleinecke wrote:
> On Friday, August 21, 2015 at 1:39:57 PM UTC-7, Richard Bos wrote:
>> David Kleinecke <dkleinecke@gmail.com> wrote:
>>
>>> On Wednesday, August 19, 2015 at 5:13:07 PM UTC-7, Keith Thompson wrote:
[Restore clipped context:]
>>>> David Kleinecke <dkleinecke@gmail.com> writes:
>>>>> On Tuesday, August 18, 2015 at 9:51:00 AM UTC-7, Ike Naar wrote:
>>>>>> On 2015-08-18, David Kleinecke <dkleinecke@gmail.com> wrote:
>>>>>>> Alternativly I could some other non-ASCII character (CTRL-Z, for example
>>>>>>> for soft EOL.
>>>>>>
>>>>>> CTRL-Z *is* an ASCII character (SUB, code point 26(decimal) or 1A(hex)).
>>>>>
>>>>> As elsewhere - a bag of tells. What's your name for the letters we
>>>>> actually use (hint: not printable)?
[End restored section]
...
>>>> The word "alphabet" is perhaps not the best choice for what you're
>>>> trying to say. The word often refers to just letters; see for example,
>>>> the isalpha() function.
>>>
>>> Alphabet is the usual word for whatever character ste a text is using.
>>
>> '.' and '(' are in your alphabet?
>>
>> Richard
>
> Be careful here "text" includes a lot of things like Chinese writing
> and Sumerian and Egyptian (see Unicode - they may even include the
> figures on an Easter Island taking biard by now).
>
> The crucial attribute of a text is that it is a sequence of glyphs -
> written in a book, carved on a rock, you name it). If presented with
> a text I haven't seen before I count the different glyphs (not always
> easy). The set of all different glyphs is the alphabet of the text.
> The alphabet the C standard is thinking of contains the 91 glyphs
> listed in 5.2.1 plus the space character. These 92 glyphs are encoded
> as byte values in a way the standard leaves us to guess is what is
> called the ANSII character set. The standard adds some byte values that
> that are encoded by glyph pairs.
>
> My question was - is there a generally agree-upon name for these 92
> glyphs (incuding the blank glyph)?
Not really - all of the terms in the standard that might otherwise
apply, apply to the characters, not to the glyphs that are displayed
when those characters are sent to a display device. The reason the
standard doesn't have any names for sets of glyphs is because the
standard doesn't say anything about glyphs, which are outside the scope
of the standard. That's the key reason why the following statement is true:
> Note C would remain C if all the alphabet glyphs were re-arranged or
> changed into diferent shapes.
If the C standard actually said something about the glyphs, you wouldn't
be free to rearrange them.
"The term _printing character_ refers to a member of a locale-specific
set of characters, each of which occupies one printing position on a
display device;the term _control character_ refers to a member of a
locale-specific set of characters that are not printing
characters. All letters and digits are printing characters." (7.4p3)
The 92 characters that produce the glyphs you're talking about when
displayed include 29 graphic characters and the blank character. That
those 30 characters are also printing characters must be inferred - it's
not stated directly. However, those 92 characters are precisely all of
the members of the basic source character set and the basic execution
characters set that are NOT described as control characters. It follows
from the definitions above that all of them must be printing characters.
Now, your original question specified that "printable" was not an
acceptable answer. Would "printing" be acceptable? If not, then there's
no answer to your question within the context of the C standard.
This leads to some questions - would the category whose name you're
asking for include only the source character set, only the execution
character set, or both? With regard to your concentration on glyphs, the
distinction is as follows: glyphs corresponding to the members of the
source character set are normally displayed only when editing the source
code. Glyphs corresponding to the members of the execution character set
are normally only displayed when a program calls one of the output
functions (such as printf()) on a stream that is connected to a display
device. Glyphs representing those same characters will also be seen when
calling text display routines associated with the graphics system you're
using, though that's outside the scope of the C standard, and the glyphs
produced by the graphics system might not match the glyphs produced by
the display device.
Should the category whose name you're asking after include the glyphs
produced by sending printing characters from the extended versions of
those character sets to a display device? The extended character set
will generally include all letters not used in US English, as well as a
large variety of various graphic characters.
Referring back to your original comment, the SUB character from the
ASCII character set would be a control character, not a printing
character, and it would be a part of the extended character set, not the
basic character set.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-22 18:59 -0700 |
| Message-ID | <8357062a-f639-438a-83d1-2f0c7319b723@googlegroups.com> |
| In reply to | #67979 |
On Friday, August 21, 2015 at 9:07:26 PM UTC-7, James Kuyper wrote:
> On 08/21/2015 08:17 PM, David Kleinecke wrote:
> > On Friday, August 21, 2015 at 1:39:57 PM UTC-7, Richard Bos wrote:
> >> David Kleinecke <dkleinecke@gmail.com> wrote:
> >>
> >>> On Wednesday, August 19, 2015 at 5:13:07 PM UTC-7, Keith Thompson wrote:
>
> [Restore clipped context:]
> >>>> David Kleinecke <dkleinecke@gmail.com> writes:
> >>>>> On Tuesday, August 18, 2015 at 9:51:00 AM UTC-7, Ike Naar wrote:
> >>>>>> On 2015-08-18, David Kleinecke <dkleinecke@gmail.com> wrote:
> >>>>>>> Alternativly I could some other non-ASCII character (CTRL-Z, for example
> >>>>>>> for soft EOL.
> >>>>>>
> >>>>>> CTRL-Z *is* an ASCII character (SUB, code point 26(decimal) or 1A(hex)).
> >>>>>
> >>>>> As elsewhere - a bag of tells. What's your name for the letters we
> >>>>> actually use (hint: not printable)?
> [End restored section]
>
> ...
> >>>> The word "alphabet" is perhaps not the best choice for what you're
> >>>> trying to say. The word often refers to just letters; see for example,
> >>>> the isalpha() function.
> >>>
> >>> Alphabet is the usual word for whatever character ste a text is using.
> >>
> >> '.' and '(' are in your alphabet?
> >>
> >> Richard
> >
> > Be careful here "text" includes a lot of things like Chinese writing
> > and Sumerian and Egyptian (see Unicode - they may even include the
> > figures on an Easter Island taking biard by now).
> >
> > The crucial attribute of a text is that it is a sequence of glyphs -
> > written in a book, carved on a rock, you name it). If presented with
> > a text I haven't seen before I count the different glyphs (not always
> > easy). The set of all different glyphs is the alphabet of the text.
> > The alphabet the C standard is thinking of contains the 91 glyphs
> > listed in 5.2.1 plus the space character. These 92 glyphs are encoded
> > as byte values in a way the standard leaves us to guess is what is
> > called the ANSII character set. The standard adds some byte values that
> > that are encoded by glyph pairs.
> >
> > My question was - is there a generally agree-upon name for these 92
> > glyphs (incuding the blank glyph)?
>
> Not really - all of the terms in the standard that might otherwise
> apply, apply to the characters, not to the glyphs that are displayed
> when those characters are sent to a display device. The reason the
> standard doesn't have any names for sets of glyphs is because the
> standard doesn't say anything about glyphs, which are outside the scope
> of the standard. That's the key reason why the following statement is true:
>
> > Note C would remain C if all the alphabet glyphs were re-arranged or
> > changed into diferent shapes.
>
> If the C standard actually said something about the glyphs, you wouldn't
> be free to rearrange them.
>
> "The term _printing character_ refers to a member of a locale-specific
> set of characters, each of which occupies one printing position on a
> display device;the term _control character_ refers to a member of a
> locale-specific set of characters that are not printing
> characters. All letters and digits are printing characters." (7.4p3)
>
> The 92 characters that produce the glyphs you're talking about when
> displayed include 29 graphic characters and the blank character. That
> those 30 characters are also printing characters must be inferred - it's
> not stated directly. However, those 92 characters are precisely all of
> the members of the basic source character set and the basic execution
> characters set that are NOT described as control characters. It follows
> from the definitions above that all of them must be printing characters.
>
> Now, your original question specified that "printable" was not an
> acceptable answer. Would "printing" be acceptable? If not, then there's
> no answer to your question within the context of the C standard.
>
> This leads to some questions - would the category whose name you're
> asking for include only the source character set, only the execution
> character set, or both? With regard to your concentration on glyphs, the
> distinction is as follows: glyphs corresponding to the members of the
> source character set are normally displayed only when editing the source
> code. Glyphs corresponding to the members of the execution character set
> are normally only displayed when a program calls one of the output
> functions (such as printf()) on a stream that is connected to a display
> device. Glyphs representing those same characters will also be seen when
> calling text display routines associated with the graphics system you're
> using, though that's outside the scope of the C standard, and the glyphs
> produced by the graphics system might not match the glyphs produced by
> the display device.
>
> Should the category whose name you're asking after include the glyphs
> produced by sending printing characters from the extended versions of
> those character sets to a display device? The extended character set
> will generally include all letters not used in US English, as well as a
> large variety of various graphic characters.
>
> Referring back to your original comment, the SUB character from the
> ASCII character set would be a control character, not a printing
> character, and it would be a part of the extended character set, not the
> basic character set.
--
If you are willing to call the space character "printable" i'll go
with 92 printable characters.
I believe you understand the problem area I am fussing about -
character sets.
The guts of the problem are that the only character set a C program
actually knows about are the objects of types "char". For now I am
going to ignore wide characters. Effectively that means bytes and
strings of bytes. These bytes are represented externally by devices
a C program has minimal control over. There is almost always a display
involved and there is usually an input device that reflects the same
alphabet (in my sense) as the output display. The actual glyph stream
that is displayed can be rather complexly related to the styte stream
the porgram sends to it (usually by what is called markup, eg HTML).
But the source code for the program must find a way to describe the
manipulations to be made on the byte encoding of the displayed text.
The C standard library describes one solution to this confused
situation. It is a solution suitable for character-based terminals
(conbsoles in the modern jargon).
But I have hardly touched upon the C source as a text. The C compiler
never looks at this source (except perhaps if there is an error). The
source text is turned into a succession of tokens (in phase 3 of the
processor). But no more for now.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-22 23:22 -0400 |
| Message-ID | <mrbe61$ka9$1@dont-email.me> |
| In reply to | #68081 |
On 08/22/2015 09:59 PM, David Kleinecke wrote: > On Friday, August 21, 2015 at 9:07:26 PM UTC-7, James Kuyper wrote: ... >> Now, your original question specified that "printable" was not an >> acceptable answer. Would "printing" be acceptable? If not, then there's >> no answer to your question within the context of the C standard. ... > If you are willing to call the space character "printable" i'll go > with 92 printable characters. It's printable in the same sense that 0 is a number and "" is a string. > I believe you understand the problem area I am fussing about - > character sets. I can only say that I do understand that you are fussing about character sets. What the fuss is about remains unclear to me. > The guts of the problem are that the only character set a C program > actually knows about are the objects of types "char". ... There are two character sets that a C program can know about - the basic execution character set and the extended execution character set. Both can be encoded in char arrays. The latter may require multi-byte encoding. C standard library provide routines for dealing with such encodings. In 1994, wchar_t was added, in 2011, char16_t and char32_t were added. Any complaints you have about the lack of character support in C90 should be re-evaluated in light of the changes that were made to character support in later versions. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-23 19:17 -0700 |
| Message-ID | <e878107f-4982-49d0-9dc5-4697570a38b4@googlegroups.com> |
| In reply to | #68084 |
On Saturday, August 22, 2015 at 8:22:29 PM UTC-7, James Kuyper wrote: > On 08/22/2015 09:59 PM, David Kleinecke wrote: > > On Friday, August 21, 2015 at 9:07:26 PM UTC-7, James Kuyper wrote: > ... > >> Now, your original question specified that "printable" was not an > >> acceptable answer. Would "printing" be acceptable? If not, then there's > >> no answer to your question within the context of the C standard. > ... > > If you are willing to call the space character "printable" i'll go > > with 92 printable characters. > > It's printable in the same sense that 0 is a number and "" is a string. > > > I believe you understand the problem area I am fussing about - > > character sets. > > I can only say that I do understand that you are fussing about character > sets. What the fuss is about remains unclear to me. > > > The guts of the problem are that the only character set a C program > > actually knows about are the objects of types "char". ... > > There are two character sets that a C program can know about - the basic > execution character set and the extended execution character set. Both > can be encoded in char arrays. The latter may require multi-byte > encoding. C standard library provide routines for dealing with such > encodings. > In 1994, wchar_t was added, in 2011, char16_t and char32_t were added. > Any complaints you have about the lack of character support in C90 > should be re-evaluated in light of the changes that were made to > character support in later versions. > -- > James Kuyper Come on - you know I have no use for any standard more recent than C90 and not much use for the standard library. wchar_t is in the C90 standard. I would like to see how to do decent glyph manipulation and stay within C90 standard. I think it can be done but I don't see my way clear yet. C knows about other character stes. The first thing that happens (5.1.1.2) is "Physical source file characters are mapped to the source character set ... "
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-23 21:35 -0700 |
| Message-ID | <lnegitz4kg.fsf@kst-u.example.com> |
| In reply to | #68178 |
David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> Come on - you know I have no use for any standard more recent than
> C90 and not much use for the standard library.
Don't expect much sympathy for that point of view, and don't complain
when others happen to mention more current editions of the standard.
> wchar_t is in the C90 standard.
Yes.
> I would like to see how to do decent glyph manipulation and stay within
> C90 standard. I think it can be done but I don't see my way clear yet.
What kind of "glyph manipulation" are you talking about?
> C knows about other character stes. The first thing that happens
> (5.1.1.2) is "Physical source file characters are mapped to the source
> character set ... "
That mapping may be the identity mapping (and probably is in most
implementations).
--
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 | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-24 16:59 -0700 |
| Message-ID | <1f1add4c-7e05-42c2-8223-389f85c9d107@googlegroups.com> |
| In reply to | #68182 |
On Sunday, August 23, 2015 at 8:09:15 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > [...] > > Come on - you know I have no use for any standard more recent than > > C90 and not much use for the standard library. > > Don't expect much sympathy for that point of view, and don't complain > when others happen to mention more current editions of the standard. I'm not looking for sympathy - but I do expect a reply to a statement of mine to framed in the same context as my statement > > I would like to see how to do decent glyph manipulation and stay within > > C90 standard. I think it can be done but I don't see my way clear yet. > > What kind of "glyph manipulation" are you talking about? Any kind of glyph manipulation - GUI screens, speech ouput, Braille. printing, you name it - even an old-fashioned teletype. > > C knows about other character stes. The first thing that happens > > (5.1.1.2) is "Physical source file characters are mapped to the source > > character set ... " > > That mapping may be the identity mapping (and probably is in most > implementations). Well, it does include the CRLF fixup. I dunno anything about how Chinese programmers code - or any of the hundreds of other scripts used world-wide. Or even something as simple as an n-tilde. Aren't most text-processors using UTF-8 these days?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-24 17:57 -0700 |
| Message-ID | <lntwroxk0s.fsf@kst-u.example.com> |
| In reply to | #68277 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Sunday, August 23, 2015 at 8:09:15 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> [...]
>> > Come on - you know I have no use for any standard more recent than
>> > C90 and not much use for the standard library.
>>
>> Don't expect much sympathy for that point of view, and don't complain
>> when others happen to mention more current editions of the standard.
>
> I'm not looking for sympathy - but I do expect a reply to a statement
> of mine to framed in the same context as my statement
There are (at least) two contexts to consider: your article, and the
newsgroup. If post-1990 changes to the C standard affect the answer to
a question, I'd say it's perfectly approprate to mention them -- for the
benefit of other readers, if nothing else.
>> > I would like to see how to do decent glyph manipulation and stay within
>> > C90 standard. I think it can be done but I don't see my way clear yet.
>>
>> What kind of "glyph manipulation" are you talking about?
>
> Any kind of glyph manipulation - GUI screens, speech ouput, Braille.
> printing, you name it - even an old-fashioned teletype.
For an old-fashioned teletype, you probably aren't going to have access
to any information about glyphs. You send bytes representing characters
to the device, and it prints them.
You can certainly define a data structure representing a glyph or a
collection of glyphs and manipulate it in C. If I understand you
correctly, you might look into how fonts are represented (there are
several standards, and I'm not familiar with any of them). Rendering
those glyphs on an output device is another matter. That's beyond the
scope of the C standard -- but of course that doesn't mean you can't do
it in C.
>> > C knows about other character stes. The first thing that happens
>> > (5.1.1.2) is "Physical source file characters are mapped to the source
>> > character set ... "
>>
>> That mapping may be the identity mapping (and probably is in most
>> implementations).
>
> Well, it does include the CRLF fixup.
Good point -- though that may not be necessary for Unix-hosted
compilers.
> I dunno anything about how
> Chinese programmers code - or any of the hundreds of other scripts
> used world-wide. Or even something as simple as an n-tilde.
Most programming languages use English-language keywords, but support
for non-Latin characters in comments, identifiers, and string literals
has been improving.
> Aren't
> most text-processors using UTF-8 these days?
Possibly, but I don't know. (Windows tends to use UTF-16.)
--
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 | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-08-25 01:09 -0700 |
| Message-ID | <MPG.3045c29c77befe9d53@news.eternal-september.org> |
| In reply to | #68282 |
Keith Thompson wrote: > You can certainly define a data structure representing a glyph or a > collection of glyphs and manipulate it in C. If I understand you > correctly, you might look into how fonts are represented (there are > several standards, and I'm not familiar with any of them). But those standards are probably less than 25 years old, so he wouldn't be interested.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-25 19:03 -0700 |
| Message-ID | <ddc3e580-8b73-4da6-b8d6-2c1e68fd00b9@googlegroups.com> |
| In reply to | #68290 |
On Tuesday, August 25, 2015 at 1:09:53 AM UTC-7, Philip Lantz wrote: > Keith Thompson wrote: > > You can certainly define a data structure representing a glyph or a > > collection of glyphs and manipulate it in C. If I understand you > > correctly, you might look into how fonts are represented (there are > > several standards, and I'm not familiar with any of them). > > But those standards are probably less than 25 years old, so he wouldn't > be interested. Good example of drawing the wrong conclusion. I'm no Ludddite. But I want C to be the universal high order assembler and few of the more recent (at my age I'm allowed to consider 1999 recent) changes in the standard seem to be helpful. And I am unwilling to accept things I deplore just because they are packaged with things that seem sensible. Recent discussions have disclosed the fact that I am further down on the standard library than on C proper. Thankfullly the standard provides free-standing C as well as hosted C.
[toc] | [prev] | [next] | [standalone]
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web