Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #73070 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2015-10-16 13:29 -0700 |
| Last post | 2015-10-16 20:45 -0700 |
| Articles | 20 on this page of 168 — 20 participants |
Back to article view | Back to comp.lang.c
C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 13:29 -0700
Re: C struct syntax allowance by usage Siri Cruz <chine.bleu@yahoo.com> - 2015-10-16 13:47 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-16 14:12 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-16 22:15 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 14:38 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-17 10:32 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-17 05:26 -0700
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-17 14:17 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-17 06:48 -0700
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-17 19:01 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-17 11:17 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-16 15:28 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-17 01:41 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 18:23 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 11:04 +0200
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 10:31 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 14:38 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 11:14 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 15:25 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 11:31 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 15:38 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 12:32 +1300
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 11:35 +0200
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-18 11:16 +0100
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 13:40 +0200
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-18 17:35 +0100
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-18 10:52 -0700
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-18 11:02 -0700
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-18 19:59 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-18 12:15 -0700
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-18 21:41 +0100
Likeliehood of RDC/SeaAlive implementation (Was: C struct syntax allowance by usage) gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-19 08:23 +0000
Re: C struct syntax allowance by usage Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-18 14:02 -0400
Re: C struct syntax allowance by usage Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-18 14:19 -0400
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-18 21:13 +0100
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 20:37 +0200
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-18 20:27 +0100
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 23:14 +0200
Re: C struct syntax allowance by usage asetofsymbols@gmail.com - 2015-10-18 15:09 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-18 16:11 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-19 07:57 +1300
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-18 20:11 +0100
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-19 09:19 +1300
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 11:19 +0200
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-18 03:08 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 13:52 +0200
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-18 05:39 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 14:57 +0200
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-19 10:31 +1300
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-18 15:49 +0100
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-18 16:53 -0700
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-19 01:50 +0100
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-19 02:28 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-19 12:38 +0200
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-19 12:09 +0100
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-19 14:26 +0200
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-19 13:34 +0100
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-20 02:36 +0000
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-19 05:09 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-19 14:41 +0200
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-19 06:08 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-19 15:20 +0200
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-19 08:24 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-20 08:43 +1300
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-19 13:00 -0700
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-19 20:34 +0000
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-20 09:47 +1300
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-19 16:32 -0700
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-20 10:37 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-19 21:24 +0000
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-20 13:49 +0000
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-20 07:33 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-20 15:53 +0000
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-20 10:37 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-21 05:05 +0000
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-21 02:02 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 06:07 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-21 14:15 +0100
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 09:23 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-21 18:30 +0100
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 12:13 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-21 21:17 +0100
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 14:21 -0700
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-21 14:55 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 15:45 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-22 14:33 +0200
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-22 08:54 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-23 15:59 +0200
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-23 15:03 -0700
Re: C struct syntax allowance by usage Richard Damon <Richard@Damon-Family.org> - 2015-10-24 10:37 -0400
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-21 23:26 +0100
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 15:56 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 05:19 +0000
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-22 11:08 +0100
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-22 14:58 +0200
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-22 14:06 +0200
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-22 07:41 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-22 14:00 +0100
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-22 21:00 +0000
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-22 14:57 -0700
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-21 14:41 +0000
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-21 13:01 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 13:25 -0700
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-22 07:44 +0000
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-21 13:41 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 05:22 +0000
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-22 01:01 -0700
Re: C struct syntax allowance by usage Les Cargill <lcargill99@comcast.com> - 2015-10-22 08:00 -0500
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-21 09:49 -0400
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-21 13:20 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-20 15:40 +0000
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-20 11:55 -0400
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-20 10:34 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-21 05:20 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-21 05:11 +0000
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-21 09:47 -0400
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 05:32 +0000
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-22 10:08 -0400
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 21:45 +0000
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-22 19:09 -0400
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-22 19:22 -0400
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-22 17:49 -0700
Re: C struct syntax allowance by usage Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-22 21:13 -0400
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-23 11:36 +0000
Re: C struct syntax allowance by usage Robert Wessel <robertwessel2@yahoo.com> - 2015-10-22 20:18 -0500
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-23 11:55 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-23 11:14 +0000
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-23 09:09 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-24 09:31 +0000
Re: C struct syntax allowance by usage raltbos@xs4all.nl (Richard Bos) - 2015-11-10 15:17 +0000
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-11-10 10:39 -0800
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-10 11:02 -0800
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-23 15:54 -0400
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-23 13:51 -0700
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-23 17:41 -0400
Re: C struct syntax allowance by usage raltbos@xs4all.nl (Richard Bos) - 2015-11-10 15:32 +0000
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-23 15:17 -0700
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-23 16:34 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-24 09:51 +0000
Re: C struct syntax allowance by usage Richard Damon <Richard@Damon-Family.org> - 2015-10-24 10:01 -0400
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-24 12:38 -0400
Re: C struct syntax allowance by usage Robert Wessel <robertwessel2@yahoo.com> - 2015-10-24 13:56 -0500
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-24 15:17 -0400
Re: C struct syntax allowance by usage Robert Wessel <robertwessel2@yahoo.com> - 2015-10-25 13:47 -0500
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-25 23:46 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-25 07:05 +0000
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-25 10:59 -0400
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-26 02:24 +0000
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-25 11:13 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-26 02:58 +0000
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-24 11:02 -0700
Re: C struct syntax allowance by usage Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2015-10-24 20:13 +0200
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-24 12:45 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-24 10:30 +1300
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-19 12:05 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 15:57 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-17 00:54 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 17:19 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 15:33 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 19:41 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 15:58 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 20:10 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 16:49 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 20:59 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 11:32 +0200
Re: C struct syntax allowance by usage Richard Damon <Richard@Damon-Family.org> - 2015-10-16 23:15 -0400
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 20:34 -0700
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 20:45 -0700
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-22 19:22 -0400 |
| Message-ID | <n0bquv$ae3$1@dont-email.me> |
| In reply to | #73575 |
On 10/22/2015 07:09 PM, James Kuyper wrote: ... > With CHAR_BIT 256, UCHAR_MAX would be pow(2, 256). Sorry: pow(2, 256)-1.0. The relative inaccuracy of that expression is smaller than any other error I've ever made in my life. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-22 17:49 -0700 |
| Message-ID | <205bcbf4-81dd-4afc-b897-cd3fe64f759b@googlegroups.com> |
| In reply to | #73575 |
On Thursday, October 22, 2015 at 6:10:08 PM UTC-5, James Kuyper wrote: > Whatever method it uses, that's what necessarily would result from using > a conforming implementation of C or C++ to write a '\n' to a text > stream. It could NOT result in the creation of CR, NL, or LF characters > - those would have to be represented in some other way, probably an > octal escape sequence for NL. In C, '\n' is a positive number which can be represented in type "char". If text files mark line boundaries some other way, then writing '\n' to a file opened in text mode must cause the stdio library to generate a line boundary.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2015-10-22 21:13 -0400 |
| Message-ID | <rRfWx.167400$JC.37985@fx11.iad> |
| In reply to | #73575 |
On Thursday October 22 2015 19:09, in comp.lang.c, "James Kuyper" <jameskuyper@verizon.net> wrote: [snip] > Since no "end of line" character is reserved, how is "end of line" > conventionally indicated on OS/360? I know of several different methods > that don't require such a character, I just want to know which one is > used by OS/360. How is "end of line" conventionally indicated on OS/360, you ask. Well, it isn't. OS/360 is a "record oriented" operating system. Records are fixed-length, typically 80 bytes for input and 133 bytes for (text) output. It does get complicated; programs usually specify to the OS what record-length they expect a file to have, and if the OS detects a mismatch between the file record-length and the program's record-length expectation, the OS takes actions to terminate the program. [snip] HTH -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-23 11:36 +0000 |
| Message-ID | <n0d64g$gnc$1@speranza.aioe.org> |
| In reply to | #73579 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> On Thursday October 22 2015 19:09, in comp.lang.c, "James Kuyper"
(snip)
>> Since no "end of line" character is reserved, how is "end of line"
>> conventionally indicated on OS/360? I know of several different methods
>> that don't require such a character, I just want to know which one is
>> used by OS/360.
> How is "end of line" conventionally indicated on OS/360, you ask.
> Well, it isn't.
> OS/360 is a "record oriented" operating system. Records are fixed-length,
> typically 80 bytes for input and 133 bytes for (text) output. It does get
> complicated; programs usually specify to the OS what record-length they
> expect a file to have, and if the OS detects a mismatch between the file
> record-length and the program's record-length expectation, the OS takes
> actions to terminate the program.
Fixed length records are common, and the early Fortran compilers
only knew about them for formatted files, or RECFM=VBS for unformatted.
PL/I likes VB, variable length with four byte record and block
descriptors. I believe that later Fortran compilers and also
C compilers use VB (variable length blocked records).
VBS is special, I believe originally for Fortran unformatted.
It allows for records that are longer than blocks. It is not
normally used for text files.
The spooling systems at least by MVS (successor to OS/360 on S/370
systems) knows about both F (fixed) and V (variable) length
records, blocked or unblocked.
In addition, output (for printer) files can have A or M, so,
RECFM=FBA or FBM or VBA or VBM, where A have ASA carriage control
characters in column 1, and M have machine specific carriage
control characters in column 1.
I haven't tried it, but C text output files for VBA might convert
'\f' to records with '1' in column 1.
PL/I STREAM output, which may have had some influence on C,
is stream oriented, such that you can read or write a line of a text
file from more than one I/O statement. That is different from
Fortran, which only recently allows that.
For PL/I, PUT SKIP; goes to the next line, so you can
PUT SKIP LIST('This is one line.');
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-10-22 20:18 -0500 |
| Message-ID | <j72j2b1i1b9js5vdduppbd51sall4jrfc4@4ax.com> |
| In reply to | #73575 |
On Thu, 22 Oct 2015 19:09:41 -0400, James Kuyper
<jameskuyper@verizon.net> wrote:
>> It more has to do with the OS/360 file system than Fortran, but there
>> were no C compilers for OS/360 at the time, and maybe still aren't.
>>
>> OS/360 does not reserver an "end of line" character. CR, NL, and LF
>> are all valid characters in a text file, and I could even use then
>> inside character constants in Fortran. I suppose I could have used
>> them in C, if I had a C compiler.
>
>Since no "end of line" character is reserved, how is "end of line"
>conventionally indicated on OS/360? I know of several different methods
>that don't require such a character, I just want to know which one is
>used by OS/360.
>
>Whatever method it uses, that's what necessarily would result from using
>a conforming implementation of C or C++ to write a '\n' to a text
>stream. It could NOT result in the creation of CR, NL, or LF characters
>- those would have to be represented in some other way, probably an
>octal escape sequence for NL.
Traditional text files are series of records stored with an explicit
length (somewhere) in the file system. In some cases the storage of
the length may by done physically by the I/O device (say a tape or
disk drive), or may be implicit in the I/O device (80 columns for a
punch card, for example). Other formats allow packing ("blocking") of
multiple records into a larger I/O block. The length attribute is not
(usually) part of the user visible data, but is available as metadata
about the record in question. The gyrations the C standard library
goes through to map traditional record-oriented files into text
streams can be rather exciting.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-23 11:55 +0000 |
| Message-ID | <n0d775$j6g$1@speranza.aioe.org> |
| In reply to | #73580 |
Robert Wessel <robertwessel2@yahoo.com> wrote:
> On Thu, 22 Oct 2015 19:09:41 -0400, James Kuyper
(snip)
>>Since no "end of line" character is reserved, how is "end of line"
>>conventionally indicated on OS/360? I know of several different methods
>>that don't require such a character, I just want to know which one is
>>used by OS/360.
(snip)
> Traditional text files are series of records stored with an explicit
> length (somewhere) in the file system. In some cases the storage of
> the length may by done physically by the I/O device (say a tape or
> disk drive), or may be implicit in the I/O device (80 columns for a
> punch card, for example). Other formats allow packing ("blocking") of
> multiple records into a larger I/O block. The length attribute is not
> (usually) part of the user visible data, but is available as metadata
> about the record in question. The gyrations the C standard library
> goes through to map traditional record-oriented files into text
> streams can be rather exciting.
For early, small, systems, the ability to read/write unblocked
data allowed for smaller I/O buffers. That was usual for machines
with 8K or even 64K bytes of core. Disk and tape hardware can
read or write such record/blocks.
For OS/360, there are two ways (access methods) to read/write text
files called BSAM and QSAM. For QSAM, system routines do all the
work of keeping track of records and blocks.
For BSAM, the system supplies/accepts blocks, keeps track of record
and block lengths. The user program, which would be the C library
in the caes of C, does the work of keeping track of records and
blocks. For unblocked files, it is obviously easier.
Note that unlike Unix and DOS/windows, disks are not formatted
with 512 byte blocks. If you write a file with REFCM=F, LRECL=80
and BLKSIZE=80, the physical blocks on disk are 80 bytes long,
at least as seen by the channel. For larger systems, it is usual
to read/write blocked records such as BLKSIZE=3200, up to the
track size for the drive.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-23 11:14 +0000 |
| Message-ID | <n0d4qj$dn3$1@speranza.aioe.org> |
| In reply to | #73575 |
James Kuyper <jameskuyper@verizon.net> wrote:
> On 10/22/2015 05:45 PM, glen herrmannsfeldt wrote:
>> James Kuyper <jameskuyper@verizon.net> wrote:
(snip)
(I wrote)
>>>>>> Only if you don't want any actual '\n' in your file, on
>>>>>> file systems that allow them, or
>>>>> I can't make sense of that response. Perhaps you got the wording
>>>>> reversed? ...
> You still haven't answered this question. If you want to answer
> something other than "Yes" or "No", could you please precede your answer
> with an explanation why neither "Yes" nor "No" is an appropriate answer.
> Nothing you have said so far in response to that question seems
> responsive. You still haven't discussed writing '\n' to a text stream
> using C or C++ on a file system that allows them to be written.
I presume that one character won't be written, even on file systems
that allow it.
>>>>> ... In C and C++, outputting a '\n' to a text stream will put an
>>>>> '\n' in your file, on file systems that allow them. On the other hand,
>>>>> if you
(snip)
>> It more has to do with the OS/360 file system than Fortran, but there
>> were no C compilers for OS/360 at the time, and maybe still aren't.
>> OS/360 does not reserver an "end of line" character. CR, NL, and LF
>> are all valid characters in a text file, and I could even use then
>> inside character constants in Fortran. I suppose I could have used
>> them in C, if I had a C compiler.
> Since no "end of line" character is reserved, how is "end of line"
> conventionally indicated on OS/360? I know of several different methods
> that don't require such a character, I just want to know which one is
> used by OS/360.
There are three ways:
RECFM=F (or FB) fixed length records, unblocked or blocked.
RECFM=V (or VB) variable length records with a four byte record
descriptor word and four byte block descriptor word, both of which
have a length field.
RECFM=U (undefined) you get to do whatever you want with the
bytes in a block.
> Whatever method it uses, that's what necessarily would result from using
> a conforming implementation of C or C++ to write a '\n' to a text
> stream. It could NOT result in the creation of CR, NL, or LF characters
> - those would have to be represented in some other way, probably an
> octal escape sequence for NL.
(snip)
>> On systems with CHAR_BIT 256, ...
> With CHAR_BIT 256, UCHAR_MAX would be pow(2, 256). On such a system
> there would be sufficient room in unsigned char for every person on
> earth to have their own personalized version of every Unicode character.
> Perhaps you meant something else? I'm guessing that you meant
> CHAR_BIT==8, UCHAR_MAX==255.
yes. I was thinking about both at the same time, and wrote the
wrong one.
>> ...there is no way in C to write 256
>> different characters inside a line, even when no character is used
>> by the system for an end of line marker.
> True. The basic character set is required to include all of the
> following characters: '\a', '\b', '\f', '\r', '\v', and '\0', none of
> which could appear in a line in a text stream without invalidating the
> guarantee provided by 7.21.2p2. Among other possibilities allowed by
> that fact, all of those characters could simply be dropped when written
> to or read from a text stream.
> On a system where end-of-line is not indicated by a special character,
> '\n' could also not appear in a text stream, because any attempt to
> write it to a text stream would cause a new line to be created, rather
> than creation of a byte containing the same value as '\n'.
(snip)
>>> So, in that regard, it's similar in effect to System.out.format("\n") in
> Sorry - I meant to write System.out.format("%n") there.
>>> Java, or printf("\n") in C/C++ - right?
>> My understanding is that on DOS/Windows systems that
>> System.out.println(); and System.out.format("%n");
>> write "\r\n" to the file, where
> So, the answer to my question is "yes", as I expected, right?
> If not, could you identify a system which shows that
> System.out.println(), System.out.format("%n") and printf("\n") produce
> different results?
There are C compiles for descendants of OS/360, though I haven't
had much of a chance to use them.
I don't know about Java for z/OS or CMS.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-23 09:09 -0700 |
| Message-ID | <lnd1w5woqe.fsf@kst-u.example.com> |
| In reply to | #73611 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
[...]
> There are C compiles for descendants of OS/360, though I haven't
> had much of a chance to use them.
>
> I don't know about Java for z/OS or CMS.
K&R1 (1978) lists the IBM 370 (a descendent of the 360) as one of
the platforms for which there are C compilers. The others, if I
recall correctly, are PDP-11, Honeywell 6000, and Interdata 8/32.
(According to Wikipedia, Bell Labs chose the Interdata 8/32 as a
target for a Unix port "because it was as different from the DEC
PDP-11 as possible".)
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-24 09:31 +0000 |
| Message-ID | <n0fj6a$86i$2@speranza.aioe.org> |
| In reply to | #73627 |
Keith Thompson <kst-u@mib.org> wrote: (snip, I wrote) >> There are C compiles for descendants of OS/360, though I haven't >> had much of a chance to use them. >> I don't know about Java for z/OS or CMS. > K&R1 (1978) lists the IBM 370 (a descendent of the 360) as one of > the platforms for which there are C compilers. The others, if I > recall correctly, are PDP-11, Honeywell 6000, and Interdata 8/32. http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=dd&subtype=sm&appname=ShopzSeries&htmlfid=897/ENUS5688-187 seems to date C/370 version 2 to 1991. https://books.google.com/books?id=n5qBImUV6NQC&pg=PA65&lpg=PA65& dq=ibm+370+c+compiler&source=bl&ots=XnrAhA9d6P&sig= kG6hoPH6qRz5mWNn3jncINIIFss&hl=en&sa=X&ved= 0CEQQ6AEwCGoVChMI0eKcid3ayAIVCNgeCh34IAER#v=onepage&q= ibm%20370%20c%20compiler&f=false (you have to put the link back together, I can't post one that long) dates the SAS/Lattice C compiler to 1985. http://csg.uwaterloo.ca/sdtp/watc.html describes the Waterloo C compiler, but doesn't seem to give dates. > (According to Wikipedia, Bell Labs chose the Interdata 8/32 as a > target for a Unix port "because it was as different from the DEC > PDP-11 as possible".) The Interdata has some similarities to S/370, but usually runs Unix in ASCII. Some of the code generator might be usable. Otherwise, I don't know which compiler K&R would have used. -- glen
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-10 15:17 +0000 |
| Message-ID | <56420a7f.1988265@news.xs4all.nl> |
| In reply to | #73627 |
Keith Thompson <kst-u@mib.org> wrote: > glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > [...] > > There are C compiles for descendants of OS/360, though I haven't > > had much of a chance to use them. > > > > I don't know about Java for z/OS or CMS. > > K&R1 (1978) lists the IBM 370 (a descendent of the 360) as one of > the platforms for which there are C compilers. The others, if I > recall correctly, are PDP-11, Honeywell 6000, and Interdata 8/32. > > (According to Wikipedia, Bell Labs chose the Interdata 8/32 as a > target for a Unix port "because it was as different from the DEC > PDP-11 as possible".) A highly admirable reasoning; one wishes their successors had been so open-minded. Richard
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-10 10:39 -0800 |
| Message-ID | <c61fc4d9-e9c1-44d1-ac3f-9eea312763b9@googlegroups.com> |
| In reply to | #75578 |
On Tuesday, November 10, 2015 at 9:18:05 AM UTC-6, Richard Bos wrote: > A highly admirable reasoning; one wishes their successors had been so > open-minded. C has historically suffered from some confusion as to whether it's more important to be able to allow C to be used to write efficient code on as many different platforms as possible, or whether it's more important to have code which is written for one platform be usable without modification on all others. I would posit that the design intention was that programmers should feel free to exploit any features and guarantees that are going to be present on all platforms where their code will need to run; such code would not work on platforms which lack those features, but it's better to have the language be usable on such platforms for code that doesn't need those features, than to say that the language can't be used at all on platforms which don't have every feature that some programmers might need. Unfortunately, it has become fashionable to say that good programmers should avoid writing code which relies upon features and guarantees that are only present in 99% of the platforms that support C (and 100% of those upon which anyone might actually want to run their code), and compiler writers should feel no obligation to make such features and guarantees available to the programmers who shouldn't be using them.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-11-10 11:02 -0800 |
| Message-ID | <c2667f57-85de-4dca-a00e-e07a483f7655@googlegroups.com> |
| In reply to | #75650 |
On Tuesday, November 10, 2015 at 1:39:34 PM UTC-5, supe...@casperkitty.com wrote:
> On Tuesday, November 10, 2015 at 9:18:05 AM UTC-6, Richard Bos wrote:
> > A highly admirable reasoning; one wishes their successors had been so
> > open-minded.
>
> C has historically suffered from some confusion as to whether it's more
> important to be able to allow C to be used to write efficient code on as
> many different platforms as possible, or whether it's more important to
> have code which is written for one platform be usable without modification
> on all others. I would posit that the design intention was that programmers
> should feel free to exploit any features and guarantees that are going to
> be present on all platforms where their code will need to run; such code
> would not work on platforms which lack those features, but it's better to
> have the language be usable on such platforms for code that doesn't need
> those features, than to say that the language can't be used at all on
> platforms which don't have every feature that some programmers might need.
>
> Unfortunately, it has become fashionable to say that good programmers should
> avoid writing code which relies upon features and guarantees that are only
> present in 99% of the platforms that support C (and 100% of those upon
> which anyone might actually want to run their code), and compiler writers
> should feel no obligation to make such features and guarantees available to
> the programmers who shouldn't be using them.
I had been proposing a core C language, one which is the target for all
C code. It has extensions to allow all of the hardware features and
quirks unique to each architecture, but only allows them as extensions
because it should not be a mandate that all people write for the full
range of hardware / machine possibilities, but only for the core C
language. In that way, then only those who need the specialized hardware
features need to be in any way concerned about their existence, and the
associated coding concerns relating to them. The rest of us simply write
C code and are done with it. I even proposed a Core C virtual machine
which supports each version of Core C that is released, allowing that code
to be tailored for any C compiler, to then allow all Core C code to run
on any platform, taking a minor performance hit, but if performance is
not critical, then write once, run anywhere ... in C.
This is part of what CAlive is, though I do not intend to write an
explicit CAlive virtual machine, but only "A" virtual machine, which I
will then add support for for my compiler.
All of this is compliant with James 4:15 ("Lord willing").
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-23 15:54 -0400 |
| Message-ID | <n0e35h$5ii$1@dont-email.me> |
| In reply to | #73611 |
On 10/23/2015 07:14 AM, glen herrmannsfeldt wrote:
> James Kuyper <jameskuyper@verizon.net> wrote:
>> On 10/22/2015 05:45 PM, glen herrmannsfeldt wrote:
>>> James Kuyper <jameskuyper@verizon.net> wrote:
>
> (snip)
>
> (I wrote)
>>>>>>> Only if you don't want any actual '\n' in your file, on
>>>>>>> file systems that allow them, or
>
>>>>>> I can't make sense of that response. Perhaps you got the wording
>>>>>> reversed? ...
>
>> You still haven't answered this question. If you want to answer
>> something other than "Yes" or "No", could you please precede your answer
>> with an explanation why neither "Yes" nor "No" is an appropriate answer.
>> Nothing you have said so far in response to that question seems
>> responsive. You still haven't discussed writing '\n' to a text stream
>> using C or C++ on a file system that allows them to be written.
>
> I presume that one character won't be written, even on file systems
> that allow it.
What lead you to that presumption? Unix is one such system, and C was
developed in parallel with Unix. On Unix systems, text mode is
essentially identical to binary mode: fputc('\n') puts a single new-line
character in the output file. Other popular systems that allow newline
characters in text files write either "\r\n" or "\n\r", but either way,
a newline character gets written.
>
>>>>>> ... In C and C++, outputting a '\n' to a text stream will put an
>>>>>> '\n' in your file, on file systems that allow them. On the other hand,
>>>>>> if you
>
> (snip)
>
>>> It more has to do with the OS/360 file system than Fortran, but there
>>> were no C compilers for OS/360 at the time, and maybe still aren't.
>
>>> OS/360 does not reserver an "end of line" character. CR, NL, and LF
>>> are all valid characters in a text file, and I could even use then
>>> inside character constants in Fortran. I suppose I could have used
>>> them in C, if I had a C compiler.
>
>> Since no "end of line" character is reserved, how is "end of line"
>> conventionally indicated on OS/360? I know of several different methods
>> that don't require such a character, I just want to know which one is
>> used by OS/360.
>
> There are three ways:
>
> RECFM=F (or FB) fixed length records, unblocked or blocked.
>
> RECFM=V (or VB) variable length records with a four byte record
> descriptor word and four byte block descriptor word, both of which
> have a length field.
>
> RECFM=U (undefined) you get to do whatever you want with the
> bytes in a block.
RECFM=U seems most appropriate for C text mode, since it sounds similar
to the normal mode on the Unix systems where C was first developed. The
NL character could be used an end-of-line indicator - but you indicate
that this is not in fact done.
THe second best alternative would be RECFM=V, using the record length
indicator to indicate the length of a line. C isn't designed with the
concept of a maximimum line length in mind, so if there is a maximum
record length (==N), then records with a length equal to the maximum
would have to be treated as continuing over in the next record.
...
>> If not, could you identify a system which shows that
>> System.out.println(), System.out.format("%n") and printf("\n") produce
>> different results?
>
> There are C compiles for descendants of OS/360, though I haven't
> had much of a chance to use them.
Well, the descriptions given for those three different methods of ending
a line suggest that they should all give the same result, even on an
OS/360. Do you have any reason to expect otherwise?
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-23 13:51 -0700 |
| Message-ID | <lnmvv9ux4w.fsf@kst-u.example.com> |
| In reply to | #73649 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 10/23/2015 07:14 AM, glen herrmannsfeldt wrote:
[...]
>> I presume that one character won't be written, even on file systems
>> that allow it.
>
> What lead you to that presumption? Unix is one such system, and C was
> developed in parallel with Unix. On Unix systems, text mode is
> essentially identical to binary mode: fputc('\n') puts a single new-line
> character in the output file. Other popular systems that allow newline
> characters in text files write either "\r\n" or "\n\r", but either way,
> a newline character gets written.
What system (popular or otherwise) writes "\n\r" to mark the end of a
line?
(Mac OS 9 and earlier used just "\r" as an end-of-line marker.)
--
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-10-23 17:41 -0400 |
| Message-ID | <n0e9ev$v3$1@dont-email.me> |
| In reply to | #73653 |
On 10/23/2015 04:51 PM, Keith Thompson wrote: > James Kuyper <jameskuyper@verizon.net> writes: ... >> character in the output file. Other popular systems that allow newline >> characters in text files write either "\r\n" or "\n\r", but either way, >> a newline character gets written. > > What system (popular or otherwise) writes "\n\r" to mark the end of a > line? According to <https://en.wikipedia.org/wiki/Newline>, "Acorn BBC and RISC OS spooled text output." I'd noticed and remembered long ago that "\r", "\n", "\n\r" and "\r\n" were all used by some system as an end-of-line indicator, but I never bothered remembering which ones used each combination. I must concede that the systems that use "\r\n" are far more popular than the ones that use "\n\r", and that the article does not indicate whether there were any C compilers for any of those systems. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-10 15:32 +0000 |
| Message-ID | <56420aa3.2024390@news.xs4all.nl> |
| In reply to | #73658 |
James Kuyper <jameskuyper@verizon.net> wrote: > On 10/23/2015 04:51 PM, Keith Thompson wrote: > > What system (popular or otherwise) writes "\n\r" to mark the end of a > > line? > > According to <https://en.wikipedia.org/wiki/Newline>, "Acorn BBC and > RISC OS spooled text output." I'd noticed and remembered long ago that > "\r", "\n", "\n\r" and "\r\n" were all used by some system as an > end-of-line indicator, but I never bothered remembering which ones used > each combination. I must concede that the systems that use "\r\n" are > far more popular than the ones that use "\n\r", and that the article > does not indicate whether there were any C compilers for any of those > systems. There certainly are now C compilers for the emulated Beeb, though I haven't used them and don't know how compliant they are. As for back then, this page: <http://www.computinghistory.org.uk/det/26671/C%20for%20the%20BBC%20Microcomputer/> seems to say so, but the same caveat applies. Richard
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-23 15:17 -0700 |
| Message-ID | <f211eda0-b007-4a83-ac51-03c9ed4bd62f@googlegroups.com> |
| In reply to | #73653 |
On Friday, October 23, 2015 at 3:51:27 PM UTC-5, Keith Thompson wrote: > What system (popular or otherwise) writes "\n\r" to mark the end of a > line? I don't know that any which write that for the purpose, but there are some systems which are designed to parse input from a wide range of sources which would regard \n\r as one line ending rather than two. I think that adds some needless complexity to the logic, which could be simplified to require no state other than the previous character read without it (the simplified logic would be "Every \r is a line boundary; every \n which is not immediately preceded by a \r is a line boundary". Recognizing \n\r as a single line boundary would require keeping additional state, since code which had seen ....\r\n\r\n" and then encountered "\r" wouldn't know whether that should be a line boundary or not unless it kept a running state. BTW, the use of the two-part separator is an offshoot of the fact that the first Teletype-brand teleprinters needed more than 1/10 second to reset the carriage position and could thus not handle a CR followed immediately by a printing character. Thus, reset carriage and advance paper was CR+LF; reset carriage without advancing paper was either CR+NUL or CR+DEL. The C programming language would obviously not like the former, and I don't know if the latter would be guaranteed to survive if a tape was duplicated (an ASR-33 that receives a DEL will punch it as a DEL, but other kinds of tape-copying apparatus might strip out DEL characters for the purpose of improving transmission efficiency since DEL would normally only appear on a tape as a result of someone typing some incorrect characters, hitting the back-step button on the punch the proper number of times, hitting "DEL" the proper number of times, and then typing the replacement text.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-23 16:34 -0700 |
| Message-ID | <lna8r9upl9.fsf@kst-u.example.com> |
| In reply to | #73664 |
supercat@casperkitty.com writes:
[...]
> BTW, the use of the two-part separator is an offshoot of the fact that
> the first Teletype-brand teleprinters needed more than 1/10 second to reset
> the carriage position and could thus not handle a CR followed immediately
> by a printing character. Thus, reset carriage and advance paper was CR+LF;
> reset carriage without advancing paper was either CR+NUL or CR+DEL. The
> C programming language would obviously not like the former, and I don't
> know if the latter would be guaranteed to survive if a tape was duplicated
> (an ASR-33 that receives a DEL will punch it as a DEL, but other kinds of
> tape-copying apparatus might strip out DEL characters for the purpose of
> improving transmission efficiency since DEL would normally only appear on
> a tape as a result of someone typing some incorrect characters, hitting
> the back-step button on the punch the proper number of times, hitting "DEL"
> the proper number of times, and then typing the replacement text.
C would have a problem with CR+NUL only if the sequence was stored in a
string. It would be easy enough to translate '\r' to the sequence
'\r','\0' on output, just like '\n' is commonly translated to '\r\n'.
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-24 09:51 +0000 |
| Message-ID | <n0fkb6$anv$1@speranza.aioe.org> |
| In reply to | #73649 |
James Kuyper <jameskuyper@verizon.net> wrote:
(snip)
>> I presume that one character won't be written, even on file systems
>> that allow it.
> What lead you to that presumption? Unix is one such system, and C was
> developed in parallel with Unix. On Unix systems, text mode is
> essentially identical to binary mode: fputc('\n') puts a single new-line
> character in the output file. Other popular systems that allow newline
> characters in text files write either "\r\n" or "\n\r", but either way,
> a newline character gets written.
OK, I didn't explain it right. I want to write a '\n' to the file
that is not an end of line. I want one in the middle of the line.
How do I do that?
(snip)
>> There are three ways:
>> RECFM=F (or FB) fixed length records, unblocked or blocked.
>> RECFM=V (or VB) variable length records with a four byte record
>> descriptor word and four byte block descriptor word, both of which
>> have a length field.
>> RECFM=U (undefined) you get to do whatever you want with the
>> bytes in a block.
> RECFM=U seems most appropriate for C text mode, since it sounds similar
> to the normal mode on the Unix systems where C was first developed. The
> NL character could be used an end-of-line indicator - but you indicate
> that this is not in fact done.
RECFM=U means that the system doesn't care what you put in it.
It is mostly used for load modules (link editor output). WYLBUR
also uses it for it own compressed files. If you write a C text file
with it, no other programs will be able to read it as text.
> THe second best alternative would be RECFM=V, using the record length
> indicator to indicate the length of a line. C isn't designed with the
> concept of a maximimum line length in mind, so if there is a maximum
> record length (==N), then records with a length equal to the maximum
> would have to be treated as continuing over in the next record.
OS/360 uses signed 16 bit numbers for I/O, The largest LRECL for
VB is 32760. You would probably surprise programs expecting a
text file if you used one that large, but it is legal.
(That includes the four byte RDW.)
You wouldn't send such a file to a printer, for example. Programs
can read the LRECL and allocate buffers based on it. Compilers
will probably also reject the files.
I think a program writing VB can set the LRECL at the end based
on the largest record seen. Otherwise, users would specify it
on the JCL DD statement.
(snip)
>> There are C compiles for descendants of OS/360, though I haven't
>> had much of a chance to use them.
> Well, the descriptions given for those three different methods of ending
> a line suggest that they should all give the same result, even on an
> OS/360. Do you have any reason to expect otherwise?
Can I read and write all 256 characters within the lines of a text file?
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-10-24 10:01 -0400 |
| Message-ID | <SaMWx.189949$ot4.156257@fx22.iad> |
| In reply to | #73678 |
On 10/24/15 5:51 AM, glen herrmannsfeldt wrote: > > OK, I didn't explain it right. I want to write a '\n' to the file > that is not an end of line. I want one in the middle of the line. > How do I do that? If you are using an interface that defines lines as being delimited by a 'newline', there is, practically by definition, no way to place a 'newline' in the middle of a line. > > Can I read and write all 256 characters within the lines of a text file? > > -- glen > If you want to read a file, and NOT have '\n' be treated as a special 'newline' character, then in C, you are supposed to use the file I/O in binary mode, and not use 'line oriented' I/O functions, but the block oriented ones.
[toc] | [prev] | [next] | [standalone]
Page 7 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