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 4 of 13 — ← Prev page 1 2 3 [4] 5 6 … 13 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-13 12:52 -0800 |
| Message-ID | <lninpilm27.fsf@kst-u.example.com> |
| In reply to | #101622 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
> 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.
I'll try to come back to this later.
[...]
>> 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.
The actual text:
Whether the last line requires a terminating new-line character is
implementation-defined.
doesn't express that *at all*. The thing that is
implementation-defined, that the implementation is required to
document, is whether the terminating new-line is required or not.
It's very clear about what the implementation is required to define,
namely the answer to a yes-or-no question. I see nothing suggesting
that an implementation must, or even should, define what happens
if the new-line is required and is not provided.
--
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-15 15:46 -0800 |
| Message-ID | <kfninpflwcw.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #101661 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>
> [...]
>
>> 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.
>
> I'll try to come back to this later.
Okay, I look forward to your later followup.
>>> 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.
>
> The actual text:
>
> Whether the last line requires a terminating new-line character is
> implementation-defined.
>
> doesn't express that *at all*. The thing that is
> implementation-defined, that the implementation is required to
> document, is whether the terminating new-line is required or not.
> It's very clear about what the implementation is required to define,
> namely the answer to a yes-or-no question. I see nothing suggesting
> that an implementation must, or even should, define what happens
> if the new-line is required and is not provided.
I believe you have this reaction because you don't yet realize the
significance of the different sense in how the word is used here.
However, let's ignore that for a moment, and for the sake of
discussion let's adopt your assumption that a "yes" or "no" is all
that's needed. Now consider an implementation whose answer to the
question is "Yes". What does the requirement mean? Remember, we
aren't talking about behavior here, but about a requirement. In
order to make sense of what is implied, the requirement must be
well-defined. For example, suppose there were a constraint
Output buffers require all intermediate shift states be
represented using a binary numbering system.
There is no way to evaluate that requirement because we don't know
what its implications are. Similarly, suppose in our putative
implementation we have a program (disclaimer: I'm just typing this
in, please excuse any minor errors):
#include <stdio.h>
int
main(){
FILE *f = fopen( "foo.bas", "w" );
if(f){
fprintf( f, "%s\n", "Oh happy day!" );
fprintf( f, "%s", "Oh unhappy day!" );
fclose( f );
}
return 0;
}
and run it (presumably with the fopen() call succeeding). What
does the implementation's "Yes" answer imply? Does it imply
(a) that the text file is written successfully, with only one
line in it? or
(b) that a file is written successfully, but it is not able
to be read as a text file? or
(c) that no new file appears in the external file system? or
(d) that the call to fclose() gives an error return, with
uncertain consequences for the file, but otherwise the
program completes execution normally? or
(e) some unknown consequence not listed above?
The answer to the question is that we don't know, because what
the specificational consequences are for a "Yes" answer is not
well-defined. In order to be interpreted reliably, statements
of requirement must be well-defined, as otherwise we don't know
what needs to be done to meet the requirement.
So apparently we have a choice. We can say the Standard is not
clear as to what is meant, or we can say the Standard stipulates
that the implementation must define what the rules are in the
case of a "yes" answer. Either way, whether the fclose() in
the program above constitutes undefined behavior is only one
possible reading among several, not an absolute certainty.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-15 16:54 -0800 |
| Message-ID | <lnwpdvg6yi.fsf@kst-u.example.com> |
| In reply to | #101900 |
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:
>>
>> [...]
>>
>>> 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.
>>
>> I'll try to come back to this later.
>
> Okay, I look forward to your later followup.
I haven't looked at every use of the word "requires" in the Standard.
Uses of "require", "required", and "requirement(s)" are also relevant.
There are, if I've counted correctly, 196 such uses in N1570.
In general, the standard can impose requirements on the beahavior of
(conforming) implementations or of programs, and most of the uses of
forms of "require" are consistent with that. The sentence in question,
in 7.21.2, is:
Whether the last line [of a text stream] requires a terminating
new-line character is implementation-defined.
and I'm assuming only the English menaing of the word "require". It
seems to attempt to impose a requirement on a text stream, which is at
least quite different from other requirements. And it is, in my
opinion, just plain poorly written.
>>>> 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.
>>
>> The actual text:
>>
>> Whether the last line requires a terminating new-line character is
>> implementation-defined.
>>
>> doesn't express that *at all*. The thing that is
>> implementation-defined, that the implementation is required to
>> document, is whether the terminating new-line is required or not.
>> It's very clear about what the implementation is required to define,
>> namely the answer to a yes-or-no question. I see nothing suggesting
>> that an implementation must, or even should, define what happens
>> if the new-line is required and is not provided.
>
> I believe you have this reaction because you don't yet realize the
> significance of the different sense in how the word is used here.
Precisely what "different sense" do you see? I agree it's used in a
different sense, but I don't believe there's enough information to
determine what that sense is.
> However, let's ignore that for a moment, and for the sake of
> discussion let's adopt your assumption that a "yes" or "no" is all
> that's needed. Now consider an implementation whose answer to the
> question is "Yes". What does the requirement mean? Remember, we
> aren't talking about behavior here, but about a requirement. In
> order to make sense of what is implied, the requirement must be
> well-defined. For example, suppose there were a constraint
>
> Output buffers require all intermediate shift states be
> represented using a binary numbering system.
>
> There is no way to evaluate that requirement because we don't know
> what its implications are. Similarly, suppose in our putative
> implementation we have a program (disclaimer: I'm just typing this
> in, please excuse any minor errors):
>
> #include <stdio.h>
> int
> main(){
> FILE *f = fopen( "foo.bas", "w" );
> if(f){
> fprintf( f, "%s\n", "Oh happy day!" );
> fprintf( f, "%s", "Oh unhappy day!" );
> fclose( f );
> }
> return 0;
> }
>
> and run it (presumably with the fopen() call succeeding). What
> does the implementation's "Yes" answer imply? Does it imply
>
> (a) that the text file is written successfully, with only one
> line in it? or
> (b) that a file is written successfully, but it is not able
> to be read as a text file? or
> (c) that no new file appears in the external file system? or
> (d) that the call to fclose() gives an error return, with
> uncertain consequences for the file, but otherwise the
> program completes execution normally? or
> (e) some unknown consequence not listed above?
>
> The answer to the question is that we don't know, because what
> the specificational consequences are for a "Yes" answer is not
> well-defined. In order to be interpreted reliably, statements
> of requirement must be well-defined, as otherwise we don't know
> what needs to be done to meet the requirement.
Right. We don't know the answer because the Standard doesn't say what
the answer is.
> So apparently we have a choice. We can say the Standard is not
> clear as to what is meant,
That's what I say.
> or we can say the Standard stipulates
> that the implementation must define what the rules are in the
> case of a "yes" answer.
How is that a reasonable choice? Nothing in the Standard requires an
implementation to define those rules.
> Either way, whether the fclose() in
> the program above constitutes undefined behavior is only one
> possible reading among several, not an absolute certainty.
It's clear to me that the Standard is not clear. The requirement in
question is badly written.
If the trailing new-line is required, and an implementation documents
that it's required, nothing in the standard either defines the behavior
of an fclose() or requires an implementation to document the behavior.
That is, by definition, undefined behavior. If you think the Standard
either defines the behavior or requires an implementation to document
the behavior, please point out where it does so.
Now perhaps the Committee didn't *intend* it to be undefined behavior,
but I'm not inclined to try to read their minds.
--
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-30 11:25 -0800 |
| Message-ID | <kfnsho0fizy.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #101905 |
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:
>>>
>>> [...]
>>>
>>>> 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.
>>>
>>> I'll try to come back to this later.
>>
>> Okay, I look forward to your later followup.
>
> I haven't looked at every use of the word "requires" in the Standard.
> Uses of "require", "required", and "requirement(s)" are also relevant.
> There are, if I've counted correctly, 196 such uses in N1570.
They may be relevant, but not necessarily more illuminating.
Part of my point is that the different words that have "require"
as a base are sometimes used in different ways. "Requirement"
(or its plural) appears to be used fairly consistently, as one
example, whereas "required" is more uneven in its usages. Taking
just "requires" (or perhaps also "require") shows the contrast
more clearly. Remember, I'm not trying to convince you of my
point of view, only to help you understand why someone might take
that point of view.
> In general, the standard can impose requirements on the beahavior of
> (conforming) implementations or of programs, and most of the uses of
> forms of "require" are consistent with that. The sentence in question,
> in 7.21.2, is:
>
> Whether the last line [of a text stream] requires a terminating
> new-line character is implementation-defined.
>
> and I'm assuming only the English menaing of the word "require".
The problem is "requires" has more than one meaning. Putting the
word 'the' before 'English meaning' makes a tacit assumption that
there is only one.
> It seems to attempt to impose a requirement on a text stream,
It could also be read as stating a limitation of text streams
(which in my view is more likely what was intended, but the
important point is that it could be read either way).
> which is at
> least quite different from other requirements. And it is, in my
> opinion, just plain poorly written.
I don't know if I would say poorly written, but certainly I agree
that some sort of clarification is called for here.
>>>>> 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.
>>>
>>> The actual text:
>>>
>>> Whether the last line requires a terminating new-line character is
>>> implementation-defined.
>>>
>>> doesn't express that *at all*. The thing that is
>>> implementation-defined, that the implementation is required to
>>> document, is whether the terminating new-line is required or not.
>>> It's very clear about what the implementation is required to define,
>>> namely the answer to a yes-or-no question. I see nothing suggesting
>>> that an implementation must, or even should, define what happens
>>> if the new-line is required and is not provided.
>>
>> I believe you have this reaction because you don't yet realize the
>> significance of the different sense in how the word is used here.
>
> Precisely what "different sense" do you see? I agree it's used in a
> different sense, but I don't believe there's enough information to
> determine what that sense is.
Let me tentatively agree with your last sentence, and expand on it
a bit.
Most "requirement"s in the Standard are imposed by the Standard,
on a program, and relate to a particular program construct (eg, a
statement, an external definition, or the operands of a particular
operator). Most uses of "requires" express requirements that are
imposed by some document, on a program (or maybe implementation),
and that relate to a program construct, or sometimes a class of
constructs. Now look at the "requires" in 7.21.2. What authority
is imposing the requirement (assuming it is a "requirement" in the
same sense that the word is used otherwise in the Standard)? On
what is the requirement being imposed - programs, implementations,
text streams, or something else? If on programs, what program
constructs are meant to be affected?
My personal view is that what the (optional) requirement is meant
to express is a limitation on the capabilities of text files.
This limitation has implications for what programs may accomplish
but it doesn't impose any requirements, in the normal Standard
sense, on any program construct. The key point though is that
we can't say for sure what program constructs might be affected,
and if so how.
>> However, let's ignore that for a moment, and for the sake of
>> discussion let's adopt your assumption that a "yes" or "no" is all
>> that's needed. Now consider an implementation whose answer to the
>> question is "Yes". What does the requirement mean? Remember, we
>> aren't talking about behavior here, but about a requirement. In
>> order to make sense of what is implied, the requirement must be
>> well-defined. For example, suppose there were a constraint
>>
>> Output buffers require all intermediate shift states be
>> represented using a binary numbering system.
>>
>> There is no way to evaluate that requirement because we don't know
>> what its implications are. Similarly, suppose in our putative
>> implementation we have a program (disclaimer: I'm just typing this
>> in, please excuse any minor errors):
>>
>> #include <stdio.h>
>> int
>> main(){
>> FILE *f = fopen( "foo.bas", "w" );
>> if(f){
>> fprintf( f, "%s\n", "Oh happy day!" );
>> fprintf( f, "%s", "Oh unhappy day!" );
>> fclose( f );
>> }
>> return 0;
>> }
>>
>> and run it (presumably with the fopen() call succeeding). What
>> does the implementation's "Yes" answer imply? Does it imply
>>
>> (a) that the text file is written successfully, with only one
>> line in it? or
>> (b) that a file is written successfully, but it is not able
>> to be read as a text file? or
>> (c) that no new file appears in the external file system? or
>> (d) that the call to fclose() gives an error return, with
>> uncertain consequences for the file, but otherwise the
>> program completes execution normally? or
>> (e) some unknown consequence not listed above?
>>
>> The answer to the question is that we don't know, because what
>> the specificational consequences are for a "Yes" answer is not
>> well-defined. In order to be interpreted reliably, statements
>> of requirement must be well-defined, as otherwise we don't know
>> what needs to be done to meet the requirement.
>
> Right. We don't know the answer because the Standard doesn't say what
> the answer is.
>
>> So apparently we have a choice. We can say the Standard is not
>> clear as to what is meant,
>
> That's what I say.
>
>> or we can say the Standard stipulates
>> that the implementation must define what the rules are in the
>> case of a "yes" answer.
>
> How is that a reasonable choice? Nothing in the Standard requires an
> implementation to define those rules.
Because of the definition of implementation-defined. We have
a situation that admits two or more possibilities, and the
implementation has to document which is chosen. If what the text
says is ambiguous, the various alternatives count as possibilities
among which the implementation has to choose.
>> Either way, whether the fclose() in
>> the program above constitutes undefined behavior is only one
>> possible reading among several, not an absolute certainty.
>
> It's clear to me that the Standard is not clear. The requirement in
> question is badly written.
>
> If the trailing new-line is required, and an implementation documents
> that it's required, nothing in the standard either defines the behavior
> of an fclose() or requires an implementation to document the behavior.
> That is, by definition, undefined behavior. If you think the Standard
> either defines the behavior or requires an implementation to document
> the behavior, please point out where it does so.
>
> Now perhaps the Committee didn't *intend* it to be undefined behavior,
> but I'm not inclined to try to read their minds.
I think you're being inconsistent. If you think the passage of
7.21.2 is unclear, then you can't know what effect it has on any
program construct, or whether it has any effect at all. If it
doesn't have any effect on any program construct, then the
behavior of fclose() is defined by its section in the Standard.
Looking at the other extreme, if we don't know what program
constructs are affected, then ANY program run on implementations
that say "yes" gives undefined behavior, by your logic. Either
you have to abandon the position that 7.21.2 is unclear, or you
have to concede that undefined behavior holds only under some
interpretations, not all. It cannot be both.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-30 14:06 -0800 |
| Message-ID | <0921553d-41f7-4f9b-980a-61ae1dd0f23f@googlegroups.com> |
| In reply to | #101905 |
On Sunday, January 15, 2017 at 6:54:28 PM UTC-6, Keith Thompson wrote: > If the trailing new-line is required, and an implementation documents > that it's required, nothing in the standard either defines the behavior > of an fclose() or requires an implementation to document the behavior. > That is, by definition, undefined behavior. If you think the Standard > either defines the behavior or requires an implementation to document > the behavior, please point out where it does so. People writing implementations that require a newline at the end of a file will generally know what will happen if code closes a file whose last character is something else, and would generally have no reason not to document it. Unless it is plausible that someone writing such an implementation would specify that a newline is required but not specify the consequences of its omission, the behavior would thus end up being treated as Implementation-Defined whether or not the Standard requires such treatment. Perhaps the subject could have been better approached as "Implementations are required to specify whether text files opened for input are guaranteed to end with a newline, and the consequences of attempting to write a text file that does not end with a newline."
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-29 06:07 -0800 |
| Message-ID | <9d132dbf-d503-4b18-830e-090b298bb6bc@googlegroups.com> |
| In reply to | #100464 |
On Thursday, December 29, 2016 at 2:19:42 AM UTC-6, Tim Rentsch wrote: > 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 Standard does not recognize any way by which an implementation could gain access to a file that it did not generate. It also imposes no requirements about what happens if an attempt is made to write a file in binary mode and read it in text mode, or vice versa. Consequently, if an implementation ensures that any text file written thereby will end with a newline, that implementation may do anything it likes if an attempt is made to open in text mode a non-empty file that ends with something other than a newline, since from the point of view of the Standard no such file could possibly exist unless written in binary mode (which would be UB). Nonetheless, since the whole *purpose* of many programs is to read files which were generated by some outside means, useful C implementations should endeavor to behave usefully when given such files.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-13 15:11 -0800 |
| Message-ID | <kfnpojqpnbb.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100585 |
supercat@casperkitty.com writes: > On Thursday, December 29, 2016 at 2:19:42 AM UTC-6, Tim Rentsch wrote: >> 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 Standard does not recognize any way by which an implementation > could gain access to a file that it did not generate. It also > imposes no requirements about what happens if an attempt is made > to write a file in binary mode and read it in text mode, or vice > versa. Both of these statements are false, but in any case they are both irrelevant to what I was saying.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-27 09:37 -0800 |
| Message-ID | <4a6fc47f-a063-4ca9-9269-4324fae7451e@googlegroups.com> |
| In reply to | #100305 |
On Monday, December 26, 2016 at 10:57:05 PM UTC+3, Manfred wrote:
> On 12/26/2016 7:39 PM, Alla _ wrote:
> >> (I don't want to repeat myself either, but if the logic were coded in a
> >> simpler way, there would have been less chance to make this mistake.)
> >
> > the notion of simplification?
> Now, this is a big statement. Simplification (more properly: complexity
> management) is a huge subject (as part of it Richard Heathfield
> mentioned earlier that functional decomposition is a skill, and he is
> right), so well beyond what can be handled here.
> Yet this tiny example shows (I think) some of its importance.
>
Thank you for all your comments and your help.
Not yet the right time to discuss this but a short question (I will be
happy to discuss this at length much later): you and Richard say
that function decomposition is a skill; this means that there are
certain rules, approaches and tools, which can be learned. I don't
recall too many specifics on this matter in K&R, though I still have
to study the whole book and do exercises from there.
Are there resources dedicated to development of functional
decomposition skill set? It seems that this is some global
skill set that is closer to the field of logic, and is not restricted
to any particular programming language, is it a correct assumption?
> > I have also added the part that deletes any unwanted trailing commas.
> > Is it better now?
> The trailing comma is a valid element of the CSV file: it means that
> there is a last field in the line which is an empty field. In your case
> it happens to be unexpected, but I would not consider this as
> "corrupted" input, so I would not handle it the way you do.
> I mentioned earlier that you have to make a decision here (you are lucky
> that you can decide what you want):
> - either you consider any extra field to be invalid, and therefore you
> fix the input file (in addition to having your program report that input
> is invalid); I gave you some hint on how to fix the spreadsheet.
> - or you allow the input lines to have additional fields after the ones
> you need/expect, and therefore simply ignore them and stop scanning the
> line after you successfully get the fields you need.
>
Yes, I was hoping that this is what I do by looping through all additional
commas and setting a buffer to '\0' right after I get all the input, valid for the task.
As to manually deleting (correcting the csv file), I have tried it many times
at the beginning - one time I have deleted up to 500 lines vertically and
horizontally; still got all those commas; another time I have increased the
range. Finally, given this has nothing to do with C, I decided to use the code
to correct the file, at least to some reasonable extent, and solve Microsoft
conversion issues sometime later.
<snip>
> See how this call does substantially the same job as strchr?
Oh ) Do you suggest that it will be more correct in terms of
function decomposition to use if (strchr...) here, and leave
the rest of the code, which tests the indexes and sets the end
of the buffer to '\0', in the outside function, thus avoiding
passing newline character addresses to that function?
How does this make the code more efficiently, if it does,
technically?
> > if (found_char(buffer, &index, &newline_r))
> > {
> > buffer[index] = '\0';
> > //DEBUG
> > printf("CR found; buffer ends at [%li]:: %s\n", index, buffer);
> > }
> And this too
> > else if (found_char(buffer, &index, &newline_n))
> > {
> > buffer[index] = '\0';
> > //DEBUG
> > printf("LF found; buffer ends at [%li]:: %s\n", index, buffer);
> > }
> >
> <snip>
>
> Good that you eliminated the code replication.
> > /** Find CR at the end of the line **/
> The newline argument points in fact to a single char, so why not making
> it a char instead of a const char* ?
I have taken const char* type from strchr declaration. Also I recall advices
I have received here that it is a good habit to show that the argument
will not be changed by the function. Have I misunderstood it?
> > bool found_char(char *buffer, size_t *index, const char *newline)
> > {
> > char *found = strchr(buffer, *newline);
> > if(found != NULL)
> > {
> > *index = found - buffer;
> > //DEBUG
> > printf("found %p, buffer %p\n", (void*)found, (void *) buffer);
> > printf("index = %li\n", *index);
> > //If array is empty
> > if(*index == 0)
> > {
> > buffer[*index] = '\0';
> > printf("Buffer is empty; please, check the input data\n");
> > return false;
> > }
> > //DEBUG
> > buffer[*index] = '&';
> > printf("Buffer [%zu]:: %s\n", *index, buffer);
> > return true;
> > }
> > else
>
> Just to mention this: no newline should not be an error condition: you
> may have a line with no newline at the end of the file. Still such a
> (last) line is a valid one.
Yes, of course, and my code doesn't return any error in such a case.
Only if some unprintable characters, other that newline, are found.
At least that was my intention. If it not seen from the code, that I have
to correct it, but I am not sure how: get_line function doesn't return false
if no newline is found; why is this incorrect?
> (This was already mentioned by some else)
> > puts("The newline character is not found");
> > return false;
> > }
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2016-12-27 19:29 +0100 |
| Message-ID | <o3ubu7$16o5$1@gioia.aioe.org> |
| In reply to | #100335 |
On 12/27/2016 6:37 PM, Alla _ wrote:
>
> Thank you for all your comments and your help.
> Not yet the right time to discuss this but a short question (I will be
> happy to discuss this at length much later): you and Richard say
> that function decomposition is a skill; this means that there are
> certain rules, approaches and tools, which can be learned. I don't
> recall too many specifics on this matter in K&R, though I still have
> to study the whole book and do exercises from there.
> Are there resources dedicated to development of functional
> decomposition skill set? It seems that this is some global
> skill set that is closer to the field of logic, and is not restricted
> to any particular programming language, is it a correct assumption?
Sure it has a broader scope than a specific language. From one side it
is also true that it may apply to different languages in different ways
(because languages offer different facilities for this task)
About resources, I think others here may have more comprehensive
information about the literature available (which by the way should be
dealt with after getting a good knowledge of the language).
> Yes, I was hoping that this is what I do by looping through all additional
> commas and setting a buffer to '\0' right after I get all the input, valid for the task.
If you simply set the terminating '\r' (if any) and '\n' to '\0', isn't
it enough?
> As to manually deleting (correcting the csv file), I have tried it many times
> at the beginning - one time I have deleted up to 500 lines vertically and
> horizontally; still got all those commas; another time I have increased the
> range. Finally, given this has nothing to do with C, I decided to use the code
> to correct the file, at least to some reasonable extent, and solve Microsoft
> conversion issues sometime later.
Indeed it has nothing to do with C. If it is hard to get rid of the
extra fields, you still have the option to ignore them - obviously this
applies to your larger program, here you only get the full line,
whatever amount of fields your input has.
>
> <snip>
>> See how this call does substantially the same job as strchr?
> Oh ) Do you suggest that it will be more correct in terms of
> function decomposition to use if (strchr...) here, and leave
> the rest of the code, which tests the indexes and sets the end
> of the buffer to '\0', in the outside function, thus avoiding
> passing newline character addresses to that function?
> How does this make the code more efficiently, if it does,
> technically?
My suggestion is simply that if found_char does the same job as strchr,
why not use strchr directly instead of found_char (obviously adapting
the code accordingly)?
>
>>> if (found_char(buffer, &index, &newline_r))
>>> {
>>> buffer[index] = '\0';
>>> //DEBUG
>>> printf("CR found; buffer ends at [%li]:: %s\n", index, buffer);
>>> }
>> And this too
>>> else if (found_char(buffer, &index, &newline_n))
>>> {
>>> buffer[index] = '\0';
>>> //DEBUG
>>> printf("LF found; buffer ends at [%li]:: %s\n", index, buffer);
>>> }
>>>
>>> /** Find CR at the end of the line **/
>> The newline argument points in fact to a single char, so why not making
>> it a char instead of a const char* ?
>
> I have taken const char* type from strchr declaration.
In the strchr declaration the const char* argument is the string to be
searched, the character to be searched for is passed by value
(specifically it is an int)
Also I recall advices
> I have received here that it is a good habit to show that the argument
> will not be changed by the function. Have I misunderstood it?
The advice is good, it is passing newline by address that is unnecessary
here.
>
>>> bool found_char(char *buffer, size_t *index, const char *newline)
>>> {
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-12-27 11:41 -0800 |
| Message-ID | <1a418fad-e67e-42d5-8e6c-eae8add76b2a@googlegroups.com> |
| In reply to | #100343 |
On Tuesday, December 27, 2016 at 12:29:35 PM UTC-6, Manfred wrote: > On 12/27/2016 6:37 PM, Alla _ wrote: > > > > Thank you for all your comments and your help. > > Not yet the right time to discuss this but a short question (I will be > > happy to discuss this at length much later): you and Richard say > > that function decomposition is a skill; this means that there are > > certain rules, approaches and tools, which can be learned. I don't > > recall too many specifics on this matter in K&R, though I still have > > to study the whole book and do exercises from there. > > Are there resources dedicated to development of functional > > decomposition skill set? It seems that this is some global > > skill set that is closer to the field of logic, and is not restricted > > to any particular programming language, is it a correct assumption? > Sure it has a broader scope than a specific language. From one side it > is also true that it may apply to different languages in different ways > (because languages offer different facilities for this task) > About resources, I think others here may have more comprehensive > information about the literature available (which by the way should be > dealt with after getting a good knowledge of the language). > The classic is probably "Notes on Structured Programming" by Edsger Dijstra. Also good is Kernighan and Pike, "The Practice of Programming". Also good is "C Interfaces and Implementations" by David Hanson. -- don't get all three.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-28 10:30 -0800 |
| Message-ID | <1d13a768-06c5-48d7-b75f-f1d75f2affb5@googlegroups.com> |
| In reply to | #100347 |
On Tuesday, December 27, 2016 at 10:42:06 PM UTC+3, luser droog wrote: > On Tuesday, December 27, 2016 at 12:29:35 PM UTC-6, Manfred wrote: > > On 12/27/2016 6:37 PM, Alla _ wrote: > > > > > > Thank you for all your comments and your help. > > > Not yet the right time to discuss this but a short question (I will be > > > happy to discuss this at length much later): you and Richard say > > > that function decomposition is a skill; this means that there are > > > certain rules, approaches and tools, which can be learned. I don't > > > recall too many specifics on this matter in K&R, though I still have > > > to study the whole book and do exercises from there. > > > Are there resources dedicated to development of functional > > > decomposition skill set? It seems that this is some global > > > skill set that is closer to the field of logic, and is not restricted > > > to any particular programming language, is it a correct assumption? > > Sure it has a broader scope than a specific language. From one side it > > is also true that it may apply to different languages in different ways > > (because languages offer different facilities for this task) > > About resources, I think others here may have more comprehensive > > information about the literature available (which by the way should be > > dealt with after getting a good knowledge of the language). > > > > The classic is probably "Notes on Structured Programming" > by Edsger Dijstra. Also good is Kernighan and Pike, > "The Practice of Programming". > > Also good is "C Interfaces and Implementations" by > David Hanson. > Thank you very much! > -- > don't get all three. Why? )
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-12-28 16:08 -0800 |
| Message-ID | <ee8fb284-f4a4-4b87-99d2-7f2285964b79@googlegroups.com> |
| In reply to | #100458 |
On Wednesday, December 28, 2016 at 12:30:19 PM UTC-6, Alla _ wrote: > On Tuesday, December 27, 2016 at 10:42:06 PM UTC+3, luser droog wrote: > > On Tuesday, December 27, 2016 at 12:29:35 PM UTC-6, Manfred wrote: > > > On 12/27/2016 6:37 PM, Alla _ wrote: > > > > > > > > Thank you for all your comments and your help. > > > > Not yet the right time to discuss this but a short question (I will be > > > > happy to discuss this at length much later): you and Richard say > > > > that function decomposition is a skill; this means that there are > > > > certain rules, approaches and tools, which can be learned. I don't > > > > recall too many specifics on this matter in K&R, though I still have > > > > to study the whole book and do exercises from there. > > > > Are there resources dedicated to development of functional > > > > decomposition skill set? It seems that this is some global > > > > skill set that is closer to the field of logic, and is not restricted > > > > to any particular programming language, is it a correct assumption? > > > Sure it has a broader scope than a specific language. From one side it > > > is also true that it may apply to different languages in different ways > > > (because languages offer different facilities for this task) > > > About resources, I think others here may have more comprehensive > > > information about the literature available (which by the way should be > > > dealt with after getting a good knowledge of the language). > > > > > > > The classic is probably "Notes on Structured Programming" > > by Edsger Dijstra. Also good is Kernighan and Pike, > > "The Practice of Programming". > > > > Also good is "C Interfaces and Implementations" by > > David Hanson. > > > Thank you very much! > > -- > > don't get all three. > Why? ) That's just my opinion that all three books are more than you need right now. They all cover a lot of the same basic ideas. Dijkstra's paper is shorter than the other two but it doesn't use C. Hanson's book is more about structuring the program into different files/modules but he does talk about functional decomposition too.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-12-27 12:50 -0800 |
| Message-ID | <3f930da8-fee7-4147-b586-ee362e3bc724@googlegroups.com> |
| In reply to | #100335 |
W dniu wtorek, 27 grudnia 2016 18:37:38 UTC+1 użytkownik Alla _ napisał: > > Thank you for all your comments and your help. > Not yet the right time to discuss this but a short question (I will be > happy to discuss this at length much later): you and Richard say > that function decomposition is a skill; this means that there are > certain rules, approaches and tools, which can be learned. I don't > recall too many specifics on this matter in K&R, though I still have > to study the whole book and do exercises from there. > Are there resources dedicated to development of functional > decomposition skill set? It seems that this is some global > skill set that is closer to the field of logic, and is not restricted > to any particular programming language, is it a correct assumption? > function decomposition in c is rather strightforward, i think anone feels what caould be turned in a function and it is just easy (much harder is to create (and debug) matter then deccomposite it on functions - and if something is harder in such decomposition it is good naming - good naming is not strightforward (coz one could easily get a lot of wrong names, too general, too specific or missing the meaning or using the wrong generalistations - this naming skill rises slowly with experience and overal domain knowledge
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-27 09:59 -0800 |
| Message-ID | <9ab352a9-d804-4eea-8263-219d68c6e821@googlegroups.com> |
| In reply to | #100305 |
On Monday, December 26, 2016 at 10:57:05 PM UTC+3, Manfred wrote:
> On 12/26/2016 7:39 PM, Alla _ wrote:
> <snip>
> See how this call does substantially the same job as strchr?
> > if (found_char(buffer, &index, &newline_r))
> > {
> > buffer[index] = '\0';
> > //DEBUG
> > printf("CR found; buffer ends at [%li]:: %s\n", index, buffer);
> > }
> And this too
> > else if (found_char(buffer, &index, &newline_n))
> > {
> > buffer[index] = '\0';
> > //DEBUG
> > printf("LF found; buffer ends at [%li]:: %s\n", index, buffer);
> > }
<snip>
Please, take a look at this piece. Have I understood you correctly
in terms of how to use a call to strchr?
The while loop:
//Read each line from the file, store in the buffer
while(fgets(buffer, sizeof(buffer), input_file) != NULL)
{
//If CR is found, its index is less than LF index
if ((found_char = strchr(buffer, newline_r)) != NULL
&& (set_index(buffer, &index, &found_char) == true))
{
buffer[index] = '\0';
//DEBUG
printf("CR found; buffer ends at [%li]:: %s\n", index, buffer);
}
else if ((found_char = strchr(buffer, newline_n)) != NULL
&& (set_index(buffer, &index, &found_char) == true))
{
buffer[index] = '\0';
//DEBUG
printf("LF found; buffer ends at [%li]:: %s\n", index, buffer);
}
else
puts("The newline character is not found");
//Delete any trailing commas
if(buffer[index-1] == ',')
{
index--;
while(!isdigit(buffer[index]) && buffer[index] == ',')
index--;
buffer[index+1] = '\0';
//DEBUG
printf("Comma found; buffer ends at [%li]:: %s\n", index+1, buffer);
}
//Check for any other unprintable characters
if(unprintable(buffer))
{
puts("CSV file contains unprintable characters");
puts("Please, correct the file and try again");
return false;
}
}
/** Set index at the end of the line **/
bool set_index(char *buffer, size_t *index, char **found_char)
{
*index = *found_char - buffer;
//DEBUG
printf("found %p, buffer %p\n", (void*)*found_char, (void *) buffer);
printf("index = %li\n", *index);
//If array is empty
if(*index == 0)
{
buffer[*index] = '\0';
printf("Buffer is empty; please, check the input data\n");
return false;
}
//DEBUG
buffer[*index] = '&';
printf("Buffer [%zu]:: %s\n", *index, buffer);
return true;
}
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2016-12-27 10:56 -0800 |
| Message-ID | <ugd56ch8phm6k4l37tm85s6af5omqkov47@4ax.com> |
| In reply to | #100341 |
On Tue, 27 Dec 2016 09:59:57 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:
<snip>
>Please, take a look at this piece. Have I understood you correctly
>in terms of how to use a call to strchr?
You are still in love with unnecessary processing.
>The while loop:
>//Read each line from the file, store in the buffer
> while(fgets(buffer, sizeof(buffer), input_file) != NULL)
> {
>
> //If CR is found, its index is less than LF index
Still an unjustified assertion.
> if ((found_char = strchr(buffer, newline_r)) != NULL
> && (set_index(buffer, &index, &found_char) == true))
You do not need index or set_index at all. But if you did, there
would be no reason to use &found_char when found_char is just as
effective.
> {
> buffer[index] = '\0';
Why not the simpler
*found_char = '\0';
> //DEBUG
> printf("CR found; buffer ends at [%li]:: %s\n", index, buffer);
You persist in using the wrong format for a size_t.
> }
> else if ((found_char = strchr(buffer, newline_n)) != NULL
> && (set_index(buffer, &index, &found_char) == true))
> {
> buffer[index] = '\0';
> //DEBUG
> printf("LF found; buffer ends at [%li]:: %s\n", index, buffer);
> }
> else
> puts("The newline character is not found");
>
> //Delete any trailing commas
> if(buffer[index-1] == ',')
> {
> index--;
> while(!isdigit(buffer[index]) && buffer[index] == ',')
Never use a single test when you can waste resources with a double
test. The isdigit test contributes nothing to the result.
> index--;
> buffer[index+1] = '\0';
> //DEBUG
> printf("Comma found; buffer ends at [%li]:: %s\n", index+1, buffer);
> }
> //Check for any other unprintable characters
> if(unprintable(buffer))
> {
> puts("CSV file contains unprintable characters");
> puts("Please, correct the file and try again");
> return false;
> }
> }
>
>/** Set index at the end of the line **/
>bool set_index(char *buffer, size_t *index, char **found_char)
If you used found_char in the call to this function, the parameter
would be char *found_char
>{
> *index = *found_char - buffer;
and this would be found_char - buffer
> //DEBUG
> printf("found %p, buffer %p\n", (void*)*found_char, (void *) buffer);
and this would be (void*)found_char
> printf("index = %li\n", *index);
> //If array is empty
> if(*index == 0)
If you really need this test, you can achieve the same result after
calling strchr with a simple
if (found_char == buffer)
> {
> buffer[*index] = '\0';
> printf("Buffer is empty; please, check the input data\n");
> return false;
> }
> //DEBUG
> buffer[*index] = '&';
> printf("Buffer [%zu]:: %s\n", *index, buffer);
> return true;
>}
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-27 12:24 -0800 |
| Message-ID | <lninq56ryt.fsf@kst-u.example.com> |
| In reply to | #100345 |
Barry Schwarz <schwarzb@dqel.com> writes:
> On Tue, 27 Dec 2016 09:59:57 -0800 (PST), Alla _
> <modelling.data@gmail.com> wrote:
[...]
>> while(fgets(buffer, sizeof(buffer), input_file) != NULL)
>> {
>>
>> //If CR is found, its index is less than LF index
>
> Still an unjustified assertion.
That depends on just what it means. After fgets(), *either* the
string contained in buffer contains exactly one LF character, which
will be at the very end, *or* it contains no LF characters at all.
If there is an LF character, then the index of a CR character
(if any) must be less than the index of the LF character.
But the comment doesn't cover the case where there is no LF character.
(I haven't read the code to determine whether it's consistent with the
comment.)
--
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 | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-28 08:35 -0800 |
| Message-ID | <850e29cc-4f44-4e13-bd30-793f0cba49b5@googlegroups.com> |
| In reply to | #100354 |
On Tuesday, December 27, 2016 at 11:22:57 PM UTC+3, Keith Thompson wrote:
> Barry Schwarz <schwarzb@dqel.com> writes:
> > On Tue, 27 Dec 2016 09:59:57 -0800 (PST), Alla _
> > <modelling.data@gmail.com> wrote:
> [...]
> >> while(fgets(buffer, sizeof(buffer), input_file) != NULL)
> >> {
> >>
> >> //If CR is found, its index is less than LF index
> >
> > Still an unjustified assertion.
>
> That depends on just what it means. After fgets(), *either* the
> string contained in buffer contains exactly one LF character, which
> will be at the very end, *or* it contains no LF characters at all.
> If there is an LF character, then the index of a CR character
> (if any) must be less than the index of the LF character.
>
I am confused now. When writing that assertion, I have meant exactly
this: if there are *both* CR and LF, then CR always comes first, followed
by LF; that is the sequence I have met everywhere I looked to find out
about these two. After reading comment Barry posted, I have understood
that I was wrong, and there are cases when CR doesn't come before LF,
if these both are present at the end of the line. So what assertion is
a correct one? Have I misunderstood Barry?
> But the comment doesn't cover the case where there is no LF character.
>
> (I haven't read the code to determine whether it's consistent with the
> comment.)
>
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-28 09:16 -0800 |
| Message-ID | <lnh95o55zk.fsf@kst-u.example.com> |
| In reply to | #100432 |
Alla _ <modelling.data@gmail.com> writes:
> On Tuesday, December 27, 2016 at 11:22:57 PM UTC+3, Keith Thompson wrote:
>> Barry Schwarz <schwarzb@dqel.com> writes:
>> > On Tue, 27 Dec 2016 09:59:57 -0800 (PST), Alla _
>> > <modelling.data@gmail.com> wrote:
>> [...]
>> >> while(fgets(buffer, sizeof(buffer), input_file) != NULL)
>> >> {
>> >>
>> >> //If CR is found, its index is less than LF index
>> >
>> > Still an unjustified assertion.
>>
>> That depends on just what it means. After fgets(), *either* the
>> string contained in buffer contains exactly one LF character, which
>> will be at the very end, *or* it contains no LF characters at all.
>> If there is an LF character, then the index of a CR character
>> (if any) must be less than the index of the LF character.
>>
> I am confused now. When writing that assertion, I have meant exactly
> this: if there are *both* CR and LF, then CR always comes first, followed
> by LF; that is the sequence I have met everywhere I looked to find out
> about these two.
That's correct.
> After reading comment Barry posted, I have understood
> that I was wrong, and there are cases when CR doesn't come before LF,
> if these both are present at the end of the line.
I'm not sure what Barry meant; I'll let him explain it. But as
I explained, after fgets(), either there's a single LF ('\n') at
the end of the string, or there is no LF in the string at all --
therefore a CR ('\r') if any, appears before an LF, if any.
Normally if there's a CR, it will be part of a CR-LF pair at the end of
the line (that's the Windows text file format). But it's also entirely
possible to have a stray CR in the middle of a line. A file containing
such a line is probably malformed, and I suggest ignoring the
possibility, at least for now.
> So what assertion is
> a correct one? Have I misunderstood Barry?
Possibly.
>> But the comment doesn't cover the case where there is no LF character.
>>
>> (I haven't read the code to determine whether it's consistent with the
>> comment.)
--
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 | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-28 10:08 -0800 |
| Message-ID | <c51d0d42-333f-4213-95fa-aae6af606af9@googlegroups.com> |
| In reply to | #100437 |
On Wednesday, December 28, 2016 at 8:16:24 PM UTC+3, Keith Thompson wrote:
> Alla _ <modelling.data@gmail.com> writes:
> > On Tuesday, December 27, 2016 at 11:22:57 PM UTC+3, Keith Thompson wrote:
> >> Barry Schwarz <schwarzb@dqel.com> writes:
> >> > On Tue, 27 Dec 2016 09:59:57 -0800 (PST), Alla _
> >> > <modelling.data@gmail.com> wrote:
> >> [...]
> >> >> while(fgets(buffer, sizeof(buffer), input_file) != NULL)
> >> >> {
> >> >>
> >> >> //If CR is found, its index is less than LF index
> >> >
> >> > Still an unjustified assertion.
> >>
> >> That depends on just what it means. After fgets(), *either* the
> >> string contained in buffer contains exactly one LF character, which
> >> will be at the very end, *or* it contains no LF characters at all.
> >> If there is an LF character, then the index of a CR character
> >> (if any) must be less than the index of the LF character.
> >>
> > I am confused now. When writing that assertion, I have meant exactly
> > this: if there are *both* CR and LF, then CR always comes first, followed
> > by LF; that is the sequence I have met everywhere I looked to find out
> > about these two.
>
> That's correct.
>
> > After reading comment Barry posted, I have understood
> > that I was wrong, and there are cases when CR doesn't come before LF,
> > if these both are present at the end of the line.
>
> I'm not sure what Barry meant; I'll let him explain it. But as
> I explained, after fgets(), either there's a single LF ('\n') at
> the end of the string, or there is no LF in the string at all --
> therefore a CR ('\r') if any, appears before an LF, if any.
>
> Normally if there's a CR, it will be part of a CR-LF pair at the end of
> the line (that's the Windows text file format). But it's also entirely
> possible to have a stray CR in the middle of a line. A file containing
> such a line is probably malformed, and I suggest ignoring the
> possibility, at least for now.
>
All right. This is exactly what I thought is going on. Thank you.
> > So what assertion is
> > a correct one? Have I misunderstood Barry?
>
> Possibly.
Seems like I did misunderstood his words.
>
<snip>
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2016-12-27 22:34 +0100 |
| Message-ID | <o3umou$1s46$1@gioia.aioe.org> |
| In reply to | #100345 |
On 12/27/2016 7:56 PM, Barry Schwarz wrote:
> On Tue, 27 Dec 2016 09:59:57 -0800 (PST), Alla _
> <modelling.data@gmail.com> wrote:
>
>> The while loop:
>> //Read each line from the file, store in the buffer
>> while(fgets(buffer, sizeof(buffer), input_file) != NULL)
>> {
>>
>> //If CR is found, its index is less than LF index
>
> Still an unjustified assertion.
As Keith pointed out, after fgets the LF (if any) is last, so the CR (if
any) comes earlier.
>
>> if ((found_char = strchr(buffer, newline_r)) != NULL
>> && (set_index(buffer, &index, &found_char) == true))
>
> You do not need index or set_index at all.
Indeed. Obviously found_char must be properly declared.
> Why not the simpler
> *found_char = '\0';
Indeed too.
<snip>
>> //Delete any trailing commas
As said, a trailing comma is valid in CSV, so I don't see why deleting
it. Moreover, any check (except possibly for unprintable()) on the field
contents (isdigit etc..) is dependent on the expected contents of the
CSV file, which is unspecified here - in fact if your goal here is to
get rid of the CRLF ending, and terminate the line with \0 instead, what
more do you want to do here?
>> }
>>
[toc] | [prev] | [next] | [standalone]
Page 4 of 13 — ← Prev page 1 2 3 [4] 5 6 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web