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 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-24 12:38 -0400 |
| Message-ID | <562BB423.7020707@verizon.net> |
| In reply to | #73678 |
On 10/24/2015 05:51 AM, glen herrmannsfeldt wrote:
> 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?
On systems which use '\n' to indicate the end-of-line, there's
inherently no way to do it; it's logically impossible. On systems which
use other methods, you can only do it by opening the stream in binary
mode, and writing '\n'. This requires that you do the end-of-line
marking yourself - converting the '\n' character into a system-specific
method of marking line endings is something C only does in text mode.
>>> 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. ...
I would expect line printers might have a maximum line length, and if
so, I'd expect problems trying to print a line longer than that. Most of
the printers I've used that weren't line printers would treat text data
that doesn't contain any newline characters by starting a new line when
it reaches the right edge of the page, and starting a new page when it
reaches the bottom edge of the page. Are OS/360 systems only compatible
with line printers, or do the non-line-printers that they can be
attached to have different behavior than the one I describe?
> ... Programs
> can read the LRECL and allocate buffers based on it. Compilers
> will probably also reject the files.
So LRECL is, in fact, the conventional approach on OS/360 for indicating
where the end of a line is? I asked you before, but you never identified
what the conventional approach is.
C allows an implementation to have a maximum line length, but doesn't
require it. I wouldn't be surprised by a compiler that rejected an
overly long line, and I personally would never write a line longer than
80 characters, but I'd prefer a compiler that would complain only if it
couldn't dynamically allocate enough room to store the line.
>>> 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?
Such a file necessarily contains the characters '\a', '\b', '\f', '\v',
and '\0'. Any one of those characters violates the conditions imposed by
7.21.2p2, and a conforming implementation of C is therefore allowed to
drop such characters, either when writing to text stream, or when
reading from a text stream - it's up to the implementation whether or
not that actually occurs.
Since you describe OS/360 as not using the '\n' character as an
end-of-line marker, nor even as part of a multi-character end-of-line
marker, there's no way to write such a character to a text stream. So,
the answer is no - you'd have to open it as a binary stream if you want
it to include that character.
So, getting back to my question, which you still haven't answered: given
that the descriptions that you gave me for Java's System.out.println(),
System.out.format("%n"), and the C standard's description of writing a
'\n' character to a text stream all say comparable things about what the
result would be, do you have any reason to believe that the result would
be different between those three on an OS/360 system? I would expect all
three to set the LRECL for the current block to the number of characters
written since the last block was written. Do you have any reason to
expect that any of those three would do something different?
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-10-24 13:56 -0500 |
| Message-ID | <o7hn2b9a8eugbhgmm38pt5utohf29irsrj@4ax.com> |
| In reply to | #73702 |
On Sat, 24 Oct 2015 12:38:59 -0400, James Kuyper
<jameskuyper@verizon.net> wrote:
>On 10/24/2015 05:51 AM, glen herrmannsfeldt wrote:
>> 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?
>
>On systems which use '\n' to indicate the end-of-line, there's
>inherently no way to do it; it's logically impossible. On systems which
>use other methods, you can only do it by opening the stream in binary
>mode, and writing '\n'. This requires that you do the end-of-line
>marking yourself - converting the '\n' character into a system-specific
>method of marking line endings is something C only does in text mode.
>
>>>> 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. ...
>
>I would expect line printers might have a maximum line length, and if
>so, I'd expect problems trying to print a line longer than that. Most of
>the printers I've used that weren't line printers would treat text data
>that doesn't contain any newline characters by starting a new line when
>it reaches the right edge of the page, and starting a new page when it
>reaches the bottom edge of the page. Are OS/360 systems only compatible
>with line printers, or do the non-line-printers that they can be
>attached to have different behavior than the one I describe?
OS/360 I can't answer, but later versions of the OS have certainly
supported more sophisticated printers. Somewhat oversimplified, AFP
printers use a page description language (think PCL5 or Postscript),
to render a page. The elements of that are still typically stored in
record oriented files (for spooling, for example), although they don't
need to be quite as fixed length as line printer data, and the
communication with the printer can often use much larger (and more
variable) sized I/O blocks.
OTOH line printer output is not uncommonly written in variable format
either, but records are assumed to be padded with spaces out to the
physical line length.
>> ... Programs
>> can read the LRECL and allocate buffers based on it. Compilers
>> will probably also reject the files.
>
>So LRECL is, in fact, the conventional approach on OS/360 for indicating
>where the end of a line is? I asked you before, but you never identified
>what the conventional approach is.
>
>C allows an implementation to have a maximum line length, but doesn't
>require it. I wouldn't be surprised by a compiler that rejected an
>overly long line, and I personally would never write a line longer than
>80 characters, but I'd prefer a compiler that would complain only if it
>couldn't dynamically allocate enough room to store the line.
>
>>>> 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?
>
>Such a file necessarily contains the characters '\a', '\b', '\f', '\v',
>and '\0'. Any one of those characters violates the conditions imposed by
>7.21.2p2, and a conforming implementation of C is therefore allowed to
>drop such characters, either when writing to text stream, or when
>reading from a text stream - it's up to the implementation whether or
>not that actually occurs.
>Since you describe OS/360 as not using the '\n' character as an
>end-of-line marker, nor even as part of a multi-character end-of-line
>marker, there's no way to write such a character to a text stream. So,
>the answer is no - you'd have to open it as a binary stream if you want
>it to include that character.
>
>So, getting back to my question, which you still haven't answered: given
>that the descriptions that you gave me for Java's System.out.println(),
>System.out.format("%n"), and the C standard's description of writing a
>'\n' character to a text stream all say comparable things about what the
>result would be, do you have any reason to believe that the result would
>be different between those three on an OS/360 system? I would expect all
>three to set the LRECL for the current block to the number of characters
>written since the last block was written. Do you have any reason to
>expect that any of those three would do something different?
Somewhat oversimplified:
The term LRECL is a bit overloaded - it has meaning both in terms of
the format of the file, and the API.
LRECL is only related to the physical storing of the record size in
some cases, particularly where the record format ("RECFM") specifies a
fixed format. For example, if you defined the file as
"RECFM=FB,LRECL=100", the file would have fixed lengths records of 100
bytes, "blocked" into larger I/O blocks (I've omitted the
specification for that). Typically then the program would read or
write records, and would often not even have to specify an actual
length (since it's fixed). The system would handle the blocking of
those records into physical blocks, and would ultimately write a
physical block some multiple of the specified LRECL.
In the case of a variable length (record) file, the LRECL in the
definition specifies the maximum allowed (variable length) record for
the file.
At the API level, LRECL what's communicated by the system to the
application (on a read) or by the application to the system (on a
write). As mentioned above, for a fixed format file that's often
redundant, but for a variable format file ("RECFM=VB", for example),
it's required. For a VB file, the system will store a length field in
front of each record in the block, and return that when the
application reads the record.
If you're writing to a variable format file in C text mode, the length
of each _record_ will be the number of characters (assuming a simple
character encoding) written between consecutive "\n" characters. The
limit for the record size can be defined with the file, and the
current C library implementations appear to just wrap to a new record
if you overflow the limit. The 32K-less-a-few* limit always applies,
except in the cases of "spanned" records, where records can be any
size, but you need special techniques for reading/writing them.
Writing to a fixed format file will usually get the "lines" padded or
wrapped as necessary (although truncation happens in some cases).
In the cases of wrapping or padding, you'll see that when you read the
file back in.
Binary streams are a bit different, in that they don't have \n
delimiters, and output just wraps from one record to the next
(although you can still see padding on the past record in file in some
cases).
Confusing the situation is the presence of "Unix" format file support,
which provides a (Unix) traditional hierarchical directory of byte
stream files. While mostly frequently used by Unix programs, these
can be accessed by traditional programs as well. In which case
sequential files can be processed which are both length delimited and
terminator delimited.
The "XL C/C++ Programming Guide" devotes some 45 pages to explaining
this mess more thoroughly.
*The "few" varies by access method, and in a few cases you can have
65536 instead.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-24 15:17 -0400 |
| Message-ID | <562BD959.8000601@verizon.net> |
| In reply to | #73716 |
On 10/24/2015 02:56 PM, Robert Wessel wrote: ... > Writing to a fixed format file will usually get the "lines" padded or > wrapped as necessary (although truncation happens in some cases). > > In the cases of wrapping or padding, you'll see that when you read the > file back in. The C standard explicitly allows for the possibility that padding blanks at the end of a line could be dropped somewhere along the line between being written to a text stream and being read back. However, if no such padding was provided, the standard gives the implementation no permission to add such padding (7.21.2p3). An implementation of C would therefore have to come up with some method of making the added padding invisible. The simplest way to do so would be to drop all such padding on input from a text stream, whether or not it was present when first written to the file.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-10-25 13:47 -0500 |
| Message-ID | <0t8q2bpsqaddip6s25v2o7d9fmodhiof8u@4ax.com> |
| In reply to | #73722 |
On Sat, 24 Oct 2015 15:17:45 -0400, James Kuyper <jameskuyper@verizon.net> wrote: >On 10/24/2015 02:56 PM, Robert Wessel wrote: >... >> Writing to a fixed format file will usually get the "lines" padded or >> wrapped as necessary (although truncation happens in some cases). >> >> In the cases of wrapping or padding, you'll see that when you read the >> file back in. > >The C standard explicitly allows for the possibility that padding blanks >at the end of a line could be dropped somewhere along the line between >being written to a text stream and being read back. However, if no such >padding was provided, the standard gives the implementation no >permission to add such padding (7.21.2p3). An implementation of C would >therefore have to come up with some method of making the added padding >invisible. The simplest way to do so would be to drop all such padding >on input from a text stream, whether or not it was present when first >written to the file. Never knew that...
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-25 23:46 +0000 |
| Message-ID | <n0jpla$2aa$1@speranza.aioe.org> |
| In reply to | #73722 |
James Kuyper <jameskuyper@verizon.net> wrote: > On 10/24/2015 02:56 PM, Robert Wessel wrote: >> Writing to a fixed format file will usually get the "lines" padded or >> wrapped as necessary (although truncation happens in some cases). PL/I STREAM I/O does it, but that is a feature of STREAM, not a feature of fixed length records. Most OS/360 programs either truncate or give a (usually fatal) error. >> In the cases of wrapping or padding, you'll see that when you read the >> file back in. > The C standard explicitly allows for the possibility that padding blanks > at the end of a line could be dropped somewhere along the line between > being written to a text stream and being read back. However, if no such > padding was provided, the standard gives the implementation no > permission to add such padding (7.21.2p3). An implementation of C would > therefore have to come up with some method of making the added padding > invisible. The simplest way to do so would be to drop all such padding > on input from a text stream, whether or not it was present when first > written to the file. I think that is what I would expect. As noted, VB (variable length blocked) probably fits C better, but it would be convenient to be able to read and write FB files. Note that the unix dd command will convert to/from fixed length records, removing any trailing blanks when it does. But also, I have used text editors that remove traiing blanks for lines, I believe even if you don't edit the line. Usually I don't want them, but it does make some things harder. -- glen
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-25 07:05 +0000 |
| Message-ID | <n0hv0e$u3$1@speranza.aioe.org> |
| In reply to | #73702 |
James Kuyper <jameskuyper@verizon.net> wrote:
> On 10/24/2015 05:51 AM, glen herrmannsfeldt wrote:
(snip)
>> 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?
> On systems which use '\n' to indicate the end-of-line, there's
> inherently no way to do it; it's logically impossible. On systems which
> use other methods, you can only do it by opening the stream in binary
> mode, and writing '\n'. This requires that you do the end-of-line
> marking yourself - converting the '\n' character into a system-specific
> method of marking line endings is something C only does in text mode.
But you still need a way to indicate line ends.
(I previously wrote)
>>>> 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.
(snip, I wrote)
>> 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. ...
> I would expect line printers might have a maximum line length, and if
> so, I'd expect problems trying to print a line longer than that. Most of
> the printers I've used that weren't line printers would treat text data
> that doesn't contain any newline characters by starting a new line when
> it reaches the right edge of the page, and starting a new page when it
> reaches the bottom edge of the page. Are OS/360 systems only compatible
> with line printers, or do the non-line-printers that they can be
> attached to have different behavior than the one I describe?
I believe are are either line printers or emulate line printers.
There are some pretty interesting printers. The 1403 train printer
was very popular.
https://en.wikipedia.org/wiki/IBM_1403
the printer buffers a whole line, then prints when a character on the
line is in position. Since the train spacing is different from the
print position spacing, it isn't possible for all hammers to fire
at once. That allows sharing of comparator logic. Trains with
fewer different characters, and so more copies of each, print faster.
I believe the print spooler will reject files with an LRECL too big.
>> ... Programs
>> can read the LRECL and allocate buffers based on it. Compilers
>> will probably also reject the files.
> So LRECL is, in fact, the conventional approach on OS/360 for indicating
> where the end of a line is? I asked you before, but you never identified
> what the conventional approach is.
LRECL is logical record length. For FB, it is the length of the fixed
length records. For VB, it is four plus the maximum possible line
length. The usual printers have 132 columns, but 120 also exist,
so the popular LRECL for printers are 121 and 133 for FB,
or 125 and 137 for VB.
LRECL is a property of a file, not a line. It goes into the directory
(VTOC) along with other file properties, such as BLKSIZE.
For FB (fixed length records) LRECL is all you need to know to find
line ends. If a file is RECFM=FB,LRECL=80,BLKSIZE=3200 blocks of 3200
bytes are written to the disk. (Pretty similar to the way blocks
are written to tape in unix.) The 3200 bytes are read into a buffer,
and either the OS or program divide the 3200 bytes into 80 byte
records. (The last block in a file can be shorter.)
For VB (variable length records) records of up to LRECL bytes,
including a four byte record descriptor word go into a buffer of
BLKSIZE bytes with a block descriptor word in front. If the
block isn't full, less than BLKSIZE bytes are written to disk.
The disk hardware keeps track of how long each block is.
https://en.wikipedia.org/wiki/Count_key_data
In the FB case, it is easy to figure out how many blocks go on
a disk track. Not so easy for VB or U, but the system will figure
out how to write them. Files are allocated in tracks, not blocks.
> C allows an implementation to have a maximum line length, but doesn't
> require it. I wouldn't be surprised by a compiler that rejected an
> overly long line, and I personally would never write a line longer than
> 80 characters, but I'd prefer a compiler that would complain only if it
> couldn't dynamically allocate enough room to store the line.
You mean for compiler input. I suppose an OS/360 C compiler might
accept a large LRECL. LRECL is convenient in allowing the program
(compiler) to allocate the buffer to the appropriate size at the
beginning, and not have to dynamically resize them later.
>>>> 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?
> Such a file necessarily contains the characters '\a', '\b', '\f', '\v',
> and '\0'. Any one of those characters violates the conditions imposed by
> 7.21.2p2, and a conforming implementation of C is therefore allowed to
> drop such characters, either when writing to text stream, or when
> reading from a text stream - it's up to the implementation whether or
> not that actually occurs.
> Since you describe OS/360 as not using the '\n' character as an
> end-of-line marker, nor even as part of a multi-character end-of-line
> marker, there's no way to write such a character to a text stream. So,
> the answer is no - you'd have to open it as a binary stream if you want
> it to include that character.
> So, getting back to my question, which you still haven't answered: given
> that the descriptions that you gave me for Java's System.out.println(),
> System.out.format("%n"), and the C standard's description of writing a
> '\n' character to a text stream all say comparable things about what the
> result would be, do you have any reason to believe that the result would
> be different between those three on an OS/360 system? I would expect all
> three to set the LRECL for the current block to the number of characters
> written since the last block was written. Do you have any reason to
> expect that any of those three would do something different?
As far as I understand it, with System.out.println() and
System.out.format("%n"); a line boundary can be created without
losing the ability to write any specific character. I suppose I
could ask in a Java newsgroup.
To continue in a different direction, Fortran unformatted files,
which I suspect would correspond to C binary files, use RECFM=VBS.
VBS allows for LRECL greater than BLKSIZE, which was pretty important
with the smaller devices for OS/360. The common 2314 disk allows
for a maximum BLKSIZE of 7294 bytes, but usually it would be even
smaller. Double buffering requries two buffers of BLKSIZE bytes.
Like unix tapes, where each write() call writes one block, and
each read() reads one block. But fwrite() and fread() don't have
a way to indicate block boundaries.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-25 10:59 -0400 |
| Message-ID | <562CEE47.9090209@verizon.net> |
| In reply to | #73753 |
On 10/25/2015 03:05 AM, glen herrmannsfeldt wrote:
> James Kuyper <jameskuyper@verizon.net> wrote:
>> On 10/24/2015 05:51 AM, glen herrmannsfeldt wrote:
>
> (snip)
>
>>> 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?
>
>> On systems which use '\n' to indicate the end-of-line, there's
>> inherently no way to do it; it's logically impossible. On systems which
>> use other methods, you can only do it by opening the stream in binary
>> mode, and writing '\n'. This requires that you do the end-of-line
>> marking yourself - converting the '\n' character into a system-specific
>> method of marking line endings is something C only does in text mode.
>
> But you still need a way to indicate line ends.
Well, yes, that's implied by my statement "This requires that you do the
end-of-line marking yourself". Your point is?
...
>>> ... Programs
>>> can read the LRECL and allocate buffers based on it. Compilers
>>> will probably also reject the files.
>
>> So LRECL is, in fact, the conventional approach on OS/360 for indicating
>> where the end of a line is? I asked you before, but you never identified
>> what the conventional approach is.
[snip a lot of words that make it clear that LRECL isn't the relevant
mechanism, without bothering to identify how line lengths are
conventionally kept track of on such a system]
I know that on some systems, when working on files with fixed record
sizes, the end of a line is indicated by the fact that the parts of the
block that are after the end of the line are padded with blank or null
characters - which is why the standard doesn't guarantee that blanks
written at the end of a line will be there when the line is read back
in. All such blanks can be dropped on input, whether they were the
result of explicit output or just padding. Is something like that
approach used?
If you do in fact have any idea how line lengths are conventionally
determined on this platform, please explain. If you don't know, say so.
And please use the term "line length" or "end of line" in your response
so that it's clear that you are actually responding to my request,
rather than merely doing another info dump.
...
>> So, getting back to my question, which you still haven't answered: given
>> that the descriptions that you gave me for Java's System.out.println(),
>> System.out.format("%n"), and the C standard's description of writing a
>> '\n' character to a text stream all say comparable things about what the
>> result would be, do you have any reason to believe that the result would
>> be different between those three on an OS/360 system? I would expect all
>> three to set the LRECL for the current block to the number of characters
>> written since the last block was written. Do you have any reason to
>> expect that any of those three would do something different?
>
> As far as I understand it, with System.out.println() and
> System.out.format("%n"); a line boundary can be created without
So, do you have any reason to believe that fputc('\n') to a text file
would fail to produce exactly the same kind of line boundary? If so,
what it that reason?
And, while I hate to have to repeat myself, but you've repeatedly
avoided answering this question: how would that line boundary be indicated?
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-26 02:24 +0000 |
| Message-ID | <n0k2te$gqa$1@speranza.aioe.org> |
| In reply to | #73767 |
James Kuyper <jameskuyper@verizon.net> wrote:
(snip)
(I wrote)
>> But you still need a way to indicate line ends.
> Well, yes, that's implied by my statement "This requires that you
> do the end-of-line marking yourself". Your point is?
>>> So LRECL is, in fact, the conventional approach on OS/360 for indicating
>>> where the end of a line is? I asked you before, but you never identified
>>> what the conventional approach is.
> [snip a lot of words that make it clear that LRECL isn't the relevant
> mechanism, without bothering to identify how line lengths are
> conventionally kept track of on such a system]
> I know that on some systems, when working on files with fixed record
> sizes, the end of a line is indicated by the fact that the parts of the
> block that are after the end of the line are padded with blank or null
> characters - which is why the standard doesn't guarantee that blanks
> written at the end of a line will be there when the line is read back
> in. All such blanks can be dropped on input, whether they were the
> result of explicit output or just padding. Is something like that
> approach used?
Theoretically FB (fixed record length) just gives you some number
of characters to fill up, but yes usually lines are padded with
blanks for text files. It is convenient for punched cards where
no holes punched is blank (X'40').
FB files with LRECL=80 are often called "card image" as it is
byte for byte what you get copying cards to disk (or tape).
But OS/360 object programs are also FB and LRECL=80. Unused columns
are blank filled, but not padded. Interestingly, one field in the
END card of an object program holds the start address if specified,
or blanks if not. Seems programs can't have X'404040' as their start
address.
> If you do in fact have any idea how line lengths are conventionally
> determined on this platform, please explain. If you don't know, say so.
> And please use the term "line length" or "end of line" in your response
> so that it's clear that you are actually responding to my request,
> rather than merely doing another info dump.
As above for FB, blank padded to a specified LRECL.
For VB, no padding is needed, each line (record) has a record
descriptor with a two byte length (in four bytes). LRECL gives
the maximum line length including the RDW. The maximum BLKSIZE
is 32760, so maximum LRECL is 32756, leaving 32752 characters
of text per line (record).
(snip)
>> As far as I understand it, with System.out.println() and
>> System.out.format("%n"); a line boundary can be created without
> So, do you have any reason to believe that fputc('\n') to a text file
> would fail to produce exactly the same kind of line boundary? If so,
> what it that reason?
Yes, I believe it would. But Java System.out.print("\n"); does
not have to generate a line boundary. (Besides the fact that
char in Java is 16 bits.)
> And, while I hate to have to repeat myself, but you've repeatedly
> avoided answering this question: how would that line boundary
> be indicated?
For OS/360 itself, there is nothing like fputc(). For I/O devices
like card readers, printers, disks, and tape, the smallest I/O
operation is a block or record. Terminal input is also buffered
externally from the processor such that whole lines are read
or written at once. (For output, the system doesn't really care,
but for input you normally don't get an interrupt until the
appropriate terminal line-end character is seen.)
I suppose in unix terms, there are block I/O devices, but not
character devices. You can write a disk file with LRECL=1,
and for that matter BLKSIZE=1, though. (In reading tapes, a block
less than 12 bytes with an error is treated as noise.)
Disks and tapes have interblock gaps, so you don't want to do that.
Oh, direct access files are RECFM=F (not blocked). Each read or
write maps directly to a disk block. As above, you can set LRECL
to any size you want, from 1 to the track size on the disk.
Data is read/written directly to your buffer.
Spooled I/O (SYSIN, the usual DDNAME for what unix calls stdin,
and SYSPRINT for what unix calls stdout) are usually buffered
and reblocked by the system, at least on larger machines.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-25 11:13 -0700 |
| Message-ID | <e218fd32-22e0-4a6f-a01e-9c64d1aa7289@googlegroups.com> |
| In reply to | #73753 |
On Sunday, October 25, 2015 at 2:06:04 AM UTC-5, glen herrmannsfeldt wrote: > the printer buffers a whole line, then prints when a character on the > line is in position. Since the train spacing is different from the > print position spacing, it isn't possible for all hammers to fire > at once. That allows sharing of comparator logic. Trains with > fewer different characters, and so more copies of each, print faster. About 25 years ago, I acquired some not-quite-working chain printers and contemplated designing some control electronics. My first thought was to try to design some high-speed comparator logic, but then I decided a better approach would be to use a RAM matrix with one column for each print column and one row for each chain position. I never built the thing, but I've long wondered whether "real" chain printers used comparators or whether they used a RAM matrix approach. Since you mention the possibility of skewing the chain/head spacing (on the units I had the chain links were exactly two columns apart) that got me thinking that perhaps the comparator approach could work excellently with delay-line storage. Any idea how they were actually implemented?
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-26 02:58 +0000 |
| Message-ID | <n0k4tj$jl3$1@speranza.aioe.org> |
| In reply to | #73774 |
supercat@casperkitty.com wrote: > On Sunday, October 25, 2015 at 2:06:04 AM UTC-5, glen herrmannsfeldt wrote: >> the printer buffers a whole line, then prints when a character on the >> line is in position. Since the train spacing is different from the >> print position spacing, it isn't possible for all hammers to fire >> at once. That allows sharing of comparator logic. Trains with >> fewer different characters, and so more copies of each, print faster. > About 25 years ago, I acquired some not-quite-working chain printers and > contemplated designing some control electronics. My first thought was to > try to design some high-speed comparator logic, but then I decided a better > approach would be to use a RAM matrix with one column for each print column > and one row for each chain position. I never built the thing, but I've > long wondered whether "real" chain printers used comparators or whether they > used a RAM matrix approach. Since you mention the possibility of skewing > the chain/head spacing (on the units I had the chain links were exactly two > columns apart) that got me thinking that perhaps the comparator approach > could work excellently with delay-line storage. Any idea how they were > actually implemented? I was not so long ago figuring out how printers work on the 360/20, the bottom of the 360 line. They do a lot to keep the price down, including having the CPU directly control I/O devices instead of external controllers. The cheaper printer uses a type bar with character spacing matching the print column spacing. At the beginning of a print line, the CPU computes the type bar offset for each character to be printed (depends on which way the bar is going). At each bar position it subracts one from each, and fires the hammer when it gets to zero. The mapping for four different type bars is built into the microcode. For the faster and nicer 1403: https://en.wikipedia.org/wiki/IBM_1403 the characters are on a chain or train (depends on the model). They are changable. It is rare to run a train with lower case characters, which print about half the speed. There is an additional buffer, separate from CPU memory. The mapping from bytes to print positions is done in software. (You can buy custom trains, or otherwise remap the ones you have. It is usual to map lower case to upper case with upper case only trains.) I believe the spacing is such that every 12th print column lines up with the train at once, and usual printers have 120 or 132 columns. I believe dedicated hardware looks up the characters in the buffer, matches them to print positions, and fires the hammers as appropriate. When all characters on a line have been printed, it advances to the next line. Some trains have a non-uniform distribution, such that rarely printed characters occur less often, and print slower. That is from the time when memory was core, so the print buffer and train mapping table are all in core. The controller between the 360 and the printer is really a special purpose computer, microcoded similar to the way low end computers were. The IBM 3800 https://en.wikipedia.org/wiki/IBM_3800 from 1976 is a page printer. It prints whole pages at once, moving the paper at a uniform speed. It prints 10,020 line/min at 6lpi, or 20,040 at 12lpi. That is about 28.3 inches per second, or 0.72 m/s (depending on where you are). You can only print one character in each print position, except that it does know how to overprint underlines when needed. It fills a buffer with a whole page image, then prints it while looking up character images in another table. (Later versions could do bit mapped printing, the early ones only characters, but you could have four different character sets on one page.) -- glen
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-24 11:02 -0700 |
| Message-ID | <330328eb-ada6-4fd4-b56e-2d63d934ef0f@googlegroups.com> |
| In reply to | #73678 |
On Saturday, October 24, 2015 at 4:51:46 AM UTC-5, 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? C allows files to be opened in two modes: text mode and binary mode. If a file is opened in binary mode, then it will be seen as a sequence of bytes. A function like "fgets" will likely read until either the next newline character is observed, the specified number of characters have been read, or the end of file is reached. Although fgets will use a newline character as a cue to stop reading, that character will otherwise not be viewed as anything "special". If a file is opened in text mode, then it will effectively be passed through a filter such that the stream of data the C program sees will have a newline character inserted at all line boundaries, and any other hardware- specific line-boundary indications removed. For example, if a system were to indicate lines of n=0..253 bytes as a byte value n+1 followed by n bytes, lines of more than 253 bytes as an FF followed by 253 bytes and then the balance of the line, and end-of-file by a zero byte where the line-length indicator had been expected, then if a file contained: 05 48 65 6C 6C 6F 03 48 49 21 00 len H e l l o len H I ! eof then a C program which opened the file in text mode and attempted to fread as much as it could into dat[] would read 48 65 6C 6C 6F 0A 48 49 21 0A H e l l o \n H i ! \n Opening the file in binary mode would likely yield the data shown above, with each line preceded by its length. Note that if the file contained newline characters embedded within lines, reading it in text mode would not allow code to distinguish those from real line boundaries; reading the file in binary mode would allow such a distinction, but would code would have to know how to recognize the line boundaries and contents for itself.
[toc] | [prev] | [next] | [standalone]
| From | Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> |
|---|---|
| Date | 2015-10-24 20:13 +0200 |
| Message-ID | <562bca8c$0$24137$e4fe514c@textnews.kpn.nl> |
| In reply to | #73678 |
On 24.10.15 11:51, glen herrmannsfeldt wrote:
> 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)
Use binary files and read/write whatever you fancy.
I hope you survive anarchy in data i/o.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-24 12:45 -0700 |
| Message-ID | <lnsi50t5hs.fsf@kst-u.example.com> |
| In reply to | #73678 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
[...]
> 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?
[...]
Interesting question.
I presume this is in the context of a system that doesn't use the '\n'
character to mark end-of-line in a text file, as Unix does. (On a
Unix-like system, what you're asking is logically impossible.) So
writing '\n' to a file in text mode will translate to the system's
end-of-line marker, and vice versa on input.
The obvious answer is to write to the file in binary mode, so writing
'\n' will write that literal character -- but then there's no portable
way to write an actual end-of-line marker. In fact, it might not even
be possible to write an actual end-of-line marker in binary mode. For
example, a system might represent binary files as arbitrary byte
sequences, and text files as sequences of fixed-length records, making
it impossible to create a text file using binary mode.
So I think the answer is that you can't do that. Which means that for a
system that uses an atypical text file representation, the character
that a C implementation chooses to use for '\n' should be something that
you would very rarely, if ever, want to write to a text file.
It's a hole in C's stdio semantics, but not one that's likely to cause
any problems in practice.
The most realistic case, I suppose, is writing a Unix-style text file on
Windows -- but for that case using binary mode should work.
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-24 10:30 +1300 |
| Message-ID | <d8vn77FuctcU2@mid.individual.net> |
| In reply to | #73611 |
glen herrmannsfeldt wrote: > James Kuyper <jameskuyper@verizon.net> wrote: > >> 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. That is a dangerous presumption! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-19 12:05 +0100 |
| Message-ID | <878u6zktj8.fsf@bsb.me.uk> |
| In reply to | #73270 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Monday, October 19, 2015 at 1:50:14 AM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> > On Sunday, October 18, 2015 at 3:50:08 PM UTC+1, Ben Bacarisse wrote:
>> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> >>
>> >> Can you give some examples so I know what you mean by "going back to C"?
>> >> The new languages that I've been reading about seem to be far removed
>> >> form C (even if the designers went back there for a starting point),
>> >> which tells me that C is not a good end-point for a modern programming
>> >> language.
>> >>
>> > By definition, if you create a new language using C as your basis
>> > and starting point, you're trying to make something a bit different
>> > for C. But it's also a compliment to C.
>>
>> I was hoping for an answer to my question. I just wanted to know what
>> you consider examples of new languages that went back to C for a
>> starting point. For some, if it uses {}s, it's a homage to C (I don't
>> accuse you of that, but I have no idea what languages you mean yet).
>>
> C++, C sharp, Objective C are obvious examples. They've even got C in their
> name. They're taking C as the starting point, and making it better or
> different.
Thank you. I now know what you meant. None of these designs seem to me
to advertise the virtues of C so I'm not sure what you think they show
about C.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-16 15:57 -0700 |
| Message-ID | <fa3cdb56-bed8-48d8-9a6a-f73e333acd86@googlegroups.com> |
| In reply to | #73070 |
On Friday, October 16, 2015 at 4:29:26 PM UTC-4, Rick C. Hodgin wrote:
> 01: struct SAbc
> 02: {
> 03: int i;
> 04: float f;
> 05: };
> 06:
> 07: int main(int argc, char* argv[])
> 08: {
> 09: struct SAbc abc;
> 10:
> 11: abc = 5;
> 12: abc = 2.0f;
> 13:
> 14: printf("%d, %f\n", abc, abc);
> 15: }
I could also see this syntax extending all the way out to this:
07: int main(int argc, char* argv[])
08: {
09: struct SAbc abc;
10:
11: abc = 5;
12: abc = 2.0f;
13:
14: printf("%d, %f\n", abc);
15: }
Because there is only one float reference, the third parameter of
the printf() statement would not be needed. It would auto-resolve
to the float member.
||||||||||
|| You could theoretically even introduce this (though I think this
|| makes it much harder to understand without GUI auto-show features
|| enabled to actually see what it's resolving to):
||
|| 12: = 2.0f;
||
|| No "abc.f" or "abc" even would be needed here because the assignment
|| is from a float, and it would search for matching floats in context.
|| If only one was found, it would be able to reference it exactly.
||||||||||
-----
I think I'll call this feature auto-resolve, with the act of
searching being referred to then, naturally, as auto-resolving.
Or, I could follow the example of Dr. Heinz Doofenshmirtz and
call it "THE AUTO-RESOLVINATOR!"
https://en.wikipedia.org/wiki/Dr._Heinz_Doofenshmirtz
https://www.youtube.com/watch?v=Sj7yxI-r_ag
But ... nah. :-)
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-17 00:54 +0100 |
| Message-ID | <mvs2ja$qoi$1@dont-email.me> |
| In reply to | #73108 |
On 16/10/2015 23:57, Rick C. Hodgin wrote:
> On Friday, October 16, 2015 at 4:29:26 PM UTC-4, Rick C. Hodgin wrote:
>> 01: struct SAbc
>> 02: {
>> 03: int i;
>> 04: float f;
>> 09: struct SAbc abc;
>> 10:
>> 11: abc = 5;
>> 12: abc = 2.0f;
> 14: printf("%d, %f\n", abc);
This is not a satisfactory feature. For a start, it is very restrictive
as it will only work with certain combinations of types with the struct.
And looking at it from a higher level, it means being able to do this:
a = x;
a = y;
a = z;
which in most languages assigns successive different values to a. Here,
a becomes the collection (x,y,z). Until you do:
a = w;
then, if w is also a compatible struct, it replaces all of a. Then
someone makes a small change to the types of a (int becomes float for
example, or adds an extra field so there are two int members) and your
program is suddenly full of type errors.
> 14: printf("%d, %f\n", abc);
And it gets worse! What happens here:
int w; float x; int y;
w = x + abc + y;
Does it look for an int field of abc or a float one? How about when that
print format string is only known at runtime?
You're also drawing a line between int and float types which in C are
usually well integrated.
What about:
int i = ****p; where p is a struct {int**** a; float**** b;};?
Or a and b might themselves be pointers to structs that contain pointers
to structs that eventually become ints or floats. That means that i =
x->y->z could involve searching a tree looking for the first path
amongst dozens that results in a matching type for i, but it needs to
make sure it's a unique path.
As I said, I could go on...
>> You also lose the ability to pick up an incorrect assignment of a
>> scalar to a struct.
>
> How so?
Because given this:
struct {int x; float y; int* z;} s, t;
int a;
then typing s=a instead of s=t is normally a type error. With your
feature, such errors will not be picked up. Not when the type of a
matches one of the members of the struct, and that type occurs just once.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-16 17:19 -0700 |
| Message-ID | <f8f626fa-cae9-40d4-aac6-9de85fdc13a1@googlegroups.com> |
| In reply to | #73112 |
On Friday, October 16, 2015 at 7:54:28 PM UTC-4, Bart wrote:
> On 16/10/2015 23:57, Rick C. Hodgin wrote:
> > On Friday, October 16, 2015 at 4:29:26 PM UTC-4, Rick C. Hodgin wrote:
> >> 01: struct SAbc
> >> 02: {
> >> 03: int i;
> >> 04: float f;
>
> >> 09: struct SAbc abc;
> >> 10:
> >> 11: abc = 5;
> >> 12: abc = 2.0f;
>
> > 14: printf("%d, %f\n", abc);
>
> This is not a satisfactory feature. For a start, it is very restrictive
> as it will only work with certain combinations of types with the struct.
Its purpose is for what it would be used for, and not for other things.
> And looking at it from a higher level, it means being able to do this:
>
> a = x;
> a = y;
> a = z;
>
> which in most languages assigns successive different values to a. Here,
> a becomes the collection (x,y,z). Until you do:
While it would be possible to do this ... the purpose of adding the
auto-resolve feature to CAlive would be make code clearer where
possible, not to make it more difficult to read. However, from within
the GUI's ability to possess "show auto-resolves," it would be possible
to show in source code the forms they resolve to so that it would
make sense to developers.
But, I would never write the above code.
> a = w;
>
> then, if w is also a compatible struct, it replaces all of a. Then
> someone makes a small change to the types of a (int becomes float for
> example, or adds an extra field so there are two int members) and your
> program is suddenly full of type errors.
I mentioned this in a previous post. The GUI editor would have
refactoring abilities which would specifically catch this, and
auto-insert the names for members which would then become ambiguous.
The Visual Studio add-on called "Visual Assist X" has this feature
today for C++ prototypes:
int function(int a, int b = 2, int c = 3);
void function(void)
{
int k = function(1); // Auto-fills with b=2, c=3
}
Were I to then remove the "int b = 2" code, rather than generate
errors in every place in my source code where I don't have the b
parameter, it has a feature to auto-insert those values.
http://forums.wholetomato.com/forum/topic.asp?TOPIC_ID=12411
> > 14: printf("%d, %f\n", abc);
>
> And it gets worse! What happens here:
>
> int w; float x; int y;
>
> w = x + abc + y;
>
> Does it look for an int field of abc or a float one? How about when that
> print format string is only known at runtime?
It would report that this is ambiguous because it cannot be clearly
resolved in code. Only in the cases of you using float + float + float
storing to a float would it be able to assume that you were wanting
to insert a float int he abc position above.
> You're also drawing a line between int and float types which in C are
> usually well integrated.
I'm distinguishing at the level of types. All types.
> What about:
>
> int i = ****p; where p is a struct {int**** a; float**** b;};?
It would report a "Really? Do you honestly believe your code needs
this?" error, and then reformat the hard drive.
> Or a and b might themselves be pointers to structs that contain pointers
> to structs that eventually become ints or floats. That means that i =
> x->y->z could involve searching a tree looking for the first path
> amongst dozens that results in a matching type for i, but it needs to
> make sure it's a unique path.
If they resolve to the type, and they are the only ones which do, then
yes, it would use that for the auto-resolve. And, the ABI model used
for CAlive's LiveCode would allow it to be know what it's resolving to
from within the GUI, debugger, or source code tree from the high level
.ca file, all the way down to the assembly level.
> As I said, I could go on...
Apart from bad coding styles and practices, there would be nothing
that would prevent things from being used as you indicate. But I
can also today use #define statements to make my code read the
opposite of things I want, so as to confuse people.
// somefile.h
#define EQUALS !=
#define NOTEQUALS ==
// somefile.c
if (x EQUALS y) ...
A person reading only somefile.c might be easily misled. But, C
allows it. In a similar way the code samples you have above would
mislead developers, but CAlive would allow it.
> >> You also lose the ability to pick up an incorrect assignment of a
> >> scalar to a struct.
> >
> > How so?
>
> Because given this:
>
> struct {int x; float y; int* z;} s, t;
> int a;
>
> then typing s=a instead of s=t is normally a type error. With your
> feature, such errors will not be picked up. Not when the type of a
> matches one of the members of the struct, and that type occurs just once.
CAlive would allow that error to pass through. However, you would be
able to find the error when an "uninitialized reference" was made to
either the y or z members in later code.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-17 15:33 +1300 |
| Message-ID | <d8dqccFp0vsU6@mid.individual.net> |
| In reply to | #73112 |
Bartc wrote:
> On 16/10/2015 23:57, Rick C. Hodgin wrote:
>> On Friday, October 16, 2015 at 4:29:26 PM UTC-4, Rick C. Hodgin wrote:
>>> 01: struct SAbc
>>> 02: {
>>> 03: int i;
>>> 04: float f;
>
>>> 09: struct SAbc abc;
>>> 10:
>>> 11: abc = 5;
>>> 12: abc = 2.0f;
>
>> 14: printf("%d, %f\n", abc);
>
> This is not a satisfactory feature. For a start, it is very restrictive
> as it will only work with certain combinations of types with the struct.
Indeed. A reasonable example would be something like:
struct Foo { int i; short s; };
Foo foo;
foo = 42; // Which member gets the assignment?
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-16 19:41 -0700 |
| Message-ID | <2c9f280f-01d1-4644-a62f-40853c80ee6b@googlegroups.com> |
| In reply to | #73125 |
On Friday, October 16, 2015 at 10:33:57 PM UTC-4, Ian Collins wrote:
> Bartc wrote:
> > On 16/10/2015 23:57, Rick C. Hodgin wrote:
> >> On Friday, October 16, 2015 at 4:29:26 PM UTC-4, Rick C. Hodgin wrote:
> >>> 01: struct SAbc
> >>> 02: {
> >>> 03: int i;
> >>> 04: float f;
> >
> >>> 09: struct SAbc abc;
> >>> 10:
> >>> 11: abc = 5;
> >>> 12: abc = 2.0f;
> >
> >> 14: printf("%d, %f\n", abc);
> >
> > This is not a satisfactory feature. For a start, it is very restrictive
> > as it will only work with certain combinations of types with the struct.
>
> Indeed. A reasonable example would be something like:
>
> struct Foo { int i; short s; };
>
> Foo foo;
>
> foo = 42; // Which member gets the assignment?
Neither. The target cannot be resolved into a single entity given
that 42 could apply to both int and short. It would report an
"ambiguous assignment, unable to auto-resolve" error.
However, these would both work:
foo = (int)42;
foo = (short)42;
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
Page 8 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