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 10 of 13 — ← Prev page 1 … 8 9 [10] 11 12 13 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-05 14:23 +0000 |
| Message-ID | <87h95dk2l4.fsf@bsb.me.uk> |
| In reply to | #101169 |
Alla _ <modelling.data@gmail.com> writes: > 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. Yes, most of them. But I was trying to find out why your testing isn't working. It's possible that you just didn't notice that one file you are using is giving the wrong results. If that's the case, it points to an area you need to take more care over. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2017-01-04 12:26 -0800 |
| Message-ID | <1slq6cp24nbuhn955c0e8ot3fmhk7vg0ut@4ax.com> |
| In reply to | #101093 |
On Wed, 4 Jan 2017 07:06:19 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:
<snip>
>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):
So in this single message thread, we now have two unfinished versions
of Ben's Exercise #2. Don't you think it would be a good idea to
finish one version before jumping on another?
>#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);
Every failure should have an error message.
> return EXIT_FAILURE;
> }
> //Call function average only when index_n > 0
Obviously a residual comment. There is more to programming than
rushing to change the executable code.
> 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))
Will this code accept or reject a line containing "1 2"? What should
it do?
> {
> fprintf(stderr, "Incorrect input, line '%zu'\n", line);
If the line "1a" was the first line in the file, this error message
would specify line 0. We all know that array elements and other
pointer arithmetic start at 0 but I don't think I have ever seen a
line in a text file identified as 0. Even a C programmer counting the
lines in your file to find the error would start at 1. But if that
was your intent, then ignore the fact that I find it unusual.
> line++;
> continue;
> }
>
> *sum += number;
> (*index_n)++;
> line++;
> }
>
> if (ferror(input_file))
> {
> if(*index_n != 0)
Why does this error message depend on some previous values being
successfully processed? What should happen if three invalid lines are
processed and then an I/O error occurs?
> 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");
Rather than this message, why not specify how many lines were
successfully processed, even if it is 0?
> return false;
> }
> return true;
>}
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-05 13:38 -0800 |
| Message-ID | <71362ece-64c4-499f-861e-59bd89a90573@googlegroups.com> |
| In reply to | #101126 |
On Wednesday, January 4, 2017 at 11:26:09 PM UTC+3, Barry Schwarz wrote:
> On Wed, 4 Jan 2017 07:06:19 -0800 (PST), Alla _
> <modelling.data@gmail.com> wrote:
>
> <snip>
>
> >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):
>
> So in this single message thread, we now have two unfinished versions
> of Ben's Exercise #2. Don't you think it would be a good idea to
> finish one version before jumping on another?
Yes.
>
> >#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);
>
> Every failure should have an error message.
Yes, and the program return the message explaining the failure, but
the message comes from the failed function. Please, take a look
at the end of the function. Actually, it's better to look at the last code
I have posted a few minutes ago. Anyway, this part has not been
changed.
>
> > return EXIT_FAILURE;
> > }
> > //Call function average only when index_n > 0
>
> Obviously a residual comment. There is more to programming than
> rushing to change the executable code.
Agree, and have already found this mistake; it is corrected in the new
better version of the code.
>
> > if(index_n > 0)
> > {
> > average_num = sum/index_n;
> > printf("%.2f\n", average_num);
> > fclose(fp);
> > return EXIT_SUCCESS;
> > }
> > }
<snip>
> >
> > if (ferror(input_file))
> > {
> > if(*index_n != 0)
>
> Why does this error message depend on some previous values being
> successfully processed? What should happen if three invalid lines are
> processed and then an I/O error occurs?
The program reports each invalid line naming it's number.
>
> > 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");
>
> Rather than this message, why not specify how many lines were
> successfully processed, even if it is 0?
This doesn't sound practical. Why would I be interested in the sum of
successfully processed lines rather than in the line at which the program
has stopped and returned failure, not processing any input further?
>
> > return false;
> > }
> > return true;
> >}
>
> --
> Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2017-01-05 16:25 -0800 |
| Message-ID | <hlot6cljqutlmp2bvqbsp4l6ql2o3v09oo@4ax.com> |
| In reply to | #101204 |
On Thu, 5 Jan 2017 13:38:38 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:
>On Wednesday, January 4, 2017 at 11:26:09 PM UTC+3, Barry Schwarz wrote:
<snip>
>> > if (ferror(input_file))
>> > {
>> > if(*index_n != 0)
>>
>> Why does this error message depend on some previous values being
>> successfully processed? What should happen if three invalid lines are
>> processed and then an I/O error occurs?
>The program reports each invalid line naming it's number.
Consider this sequence. The program process three invalid lines and
detects an I/O error on line 4. You skip the first message below and
print the second. Why not tell the user where in the file the I/O
error occurred so a fix can be attempted?
>> > 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");
>>
>> Rather than this message, why not specify how many lines were
>> successfully processed, even if it is 0?
>This doesn't sound practical. Why would I be interested in the sum of
>successfully processed lines rather than in the line at which the program
>has stopped and returned failure, not processing any input further?
After the error, the desired results may indeed be meaningless. But
since an error did occur, it is prudent to give the user as much
information as is readily available to facilitate corrective action.
>> > return false;
>> > }
>> > return true;
>> >}
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-04 12:21 +0000 |
| Message-ID | <87k2abm2wf.fsf@bsb.me.uk> |
| In reply to | #101082 |
Mark Bluemel has also made the key point here but I'm going to reply as well because I want to add a couple of other remarks... Alla _ <modelling.data@gmail.com> writes: <snip> >> 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. Almost. Very close now. I think you need a develop a more diabolical testing regime. You should be trying very hard to break your program and, by now, I'd expect you to have many files (or many one large file with many lines) that are in some way odd or special that you throw at each version to see if it breaks. The two cases you need to think about are a line with nothing in it, and a line with a number but some trailing spaces. This last one should really have been in your tests. It was even in the list I sent you! When you have that sorted out, I'm going to say "now re-organise the code to remove the continue" so you can do that before waiting, but make the changes needed for correctness first. Don't do it yet. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-05 02:52 -0800 |
| Message-ID | <5e5ee268-ad6a-4aea-a38d-749f5f73d024@googlegroups.com> |
| In reply to | #101088 |
On Wednesday, January 4, 2017 at 3:21:46 PM UTC+3, Ben Bacarisse wrote:
> Mark Bluemel has also made the key point here but I'm going to reply
> as well because I want to add a couple of other remarks...
>
> Alla _ <modelling.data@gmail.com> writes:
> <snip>
> >> 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.
>
> Almost. Very close now.
>
> I think you need a develop a more diabolical testing regime. You should
> be trying very hard to break your program and, by now, I'd expect you to
> have many files (or many one large file with many lines) that are in
> some way odd or special that you throw at each version to see if it
> breaks.
>
> The two cases you need to think about are a line with nothing in it, and
> a line with a number but some trailing spaces. This last one should
> really have been in your tests. It was even in the list I sent you!
>
> When you have that sorted out, I'm going to say "now re-organise the
> code to remove the continue" so you can do that before waiting, but make
> the changes needed for correctness first. Don't do it yet.
Please, take a look at the version below. Yesterday in my reply to Mark I have
posted a version with a few bugs, which I have managed to find. The version
I am posting now uses the no-additional-array approach, suggested by Mark,
because it was easier to spot mistakes using that approach (Thank you, Mark!).
If this version is all right, I will correct my array version as well based on corrections
I have implemented here. Also, I have eliminated the 'continue' thing, because it
bothered me a lot, even without you commenting on it, but I am glad you have
brought that up as well - it did tell me I was right feeling bad about using it.
#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);
bool empty_input(char *buffer);
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);
//Process lines that contain only 1 number
if ( (not_converted > buffer) && (!empty_input(buffer) &&
empty_input(not_converted)) )
{
*sum += number;
(*index_n)++;
line++;
}
else
{
fprintf(stderr, "Incorrect input line '%zu'\n", line);
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 check for empty lines **/
bool empty_input(char *buffer)
{
if (*buffer == '\r' || *buffer == '\n')
return true;
else
{
while(isspace(*buffer++));
if(*buffer == '\0')
return true;
}
return false;
}
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-05 14:13 +0000 |
| Message-ID | <87mvf5k31l.fsf@bsb.me.uk> |
| In reply to | #101162 |
Alla _ <modelling.data@gmail.com> writes:
<snip>
> If this version is all right,
Oh, so close! There a couple of oddities that need to be cleared up but
the main problem is here:
> bool empty_input(char *buffer)
(add const)
> {
> if (*buffer == '\r' || *buffer == '\n')
> return true;
> else
> {
> while(isspace(*buffer++));
> if(*buffer == '\0')
> return true;
> }
> return false;
> }
This function examines data that is has business looking at. It's hard
to test for this sort of thing but you might see the error if you feed
your program two valid lines line this:
12346789
1
The second line has a single space after the '1'. I can't get sure
you'll see a problem but you might. Of course, I found the problem by
reasoning about the program -- there's no way I could expect to just hit
on that test case.
Every time I write (or see) a loop I work out the condition that must be
true immediately after it. For loop like this
while (C(*p++)) ... ;
What do we know? Can you say, succinctly what's true after a loop like
that?
Once you find and fix that bug, try to write the function as just
two or three lines. Hint: vffcnpr('\e') vf gehr nf vf vfcnpr('\a').
(That scrambled text is called ROT13 -- it's every letter moved 13
places up the alphabet. The point is you might not yet want to see the
hint but you can if you choose to (but your news read may not have a
rot13 function).
Once you've made it really small, explain to me why your short version
is the same as your long version.
There are also a couple of logical oddities that need to be cleared
up...
<sip>
> //Process lines that contain only 1 number
> if ( (not_converted > buffer) && (!empty_input(buffer) &&
> empty_input(not_converted)) )
What happens if you write
if ( (not_converted > buffer) && empty_input(not_converted) )
instead? Once you know the answer explain to me -- by reasoning about
your code -- why you are right.
Finally, the program can still report "Open failure!". Can you work out
what must be true for this to happen and, from that, can you write a
test case you will make it happen? Try to do it by thinking about the
program.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-05 07:54 -0800 |
| Message-ID | <d471f5c2-ced3-4e3b-92f0-63283475bfe3@googlegroups.com> |
| In reply to | #101170 |
On Thursday, January 5, 2017 at 5:13:52 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
> <snip>
>
> > If this version is all right,
>
> Oh, so close! There a couple of oddities that need to be cleared up but
> the main problem is here:
>
> > bool empty_input(char *buffer)
> (add const)
> > {
> > if (*buffer == '\r' || *buffer == '\n')
> > return true;
> > else
> > {
> > while(isspace(*buffer++));
> > if(*buffer == '\0')
> > return true;
> > }
> > return false;
> > }
>
> This function examines data that is has business looking at. It's hard
> to test for this sort of thing but you might see the error if you feed
> your program two valid lines line this:
>
> 12346789
> 1
>
> The second line has a single space after the '1'. I can't get sure
> you'll see a problem but you might. Of course, I found the problem by
> reasoning about the program -- there's no way I could expect to just hit
> on that test case.
Oh, I have again "committed the same crime" I hoped I'm done with )
I should increment the buffer after the loop:
while(isspace(*buffer))
buffer++;
<snip>
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-05 07:59 -0800 |
| Message-ID | <ffa188b9-45f5-44ab-9fcd-cadd2cf16740@googlegroups.com> |
| In reply to | #101170 |
On Thursday, January 5, 2017 at 5:13:52 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
> <snip>
>
> > If this version is all right,
>
> Oh, so close! There a couple of oddities that need to be cleared up but
> the main problem is here:
>
> > bool empty_input(char *buffer)
> (add const)
> > {
> > if (*buffer == '\r' || *buffer == '\n')
> > return true;
> > else
> > {
> > while(isspace(*buffer++));
> > if(*buffer == '\0')
> > return true;
> > }
> > return false;
> > }
>
> This function examines data that is has business looking at. It's hard
> to test for this sort of thing but you might see the error if you feed
> your program two valid lines line this:
>
> 12346789
> 1
>
> The second line has a single space after the '1'. I can't get sure
> you'll see a problem but you might. Of course, I found the problem by
> reasoning about the program -- there's no way I could expect to just hit
> on that test case.
>
> Every time I write (or see) a loop I work out the condition that must be
> true immediately after it. For loop like this
>
> while (C(*p++)) ... ;
>
> What do we know? Can you say, succinctly what's true after a loop like
> that?
Sorry, didn't reach this part yet when posted the previous reply.
First I move the buffer one address further, and only then the test
is performed, hence I skip one character (or space, or whatever is
there).
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-05 08:12 -0800 |
| Message-ID | <465b5e47-2fc5-4713-8574-cfd87aedea6d@googlegroups.com> |
| In reply to | #101170 |
On Thursday, January 5, 2017 at 5:13:52 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
> <snip>
>
> > If this version is all right,
>
> Oh, so close! There a couple of oddities that need to be cleared up but
> the main problem is here:
>
> > bool empty_input(char *buffer)
> (add const)
> > {
> > if (*buffer == '\r' || *buffer == '\n')
> > return true;
> > else
> > {
> > while(isspace(*buffer++));
> > if(*buffer == '\0')
> > return true;
> > }
> > return false;
> > }
>
> This function examines data that is has business looking at. It's hard
> to test for this sort of thing but you might see the error if you feed
> your program two valid lines line this:
>
> 12346789
> 1
>
> The second line has a single space after the '1'. I can't get sure
> you'll see a problem but you might. Of course, I found the problem by
> reasoning about the program -- there's no way I could expect to just hit
> on that test case.
>
> Every time I write (or see) a loop I work out the condition that must be
> true immediately after it. For loop like this
>
> while (C(*p++)) ... ;
>
> What do we know? Can you say, succinctly what's true after a loop like
> that?
>
> Once you find and fix that bug, try to write the function as just
> two or three lines. Hint: vffcnpr('\e') vf gehr nf vf vfcnpr('\a').
> (That scrambled text is called ROT13 -- it's every letter moved 13
> places up the alphabet. The point is you might not yet want to see the
> hint but you can if you choose to (but your news read may not have a
> rot13 function).
>
> Once you've made it really small, explain to me why your short version
> is the same as your long version.
Here ))))
/** Function to check for empty lines **/
bool empty_input(char *buffer)
{
while(isspace(*buffer))
buffer++;
return *buffer == '\0';
}
Answering your question above: because I am ...well, because I
am yet incapable of thinking correctly, smartly, succinctly, etc,
all these are euphemisms for saying that I am... Ok, no self
flagellation, it does no good )
<snip>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-05 17:15 +0000 |
| Message-ID | <87vattig2r.fsf@bsb.me.uk> |
| In reply to | #101176 |
Alla _ <modelling.data@gmail.com> writes:
> On Thursday, January 5, 2017 at 5:13:52 PM UTC+3, Ben Bacarisse wrote:
<snip>
>> Once you find and fix that bug, try to write the function as just
>> two or three lines.
<snip>
>> Once you've made it really small, explain to me why your short version
>> is the same as your long version.
> Here ))))
> /** Function to check for empty lines **/
> bool empty_input(char *buffer)
add const there
> {
> while(isspace(*buffer))
> buffer++;
> return *buffer == '\0';
> }
> Answering your question above: because I am ...well, because I
> am yet incapable of thinking correctly, smartly, succinctly, etc,
> all these are euphemisms for saying that I am... Ok, no self
> flagellation, it does no good )
No, that's not my question. It was not about making you feel bad but
about learning to reason about code.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-05 09:19 -0800 |
| Message-ID | <a80e51f2-8cd4-4493-af50-47bb80715236@googlegroups.com> |
| In reply to | #101184 |
On Thursday, January 5, 2017 at 8:15:15 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> > On Thursday, January 5, 2017 at 5:13:52 PM UTC+3, Ben Bacarisse wrote:
> <snip>
> >> Once you find and fix that bug, try to write the function as just
> >> two or three lines.
> <snip>
> >> Once you've made it really small, explain to me why your short version
> >> is the same as your long version.
> > Here ))))
> > /** Function to check for empty lines **/
> > bool empty_input(char *buffer)
>
> add const there
>
> > {
> > while(isspace(*buffer))
> > buffer++;
> > return *buffer == '\0';
> > }
> > Answering your question above: because I am ...well, because I
> > am yet incapable of thinking correctly, smartly, succinctly, etc,
> > all these are euphemisms for saying that I am... Ok, no self
> > flagellation, it does no good )
>
> No, that's not my question. It was not about making you feel bad but
> about learning to reason about code.
I know, I did ) To be explicit, testing for '\r' and '\n' was redundant.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-05 08:28 -0800 |
| Message-ID | <68ad239b-66b1-40aa-a1c2-64f0c1ca5336@googlegroups.com> |
| In reply to | #101170 |
On Thursday, January 5, 2017 at 5:13:52 PM UTC+3, Ben Bacarisse wrote: > Alla _ <modelling.data@gmail.com> writes: > <snip> > There are also a couple of logical oddities that need to be cleared > up... > > <sip> > > //Process lines that contain only 1 number > > if ( (not_converted > buffer) && (!empty_input(buffer) && > > empty_input(not_converted)) ) > > What happens if you write > > if ( (not_converted > buffer) && empty_input(not_converted) ) > > instead? Once you know the answer explain to me -- by reasoning about > your code -- why you are right. if ( not_converted > buffer && empty_input(not_converted) ) it is enough to have only this test, because if the buffer is empty, then not_converted cannot be bigger than buffer, no numbers could have been processed by strtod function; therefore, if the buffer is empty, not_converted == buffer, and that is taken care of in the else part. So, my (!empty_input(buffer) ) was redundant.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-05 17:20 +0000 |
| Message-ID | <87pok1iftr.fsf@bsb.me.uk> |
| In reply to | #101179 |
Alla _ <modelling.data@gmail.com> writes: > On Thursday, January 5, 2017 at 5:13:52 PM UTC+3, Ben Bacarisse wrote: >> Alla _ <modelling.data@gmail.com> writes: >> > <snip> >> There are also a couple of logical oddities that need to be cleared >> up... >> >> <sip> >> > //Process lines that contain only 1 number >> > if ( (not_converted > buffer) && (!empty_input(buffer) && >> > empty_input(not_converted)) ) >> >> What happens if you write >> >> if ( (not_converted > buffer) && empty_input(not_converted) ) >> >> instead? Once you know the answer explain to me -- by reasoning about >> your code -- why you are right. > if ( not_converted > buffer && empty_input(not_converted) ) > it is enough to have only this test, because if the buffer is empty, then > not_converted cannot be bigger than buffer, no numbers could have > been processed by strtod function; therefore, if the buffer is empty, > not_converted == buffer, and that is taken care of in the else part. > So, my (!empty_input(buffer) ) was redundant. Excellent! That's exactly how you need to be thinking about code. Programmers start by "playing computer" -- you run though what's happening in your mind pretending to do the actions of the machine, but that almost never yields any high-level understand of what can and can't happen. You have to stat looking at program in a more abstract way. Not that any of us stops "playing computer" (at least not as far as I know) but you do have to add new intellectual tools. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-05 10:45 -0800 |
| Message-ID | <c3669d85-ac7a-4c2b-a175-99dfa154d830@googlegroups.com> |
| In reply to | #101186 |
On Thursday, January 5, 2017 at 8:20:40 PM UTC+3, Ben Bacarisse wrote: > Alla _ <modelling.data@gmail.com> writes: > > > On Thursday, January 5, 2017 at 5:13:52 PM UTC+3, Ben Bacarisse wrote: > >> Alla _ <modelling.data@gmail.com> writes: > >> > > <snip> > >> There are also a couple of logical oddities that need to be cleared > >> up... > >> > >> <sip> > >> > //Process lines that contain only 1 number > >> > if ( (not_converted > buffer) && (!empty_input(buffer) && > >> > empty_input(not_converted)) ) > >> > >> What happens if you write > >> > >> if ( (not_converted > buffer) && empty_input(not_converted) ) > >> > >> instead? Once you know the answer explain to me -- by reasoning about > >> your code -- why you are right. > > if ( not_converted > buffer && empty_input(not_converted) ) > > it is enough to have only this test, because if the buffer is empty, then > > not_converted cannot be bigger than buffer, no numbers could have > > been processed by strtod function; therefore, if the buffer is empty, > > not_converted == buffer, and that is taken care of in the else part. > > So, my (!empty_input(buffer) ) was redundant. > > Excellent! That's exactly how you need to be thinking about code. > > Programmers start by "playing computer" -- you run though what's > happening in your mind pretending to do the actions of the machine, but > that almost never yields any high-level understand of what can and can't > happen. You have to stat looking at program in a more abstract way. > Not that any of us stops "playing computer" (at least not as far as I > know) but you do have to add new intellectual tools. > Thank you ) Have I correctly answered about open failure?
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-05 09:02 -0800 |
| Message-ID | <a07a23cb-f4ee-420c-9810-f19ec1d929a4@googlegroups.com> |
| In reply to | #101170 |
On Thursday, January 5, 2017 at 5:13:52 PM UTC+3, Ben Bacarisse wrote: > Alla _ <modelling.data@gmail.com> writes: <snip> > Finally, the program can still report "Open failure!". Can you work out > what must be true for this to happen and, from that, can you write a > test case you will make it happen? Try to do it by thinking about the > program. When I have first read this question, I said 'no way, that's definitely beyond my current capacity", but then.. by reasoning through the code, and only then confirming it by testing, I have one answer - I can get Open failure when index_n == 0, i.e. when there is no valid input in the file, and hence I never get to the point of EXIT_SUCCESS. It looks like a flaw, isn't it? > > -- > Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-05 19:49 +0000 |
| Message-ID | <878tqpi8x1.fsf@bsb.me.uk> |
| In reply to | #101180 |
Alla _ <modelling.data@gmail.com> writes: > On Thursday, January 5, 2017 at 5:13:52 PM UTC+3, Ben Bacarisse wrote: >> Alla _ <modelling.data@gmail.com> writes: > <snip> >> Finally, the program can still report "Open failure!". Can you work out >> what must be true for this to happen and, from that, can you write a >> test case you will make it happen? Try to do it by thinking about the >> program. > When I have first read this question, I said 'no way, that's definitely > beyond my current capacity", but then.. by reasoning through the > code, and only then confirming it by testing, I have one answer - > I can get Open failure when index_n == 0, i.e. when there is no > valid input in the file, and hence I never get to the point of > EXIT_SUCCESS. Yes, you are getting the hang it. > It looks like a flaw, isn't it? Yes, you need to report open failure only when the open fails. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-05 13:28 -0800 |
| Message-ID | <dd1c283c-79ef-4722-8f1e-5916cbdb2744@googlegroups.com> |
| In reply to | #101198 |
On Thursday, January 5, 2017 at 10:49:54 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> > On Thursday, January 5, 2017 at 5:13:52 PM UTC+3, Ben Bacarisse wrote:
> >> Alla _ <modelling.data@gmail.com> writes:
> > <snip>
> >> Finally, the program can still report "Open failure!". Can you work out
> >> what must be true for this to happen and, from that, can you write a
> >> test case you will make it happen? Try to do it by thinking about the
> >> program.
> > When I have first read this question, I said 'no way, that's definitely
> > beyond my current capacity", but then.. by reasoning through the
> > code, and only then confirming it by testing, I have one answer -
> > I can get Open failure when index_n == 0, i.e. when there is no
> > valid input in the file, and hence I never get to the point of
> > EXIT_SUCCESS.
>
> Yes, you are getting the hang it.
>
> > It looks like a flaw, isn't it?
>
> Yes, you need to report open failure only when the open fails.
>
Please, take a look two version of this exercise; one - using sum, another
using array. I also post a second version of handling the 'open failure' issue -
please, let me know which approach "looks" better in terms of style, logic, etc.
(1) Sum version:
#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);
bool empty_input(const char *buffer);
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;
}
//Compute average only if index_n > 0
if(index_n == 0)
{
fprintf(stderr, "No input to process\n");
fclose(fp);
return EXIT_FAILURE;
}
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);
//Process lines that contain only 1 number
if ( not_converted > buffer && empty_input(not_converted) )
{
*sum += number;
(*index_n)++;
line++;
}
else
{
fprintf(stderr, "Incorrect input line '%zu'\n", line);
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 check for empty lines **/
bool empty_input(const char *buffer)
{
while(isspace(*buffer))
buffer++;
return *buffer == '\0';
}
(2) Array version:
#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_numbers (FILE *input_file, double *numbers, size_t *index_n);
bool empty_input(const char *buffer);
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_numbers(fp, numbers, &index_n) )
{
fclose(fp);
return EXIT_FAILURE;
}
//Call function average only when index_n > 0
if(index_n == 0)
{
fprintf(stderr, "No input to process\n");
fclose(fp);
return EXIT_FAILURE;
}
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 numbers
from the file line by line
**/
bool get_numbers (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);
//Process lines that contain only 1 number
if ( not_converted > buffer && empty_input(not_converted) )
{
//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++;
}
else
{
fprintf(stderr, "Incorrect input line '%zu'\n", line);
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 check for empty lines **/
bool empty_input(const char *buffer)
{
while(isspace(*buffer))
buffer++;
return *buffer == '\0';
}
/** 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;
}
(3) Alternative 'open failure' issue based on 'sum' version;
in this version I first put the if(!fp), deal with it, and only
if it is not true, proceed with the whole process. I show only
the main function here:
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");
//Couldn't open the file
if ( !fp )
{
fprintf(stderr, "%s - %s\n", data_file, errno ? strerror(errno) : "Open failure!");
return EXIT_FAILURE;
}
double sum = 0;
size_t index_n = 0;
double average_num;
if( !get_numbers(fp, &sum, &index_n) )
{
fclose(fp);
return EXIT_FAILURE;
}
//Compute average only if index_n > 0
if(index_n == 0)
{
fprintf(stderr, "No input to process\n");
fclose(fp);
return EXIT_FAILURE;
}
average_num = sum/index_n;
printf("%.2f\n", average_num);
fclose(fp);
return EXIT_SUCCESS;
}
What do you think?
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2017-01-05 16:14 -0800 |
| Message-ID | <27ot6c1a6chu99pbm83nt8hqn71bhibfbn@4ax.com> |
| In reply to | #101203 |
On Thu, 5 Jan 2017 13:28:01 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:
snip>
>(1) Sum version:
>#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);
>bool empty_input(const char *buffer);
>
>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;
> }
> //Compute average only if index_n > 0
> if(index_n == 0)
> {
> fprintf(stderr, "No input to process\n");
A trivial point. You don't know if the file was empty (as your
message implies) or all the input you processed failed validation.
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-06 00:50 +0000 |
| Message-ID | <87o9zlggg7.fsf@bsb.me.uk> |
| In reply to | #101203 |
Alla _ <modelling.data@gmail.com> writes: > On Thursday, January 5, 2017 at 10:49:54 PM UTC+3, Ben Bacarisse wrote: >> Alla _ <modelling.data@gmail.com> writes: >> >> > On Thursday, January 5, 2017 at 5:13:52 PM UTC+3, Ben Bacarisse wrote: >> >> Alla _ <modelling.data@gmail.com> writes: >> > <snip> >> >> Finally, the program can still report "Open failure!". Can you work out >> >> what must be true for this to happen and, from that, can you write a >> >> test case you will make it happen? Try to do it by thinking about the >> >> program. >> > When I have first read this question, I said 'no way, that's definitely >> > beyond my current capacity", but then.. by reasoning through the >> > code, and only then confirming it by testing, I have one answer - >> > I can get Open failure when index_n == 0, i.e. when there is no >> > valid input in the file, and hence I never get to the point of >> > EXIT_SUCCESS. >> >> Yes, you are getting the hang it. >> >> > It looks like a flaw, isn't it? >> >> Yes, you need to report open failure only when the open fails. >> > Please, take a look two version of this exercise; one - using sum, another > using array. It's fine. Exercise 2 is done! Let's move on to number 3... > I also post a second version of handling the 'open failure' issue - > please, let me know which approach "looks" better in terms of style, > logic, etc. I really have no view on that. Pick one and run with it. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 10 of 13 — ← Prev page 1 … 8 9 [10] 11 12 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web