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 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-03 14:42 +0000 |
| Message-ID | <87a8b8i4sl.fsf@bsb.me.uk> |
| In reply to | #100973 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 02/01/17 22:53, Ian Collins wrote:
>> On 01/ 3/17 08:56 AM, Ike Naar wrote:
>>> On 2017-01-02, Richard Heathfield <rjh@cpax.org.uk> wrote:
>>>> bool check_line(char *ptr)
>>>> {
>>>> char *endptr = NULL;
>>>
>>> The initialization of endptr to NULL is meaningless.
>>
>> It is unnecessary rather than meaningless in this specific case, but
>> leaving out the initialisation will very likely generate a diagnostic.
>> Yes you can suppress the used before assignment warning, but do you
>> really want to loose it in the cases where it is a genuine bug?
>
> I certainly wouldn't want to loose it. Really, is it /so/ hard to
> distinguish "lose" and "loose"?
For some people, yes, though I don't think you can tell from one
instance. (For example, is it really so hard to distinguish between
endptr and &endptr?)
> To answer the question you meant to ask, yes, I'm perfectly content to
> lose the "used before assignment" diagnostic message (on compilers
> that provide it) in return for being certain that every object in the
> program has a deterministic value for as much as possible of its
> lifetime.
In my view the value NULL is not the ideal one here. If I wanted an
initial value, I'd set it to ptr because endptr == ptr is the primary
indicator that strtod went wrong. Your code does not use *endptr, but
in an example that did, a casual reader would have to check that the
initial value of NULL will always have been replace by that point in the
code -- in effect wiping out some of the advantage of the
initialisation.
With char *endptr = ptr; even the return ptr == endptr; will be more
obvious without detailed knowledge of what strtod does in every case.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-03 15:11 +0000 |
| Message-ID | <o4gest$b1e$1@dont-email.me> |
| In reply to | #100984 |
On 03/01/17 14:42, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 02/01/17 22:53, Ian Collins wrote:
>>> On 01/ 3/17 08:56 AM, Ike Naar wrote:
>>>> On 2017-01-02, Richard Heathfield <rjh@cpax.org.uk> wrote:
>>>>> bool check_line(char *ptr)
>>>>> {
>>>>> char *endptr = NULL;
>>>>
>>>> The initialization of endptr to NULL is meaningless.
>>>
>>> It is unnecessary rather than meaningless in this specific case, but
>>> leaving out the initialisation will very likely generate a diagnostic.
>>> Yes you can suppress the used before assignment warning, but do you
>>> really want to loose it in the cases where it is a genuine bug?
>>
>> I certainly wouldn't want to loose it. Really, is it /so/ hard to
>> distinguish "lose" and "loose"?
>
> For some people, yes, though I don't think you can tell from one
> instance. (For example, is it really so hard to distinguish between
> endptr and &endptr?)
No, it's really easy. My excuse is a laptop keyboard (my current
environment doesn't easily lend itself to using an external keyboard,
and my laptop seems to have a mind of its own). Maybe he has an excuse too.
>> To answer the question you meant to ask, yes, I'm perfectly content to
>> lose the "used before assignment" diagnostic message (on compilers
>> that provide it) in return for being certain that every object in the
>> program has a deterministic value for as much as possible of its
>> lifetime.
>
> In my view the value NULL is not the ideal one here. If I wanted an
> initial value, I'd set it to ptr because endptr == ptr is the primary
> indicator that strtod went wrong.
For me, that's a good reason to set it to NULL.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-03 16:32 +0000 |
| Message-ID | <87vatwgl4f.fsf@bsb.me.uk> |
| In reply to | #100993 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 03/01/17 14:42, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>
>>> On 02/01/17 22:53, Ian Collins wrote:
>>>> On 01/ 3/17 08:56 AM, Ike Naar wrote:
>>>>> On 2017-01-02, Richard Heathfield <rjh@cpax.org.uk> wrote:
>>>>>> bool check_line(char *ptr)
>>>>>> {
>>>>>> char *endptr = NULL;
>>>>>
>>>>> The initialization of endptr to NULL is meaningless.
>>>>
>>>> It is unnecessary rather than meaningless in this specific case, but
>>>> leaving out the initialisation will very likely generate a diagnostic.
>>>> Yes you can suppress the used before assignment warning, but do you
>>>> really want to loose it in the cases where it is a genuine bug?
>>>
>>> I certainly wouldn't want to loose it. Really, is it /so/ hard to
>>> distinguish "lose" and "loose"?
>>
>> For some people, yes, though I don't think you can tell from one
>> instance. (For example, is it really so hard to distinguish between
>> endptr and &endptr?)
>
> No, it's really easy.
I'm not sure what you mean here. Is there a joke I'm missing or some
hyper-literal reading of your words that I'm ignoring?
<snip>
>>> To answer the question you meant to ask, yes, I'm perfectly content to
>>> lose the "used before assignment" diagnostic message (on compilers
>>> that provide it) in return for being certain that every object in the
>>> program has a deterministic value for as much as possible of its
>>> lifetime.
>>
>> In my view the value NULL is not the ideal one here. If I wanted an
>> initial value, I'd set it to ptr because endptr == ptr is the primary
>> indicator that strtod went wrong.
>
> For me, that's a good reason to set it to NULL.
Ah right. Can you explain, maybe with an example? In the example you
gave above, I commented on why I felt the last line was clearer with ptr
as the initial value, but you didn't comment on that. If you think that
remark missed the point, by all means resurrect it as the example to
discuss.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-03 17:24 +0000 |
| Message-ID | <o4gmkr$8qd$1@dont-email.me> |
| In reply to | #101009 |
On 03/01/17 16:32, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 03/01/17 14:42, Ben Bacarisse wrote:
>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>
>>>> On 02/01/17 22:53, Ian Collins wrote:
>>>>> On 01/ 3/17 08:56 AM, Ike Naar wrote:
>>>>>> On 2017-01-02, Richard Heathfield <rjh@cpax.org.uk> wrote:
>>>>>>> bool check_line(char *ptr)
>>>>>>> {
>>>>>>> char *endptr = NULL;
>>>>>>
>>>>>> The initialization of endptr to NULL is meaningless.
>>>>>
>>>>> It is unnecessary rather than meaningless in this specific case, but
>>>>> leaving out the initialisation will very likely generate a diagnostic.
>>>>> Yes you can suppress the used before assignment warning, but do you
>>>>> really want to loose it in the cases where it is a genuine bug?
>>>>
>>>> I certainly wouldn't want to loose it. Really, is it /so/ hard to
>>>> distinguish "lose" and "loose"?
>>>
>>> For some people, yes, though I don't think you can tell from one
>>> instance. (For example, is it really so hard to distinguish between
>>> endptr and &endptr?)
>>
>> No, it's really easy.
>
> I'm not sure what you mean here. Is there a joke I'm missing or some
> hyper-literal reading of your words that I'm ignoring?
I mean it's really easy to distinguish between endptr and &endptr. That
isn't hyper-literal. It's just literal.
What is not quite so easy is to compose Usenet articles on a dodgy
laptop keyboard. This is why I've kept my replies relatively short
recently, and sometimes avoided replying altogether. I'm doing my best,
but obviously Usenet isn't my highest priority.
>
> <snip>
>>>> To answer the question you meant to ask, yes, I'm perfectly content to
>>>> lose the "used before assignment" diagnostic message (on compilers
>>>> that provide it) in return for being certain that every object in the
>>>> program has a deterministic value for as much as possible of its
>>>> lifetime.
>>>
>>> In my view the value NULL is not the ideal one here. If I wanted an
>>> initial value, I'd set it to ptr because endptr == ptr is the primary
>>> indicator that strtod went wrong.
>>
>> For me, that's a good reason to set it to NULL.
>
> Ah right. Can you explain, maybe with an example? In the example you
> gave above, I commented on why I felt the last line was clearer with ptr
> as the initial value, but you didn't comment on that. If you think that
> remark missed the point, by all means resurrect it as the example to
> discuss.
I'd rather have the value of endptr be NULL (which is easily detectable
in the sense that, by inspecting its value, one can immediately tell
that it's invalid) than a non-NULL value (which isn't).
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-03 17:48 +0000 |
| Message-ID | <87h95gghlu.fsf@bsb.me.uk> |
| In reply to | #101016 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 03/01/17 16:32, Ben Bacarisse wrote: >> Richard Heathfield <rjh@cpax.org.uk> writes: >> >>> On 03/01/17 14:42, Ben Bacarisse wrote: <snip> >>>> For some people, yes, though I don't think you can tell from one >>>> instance. (For example, is it really so hard to distinguish between >>>> endptr and &endptr?) >>> >>> No, it's really easy. >> >> I'm not sure what you mean here. Is there a joke I'm missing or some >> hyper-literal reading of your words that I'm ignoring? > > I mean it's really easy to distinguish between endptr and > &endptr. That isn't hyper-literal. It's just literal. Oh I see. Sorry. I thought you were disagreeing with me that lose/loose is indeed hard for some people. <snip> >>>> In my view the value NULL is not the ideal one here. If I wanted an >>>> initial value, I'd set it to ptr because endptr == ptr is the primary >>>> indicator that strtod went wrong. >>> >>> For me, that's a good reason to set it to NULL. >> >> Ah right. Can you explain, maybe with an example? In the example you >> gave above, I commented on why I felt the last line was clearer with ptr >> as the initial value, but you didn't comment on that. If you think that >> remark missed the point, by all means resurrect it as the example to >> discuss. > > I'd rather have the value of endptr be NULL (which is easily > detectable in the sense that, by inspecting its value, one can > immediately tell that it's invalid) than a non-NULL value (which > isn't). I don't see how that helps. Can you say what you disagree with about the argument I gave for your three-line function (unless you want to show another example)? In that example, initialisation (any initialisation) has no effect on the semantics of the function. The only help it can offer is in readability or clarity or in robustness in the face of changes and so on. But, to me, the clarity is marginally improved by using ptr rather than NULL because any doubt about whether strtod sets endptr to ptr in some error cases becomes irrelevant to understanding the return value. And if you know that strtod sets endptr to ptr in all error cases then you don't care about the inital value anyway. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-03 18:56 +0000 |
| Message-ID | <o4gs1j$sv9$1@dont-email.me> |
| In reply to | #101018 |
On 03/01/17 17:48, Ben Bacarisse wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > >> On 03/01/17 16:32, Ben Bacarisse wrote: >>> Richard Heathfield <rjh@cpax.org.uk> writes: >>> >>>> On 03/01/17 14:42, Ben Bacarisse wrote: > <snip> > >>>>> For some people, yes, though I don't think you can tell from one >>>>> instance. (For example, is it really so hard to distinguish between >>>>> endptr and &endptr?) >>>> >>>> No, it's really easy. >>> >>> I'm not sure what you mean here. Is there a joke I'm missing or some >>> hyper-literal reading of your words that I'm ignoring? >> >> I mean it's really easy to distinguish between endptr and >> &endptr. That isn't hyper-literal. It's just literal. > > Oh I see. Sorry. I thought you were disagreeing with me that > lose/loose is indeed hard for some people. If you think it's hard for some people, so be it --- I'm not about to fight about it in comp.lang.c. > > <snip> >>>>> In my view the value NULL is not the ideal one here. If I wanted an >>>>> initial value, I'd set it to ptr because endptr == ptr is the primary >>>>> indicator that strtod went wrong. >>>> >>>> For me, that's a good reason to set it to NULL. >>> >>> Ah right. Can you explain, maybe with an example? In the example you >>> gave above, I commented on why I felt the last line was clearer with ptr >>> as the initial value, but you didn't comment on that. If you think that >>> remark missed the point, by all means resurrect it as the example to >>> discuss. >> >> I'd rather have the value of endptr be NULL (which is easily >> detectable in the sense that, by inspecting its value, one can >> immediately tell that it's invalid) than a non-NULL value (which >> isn't). > > I don't see how that helps. Okay. I'm surprised, but okay. > Can you say what you disagree with about > the argument I gave for your three-line function (unless you want to > show another example)? Programming is a sufficiently difficult activity that I find it helpful to take steps to make it as easy as possible. One of the ways that I do this is to adopt conventions, styles, habits of coding that /on the whole/ tend to reduce the amount of thought and time I have to spend writing and debugging code. One of the ways that I reduce the amount of time I have to spend debugging code is to do my best to ensure that, at all times as far as is practicable, every object in the program has a known, determinate value. If that value is NULL and the value is being dereferenced, I know immediately that there's a problem, whereas if I'd set it to some other non-NULL value I would /not/ necessarily immediately know that there's a problem. I have tried to make this as explicit an explanation as possible so that there can be no room for misunderstanding. I hope you now understand my position, even if you don't agree with it. > In that example, initialisation (any initialisation) has no effect on > the semantics of the function. The only help it can offer is in > readability or clarity or in robustness in the face of changes and so > on. Right. And, since I type T *t = NULL; /anyway/, the other bonus of leaving it as NULL is that I've already typed it, without even thinking about it. > But, to me, the clarity is marginally improved by using ptr rather > than NULL because any doubt about whether strtod sets endptr to ptr in > some error cases becomes irrelevant to understanding the return value. Okay, so if you're writing the code, that's how you'd write it. It's not how I'd write it. Vive la difference! > And if you know that strtod sets endptr to ptr in all error cases then > you don't care about the inital value anyway. I never did care about the initial value. If I /had/ cared about the initial value, I'd have thought about it. Because I didn't care, I didn't think about it --- I instead adopted my default attitude towards initial values, which was to choose the static default if no better alternative presented itself immediately to my mind when I was typing the definition. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-03 19:46 +0000 |
| Message-ID | <871swkgc5f.fsf@bsb.me.uk> |
| In reply to | #101019 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 03/01/17 17:48, Ben Bacarisse wrote: <snip> >> Oh I see. Sorry. I thought you were disagreeing with me that >> lose/loose is indeed hard for some people. > > If you think it's hard for some people, so be it --- I'm not about to > fight about it in comp.lang.c. I don't want to fight about it either. I was just hoping you'd believe me (rather than believing that I think it) but it's understandable that you remain sceptical. >> Richard Heathfield <rjh@cpax.org.uk> writes: <snip> >>> I'd rather have the value of endptr be NULL (which is easily >>> detectable in the sense that, by inspecting its value, one can >>> immediately tell that it's invalid) than a non-NULL value (which >>> isn't). >> >> I don't see how that helps. > > Okay. I'm surprised, but okay. Because, in this case, the only inspection is to compare against ptr and NULL is not invalid for that purpose. In fact if that value were to survive, it gives the rather odd result of making the strtod call appear successful. In some peculiar sense, ptr could be seen as the really "invalid" value here. >> Can you say what you disagree with about >> the argument I gave for your three-line function (unless you want to >> show another example)? > > Programming is a sufficiently difficult activity that I find it > helpful to take steps to make it as easy as possible. One of the ways > that I do this is to adopt conventions, styles, habits of coding that > /on the whole/ tend to reduce the amount of thought and time I have to > spend writing and debugging code. One of the ways that I reduce the > amount of time I have to spend debugging code is to do my best to > ensure that, at all times as far as is practicable, every object in > the program has a known, determinate value. If that value is NULL and > the value is being dereferenced, I know immediately that there's a > problem, whereas if I'd set it to some other non-NULL value I would > /not/ necessarily immediately know that there's a problem. The bit I was missing is that you don't always choose the value based on the particular circumstances of each declaration, but on some rule of thumb. (You explain below that sometimes a value is chosen for a specific purpose. I do know it's not a blanket rule.) <snip> >> But, to me, the clarity is marginally improved by using ptr rather >> than NULL because any doubt about whether strtod sets endptr to ptr in >> some error cases becomes irrelevant to understanding the return value. > > Okay, so if you're writing the code, that's how you'd write it. It's > not how I'd write it. Vive la difference! Actually I don't think I would have because I hadn't thought of it before. You see I must confess to the fact that your code made me wonder, just for a moment if, strtod would *always* set endptr because I looked at the initial value and the return line and thought: "oh, the default here is to succeed -- that's odd". It was only a moment, but that thought made me think I might choose, were I to choose a value at all, something else. <snip> > I never did care about the initial value. If I /had/ cared about the > initial value, I'd have thought about it. Yes, that was the key bit I didn't know before. It may have been a lot of words about very little, but I've learned something just from looking at three lines of code. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-03 13:37 -0800 |
| Message-ID | <cbd31c22-bc12-492a-8b47-143f5cb6d50d@googlegroups.com> |
| In reply to | #101019 |
On Tuesday, January 3, 2017 at 9:56:21 PM UTC+3, Richard Heathfield wrote: > On 03/01/17 17:48, Ben Bacarisse wrote: > > Richard Heathfield <rjh@cpax.org.uk> writes: > > > >> On 03/01/17 16:32, Ben Bacarisse wrote: > >>> Richard Heathfield <rjh@cpax.org.uk> writes: > >>> > >>>> On 03/01/17 14:42, Ben Bacarisse wrote: > > <snip> > > > >>>>> For some people, yes, though I don't think you can tell from one > >>>>> instance. (For example, is it really so hard to distinguish between > >>>>> endptr and &endptr?) > >>>> > >>>> No, it's really easy. > >>> > >>> I'm not sure what you mean here. Is there a joke I'm missing or some > >>> hyper-literal reading of your words that I'm ignoring? > >> > >> I mean it's really easy to distinguish between endptr and > >> &endptr. That isn't hyper-literal. It's just literal. > > > > Oh I see. Sorry. I thought you were disagreeing with me that > > lose/loose is indeed hard for some people. > > If you think it's hard for some people, so be it --- I'm not about to > fight about it in comp.lang.c. > > > > > <snip> > >>>>> In my view the value NULL is not the ideal one here. If I wanted an > >>>>> initial value, I'd set it to ptr because endptr == ptr is the primary > >>>>> indicator that strtod went wrong. > >>>> > >>>> For me, that's a good reason to set it to NULL. > >>> > >>> Ah right. Can you explain, maybe with an example? In the example you > >>> gave above, I commented on why I felt the last line was clearer with ptr > >>> as the initial value, but you didn't comment on that. If you think that > >>> remark missed the point, by all means resurrect it as the example to > >>> discuss. > >> > >> I'd rather have the value of endptr be NULL (which is easily > >> detectable in the sense that, by inspecting its value, one can > >> immediately tell that it's invalid) than a non-NULL value (which > >> isn't). > > > > I don't see how that helps. > > Okay. I'm surprised, but okay. > > > Can you say what you disagree with about > > the argument I gave for your three-line function (unless you want to > > show another example)? > > Programming is a sufficiently difficult activity that I find it helpful > to take steps to make it as easy as possible. One of the ways that I do > this is to adopt conventions, styles, habits of coding that /on the > whole/ tend to reduce the amount of thought and time I have to spend > writing and debugging code. One of the ways that I reduce the amount of > time I have to spend debugging code is to do my best to ensure that, at > all times as far as is practicable, every object in the program has a > known, determinate value. If that value is NULL and the value is being > dereferenced, I know immediately that there's a problem, whereas if I'd > set it to some other non-NULL value I would /not/ necessarily > immediately know that there's a problem. > > I have tried to make this as explicit an explanation as possible so that > there can be no room for misunderstanding. I hope you now understand my > position, even if you don't agree with it. > > > In that example, initialisation (any initialisation) has no effect on > > the semantics of the function. The only help it can offer is in > > readability or clarity or in robustness in the face of changes and so > > on. > > Right. And, since I type T *t = NULL; /anyway/, the other bonus of > leaving it as NULL is that I've already typed it, without even thinking > about it. > > > But, to me, the clarity is marginally improved by using ptr rather > > than NULL because any doubt about whether strtod sets endptr to ptr in > > some error cases becomes irrelevant to understanding the return value. > > Okay, so if you're writing the code, that's how you'd write it. It's not > how I'd write it. Vive la difference! > > > And if you know that strtod sets endptr to ptr in all error cases then > > you don't care about the inital value anyway. > > I never did care about the initial value. If I /had/ cared about the > initial value, I'd have thought about it. Because I didn't care, I > didn't think about it --- I instead adopted my default attitude towards > initial values, which was to choose the static default if no better > alternative presented itself immediately to my mind when I was typing > the definition. > Interesting discussion. I should confess that your habit, Richard, is hard-coded in my brain ) I always use it since you have showed it to me. Not that I am trying to interfere into this dialogue. It was just a short note.
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2017-01-02 13:56 -0800 |
| Message-ID | <imil6clkv01cbi4oidq6v597rsl760b3i2@4ax.com> |
| In reply to | #100895 |
On Mon, 2 Jan 2017 19:45:27 +0000, Richard Heathfield
<rjh@cpax.org.uk> wrote:
>On 02/01/17 19:30, Alla _ wrote:
>> bool check_line(char *ptr, size_t line)
>> {
>> while(*ptr)
>> {
>> //Ignore the sign
>> if( (*ptr == '-' || *ptr == '+' ||
>> *ptr == '.') && *(ptr+1) != '\0')
>> ptr++;
>> //Check for non-numerical characters
>> if (!isdigit(*ptr))
>> {
>> fprintf(stderr, "The line '%zu' contains non-numerical values.\n", line);
>> return true;
>> }
>> ptr++;
>> }
>> return false;
>> }
<snip>
>If you can do without the pointless noise, the function can be reduced
>to this:
>
>bool check_line(char *ptr)
>{
> char *endptr = NULL;
> strtod(ptr, endptr);
> return ptr == endptr;
>}
This only handles for the case where no conversion is performed. It
does not handle the case where garbage follows the number. Consider
return (ptr == endptr) || (*endptr && *endptr != '\n');
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-03 03:52 -0800 |
| Message-ID | <0ffc9b05-76c6-47ef-8508-44d70383c2aa@googlegroups.com> |
| In reply to | #100895 |
On Tuesday, January 3, 2017 at 2:25:46 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> > On Monday, January 2, 2017 at 10:45:35 PM UTC+3, Richard Heathfield wrote:
> >> On 02/01/17 19:30, Alla _ wrote:
> >> > bool check_line(char *ptr, size_t line)
> >> > {
> >> > while(*ptr)
> >> > {
> >> > //Ignore the sign
> >> > if( (*ptr == '-' || *ptr == '+' ||
> >> > *ptr == '.') && *(ptr+1) != '\0')
> >> > ptr++;
> >> > //Check for non-numerical characters
> >> > if (!isdigit(*ptr))
> >> > {
> >> > fprintf(stderr, "The line '%zu' contains non-numerical values.\n", line);
> >> > return true;
> >> > }
> >> > ptr++;
> >> > }
> >> > return false;
> >> > }
> >>
> >> You can replace this with:
> >>
> >> bool check_line(char *ptr, size_t line)
> >> {
> >> char *endptr = NULL;
> >> strtod(ptr, &endptr);
> >> if(ptr == endptr)
> >> {
> >> fprintf(stderr,
> >> "The line '%zu' contains non-numerical values.\n",
> >> line);
> >> }
> >> return ptr == endptr;
> >> }
> >>
> >> If you can do without the pointless noise, the function can be reduced
> >> to this:
> >>
> >> bool check_line(char *ptr)
> >> {
> >> char *endptr = NULL;
> >> strtod(ptr, endptr);
> >> return ptr == endptr;
> >> }
> >>
> > <snip>
> > I thought that I need to loop through the whole line anyway,
> > because according to the spec I have to ignore each line
> > that contains a non-numerical value, and this value can
> > be anywhere in the line, not only at the particular location.
> > I guess this piece has to be in the while loop. Am I wrong?
>
> You don't need to loop through the whole line -- that's just the way you
> are currently thinking about it -- but you are right that Richard's
> version does not solve the problem, and I don't think he was actually
> trying to either. I think the point he was making is that your function
> is simply trying to do that same scanning that strtod does.
>
> Here's a tip: strtod gives you back a pointer to the first first
> character that was not part of a number. Just think how useful that is!
> And remember, if you find yourself writing more than a very few lines,
> your are over complicating things.
One more clarification:
You have said that the program should ignore a line that contains
any non-numerical values. How can I not loop through the line to
make sure there are not non-numerical values somewhere closer
to the end, or in the middle, or elsewhere? For example, a line can be:
space space space 9,876,90,a,b,cdef89
- fgets will store this line in the buffer
- strtod will convert 9 into a floating-point number
and stop at comma, which is a valid character, and
a program can treat as a valid one;
- but this line is still illegitimate because it has alphas;
this is why I thought I have to loop through the line
first before calling strtod, to eliminate such lines.
-
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-03 14:20 +0000 |
| Message-ID | <87ful0i5rq.fsf@bsb.me.uk> |
| In reply to | #100957 |
Alla _ <modelling.data@gmail.com> writes:
> On Tuesday, January 3, 2017 at 2:25:46 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>
>> > On Monday, January 2, 2017 at 10:45:35 PM UTC+3, Richard Heathfield wrote:
>> >> On 02/01/17 19:30, Alla _ wrote:
>> >> > bool check_line(char *ptr, size_t line)
>> >> > {
>> >> > while(*ptr)
>> >> > {
>> >> > //Ignore the sign
>> >> > if( (*ptr == '-' || *ptr == '+' ||
>> >> > *ptr == '.') && *(ptr+1) != '\0')
>> >> > ptr++;
>> >> > //Check for non-numerical characters
>> >> > if (!isdigit(*ptr))
>> >> > {
>> >> > fprintf(stderr, "The line '%zu' contains non-numerical values.\n", line);
>> >> > return true;
>> >> > }
>> >> > ptr++;
>> >> > }
>> >> > return false;
>> >> > }
>> >>
>> >> You can replace this with:
>> >>
>> >> bool check_line(char *ptr, size_t line)
>> >> {
>> >> char *endptr = NULL;
>> >> strtod(ptr, &endptr);
>> >> if(ptr == endptr)
>> >> {
>> >> fprintf(stderr,
>> >> "The line '%zu' contains non-numerical values.\n",
>> >> line);
>> >> }
>> >> return ptr == endptr;
>> >> }
>> >>
>> >> If you can do without the pointless noise, the function can be reduced
>> >> to this:
>> >>
>> >> bool check_line(char *ptr)
>> >> {
>> >> char *endptr = NULL;
>> >> strtod(ptr, endptr);
>> >> return ptr == endptr;
>> >> }
>> >>
>> > <snip>
>> > I thought that I need to loop through the whole line anyway,
>> > because according to the spec I have to ignore each line
>> > that contains a non-numerical value, and this value can
>> > be anywhere in the line, not only at the particular location.
>> > I guess this piece has to be in the while loop. Am I wrong?
>>
>> You don't need to loop through the whole line -- that's just the way you
>> are currently thinking about it -- but you are right that Richard's
>> version does not solve the problem, and I don't think he was actually
>> trying to either. I think the point he was making is that your function
>> is simply trying to do that same scanning that strtod does.
>>
>> Here's a tip: strtod gives you back a pointer to the first first
>> character that was not part of a number. Just think how useful that is!
>> And remember, if you find yourself writing more than a very few lines,
>> your are over complicating things.
> One more clarification:
> You have said that the program should ignore a line that contains
> any non-numerical values. How can I not loop through the line to
> make sure there are not non-numerical values somewhere closer
> to the end, or in the middle, or elsewhere?
"You don't always have to scan the whole line" might have been a better
way to put it.
> For example, a line can be:
> space space space 9,876,90,a,b,cdef89
> - fgets will store this line in the buffer
> - strtod will convert 9 into a floating-point number
> and stop at comma, which is a valid character, and
> a program can treat as a valid one;
This program must reject the line because of the comma and it can reject
it now without looking any further alone the line.
It's possible the specification was not clear, but I can firm it up as
we go. Go though this list and tell me which lines you plan to accept
and which ones you plan to reject (based on how you read my
specification). In what follows I need to be able to show spaces so I
will write them as _.
1.34
__-2
6_5_4
__43__
1.34e-9
-2-3
1e5
+6x
1,2,3
This is part of programming. You get a specification and it is often
unclear so you write out lots of examples and see what makes sense in
the cases where the specification is not 100% unambiguous.
> - but this line is still illegitimate because it has alphas;
> this is why I thought I have to loop through the line
> first before calling strtod, to eliminate such lines.
Why would you do it before calling strtod?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-03 13:19 -0800 |
| Message-ID | <fed629b4-0b6c-423e-86ea-6f18eeffb3d4@googlegroups.com> |
| In reply to | #100979 |
On Tuesday, January 3, 2017 at 5:21:04 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> > On Tuesday, January 3, 2017 at 2:25:46 PM UTC+3, Ben Bacarisse wrote:
> >> Alla _ <modelling.data@gmail.com> writes:
> >>
> >> > On Monday, January 2, 2017 at 10:45:35 PM UTC+3, Richard Heathfield wrote:
> >> >> On 02/01/17 19:30, Alla _ wrote:
> >> >> > bool check_line(char *ptr, size_t line)
> >> >> > {
> >> >> > while(*ptr)
> >> >> > {
> >> >> > //Ignore the sign
> >> >> > if( (*ptr == '-' || *ptr == '+' ||
> >> >> > *ptr == '.') && *(ptr+1) != '\0')
> >> >> > ptr++;
> >> >> > //Check for non-numerical characters
> >> >> > if (!isdigit(*ptr))
> >> >> > {
> >> >> > fprintf(stderr, "The line '%zu' contains non-numerical values.\n", line);
> >> >> > return true;
> >> >> > }
> >> >> > ptr++;
> >> >> > }
> >> >> > return false;
> >> >> > }
> >> >>
> >> >> You can replace this with:
> >> >>
> >> >> bool check_line(char *ptr, size_t line)
> >> >> {
> >> >> char *endptr = NULL;
> >> >> strtod(ptr, &endptr);
> >> >> if(ptr == endptr)
> >> >> {
> >> >> fprintf(stderr,
> >> >> "The line '%zu' contains non-numerical values.\n",
> >> >> line);
> >> >> }
> >> >> return ptr == endptr;
> >> >> }
> >> >>
> >> >> If you can do without the pointless noise, the function can be reduced
> >> >> to this:
> >> >>
> >> >> bool check_line(char *ptr)
> >> >> {
> >> >> char *endptr = NULL;
> >> >> strtod(ptr, endptr);
> >> >> return ptr == endptr;
> >> >> }
> >> >>
> >> > <snip>
> >> > I thought that I need to loop through the whole line anyway,
> >> > because according to the spec I have to ignore each line
> >> > that contains a non-numerical value, and this value can
> >> > be anywhere in the line, not only at the particular location.
> >> > I guess this piece has to be in the while loop. Am I wrong?
> >>
> >> You don't need to loop through the whole line -- that's just the way you
> >> are currently thinking about it -- but you are right that Richard's
> >> version does not solve the problem, and I don't think he was actually
> >> trying to either. I think the point he was making is that your function
> >> is simply trying to do that same scanning that strtod does.
> >>
> >> Here's a tip: strtod gives you back a pointer to the first first
> >> character that was not part of a number. Just think how useful that is!
> >> And remember, if you find yourself writing more than a very few lines,
> >> your are over complicating things.
> > One more clarification:
> > You have said that the program should ignore a line that contains
> > any non-numerical values. How can I not loop through the line to
> > make sure there are not non-numerical values somewhere closer
> > to the end, or in the middle, or elsewhere?
>
> "You don't always have to scan the whole line" might have been a better
> way to put it.
>
> > For example, a line can be:
> > space space space 9,876,90,a,b,cdef89
> > - fgets will store this line in the buffer
> > - strtod will convert 9 into a floating-point number
> > and stop at comma, which is a valid character, and
> > a program can treat as a valid one;
>
> This program must reject the line because of the comma and it can reject
> it now without looking any further alone the line.
>
> It's possible the specification was not clear, but I can firm it up as
> we go. Go though this list and tell me which lines you plan to accept
> and which ones you plan to reject (based on how you read my
> specification). In what follows I need to be able to show spaces so I
> will write them as _.
>
> 1.34 except
> __-2 except
> 6_5_4 except
> __43__except
> 1.34e-9 reject for now (later maybe, when e's are added)
> -2-3 if these are minuses, then accepts; if dashes, reject
> 1e5 reject
> +6x reject
> 1,2,3 I would accept, but you have just said that I should reject the line with commas;
so reject
And also as far as we are sort of changing the spec, then I would say
that the program should reject the lines as I have shown above not
because of commas, but because it has some alpha characters.
Would you agree with this, or is it a dash forward? Before answering,
please, see below.
>
> This is part of programming. You get a specification and it is often
> unclear so you write out lots of examples and see what makes sense in
> the cases where the specification is not 100% unambiguous.
Not a fair game - you didn't tell me you will be changing specification )
Aren't we supposed to concentrate on one particular subject now? Aren't such
non clear tasks distract? ) I don't mind but, as you have always said,
be consistent )))
Still, please, I have to understand what was my mistake in the code
I showed - the one that has the check_line function, which loops
through the line and doesn't use strtod. I want to know why that
loop doesn't do the job, why it returns errors; I have written it out on paper many times
and can't find my mistake. It will be very helpful.
>
> > - but this line is still illegitimate because it has alphas;
> > this is why I thought I have to loop through the line
> > first before calling strtod, to eliminate such lines.
>
> Why would you do it before calling strtod?
So not to make the program do unnecessary job if the line is not valid.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-04 03:30 +0000 |
| Message-ID | <87lgurfqmt.fsf@bsb.me.uk> |
| In reply to | #101038 |
Alla _ <modelling.data@gmail.com> writes:
> On Tuesday, January 3, 2017 at 5:21:04 PM UTC+3, Ben Bacarisse wrote:
<snip>
>> It's possible the specification was not clear, but I can firm it up as
>> we go. Go though this list and tell me which lines you plan to accept
>> and which ones you plan to reject (based on how you read my
>> specification). In what follows I need to be able to show spaces so I
>> will write them as _.
>>
> 1.34 except
> __-2 except
> 6_5_4 except
> __43__except
> 1.34e-9 reject for now (later maybe, when e's are added)
> -2-3 if these are minuses, then accepts; if dashes, reject
> 1e5 reject
> +6x reject
> 1,2,3 I would accept, but you have just said that I should reject the
> line with commas; so reject
That's not what I intended. Any single number representation should be
accepted and anything but a single number (and some following spaces)
should be rejected. So for the lines I gave I wanted:
1.34 accept
__-2 accept
6_5_4 reject
__43__ accept
1.34e-9 accept
-2-3 reject
1e5 accept
+6x reject
1,2,3 reject
I've tried to pin it down even more below.
<snip>
>> This is part of programming. You get a specification and it is often
>> unclear so you write out lots of examples and see what makes sense in
>> the cases where the specification is not 100% unambiguous.
>
> Not a fair game - you didn't tell me you will be changing
> specification )
I'm not changing anything. I'm saying that if it was unclear, use
examples to help work out what might and might not make sense. If you
are still unsure, just fire off a set of examples and I'll tell you want
I want your program to do with each of them.
In order to try to speed things up, here's an attempt at a more rigorous
specification:
The notation <number> means any non-empty sequence of bytes that would
be accepted by strtod as a number. <ws> means any (possibly empty)
sequence of space characters as defined by isspace. <any> refers to a
(possibly empty) sequence of entirely arbitrary bytes (digits, spaces,
newlines, anything).
Exercise 1 wanted you to average all the numbers found on lines with the
format
<number><any>
and to ignore any that don't fit that pattern. In exercise 2 you must
average the numbers found only on lines with the format
<number><ws>
In exercise 3 you must calculate the average of the differences between
pairs of numbers. Only lines of the form
<number><ws>,<ws><number><ws>
should be used. All other lines should be ignored. In exercise 4, I
added in the task of reporting lines that don't have the right format.
I think you've started to do that already, so you can drop exercise 4.
It that any better?
<snip>
> Still, please, I have to understand what was my mistake in the code I
> showed - the one that has the check_line function, which loops through
> the line and doesn't use strtod. I want to know why that loop doesn't
> do the job, why it returns errors; I have written it out on paper many
> times and can't find my mistake. It will be very helpful.
OK. First let's look a the fact that it reports "Open failure!" for all
inputs. Here's the structure:
int main(...)
{
...
errno = 0;
FILE *fp = fopen(data_file, "r");
if ( fp )
{
...
if( !get_lines(fp, numbers, &index_n) )
{
...
return EXIT_FAILURE;
}
if(index_n > 0)
{
...
return EXIT_SUCCESS;
}
}
fprintf(stderr, "%s - %s\n", data_file, errno ? strerror(errno) : "Open failure!");
...
}
So to print "Open failure!" we must arrive at the bottom of main with
errno == 0. That tells us that the file was opened because the system
you are using does set errno to non-zero on failure. So "if (fp)" was
true and to avoid both of the return statements and fall out of the big
if statement, get_lines must have returned true and index_n must have
remained 0.
get_lines returning true is not a mystery. Here's it's structure:
bool get_lines (...)
{
...
while( fgets(buffer, BUFFER_SIZE, input_file) != NULL)
{
if (*index_n == NUMBERS-1)
{
...
return false;
}
...
if (check_line(ptr, line))
{
...
continue;
}
... only here is *index_n incremented ...
}
if (ferror(input_file))
{
...
return false;
}
return true;
}
It can return false in only two situations: lots of input lines being
accepted (99 of them) or a file error. Neither is the case for the
input you gave.
Since we know that index_n remains zero we can also conclude that
check_line must return true for every line in the input.
And that also explains the other issue -- the every line is rejected
with an error message. Those messages you see come from this (slightly
edited) code:
bool check_line(char *ptr, size_t line)
{
while (*ptr)
{
if( (*ptr == '-' || *ptr == '+' || *ptr == '.') && ptr[1] != '\0')
ptr++;
if (!isdigit(*ptr))
{
fprintf(stderr, "The line '%zu' contains non-numerical values.\n", line);
return true;
}
ptr++;
}
return false;
}
(This function is called only after skipping spaces, but that does not
matter much -- the message appears regardless of leading spaces.)
The only way to avoid that message would be for the loop to run until
*ptr == 0 finding nothing but digits -- possibly preceded by a sign or
decimal point. But every line (at least in the test data you are using)
also includes a newline character and that is not a digit. The loop can
not end without !isdigit(*ptr) being true at least once.
The only lines that won't trigger the message are blank lines containing
only spaces because the initial skipping of spaces (before calling
check_line) will include skipping the newline.
Notice that I am not working through what the program does. I am trying
to deduce what must have happened based on what I know for sure: the
output. It's much easier to do this with functions that are short and
neatly structured. If you try to reason this way about your programs
you will find yourself yearning for simple, neat functions that make it
easy to do.
>> > - but this line is still illegitimate because it has alphas;
>> > this is why I thought I have to loop through the line
>> > first before calling strtod, to eliminate such lines.
>>
>> Why would you do it before calling strtod?
> So not to make the program do unnecessary job if the line is not
> valid.
Laziness is a virtue in programming. It's much better to have a simple
program that might do a little more work than a complex one that does
the minimum. Your scanning is duplicating what strtod does except for
actually calculating the number being scanned. The saving -- not
calculating that number for some invalid lines -- is insignificant
compared to the effort you have to put in to write the code. Just let
strtod do the work. That's what it's there for.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-04 02:23 -0800 |
| Message-ID | <6921a3c5-02af-47ee-837c-9d72e2ba8890@googlegroups.com> |
| In reply to | #101075 |
On Wednesday, January 4, 2017 at 6:31:00 AM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
<snip>
> I'm not changing anything. I'm saying that if it was unclear, use
> examples to help work out what might and might not make sense. If you
> are still unsure, just fire off a set of examples and I'll tell you want
> I want your program to do with each of them.
>
I see that I have, as usual, added much more layers to the task than
you have intended.
> In order to try to speed things up, here's an attempt at a more rigorous
> specification:
>
> The notation <number> means any non-empty sequence of bytes that would
> be accepted by strtod as a number. <ws> means any (possibly empty)
> sequence of space characters as defined by isspace. <any> refers to a
> (possibly empty) sequence of entirely arbitrary bytes (digits, spaces,
> newlines, anything).
>
> Exercise 1 wanted you to average all the numbers found on lines with the
> format
>
> <number><any>
>
> and to ignore any that don't fit that pattern. In exercise 2 you must
> average the numbers found only on lines with the format
>
> <number><ws>
>
I see. It's was indeed a matter of moving one line of code.
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <string.h>
#include <stdbool.h>
#include <errno.h>
#define BUFFER_SIZE 100
#define NUMBERS 100
#define TEXT "../files/ex_1.csv"
bool get_lines (FILE *input_file, double *numbers, size_t *index_n);
double average(const double *numbers, size_t index);
int main(int argc, char *argv[])
{
//Check for correct number of arguments
if(argc > 2)
{
fputs("Sorry, the program processes only one file.\n", stderr);
return EXIT_FAILURE;
}
//Determine a file to use
const char *data_file = (argc == 2)? argv[1] : TEXT;
errno = 0;
FILE *fp = fopen(data_file, "r");
if ( fp )
{
double numbers[NUMBERS] = {0};
size_t index_n = 0;
double average_num;
if( !get_lines(fp, numbers, &index_n) )
{
fclose(fp);
return EXIT_FAILURE;
}
//Call function average only when index_n > 0
if(index_n > 0)
{
average_num = average(numbers, index_n);
printf("%.2f\n", average_num);
fclose(fp);
return EXIT_SUCCESS;
}
}
//Couldn't open the file
fprintf(stderr, "%s - %s\n", data_file, errno ? strerror(errno) : "Open failure!");
return EXIT_FAILURE;
}
/** Function to read and process the data
from the file line by line
**/
bool get_lines (FILE *input_file, double *numbers, size_t *index_n)
{
char buffer[BUFFER_SIZE] = "";
size_t line = 0;
//Parse file data, store only numbers
while( fgets(buffer, sizeof(buffer), input_file) != NULL)
{
char *not_converted = NULL;
double number = strtod(buffer, ¬_converted);
//Ignore lines that contain characters other than 1 number
if (not_converted >= buffer && *not_converted != '\n')
{
fprintf(stderr, "Incorrect input, line '%zu'\n", line);
line++;
continue;
}
//Store a number in the array
if (*index_n < NUMBERS)
numbers[(*index_n)++] = number;
else
{
fprintf(stderr, "Number of data exceeds capacity; stop at line '%zu'\n", line);
return false;
}
line++;
}
if (ferror(input_file))
{
if(*index_n != 0)
fprintf(stderr, "Error: last input processed was at line '%zu': %s\n", line, buffer);
fprintf(stderr, "The function detected an error in reading a file; no data has been processed");
return false;
}
return true;
}
/** Function to find the average;
must only be called with index > 0
**/
double average(const double *numbers, size_t index)
{
double sum = 0;
for(size_t i = 0; i < index; i++)
sum += numbers[i];
return sum/index;
}
<snip>
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2017-01-04 02:56 -0800 |
| Message-ID | <8433d05b-1479-460b-a334-4ad16c1b072b@googlegroups.com> |
| In reply to | #101082 |
On Wednesday, 4 January 2017 10:23:21 UTC, Alla _ wrote:
> On Wednesday, January 4, 2017 at 6:31:00 AM UTC+3, Ben Bacarisse wrote:
> > Alla _ <modelling.data@gmail.com> writes:
> >
> <snip>
> > I'm not changing anything. I'm saying that if it was unclear, use
> > examples to help work out what might and might not make sense. If you
> > are still unsure, just fire off a set of examples and I'll tell you want
> > I want your program to do with each of them.
> >
> I see that I have, as usual, added much more layers to the task than
> you have intended.
Why? Ben is trying to get you to work on small easily achievable tasks,
why not do what he asks, and actually learn from it?
> > Exercise 1 wanted you to average all the numbers found on lines with the
> > format
> >
> > <number><any>
> >
> > and to ignore any that don't fit that pattern. In exercise 2 you must
> > average the numbers found only on lines with the format
> >
> > <number><ws>
Which exercise is the code below intended to address?
> >
> I see. It's was indeed a matter of moving one line of code.
> #include <stdio.h>
> #include <stdlib.h>
> #include <ctype.h>
> #include <string.h>
> #include <stdbool.h>
> #include <errno.h>
>
> #define BUFFER_SIZE 100
> #define NUMBERS 100
You don't need this, it places an unnecessary limit on your program.
> #define TEXT "../files/ex_1.csv"
>
> bool get_lines (FILE *input_file, double *numbers, size_t *index_n);
This is a very poor function name, in my opinion. It doesn't get lines,
it gets numbers, for a start.
> double average(const double *numbers, size_t index);
You don't need this, it places an unnecessary ...
Your main loop needs only to maintain a running total and a count of
numbers found, then you can calculate the average from those two values.
If you do this, apart from numeric overflow (which I think we can ignore
for now), you have no limits on the input file size.
>
> int main(int argc, char *argv[])
> {
> //Check for correct number of arguments
> if(argc > 2)
> {
> fputs("Sorry, the program processes only one file.\n", stderr);
> return EXIT_FAILURE;
> }
> //Determine a file to use
> const char *data_file = (argc == 2)? argv[1] : TEXT;
> errno = 0;
> FILE *fp = fopen(data_file, "r");
> if ( fp )
> {
> double numbers[NUMBERS] = {0};
Not needed
> size_t index_n = 0;
> double average_num;
>
> if( !get_lines(fp, numbers, &index_n) )
> {
> fclose(fp);
> return EXIT_FAILURE;
> }
> //Call function average only when index_n > 0
> if(index_n > 0)
> {
> average_num = average(numbers, index_n);
> printf("%.2f\n", average_num);
> fclose(fp);
> return EXIT_SUCCESS;
> }
> }
> //Couldn't open the file
> fprintf(stderr, "%s - %s\n", data_file, errno ? strerror(errno) : "Open failure!");
> return EXIT_FAILURE;
> }
> /** Function to read and process the data
> from the file line by line
> **/
> bool get_lines (FILE *input_file, double *numbers, size_t *index_n)
> {
> char buffer[BUFFER_SIZE] = "";
> size_t line = 0;
>
> //Parse file data, store only numbers
> while( fgets(buffer, sizeof(buffer), input_file) != NULL)
> {
> char *not_converted = NULL;
> double number = strtod(buffer, ¬_converted);
>
If this is exercise 1, it's not what Ben asked for. If it's exercise 2,
I don't think it's complete. Have you tested with an input file containing
lines with numbers and trailing whitespace?
> //Ignore lines that contain characters other than 1 number
> if (not_converted >= buffer && *not_converted != '\n')
> {
> fprintf(stderr, "Incorrect input, line '%zu'\n", line);
> line++;
> continue;
> }
> //Store a number in the array
> if (*index_n < NUMBERS)
> numbers[(*index_n)++] = number;
> else
> {
> fprintf(stderr, "Number of data exceeds capacity; stop at line '%zu'\n", line);
> return false;
> }
> line++;
> }
>
> if (ferror(input_file))
> {
> if(*index_n != 0)
> fprintf(stderr, "Error: last input processed was at line '%zu': %s\n", line, buffer);
> fprintf(stderr, "The function detected an error in reading a file; no data has been processed");
> return false;
> }
> return true;
> }
>
> /** Function to find the average;
> must only be called with index > 0
> **/
> double average(const double *numbers, size_t index)
> {
> double sum = 0;
> for(size_t i = 0; i < index; i++)
> sum += numbers[i];
>
> return sum/index;
> }
>
You would profitably show your test data and your test results.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-04 07:06 -0800 |
| Message-ID | <eafb96d2-cf04-48a7-9fcd-37ab538f62bf@googlegroups.com> |
| In reply to | #101084 |
On Wednesday, January 4, 2017 at 1:56:51 PM UTC+3, mark.b...@gmail.com wrote:
> On Wednesday, 4 January 2017 10:23:21 UTC, Alla _ wrote:
> > On Wednesday, January 4, 2017 at 6:31:00 AM UTC+3, Ben Bacarisse wrote:
> > > Alla _ <modelling.data@gmail.com> writes:
> > >
> > <snip>
> > > I'm not changing anything. I'm saying that if it was unclear, use
> > > examples to help work out what might and might not make sense. If you
> > > are still unsure, just fire off a set of examples and I'll tell you want
> > > I want your program to do with each of them.
> > >
> > I see that I have, as usual, added much more layers to the task than
> > you have intended.
>
> Why? Ben is trying to get you to work on small easily achievable tasks,
> why not do what he asks, and actually learn from it?
Oh, I do, but I am far from being perfect. You have picked up one phrase out
of the whole context )
And I'd say Ben is not trying, he actually does teach me how to do that )
>
> > > Exercise 1 wanted you to average all the numbers found on lines with the
> > > format
> > >
> > > <number><any>
> > >
> > > and to ignore any that don't fit that pattern. In exercise 2 you must
> > > average the numbers found only on lines with the format
> > >
> > > <number><ws>
>
> Which exercise is the code below intended to address?
It's the second one; I have posted it right after the spec for the 2nd
exercise.
>
> > >
> > I see. It's was indeed a matter of moving one line of code.
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <ctype.h>
> > #include <string.h>
> > #include <stdbool.h>
> > #include <errno.h>
> >
> > #define BUFFER_SIZE 100
> > #define NUMBERS 100
>
> You don't need this, it places an unnecessary limit on your program.
That's what has been decided for now. According to the given task,
I have to use both a limited buffer and a limited array.
>
> > #define TEXT "../files/ex_1.csv"
> >
> > bool get_lines (FILE *input_file, double *numbers, size_t *index_n);
>
> This is a very poor function name, in my opinion. It doesn't get lines,
> it gets numbers, for a start.
Agree. I will rename it going further.
>
> > double average(const double *numbers, size_t index);
>
> You don't need this, it places an unnecessary ...
I didn't understand this comment. Are you saying I don't need
the average function? What are three dots, and how the average
function, if you are referring to it, places those dots? Oh - I might
have understood what you mean: I have an array of 100 ints, and
if the line has only 1 number, as it actually does, and there are, say,
only 3 lines, then all the rest values in the array numbers are zeros.
Is that what you mean?
>
> Your main loop needs only to maintain a running total and a count of
> numbers found, then you can calculate the average from those two values.
> If you do this, apart from numeric overflow (which I think we can ignore
> for now), you have no limits on the input file size.
Please, take a look at the version I post below and let me know if this is what you mean
(short note: this is only a version, and I keep an array elsewhere because I need arrays
in my main program):
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <string.h>
#include <stdbool.h>
#include <errno.h>
#define BUFFER_SIZE 100
#define TEXT "../files/ex_1.csv"
bool get_numbers(FILE *input_file, double *sum, size_t *index_n);
int main(int argc, char *argv[])
{
//Check for correct number of arguments
if(argc > 2)
{
fputs("Sorry, the program processes only one file.\n", stderr);
return EXIT_FAILURE;
}
//Determine a file to use
const char *data_file = (argc == 2)? argv[1] : TEXT;
errno = 0;
FILE *fp = fopen(data_file, "r");
if ( fp )
{
double sum = 0;
size_t index_n = 0;
double average_num;
if( !get_numbers(fp, &sum, &index_n) )
{
fclose(fp);
return EXIT_FAILURE;
}
//Call function average only when index_n > 0
if(index_n > 0)
{
average_num = sum/index_n;
printf("%.2f\n", average_num);
fclose(fp);
return EXIT_SUCCESS;
}
}
//Couldn't open the file
fprintf(stderr, "%s - %s\n", data_file, errno ? strerror(errno) : "Open failure!");
return EXIT_FAILURE;
}
/** Function to read and process numbers
from the file line by line
**/
bool get_numbers (FILE *input_file, double *sum, size_t *index_n)
{
char buffer[BUFFER_SIZE] = "";
size_t line = 0;
//Parse file data, store only numbers
while( fgets(buffer, sizeof(buffer), input_file) != NULL)
{
char *not_converted = NULL;
double number = strtod(buffer, ¬_converted);
//Ignore lines that contain characters other than 1 number
if (not_converted >= buffer && !isspace(*not_converted))
{
fprintf(stderr, "Incorrect input, line '%zu'\n", line);
line++;
continue;
}
*sum += number;
(*index_n)++;
line++;
}
if (ferror(input_file))
{
if(*index_n != 0)
fprintf(stderr, "Error: last input processed was at line '%zu': %s\n", line, buffer);
fprintf(stderr, "The function detected an error in reading a file; no data has been processed");
return false;
}
return true;
}
<snip>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-04 15:21 +0000 |
| Message-ID | <874m1en95c.fsf@bsb.me.uk> |
| In reply to | #101093 |
Alla _ <modelling.data@gmail.com> writes: <snip> > Please, take a look at the version I post below and let me know if > this is what you mean What testing do you do? Can you show me the files you use as input when you test? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-05 03:01 -0800 |
| Message-ID | <46e06c9a-b88f-497b-a74e-8d7c101851c4@googlegroups.com> |
| In reply to | #101096 |
On Wednesday, January 4, 2017 at 6:21:27 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
> <snip>
>
> > Please, take a look at the version I post below and let me know if
> > this is what you mean
>
> What testing do you do? Can you show me the files you use as input when
> you test?
>
Of course. Here is one of them in csv format, which is a hodgepodge of the ones suggested
by you and some additional gobbledegook data; there are also smaller ones
suggested by you.
1
-2.0
xyz
7bz
3.0,2
2 ,4
1, -6.0
Years,2011,2012,2013,2014,2015
,1062,1252,1587,1934,2519
654,+814.98,1009,1190jz
Gross Profit,&&408,438,578,$744,1020
"Selling, General, and Admin Exp",254,271,364,454,576%$@
-0.154,167,214,290,444
Depreciation and Amortization,25,31,38,52,70
Operating Profit,129,136,176,238,374
Interest Expense,4,3,3,1,4
Other Gains and Losses,0,7,10,0,-1
Pretax Income,125,126,163,237,371
Income Tax Expense,55,52,65,92,141
Net Income,70,74,98,145,230
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-05 11:51 +0000 |
| Message-ID | <87shoxk9na.fsf@bsb.me.uk> |
| In reply to | #101165 |
Alla _ <modelling.data@gmail.com> writes: > On Wednesday, January 4, 2017 at 6:21:27 PM UTC+3, Ben Bacarisse wrote: >> Alla _ <modelling.data@gmail.com> writes: >> <snip> >> >> > Please, take a look at the version I post below and let me know if >> > this is what you mean >> >> What testing do you do? Can you show me the files you use as input when >> you test? >> > Of course. Here is one of them in csv format, which is a hodgepodge of the ones suggested > by you and some additional gobbledegook data; there are also smaller ones > suggested by you. I asked because it seemed that there were very simple test cases that made your program go wrong. And, indeed, even in the one you showed such cases are shown. Did you not spot, for example, that the first lines here is not an error but is reported as one (by the program as I knew it at the time I asked) and the second line is an error but is not reported as one by that program. In short, I'm trying to work out why your testing regime is not working. > 1 > > -2.0 ... (There may be a problem here in that spaces are significant to your program and I can not be 100% sure that you have posted the exact data (spaces and all) from your test files. Nor can I be sure that the way you read my messages also preserves even that files as you posted them, but I have to assume, for the moment, that nothing is going wrong there.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-05 04:04 -0800 |
| Message-ID | <c3055618-6537-4ca0-9090-8800bb3a9c15@googlegroups.com> |
| In reply to | #101167 |
On Thursday, January 5, 2017 at 2:51:14 PM UTC+3, Ben Bacarisse wrote: > Alla _ <modelling.data@gmail.com> writes: > > > On Wednesday, January 4, 2017 at 6:21:27 PM UTC+3, Ben Bacarisse wrote: > >> Alla _ <modelling.data@gmail.com> writes: > >> <snip> > >> > >> > Please, take a look at the version I post below and let me know if > >> > this is what you mean > >> > >> What testing do you do? Can you show me the files you use as input when > >> you test? > >> > > Of course. Here is one of them in csv format, which is a hodgepodge of the ones suggested > > by you and some additional gobbledegook data; there are also smaller ones > > suggested by you. > > I asked because it seemed that there were very simple test cases that > made your program go wrong. And, indeed, even in the one you showed > such cases are shown. Did you not spot, for example, that the first > lines here is not an error but is reported as one (by the program as I > knew it at the time I asked) and the second line is an error but is > not reported as one by that program. Please, take a look at the new version of the exercise 2 program I have posted today; I think I have found my errors, including the ones you refer to here, if I have understood you correctly. > In short, I'm trying to work out > why your testing regime is not working. > > > 1 > > > > -2.0 > ... > > (There may be a problem here in that spaces are significant to your > program and I can not be 100% sure that you have posted the exact data > (spaces and all) from your test files. Nor can I be sure that the way > you read my messages also preserves even that files as you posted them, > but I have to assume, for the moment, that nothing is going wrong > there.) > > -- > Ben.
[toc] | [prev] | [next] | [standalone]
Page 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web