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 8 of 13 — ← Prev page 1 … 6 7 [8] 9 10 … 13 Next page →
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-02 10:57 -0800 |
| Message-ID | <6c72c217-ee57-4820-8ae8-17b887877e9d@googlegroups.com> |
| In reply to | #100889 |
On Monday, January 2, 2017 at 9:39:06 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> > On Monday, January 2, 2017 at 4:47:50 PM UTC+3, Ben Bacarisse wrote:
<snip>
> > Also, I have followed your recommendation above, and return false
> > if the array bounds are exceeded.
> > if (not_converted > buffer)
> > {
> > if (*index_n < NUMBERS)
> > numbers[(*index_n)++] = number;
> > else
> > {
> > fprintf(stderr, "Number of data exceeds capacity; stop at line '%zu'\n", line);
> > return false;
> > }
> > }
>
> Yes, that works when you want to abandon the parse when there is not
> enough room, but I'd have to re-visit the whole function to see if it
> isn't better put put this test in the while loop. There is a general
> rule here: as code grows and changes, always look at the big picture to
> see if things have changed in such a way as to make a reorganisation
> desirable.
I see. Please, take a look at the code below. Is this what you mean?
It indeed looks much better; sad I have not noticed that myself.
It is better to first make sure that I have enough space to store
numbers before continuing other operations, otherwise the
program performs unnecessary actions.
//Parse file data, store only numbers
while( fgets(buffer, sizeof(buffer), input_file) != NULL)
{
if (*index_n == NUMBERS-1)
{
fprintf(stderr, "Number of data exceeds capacity; stop at line '%zu'\n", line);
return false;
}
index_ch = 0;
char *not_converted = NULL;
double number = strtod(buffer, ¬_converted);
if (not_converted > buffer)
numbers[(*index_n)++] = number;
line++;
}
>
<snip>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-02 21:48 +0000 |
| Message-ID | <87vatxjfq8.fsf@bsb.me.uk> |
| In reply to | #100892 |
Alla _ <modelling.data@gmail.com> writes:
> On Monday, January 2, 2017 at 9:39:06 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>
>> > On Monday, January 2, 2017 at 4:47:50 PM UTC+3, Ben Bacarisse wrote:
> <snip>
>> > Also, I have followed your recommendation above, and return false
>> > if the array bounds are exceeded.
>> > if (not_converted > buffer)
>> > {
>> > if (*index_n < NUMBERS)
>> > numbers[(*index_n)++] = number;
>> > else
>> > {
>> > fprintf(stderr, "Number of data exceeds capacity; stop at line '%zu'\n", line);
>> > return false;
>> > }
>> > }
>>
>> Yes, that works when you want to abandon the parse when there is not
>> enough room, but I'd have to re-visit the whole function to see if it
>> isn't better put put this test in the while loop. There is a general
>> rule here: as code grows and changes, always look at the big picture to
>> see if things have changed in such a way as to make a reorganisation
>> desirable.
> I see. Please, take a look at the code below. Is this what you mean?
<snip>
No, that does something else altogether. Please forget it. What you
had was fine, and the version above is also fine. As you go forward
I'll bring it up if improvements present themselves.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2017-01-02 15:58 -0800 |
| Subject | POSIX, was: Re: Reading lines from a file, eliminating CR and LF |
| Message-ID | <4ef2150a-8add-4d87-a361-db5700cb9cf8@googlegroups.com> |
| In reply to | #100877 |
On Monday, January 2, 2017 at 9:22:08 AM UTC-6, Alla _ wrote: > On Monday, January 2, 2017 at 4:47:50 PM UTC+3, Ben Bacarisse wrote: > > Alla _ <modelling.data@gmail.com> writes: > > > > <snip> > > > Let's skip all this for now. > > > > It's fine. You are writing a C program for POSIX-conforming systems. > > > Doing my best to ignore this statement and not indulge into a further > discussion, but I would love to understand and learn what you mean > here; I will read about it, but for now, please, ignore my curiosity > kindled, yet again, by your comment ) I know you're not worried about this part just yet, so feel free to save this for later. ## What POSIX is? POSIX is the Portable Operating System API that all the various UNIX flavors follow. It provides more guarantees than the C standard does, like: "long has 32 bits", "integers are two's complement", "the file system has a tree structure". It provides more functions than the C standard does, like strdup(), and glob(). ## Why is POSIX good? If you write your C code according to the C standard first, and then use the POSIX standard for extra things you need that C doesn't cover, ... then your code is automatically portable to all Unix systems: Linux, BSD, Solaris, AIX. And "mostly" portable to many popular non-unix systems like Windows and Mac. ## What are the problems with POSIX? The 'mostly' part of '"mostly" portable' will cause you some grief when taking your code to windows (esp. to Microsoft's compiler). I believe it is less painful than attempting to port Windows code to Unix, but I have never tried to do that (fearing the pain).
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2016-12-31 21:03 -0800 |
| Message-ID | <5lig6chi7afg69n4gj2epjircbvptq93ql@4ax.com> |
| In reply to | #100733 |
On Sat, 31 Dec 2016 10:50:29 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:
>On Friday, December 30, 2016 at 4:35:33 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>
><snip>
>> I would set a student these exercises:
>>
>> 1. Write a program that reads lines into a fix-size buffer (100
>> characters will do) and prints the average of any numbers found at the
>> start of a line (except for white-space). It should ignore lines that
>> don't start with a number. So, given
>>
>> 1
>> -2.0
>> xyz
>> 7bz
>>
>> it should print 2.0 ((1 - 2 + 7)/3).
><snip>
>Please, take a look at this version. I have tested it on several
You are doing, or considering, much more processing than you need to.
In fact, you are checking things the problem spec says to ignore.
>inputs, including the one suggested by you, and each time it delivered
>the result I expected. One of the comments are used is rather big, but
>I did that on purpose to explain what I try to achieve.
>Issues not solved yet:
>1) I have not yet found the way to print ((1 - 2 + 7)/3)
>2) I have not found the way to test my average function for success;
>one of the options I used was if(the values of average != 0), but this
>is incorrect because average can be 0.
Since the average value is returned directly into a local variable by
virtue of passing the variable's address, change the return type of
the average function to bool, have the function return the appropriate
success or failure value, and test that value in main.
On the other hand, how can average fail. If there are no terms in the
array, it will return a meaningless 0 but you could check for that
before you call average. So why do you think there is a need to test
average for success?
>#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_line (FILE *input_file, int *numbers, size_t *index_n);
>void average(int *numbers, float *average_num, 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 )
> {
> int numbers[BUFFER_SIZE] = {0};
> size_t index_n = 0;
> float average_num;
>
> if( !get_line(fp, numbers, &index_n) )
> {
> puts("Reading file failed");
> fclose(fp);
> return EXIT_FAILURE;
> }
> //DEBUG
> for(size_t i = 0; i < index_n; i++)
> printf("%i ", numbers[i]);
> putchar('\n');
>
> average(numbers, &average_num, index_n);
> printf("The average is %.2f\n", average_num);
> fclose(fp);
> return EXIT_SUCCESS;
>
> /***** bad test for the success of average function
> if(average_num != 0)
> {
> printf("The average is %.2f\n", average_num);
> fclose(fp);
> return EXIT_SUCCESS;
> }
> *****/
> }
> //Couldn't open the file
> printf("%s - %s\n", data_file, errno ? strerror(errno) : "Openfailure!");
>
> return EXIT_FAILURE;
>}
>
>/** Function to read and process the data
> from the file line by line
> **/
>
>bool get_line (FILE *input_file, int *numbers, size_t *index_n)
>{
> char buffer[BUFFER_SIZE] = "";
> char *ptr = NULL;
> char *not_converted = NULL;
> int number;
> size_t index_ch;
>
> //Read each character from the file, store in a buffer
> while( fgets(buffer, sizeof(buffer), input_file) != NULL)
> {
> index_ch = 0;
>
> //DEBUG
> puts("*****************************");
> printf("Buffer beg:: %s\n", buffer);
>
> //Skip spaces at the begining of the line
> while(isspace(buffer[index_ch]))
> index_ch++;
Since strtol will skip leading white space, why do you feel the need
to do it yourself?
> /** If the first character in the buffer is a number,
> or if the first character after all beginning
> spaces is a number;
> do not do anything in all other cases
> **/
> if( isdigit(buffer[index_ch])
> || (buffer[index_ch] == '-'
> && isdigit(buffer[index_ch+1])))
Why do you care what the first (or second) character is? strtol is
perfectly capable of dealing with digits, sign and digits, non-digits,
and sign followed by non-digit. It doesn't need your help.
> {
> ptr = &buffer[index_ch];
> number = (int)strtol(ptr, ¬_converted, 10);
>
> if (not_converted > ptr)
And this test will tell you without fail whether a number was really
converted.
> {
> numbers[(*index_n)++] = number;
> puts("Number is parsed.");
> }
> }
> }
>
> if (ferror(input_file))
> {
> puts("The function detected an error reading a file.");
> if(*index_n != 0)
> printf("Last input processed was: %s\n", buffer);
> return false;
> }
> return true;
>}
>
>/** Find the average **/
>void average(int *numbers, float *average_num, size_t index)
>{
> float sum = 0;
> for(size_t i = 0; i < index; i++)
> sum += numbers[i];
>
> *average_num = sum/index;
>}
>
>Very Happy New Year! )
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-02 11:30 -0800 |
| Message-ID | <ac8ed4be-a856-4569-a9ae-1b1053661f49@googlegroups.com> |
| In reply to | #100656 |
On Friday, December 30, 2016 at 4:35:33 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
<snip>
> So, given
>
> 1
> -2.0
> xyz
> 7bz
>
> 2. Write another program that ignores lines that don't have just a
> number on them. For the input above the 7bz line will now be ignored.
>
I understand that what I am going to write and show now will irritate a lot
of people here, but I truly do not see my mistake. It's the second program.
Same input. I have written a small additional function that should return
true in case it spots any non-numerical values in the line; once it did,
the while loop in the get_lines function should start a new iteration, i.e.
read next line. No problems with reading each line, but my checking
function doesn't work at all: it doesn't accept 1 as a digit, and returns
an error; it doesn't except -2.0, returns same error that there are no
digits.
Here is the output I get; the program reads every line, reports that
none contain valid input, and then also reports that it couldn't open the file:
The line '0' contains non-numerical values.
The line '1' contains non-numerical values.
The line '2' contains non-numerical values.
The line '3' contains non-numerical values.
../files/ex_1_1.csv - Open failure!
#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);
bool check_line(char *ptr, size_t line);
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);
//debug
/** for (size_t i = 0; i < index_n; i++)
printf("%.2f ", numbers[i]);
putchar('\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, BUFFER_SIZE, input_file) != NULL)
{
if (*index_n == NUMBERS-1)
{
fprintf(stderr, "Number of data exceeds capacity; stop at line '%zu'\n", line);
return false;
}
size_t index_ch = 0;
//Skip beginning spaces
while(isspace(buffer[index_ch]))
index_ch++;
//Ignore lines that contain non-numerical characters
char *ptr = &buffer[index_ch];
if (check_line(ptr, line))
{
line++;
continue;
}
//Convert numerical characters into numbers
char *not_converted = NULL;
double number = strtod(&buffer[index_ch], ¬_converted);
if (not_converted > &buffer[index_ch])
numbers[(*index_n)++] = number;
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 if line contains
non-numerical values
**/
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;
}
/** Function to find the average; called
only if the number of elements is > 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;
}
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-02 19:45 +0000 |
| Message-ID | <o4eaht$2b4$1@dont-email.me> |
| In reply to | #100894 |
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;
}
--
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 | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2017-01-02 19:56 +0000 |
| Message-ID | <slrn3vfso6lc66.34c.ike@iceland.freeshell.org> |
| In reply to | #100895 |
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.
> strtod(ptr, endptr);
> return ptr == endptr;
> }
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-02 21:09 +0000 |
| Message-ID | <o4efgc$k6g$1@dont-email.me> |
| In reply to | #100898 |
On 02/01/17 19:56, 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 may well be meaningless to you. It is not meaningless to me.
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-03 11:01 +1300 |
| Message-ID | <ed00tdFlsf9U3@mid.individual.net> |
| In reply to | #100907 |
On 01/ 3/17 10:09 AM, Richard Heathfield wrote:
> On 02/01/17 19:56, 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 may well be meaningless to you. It is not meaningless to me.
You should at least have gotten a warning about passing a char* as the
first parameter of strtod :)
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-03 12:45 +0000 |
| Message-ID | <o4g6ag$bnp$1@dont-email.me> |
| In reply to | #100915 |
On 02/01/17 22:01, Ian Collins wrote:
> On 01/ 3/17 10:09 AM, Richard Heathfield wrote:
>> On 02/01/17 19:56, 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 may well be meaningless to you. It is not meaningless to me.
>
> You should at least have gotten a warning about passing a char* as the
> first parameter of strtod :)
Why?
double strtod(const char * restrict nptr, char ** restrict endptr);
There's no reason why I can't pass a char * as the first arg of strtod.
What point are you trying to make?
--
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 14:09 +0000 |
| Message-ID | <87lgusi6ac.fsf@bsb.me.uk> |
| In reply to | #100972 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 02/01/17 22:01, Ian Collins wrote:
>> On 01/ 3/17 10:09 AM, Richard Heathfield wrote:
>>> On 02/01/17 19:56, 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 may well be meaningless to you. It is not meaningless to me.
>>
>> You should at least have gotten a warning about passing a char* as the
>> first parameter of strtod :)
>
> Why?
He meant second -- the one where you use the variable being discussed.
Yes, it's a typo, but easy to work out that's it's one from the
context.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-03 15:07 +0000 |
| Message-ID | <o4gelb$a56$1@dont-email.me> |
| In reply to | #100978 |
On 03/01/17 14:09, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 02/01/17 22:01, Ian Collins wrote:
>>> On 01/ 3/17 10:09 AM, Richard Heathfield wrote:
>>>> On 02/01/17 19:56, 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 may well be meaningless to you. It is not meaningless to me.
>>>
>>> You should at least have gotten a warning about passing a char* as the
>>> first parameter of strtod :)
>>
>> Why?
>
> He meant second -- the one where you use the variable being discussed.
> Yes, it's a typo, but easy to work out that's it's one from the
> context.
I see it /now/, but only because you clued me in to look more closely at
the second argument.
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-04 09:13 +1300 |
| Message-ID | <ed2ev6F9licU1@mid.individual.net> |
| In reply to | #100972 |
On 01/ 4/17 01:45 AM, Richard Heathfield wrote:
> On 02/01/17 22:01, Ian Collins wrote:
>> On 01/ 3/17 10:09 AM, Richard Heathfield wrote:
>>> On 02/01/17 19:56, 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 may well be meaningless to you. It is not meaningless to me.
>>
>> You should at least have gotten a warning about passing a char* as the
>> first parameter of strtod :)
>
> Why?
>
> double strtod(const char * restrict nptr, char ** restrict endptr);
>
> There's no reason why I can't pass a char * as the first arg of strtod.
> What point are you trying to make?
It was a classic case of seeing what I wanted to see. I was sure lint
gave a warning if endptr wasn't initialised, but what it was telling me
was the second parameter was the wrong type.
I should probably lose the urge to type loose messages while on holiday.
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-03 11:53 +1300 |
| Message-ID | <ed03v8Flsf9U4@mid.individual.net> |
| In reply to | #100898 |
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?
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-01-02 15:40 -0800 |
| Message-ID | <84dca433-cfbe-40c5-80b4-306e61816bbf@googlegroups.com> |
| In reply to | #100920 |
On Monday, January 2, 2017 at 10:53:36 PM UTC, 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?
>
You can argue it both ways. If endptr is not initialised, that tells
you that it must be set before it is used and might make the code
easier to follow. On the other hand, it is wild, so if it is
inadvertently used before being set, the bug might not be reproducible.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-03 13:16 +1300 |
| Message-ID | <ed08qpFlsf7U2@mid.individual.net> |
| In reply to | #100927 |
On 01/ 3/17 12:40 PM, Malcolm McLean wrote:
> On Monday, January 2, 2017 at 10:53:36 PM UTC, 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?
>>
> You can argue it both ways. If endptr is not initialised, that tells
> you that it must be set before it is used and might make the code
> easier to follow. On the other hand, it is wild, so if it is
> inadvertently used before being set, the bug might not be reproducible.
I think you just contradicted your self. In this specific case (not in
general), the pointer does not need to be set before it is used.
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-03 00:01 +0000 |
| Message-ID | <87k2adj9k4.fsf@bsb.me.uk> |
| In reply to | #100920 |
Ian Collins <ian-news@hotmail.com> writes:
> 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.
That's an enthusiastic compiler. Would it not then warn about any
function used to initialise data via a function call?
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-03 13:21 +1300 |
| Message-ID | <ed0945Flsf7U3@mid.individual.net> |
| In reply to | #100936 |
On 01/ 3/17 01:01 PM, Ben Bacarisse wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>
>> 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.
>
> That's an enthusiastic compiler. Would it not then warn about any
> function used to initialise data via a function call?
It was a lint warning before I noticed the second bug in Richard's
function :)
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2017-01-03 08:40 +0000 |
| Message-ID | <slrn3vfso6mov5.9p8.ike@iceland.freeshell.org> |
| In reply to | #100920 |
On 2017-01-02, Ian Collins <ian-news@hotmail.com> 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?
Supposing initialization would be desirable, then why initialize it
to NULL, and not to, say, ptr, "Huh?" or "Silencing PCLint warning #684" ?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-03 12:50 +0000 |
| Message-ID | <o4g6ju$co4$1@dont-email.me> |
| In reply to | #100920 |
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"?
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.
We have had this discussion in comp.lang.c many, many times over the
years, and we always end up agreeing to differ.
--
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]
Page 8 of 13 — ← Prev page 1 … 6 7 [8] 9 10 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web