Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #100280 > unrolled thread
| Started by | Alla _ <modelling.data@gmail.com> |
|---|---|
| First post | 2016-12-26 00:31 -0800 |
| Last post | 2016-12-26 14:38 -0800 |
| Articles | 20 on this page of 252 — 20 participants |
Back to article view | Back to comp.lang.c
Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 00:31 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-26 01:19 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 02:25 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-26 14:04 -0800
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2016-12-26 12:04 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 05:49 -0800
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2016-12-26 15:20 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 07:31 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <mx2927@gmail.com> - 2016-12-26 16:44 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 08:00 -0800
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2016-12-26 17:43 +0000
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-26 12:03 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-27 23:56 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-28 09:33 +0000
Re: Reading lines from a file, eliminating CR and LF Manfred <mx2927@gmail.com> - 2016-12-26 17:06 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 09:48 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-26 19:03 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 10:39 -0800
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2016-12-26 19:49 +0000
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-26 20:56 +0100
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-26 13:50 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 00:27 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-28 09:35 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 10:33 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-28 20:48 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 15:31 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-29 18:56 +0000
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-29 01:03 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 01:33 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 00:16 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-29 14:05 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 23:49 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-28 15:34 +0100
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-28 08:49 -0800
Re: Reading lines from a file, eliminating CR and LF "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-04 12:55 -0500
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 00:19 -0800
Re: Reading lines from a file, eliminating CR and LF Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 13:01 -0800
Re: Reading lines from a file, eliminating CR and LF Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 07:35 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2016-12-29 08:58 -0800
Re: Reading lines from a file, eliminating CR and LF raltbos@xs4all.nl (Richard Bos) - 2017-01-01 15:21 +0000
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-29 09:19 -0800
Re: Reading lines from a file, eliminating CR and LF Jean-Marc Bourguet <jm@bourguet.org> - 2016-12-30 08:39 +0100
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-30 09:02 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:22 -0800
Re: Reading lines from a file, eliminating CR and LF "Peter \"Shaggy\" Haywood" <phaywood@alphalink.com.au> - 2016-12-31 00:22 +1100
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 03:29 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-02 10:09 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-02 14:01 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-02 16:35 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-02 16:49 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-03 05:32 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-03 08:47 -0800
Re: Reading lines from a file, eliminating CR and LF luser droog <luser.droog@gmail.com> - 2017-01-02 15:39 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-02 17:35 -0800
Re: Reading lines from a file, eliminating CR and LF luser droog <luser.droog@gmail.com> - 2017-01-02 20:00 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 08:24 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-02 13:15 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-02 17:00 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-02 19:48 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 09:32 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-13 12:52 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 15:46 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-15 16:54 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 11:25 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-30 14:06 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2016-12-29 06:07 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 15:11 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-27 09:37 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-27 19:29 +0100
Re: Reading lines from a file, eliminating CR and LF luser droog <luser.droog@gmail.com> - 2016-12-27 11:41 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 10:30 -0800
Re: Reading lines from a file, eliminating CR and LF luser droog <luser.droog@gmail.com> - 2016-12-28 16:08 -0800
Re: Reading lines from a file, eliminating CR and LF fir <profesor.fir@gmail.com> - 2016-12-27 12:50 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-27 09:59 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-27 10:56 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-27 12:24 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 08:35 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-28 09:16 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 10:08 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-27 22:34 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 08:39 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 02:20 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 10:11 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 00:20 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-29 14:56 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 22:35 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-30 22:45 +0100
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-31 00:01 +0000
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-31 03:19 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-31 00:20 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-31 00:23 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-31 00:29 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-31 11:10 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-31 10:53 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-31 20:24 +0000
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-29 00:53 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 01:28 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-29 14:48 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 22:19 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 01:55 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 10:14 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-29 11:44 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 02:02 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 03:13 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 14:49 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 03:28 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 03:45 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 13:53 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 08:23 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 03:50 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 13:35 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-30 15:22 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 08:29 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 16:51 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-31 10:50 -0800
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2016-12-31 19:02 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-31 20:10 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-01 04:08 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-01 12:38 +0000
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2017-01-01 13:45 +0000
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2017-01-01 13:54 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 15:26 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-01 16:46 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 17:08 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-01 08:13 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-01 16:47 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 16:53 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-01 09:18 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2017-01-01 19:20 +0100
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-01 15:18 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 03:41 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 15:07 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-01 09:05 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 19:16 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 03:39 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 04:02 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 13:48 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 13:47 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 07:21 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 18:38 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 10:57 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 21:48 +0000
POSIX, was: Re: Reading lines from a file, eliminating CR and LF luser droog <luser.droog@gmail.com> - 2017-01-02 15:58 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-31 21:03 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 11:30 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-02 19:45 +0000
Re: Reading lines from a file, eliminating CR and LF Ike Naar <ike@iceland.freeshell.org> - 2017-01-02 19:56 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-02 21:09 +0000
Re: Reading lines from a file, eliminating CR and LF Ian Collins <ian-news@hotmail.com> - 2017-01-03 11:01 +1300
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 12:45 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 14:09 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 15:07 +0000
Re: Reading lines from a file, eliminating CR and LF Ian Collins <ian-news@hotmail.com> - 2017-01-04 09:13 +1300
Re: Reading lines from a file, eliminating CR and LF Ian Collins <ian-news@hotmail.com> - 2017-01-03 11:53 +1300
Re: Reading lines from a file, eliminating CR and LF Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-02 15:40 -0800
Re: Reading lines from a file, eliminating CR and LF Ian Collins <ian-news@hotmail.com> - 2017-01-03 13:16 +1300
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 00:01 +0000
Re: Reading lines from a file, eliminating CR and LF Ian Collins <ian-news@hotmail.com> - 2017-01-03 13:21 +1300
Re: Reading lines from a file, eliminating CR and LF Ike Naar <ike@iceland.freeshell.org> - 2017-01-03 08:40 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 12:50 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 14:42 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 15:11 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 16:32 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 17:24 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 17:48 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 18:56 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 19:46 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 13:37 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-02 13:56 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 03:52 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 14:20 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 13:19 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 03:30 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-04 02:23 -0800
Re: Reading lines from a file, eliminating CR and LF mark.bluemel@gmail.com - 2017-01-04 02:56 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-04 07:06 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 15:21 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 03:01 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 11:51 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 04:04 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 14:23 +0000
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-04 12:26 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 13:38 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-05 16:25 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 12:21 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 02:52 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 14:13 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 07:54 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 07:59 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 08:12 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 17:15 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 09:19 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 08:28 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 17:20 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 10:45 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 09:02 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 19:49 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 13:28 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-05 16:14 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-06 00:50 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-06 06:11 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-06 16:33 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-06 12:14 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-07 02:15 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-07 21:51 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-07 03:32 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-07 21:57 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-08 01:51 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-08 02:09 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-07 04:09 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-07 22:05 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-08 03:43 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-08 21:36 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-09 04:33 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-09 21:44 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-09 23:54 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-10 02:04 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-10 11:28 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-10 04:25 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-10 14:14 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-10 14:52 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-10 07:02 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-12 00:11 -0800
Re: Reading lines from a file, eliminating CR and LF mark.bluemel@gmail.com - 2017-01-12 01:13 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-12 01:41 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 09:55 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-12 10:25 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-08 19:02 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-09 05:27 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2017-01-07 17:06 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-07 08:11 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-05 16:04 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-04 12:36 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-04 12:49 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-04 05:19 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 15:14 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 02:57 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-05 08:24 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 02:58 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-04 13:02 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 03:37 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 02:46 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 11:25 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 02:43 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 22:45 +0000
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-29 10:17 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 00:42 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 00:51 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 11:25 +0000
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-28 20:57 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 23:16 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-26 14:38 -0800
Page 3 of 13 — ← Prev page 1 2 [3] 4 5 … 13 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-29 09:19 -0800 |
| Message-ID | <lnmvfe1wlh.fsf@kst-u.example.com> |
| In reply to | #100464 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> The C standard says that for a text stream, it's implementation-defined
>> whether the final line requires a trailing '\n'. If it *is* required by
>> the current implementation, the behavior of reading a text file with no
>> '\n' on the last line is undefined. [...]
>
> That is one plausible interpretation.
>
> Another plausible interpretation is that the situation described
> simply cannot exist. If a file is closed with a non-empty last
> line, but no newline, then that last line is either discarded or
> it is written with a newline appended. The file system may have
> no way to represent a text file with a non-empty last line but
> without a trailing newline; or, if it does, an attempt to read
> such a line may read nothing and return EOF, or it may give the
> line with a newline appended. And which of these alternatives is
> meant to hold must be specified as part of the documentation that
> specifies what the implementation-defined requirement means in
> this implementation.
The relevant wording, N1570 7.21.2p2, is:
A text stream is an ordered sequence of characters composed into
lines, each line consisting of zero or more characters plus a
terminating new-line character. Whether the last line requires
a terminating new-line character is implementation-defined.
I find that second sentence a bit sloppy. On what entity is that
requirement imposed?
You're suggesting that it imposes a requirement on the I/O functions,
to ensure that the created text file has a terminating new-line
even if the program doesn't provide one.
> Personally, I think the second of these is more likely than
> the first. But both are plausible interpretations of what
> the Standard is intended to prescribe.
I agree that the second is more likely, and certainly more
user-friendly.
But in my opinion, an implementation where
FILE *f = fopen("foo.txt", "w");
fputs("foo", f);
fclose(f);
results in a file that is not a valid text file, and cannot be
successfully opened with fopen("foo.txt", "r"), would be conforming.
On such an implementation, the requirement of 7.21.2p2 is imposed
on the program, not on the runtime library.
(For that matter, an fopen() call can fail for any reason.)
On a Unix-like system, a file is a sequence of bytes, and *any*
file can be a valid text file (possibly containing one very
long unterminated line). On other systems, text files are more
restricted. On Windows, if I write "foo\n\r" to a file in binary
mode, the result is not a valid text file (actually I'm not sure
of that, but one can imagine similar scenarios on other systems).
I suggest that, on a system that requires that terminating new-line,
writing "foo" to a file can create something that is not a valid
text file.
--
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 | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2016-12-30 08:39 +0100 |
| Message-ID | <87bmvtdfw1.fsf@news.bourguet.org> |
| In reply to | #100543 |
Keith Thompson <kst-u@mib.org> writes: > On a Unix-like system, a file is a sequence of bytes, and *any* > file can be a valid text file (possibly containing one very > long unterminated line). POSIX defines a text file in such a way that \n is a line terminator and not a line separator and thus is required at the end of a text file excepted for an empty file. Historically, utilities working on text files tended to misbehave when it was missing but GNU version of standard Unix utilities tended to handle that situation relatively sanely and thus put pressure on other implementations but I'd not be surprised if some are still misbehaving. -- Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-30 09:02 -0800 |
| Message-ID | <ln1swpz6xr.fsf@kst-u.example.com> |
| In reply to | #100629 |
Jean-Marc Bourguet <jm@bourguet.org> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> On a Unix-like system, a file is a sequence of bytes, and *any*
>> file can be a valid text file (possibly containing one very
>> long unterminated line).
>
> POSIX defines a text file in such a way that \n is a line terminator and
> not a line separator and thus is required at the end of a text file
> excepted for an empty file. Historically, utilities working on text files
> tended to misbehave when it was missing but GNU version of standard Unix
> utilities tended to handle that situation relatively sanely and thus put
> pressure on other implementations but I'd not be surprised if some are
> still misbehaving.
Interesting. The POSIX definition of "text file" can be found at
http://pubs.opengroup.org/onlinepubs/009695399/xrat/xbd_chap03.html :
The term "text file" does not prevent the inclusion of control
or other non-printable characters (other than NUL). Therefore,
standard utilities that list text files as inputs or outputs
are either able to process the special characters or they
explicitly describe their limitations within their individual
descriptions. The definition of "text file" has caused
controversy. The only difference between text and binary files
is that text files have lines of less than {LINE_MAX} bytes,
with no NUL characters, each terminated by a <newline>. The
definition allows a file with a single <newline>, but not a
totally empty file, to be called a text file. If a file ends
with an incomplete line it is not strictly a text file by this
definition. The <newline> referred to in IEEE Std 1003.1-2001
is not some generic line separator, but a single character;
files created on systems where they use multiple characters for
ends of lines are not portable to all conforming systems without
some translation process unspecified by IEEE Std 1003.1-2001.
where LINE_MAX is required to be at least 2048.
I find it particularly suprising that an empty file is not considered to
be a text file. Which raises another point I hadn't noticed. N1570
7.21.2p2 says:
Data read in from a text stream will necessarily compare equal
to the data that were earlier written out to that stream only
if: the data consist only of printing characters and the control
characters horizontal tab and new-line; no new-line character is
immediately preceded by space characters; and the last character
is a new-line character.
That doesn't cover the case of an empty stream. (Most implementations
handle that case as I'd expect.)
I don't think this implies that a C implementation on a POSIX system
"requires" a new-line on the last line (N1570 7.21.2p2).
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-02 02:22 -0800 |
| Message-ID | <kfn4m1hu5gc.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100683 |
Keith Thompson <kst-u@mib.org> writes:
> I find it particularly suprising that an empty file is not
> considered [by POSIX] to be a text file. Which raises another
> point I hadn't noticed. N1570 7.21.2p2 says:
>
> Data read in from a text stream will necessarily compare equal
> to the data that were earlier written out to that stream only
> if: the data consist only of printing characters and the control
> characters horizontal tab and new-line; no new-line character is
> immediately preceded by space characters; and the last character
> is a new-line character.
>
> That doesn't cover the case of an empty stream. [...]
7.21.3 p4:
Whether a file of zero length (on which no characters have
been written by an output stream) actually exists is
implementation-defined.
[toc] | [prev] | [next] | [standalone]
| From | "Peter \"Shaggy\" Haywood" <phaywood@alphalink.com.au> |
|---|---|
| Date | 2016-12-31 00:22 +1100 |
| Message-ID | <ll3ijd-hu5.ln1@walter.foo> |
| In reply to | #100543 |
Groovy hepcat Keith Thompson was jivin' in comp.lang.c on Fri, 30 Dec
2016 4:19 am. It's a cool scene! Dig it.
> On Windows, if I write "foo\n\r" to a file in binary
> mode, the result is not a valid text file (actually I'm not sure
> of that, but one can imagine similar scenarios on other systems).
Actually, that would be a perfectly valid text file on that particular
system, at least as far as the system itself were concerned. And I
don't know of any C implementation that would reject it.
Although, whether or not the \n\r sequence were properly translated to
\n when read in text mode by a C program would depend on the C
implementation. It would be reasonable, for example, for the
implementation to simply drop the \r. It might also be reasonable for
the implementation to just ignore and include it. I think either
behaviour is technically legal, but I'm not sure. It might be a bit of
a grey area. But in any case, I can't imagine any Windows/DOS C
implementation having problems with this.
--
----- Dig the NEW and IMPROVED news sig!! -----
-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-02 03:29 -0800 |
| Message-ID | <kfna8b9sns3.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100543 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>
> [...]
>
>>> The C standard says that for a text stream, it's implementation-defined
>>> whether the final line requires a trailing '\n'. If it *is* required by
>>> the current implementation, the behavior of reading a text file with no
>>> '\n' on the last line is undefined. [...]
>>
>> That is one plausible interpretation.
>>
>> Another plausible interpretation is that the situation described
>> simply cannot exist. If a file is closed with a non-empty last
>> line, but no newline, then that last line is either discarded or
>> it is written with a newline appended. The file system may have
>> no way to represent a text file with a non-empty last line but
>> without a trailing newline; or, if it does, an attempt to read
>> such a line may read nothing and return EOF, or it may give the
>> line with a newline appended. And which of these alternatives is
>> meant to hold must be specified as part of the documentation that
>> specifies what the implementation-defined requirement means in
>> this implementation.
>
> The relevant wording, N1570 7.21.2p2, is:
>
> A text stream is an ordered sequence of characters composed into
> lines, each line consisting of zero or more characters plus a
> terminating new-line character. Whether the last line requires
> a terminating new-line character is implementation-defined.
>
> I find that second sentence a bit sloppy. On what entity is that
> requirement imposed?
That question assumes the statement is meant to impose a
restriction rather than just reflecting some external limitation,
eg, of the underlying OS's file system.
> You're suggesting that it imposes a requirement on the I/O functions,
> to ensure that the created text file has a terminating new-line
> even if the program doesn't provide one.
I don't mean to suggest that. In fact I believe the statement is
there to accommodate file systems whose text files simply have no
way of representing lines without a terminating new line. The
"requirement" in such cases is then just a restating of one of
the limitations of the host OS file system.
>> Personally, I think the second of these is more likely than
>> the first. But both are plausible interpretations of what
>> the Standard is intended to prescribe.
>
> I agree that the second is more likely, and certainly more
> user-friendly.
>
> But in my opinion, an implementation where
>
> FILE *f = fopen("foo.txt", "w");
> fputs("foo", f);
> fclose(f);
>
> results in a file that is not a valid text file, and cannot be
> successfully opened with fopen("foo.txt", "r"), would be conforming.
> On such an implementation, the requirement of 7.21.2p2 is imposed
> on the program, not on the runtime library.
I understand the opinion, and I agree that it's possible this is
what WG14 intended. My point is that it is also possible they
intended something different, perhaps along the lines I outlined
above. I'm not trying to say my interpretation is better than
yours, or vice versa, only that either is plausible given the
wording. As to what WG14 actually intended, I think the only
way to be sure about that is to submit a DR.
> (For that matter, an fopen() call can fail for any reason.)
>
> On a Unix-like system, a file is a sequence of bytes, and *any*
> file can be a valid text file (possibly containing one very
> long unterminated line). On other systems, text files are more
> restricted. On Windows, if I write "foo\n\r" to a file in binary
> mode, the result is not a valid text file (actually I'm not sure
> of that, but one can imagine similar scenarios on other systems).
> I suggest that, on a system that requires that terminating new-line,
> writing "foo" to a file can create something that is not a valid
> text file.
Your last statement is true but irrelevant, because that can
happen in any implementation whether the last line of a text file
requires a newline or not. The question is how much latitude
does an implementation have in such a case? I believe that such
cases are not meant to be undefined behavior, but are limited to
the behaviors documented as part of the implementation-defined
property associated with final newlines for text files.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-02 10:09 -0800 |
| Message-ID | <6e6aace3-d1e8-4be3-aa16-e99032ee1fba@googlegroups.com> |
| In reply to | #100865 |
On Monday, January 2, 2017 at 5:29:44 AM UTC-6, Tim Rentsch wrote:
> Keith Thompson writes:
> > But in my opinion, an implementation where
> >
> > FILE *f = fopen("foo.txt", "w");
> > fputs("foo", f);
> > fclose(f);
> >
> > results in a file that is not a valid text file, and cannot be
> > successfully opened with fopen("foo.txt", "r"), would be conforming.
> > On such an implementation, the requirement of 7.21.2p2 is imposed
> > on the program, not on the runtime library.
>
> I understand the opinion, and I agree that it's possible this is
> what WG14 intended. My point is that it is also possible they
> intended something different, perhaps along the lines I outlined
> above. I'm not trying to say my interpretation is better than
> yours, or vice versa, only that either is plausible given the
> wording. As to what WG14 actually intended, I think the only
> way to be sure about that is to submit a DR.
There are three ways that typical file systems might handle an attempt to
write some data without a trailing newline prior to closing a file:
1. Produce a file which, when read, will appear to contain precisely the
data that was written, with no trailing newline.
2. Produce a file which, when read, will appear to contain all of the data
that was written, possibly excluding trailing padding at the ends of
lines, with a newline added to complete the last partial line.
3. Produce a file like the above, but with the last partial line omitted
(I don't know if file systems worked like that, but some printers work
that way if programs reset them before beginning operation).
I don't think the authors of the Standard would have been averse to the idea
that an implementation targeting a file system that does something else
weird might expose such semantics to a C program, but I think they intended
that a programmer who knows how the underlying file system behaves should be
able to make use of that behavior.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-02 14:01 -0800 |
| Message-ID | <ln4m1hw28s.fsf@kst-u.example.com> |
| In reply to | #100886 |
supercat@casperkitty.com writes:
[...]
> There are three ways that typical file systems might handle an attempt to
> write some data without a trailing newline prior to closing a file:
>
> 1. Produce a file which, when read, will appear to contain precisely the
> data that was written, with no trailing newline.
>
> 2. Produce a file which, when read, will appear to contain all of the data
> that was written, possibly excluding trailing padding at the ends of
> lines, with a newline added to complete the last partial line.
>
> 3. Produce a file like the above, but with the last partial line omitted
> (I don't know if file systems worked like that, but some printers work
> that way if programs reset them before beginning operation).
Those are hardly the only possibilities.
4. Produce a file that is not a valid text file. Attempting to open it
using fopen() with a mode argument of "r" will fail (possibly setting
errno to indicate something like "not a text file", though the standard
doesn't require that) -- *or* attempting to read data from the file will
at some point fail and cause ferror() to return nonzero.
> I don't think the authors of the Standard would have been averse to the idea
> that an implementation targeting a file system that does something else
> weird might expose such semantics to a C program, but I think they intended
> that a programmer who knows how the underlying file system behaves should be
> able to make use of that behavior.
The question is not what the authors would have been averse to.
Certainly behaving in one of the sensible ways you suggest is
permitted. The question is what the standard actually requires.
If it fails to define the behavior, or a choice of behaviors,
then the behavior is undefined.
The key is just what the word "requires" means in that context.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-02 16:35 -0800 |
| Message-ID | <5d417a85-145c-46c5-b08c-bb3ee88007b9@googlegroups.com> |
| In reply to | #100914 |
On Monday, January 2, 2017 at 4:00:43 PM UTC-6, Keith Thompson wrote: > supercat writes: > [...] > > There are three ways that typical file systems might handle an attempt to > > write some data without a trailing newline prior to closing a file: > > > > 1. Produce a file which, when read, will appear to contain precisely the > > data that was written, with no trailing newline. > > > > 2. Produce a file which, when read, will appear to contain all of the data > > that was written, possibly excluding trailing padding at the ends of > > lines, with a newline added to complete the last partial line. > > > > 3. Produce a file like the above, but with the last partial line omitted > > (I don't know if file systems worked like that, but some printers work > > that way if programs reset them before beginning operation). > > Those are hardly the only possibilities. > > 4. Produce a file that is not a valid text file. Attempting to open it > using fopen() with a mode argument of "r" will fail (possibly setting > errno to indicate something like "not a text file", though the standard > doesn't require that) -- *or* attempting to read data from the file will > at some point fail and cause ferror() to return nonzero. I said a "typical file system". Are you aware of any file systems that could be reasonably described as "typical" which do not behave in one of the above fashions? > > I don't think the authors of the Standard would have been averse to the idea > > that an implementation targeting a file system that does something else > > weird might expose such semantics to a C program, but I think they intended > > that a programmer who knows how the underlying file system behaves should be > > able to make use of that behavior. > > The question is not what the authors would have been averse to. > Certainly behaving in one of the sensible ways you suggest is > permitted. The question is what the standard actually requires. > If it fails to define the behavior, or a choice of behaviors, > then the behavior is undefined. > > The key is just what the word "requires" means in that context. The Standard acknowledges that an implementation might be fully conforming and yet be of such low quality as to be useless. While the Standard does not acknowledge the concept, common sense would imply that quality implementations on some platforms should offer different guarantees from those on others. For example, nothing in the Standard would forbid an implementation from converting the first eight characters of a filename to uppercase and ignoring the rest, and such behavior would be expected on an MS-DOS implementation, but a Unix implementation which behaved in that fashion would be regarded as being of low quality unless it was explicitly documented as trying to emulate some other platform (e.g. MS-DOS). The normal purpose and expectation of I/O functions in the Standard library is to interface with an underlying file system and expose the semantics thereof. The Standard would allow for implementations to do otherwise, and there are some cases where it may be useful for them to do so (mostly for the purpose of emulating other systems), but for the most part quality general-purpose implementations should expose the features and guarantees offered by the underlying system.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-02 16:49 -0800 |
| Message-ID | <lnmvf9ufva.fsf@kst-u.example.com> |
| In reply to | #100940 |
supercat@casperkitty.com writes:
> On Monday, January 2, 2017 at 4:00:43 PM UTC-6, Keith Thompson wrote:
>> supercat writes:
>> [...]
>> > There are three ways that typical file systems might handle an attempt to
>> > write some data without a trailing newline prior to closing a file:
>> >
>> > 1. Produce a file which, when read, will appear to contain precisely the
>> > data that was written, with no trailing newline.
>> >
>> > 2. Produce a file which, when read, will appear to contain all of the data
>> > that was written, possibly excluding trailing padding at the ends of
>> > lines, with a newline added to complete the last partial line.
>> >
>> > 3. Produce a file like the above, but with the last partial line omitted
>> > (I don't know if file systems worked like that, but some printers work
>> > that way if programs reset them before beginning operation).
>>
>> Those are hardly the only possibilities.
>>
>> 4. Produce a file that is not a valid text file. Attempting to open it
>> using fopen() with a mode argument of "r" will fail (possibly setting
>> errno to indicate something like "not a text file", though the standard
>> doesn't require that) -- *or* attempting to read data from the file will
>> at some point fail and cause ferror() to return nonzero.
>
> I said a "typical file system". Are you aware of any file systems that
> could be reasonably described as "typical" which do not behave in one
> of the above fashions?
No, I'm not -- but there are plenty of file systems I'm not familiar
with.
I'm talking about what the Standard requires. You're talking about what
you expect typical implementations to do. They're two different things.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-03 05:32 -0800 |
| Message-ID | <94c0b8b0-2f16-40e9-b911-40c6d71ef7f2@googlegroups.com> |
| In reply to | #100941 |
On Monday, January 2, 2017 at 6:49:47 PM UTC-6, Keith Thompson wrote:
> I'm talking about what the Standard requires. You're talking about what
> you expect typical implementations to do. They're two different things.
Suppose the only way of attempting to opening a file for output on a
particular file system will, if the floppy door is open, cause the program
to output:
Write Protect Error on drive A
Abort, Retry, or Ignore?
and--if the next character from the console is A, abort the program or, if
the next character is R and the disk has been replaced by a different, non-
write protected, disk, overwrite parts of the latter disk's directory with
the contents of the former disk's directory?
Which of the following implementations of fopen() would be conformant:
1. Always return null, regardless of whether the drive is write-protected
or not.
2. Request that the file system open the file, and if a critical error
occurs and kills the program or produces a garbled disk, so be it.
Nothing in the Standard requires that fopen() have access to a file system
within which any files can be created, and I don't think anything in the
Standard would grant fopen() any special privilege to kill the program nor
corrupt the directory on a disk rather than returning "null" if it's not
able to complete the required action. Consequently, I would suggest that
for an implementation targeting MS-DOS 1.1, the former course of action
would be conforming and the latter would not, even though the latter would
generally be more useful.
I could see reading the Standard in such a way that anything that a system
might do in response to an "fopen" would be conforming, or in a way that
would forbid conforming implementations on some platforms from performing
any I/O that wasn't guaranteed to be "safe", but I see nothing in the
Standard that would allow some platforms to arbitrarily misbehave in
response to fopen, but not allow implementations to behave arbitrarily on
platforms which behave nicely.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-03 08:47 -0800 |
| Message-ID | <lneg0kum2z.fsf@kst-u.example.com> |
| In reply to | #100970 |
supercat@casperkitty.com writes:
> On Monday, January 2, 2017 at 6:49:47 PM UTC-6, Keith Thompson wrote:
>> I'm talking about what the Standard requires. You're talking about what
>> you expect typical implementations to do. They're two different things.
>
> Suppose the only way of attempting to opening a file for output on a
> particular file system will, if the floppy door is open, cause the program
[snip]
> Which of the following implementations of fopen() would be conformant:
>
> 1. Always return null, regardless of whether the drive is write-protected
> or not.
>
> 2. Request that the file system open the file, and if a critical error
> occurs and kills the program or produces a garbled disk, so be it.
[...]
I do not care.
--
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 | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2017-01-02 15:39 -0800 |
| Message-ID | <db946999-05c5-43f9-8c4a-f794a796f438@googlegroups.com> |
| In reply to | #100886 |
On Monday, January 2, 2017 at 12:09:43 PM UTC-6, supe...@casperkitty.com wrote: > I don't think the authors of the Standard would [...] I think this continual speculation about what these persons would think is not productive. There are 2 ways of interpreting the standard which seem to me to be usable in making programming decisions: The text of the standard says what it means, and absent further clarification of the intent it remains the final word. The intent of the committee is presented primarily through the text, but the resolution for any ambiguity should be inferred based on similar clarifications that have been made which speak to their intent. Pragmatically, both positions yield the same procedure: 1. follow what the text says 2. amend that interpretation of the text, informed by later clarifications But I don't see any value in jumping (unconditionally!) straight to "What were they thinking?" That how you write a stand-up comedy routine, not a computer program.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-02 17:35 -0800 |
| Message-ID | <df32a882-030f-4292-a3b4-7c1394da41ed@googlegroups.com> |
| In reply to | #100926 |
On Monday, January 2, 2017 at 5:39:24 PM UTC-6, luser droog wrote: > On Monday, January 2, 2017 at 12:09:43 PM UTC-6, supercat wrote: > > > I don't think the authors of the Standard would [...] > > I think this continual speculation about what these persons > would think is not productive. > > There are 2 ways of interpreting the standard which seem > to me to be usable in making programming decisions: > > The text of the standard says what it means, and absent > further clarification of the intent it remains the final > word. The Standard has never endeavored to mandate that implementations provide everything that will be needed to accomplish everything that C programmers have been using the language to do. It notes that some implementations are of higher quality than others, and that it would be possible for a conforming implementation to be conforming but useless. For whatever reasons, however, it deliberately avoids specifying what would be required for something to be considered a "quality" implementation, since that would likely vary considerably depending upon the target platform (a system that limited the total size of all malloc() regions to 1024 bytes might be just fine on a system with 2KB of RAM, but would be considered laughably horrible on a system with 2GB). Even before the Standard was written, the authors of C implementations were able to use common sense to make their implementations more useful than the Standard would require; the authors of the Standard saw no reason to forbid all behaviors that would have been seen as nonsensical. Unfortunately, the nature of what "common sense" would dictate has changed over the years.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2017-01-02 20:00 -0800 |
| Message-ID | <6953fd7d-6b64-475e-8a46-716b2e501a02@googlegroups.com> |
| In reply to | #100947 |
On Monday, January 2, 2017 at 7:35:49 PM UTC-6, supe...@casperkitty.com wrote: > On Monday, January 2, 2017 at 5:39:24 PM UTC-6, luser droog wrote: > > On Monday, January 2, 2017 at 12:09:43 PM UTC-6, supercat wrote: > > > > > I don't think the authors of the Standard would [...] > > > > I think this continual speculation about what these persons > > would think is not productive. > > > > There are 2 ways of interpreting the standard which seem > > to me to be usable in making programming decisions: > > > > The text of the standard says what it means, and absent > > further clarification of the intent it remains the final > > word. > > The Standard has never endeavored to mandate that implementations provide > everything that will be needed to accomplish everything that C programmers > have been using the language to do. It notes that some implementations are > of higher quality than others, and that it would be possible for a > conforming implementation to be conforming but useless. For whatever > reasons, however, it deliberately avoids specifying what would be required > for something to be considered a "quality" implementation, since that would > likely vary considerably depending upon the target platform (a system that > limited the total size of all malloc() regions to 1024 bytes might be just > fine on a system with 2KB of RAM, but would be considered laughably horrible > on a system with 2GB). > > Even before the Standard was written, the authors of C implementations were > able to use common sense to make their implementations more useful than the > Standard would require; the authors of the Standard saw no reason to forbid > all behaviors that would have been seen as nonsensical. Unfortunately, the > nature of what "common sense" would dictate has changed over the years. But what do we do about it? How does this line of reasoning affect any choices any of us have to make? That's what I was trying to get at ... chto sdyelat?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-13 08:24 -0800 |
| Message-ID | <kfn37gnq671.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100886 |
supercat@casperkitty.com writes:
> On Monday, January 2, 2017 at 5:29:44 AM UTC-6, Tim Rentsch wrote:
>> Keith Thompson writes:
>>> But in my opinion, an implementation where
>>>
>>> FILE *f = fopen("foo.txt", "w");
>>> fputs("foo", f);
>>> fclose(f);
>>>
>>> results in a file that is not a valid text file, and cannot be
>>> successfully opened with fopen("foo.txt", "r"), would be conforming.
>>> On such an implementation, the requirement of 7.21.2p2 is imposed
>>> on the program, not on the runtime library.
>>
>> I understand the opinion, and I agree that it's possible this is
>> what WG14 intended. My point is that it is also possible they
>> intended something different, perhaps along the lines I outlined
>> above. I'm not trying to say my interpretation is better than
>> yours, or vice versa, only that either is plausible given the
>> wording. As to what WG14 actually intended, I think the only
>> way to be sure about that is to submit a DR.
>
> There are three ways that typical file systems might handle an
> attempt to write some data without a trailing newline prior to
> closing a file: [...]
>
> [...] I think [the Standard's authors] intended that a programmer
> who knows how the underlying file system behaves should be able to
> make use of that behavior.
Fine, but it's beside the point of what I was saying.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-02 13:15 -0800 |
| Message-ID | <ln8tqtw4cs.fsf@kst-u.example.com> |
| In reply to | #100865 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>> [...]
>>
>>>> The C standard says that for a text stream, it's implementation-defined
>>>> whether the final line requires a trailing '\n'. If it *is* required by
>>>> the current implementation, the behavior of reading a text file with no
>>>> '\n' on the last line is undefined. [...]
>>>
>>> That is one plausible interpretation.
>>>
>>> Another plausible interpretation is that the situation described
>>> simply cannot exist. If a file is closed with a non-empty last
>>> line, but no newline, then that last line is either discarded or
>>> it is written with a newline appended. The file system may have
>>> no way to represent a text file with a non-empty last line but
>>> without a trailing newline; or, if it does, an attempt to read
>>> such a line may read nothing and return EOF, or it may give the
>>> line with a newline appended. And which of these alternatives is
>>> meant to hold must be specified as part of the documentation that
>>> specifies what the implementation-defined requirement means in
>>> this implementation.
>>
>> The relevant wording, N1570 7.21.2p2, is:
>>
>> A text stream is an ordered sequence of characters composed into
>> lines, each line consisting of zero or more characters plus a
>> terminating new-line character. Whether the last line requires
>> a terminating new-line character is implementation-defined.
>>
>> I find that second sentence a bit sloppy. On what entity is that
>> requirement imposed?
>
> That question assumes the statement is meant to impose a
> restriction rather than just reflecting some external limitation,
> eg, of the underlying OS's file system.
I believe it merely assumes that the word "requires" means "requires".
[...]
>> On a Unix-like system, a file is a sequence of bytes, and *any*
>> file can be a valid text file (possibly containing one very
>> long unterminated line). On other systems, text files are more
>> restricted. On Windows, if I write "foo\n\r" to a file in binary
>> mode, the result is not a valid text file (actually I'm not sure
>> of that, but one can imagine similar scenarios on other systems).
>> I suggest that, on a system that requires that terminating new-line,
>> writing "foo" to a file can create something that is not a valid
>> text file.
>
> Your last statement is true but irrelevant, because that can
> happen in any implementation whether the last line of a text file
> requires a newline or not. The question is how much latitude
> does an implementation have in such a case? I believe that such
> cases are not meant to be undefined behavior, but are limited to
> the behaviors documented as part of the implementation-defined
> property associated with final newlines for text files.
If such cases are not meant to be undefined behavior, but the standard
fails (intentionally or not) to define the behavior, then the behavior
is undefined.
What "implementation-defined property" are you referring to? If it's
implementation-defined, there's a specific requirement in the standard
for the behavior to be documented.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-02 17:00 -0800 |
| Message-ID | <b539ed47-38a1-4764-b7f1-f1605c8037db@googlegroups.com> |
| In reply to | #100908 |
On Monday, January 2, 2017 at 3:15:23 PM UTC-6, Keith Thompson wrote: > What "implementation-defined property" are you referring to? If it's > implementation-defined, there's a specific requirement in the standard > for the behavior to be documented. What terminology would the authors of the Standard use for behaviors which quality general-purpose implementations should map to defined underlying platform-behaviors when such behaviors exist, but which would be impractical to define on some other platforms?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-02 19:48 -0800 |
| Message-ID | <lninpwvm53.fsf@kst-u.example.com> |
| In reply to | #100942 |
supercat@casperkitty.com writes:
> On Monday, January 2, 2017 at 3:15:23 PM UTC-6, Keith Thompson wrote:
>> What "implementation-defined property" are you referring to? If it's
>> implementation-defined, there's a specific requirement in the standard
>> for the behavior to be documented.
>
> What terminology would the authors of the Standard use for behaviors which
> quality general-purpose implementations should map to defined underlying
> platform-behaviors when such behaviors exist, but which would be impractical
> to define on some other platforms?
Probably "recommended practice".
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-13 09:32 -0800 |
| Message-ID | <kfny3yeq31r.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100908 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Keith Thompson <kst-u@mib.org> writes: >>> Tim Rentsch <txr@alumni.caltech.edu> writes: >>>> Keith Thompson <kst-u@mib.org> writes: >>> >>> [...] >>> >>>>> The C standard says that for a text stream, it's implementation-defined >>>>> whether the final line requires a trailing '\n'. If it *is* required by >>>>> the current implementation, the behavior of reading a text file with no >>>>> '\n' on the last line is undefined. [...] >>>> >>>> That is one plausible interpretation. >>>> >>>> Another plausible interpretation is that the situation described >>>> simply cannot exist. If a file is closed with a non-empty last >>>> line, but no newline, then that last line is either discarded or >>>> it is written with a newline appended. The file system may have >>>> no way to represent a text file with a non-empty last line but >>>> without a trailing newline; or, if it does, an attempt to read >>>> such a line may read nothing and return EOF, or it may give the >>>> line with a newline appended. And which of these alternatives is >>>> meant to hold must be specified as part of the documentation that >>>> specifies what the implementation-defined requirement means in >>>> this implementation. >>> >>> The relevant wording, N1570 7.21.2p2, is: >>> >>> A text stream is an ordered sequence of characters composed into >>> lines, each line consisting of zero or more characters plus a >>> terminating new-line character. Whether the last line requires >>> a terminating new-line character is implementation-defined. >>> >>> I find that second sentence a bit sloppy. On what entity is that >>> requirement imposed? >> >> That question assumes the statement is meant to impose a >> restriction rather than just reflecting some external limitation, >> eg, of the underlying OS's file system. > > I believe it merely assumes that the word "requires" means "requires". Looking through the Standard for uses of "requires", it seems clear that the "requires" in 7.21.2 is used in a different sense than most or all other uses of "requires". We know what is meant when we say the Standard (or IEC 60559, etc) requires something. But lines in a file don't "require" anything, at least not in the same way that the Standard does. So the assumption that the "requires" of 7.21.2 means the same thing it does in other places is suspect. If you have a chance to look through the Standard for "requires" (there are perhaps ten to twenty occurrences), please do and see if you think my comments in the last paragraph are apt. > [...] > >>> On a Unix-like system, a file is a sequence of bytes, and *any* >>> file can be a valid text file (possibly containing one very >>> long unterminated line). On other systems, text files are more >>> restricted. On Windows, if I write "foo\n\r" to a file in binary >>> mode, the result is not a valid text file (actually I'm not sure >>> of that, but one can imagine similar scenarios on other systems). >>> I suggest that, on a system that requires that terminating new-line, >>> writing "foo" to a file can create something that is not a valid >>> text file. >> >> Your last statement is true but irrelevant, because that can >> happen in any implementation whether the last line of a text file >> requires a newline or not. The question is how much latitude >> does an implementation have in such a case? I believe that such >> cases are not meant to be undefined behavior, but are limited to >> the behaviors documented as part of the implementation-defined >> property associated with final newlines for text files. > > If such cases are not meant to be undefined behavior, but the standard > fails (intentionally or not) to define the behavior, then the behavior > is undefined. Yes but here there is an explicit definition - the case is identified as being implementation-defined. My understanding is that any situation that falls under an implementation-defined proviso must be defined to be /something/, in the sense that the implementation cannot "define" what happens to be undefined behavior. > What "implementation-defined property" are you referring to? If it's > implementation-defined, there's a specific requirement in the standard > for the behavior to be documented. I believe the statement in 7.21.2 is meant to say that the rules for what happens in such cases is implementation-defined. I agree that the actual text used doesn't express this very well, but it's still the most sensible way of reading it that I can find. Moreover, regardless of whether you agree that it is the most sensible reading, I think it stands up as a /plausible/ reading, which has been my main point all along.
[toc] | [prev] | [next] | [standalone]
Page 3 of 13 — ← Prev page 1 2 [3] 4 5 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web