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 5 of 13 — ← Prev page 1 … 3 4 [5] 6 7 … 13 Next page →
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-28 08:39 -0800 |
| Message-ID | <2ed1e23b-6314-4c92-92c5-c0a1f53e69d0@googlegroups.com> |
| In reply to | #100360 |
On Wednesday, December 28, 2016 at 12:34:35 AM UTC+3, Manfred wrote:
> On 12/27/2016 7:56 PM, Barry Schwarz wrote:
> > On Tue, 27 Dec 2016 09:59:57 -0800 (PST), Alla _
> > <modelling.data@gmail.com> wrote:
> >
> >> The while loop:
> >> //Read each line from the file, store in the buffer
> >> while(fgets(buffer, sizeof(buffer), input_file) != NULL)
> >> {
> >>
> >> //If CR is found, its index is less than LF index
> >
> > Still an unjustified assertion.
> As Keith pointed out, after fgets the LF (if any) is last, so the CR (if
> any) comes earlier.
> >
> >> if ((found_char = strchr(buffer, newline_r)) != NULL
> >> && (set_index(buffer, &index, &found_char) == true))
<snip>
> <snip>
> >> //Delete any trailing commas
> As said, a trailing comma is valid in CSV, so I don't see why deleting
> it. Moreover, any check (except possibly for unprintable()) on the field
> contents (isdigit etc..) is dependent on the expected contents of the
> CSV file, which is unspecified here - in fact if your goal here is to
> get rid of the CRLF ending, and terminate the line with \0 instead, what
> more do you want to do here?
It seems that the verb "delete" has played a distracting role. I do not need
any trailing commas at the end of each line; the last acceptable
character is a digital one, then comes '\0'. Therefore, this part of the code
does exactly that - it traverses the buffer backwards until the first digital
character is found.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-28 02:20 -0800 |
| Message-ID | <0676d8f8-c12b-4a9a-8e7f-8d738ea92bf7@googlegroups.com> |
| In reply to | #100345 |
On Tuesday, December 27, 2016 at 9:56:54 PM UTC+3, Barry Schwarz wrote:
> On Tue, 27 Dec 2016 09:59:57 -0800 (PST), Alla _
> <modelling.data@gmail.com> wrote:
>
> <snip>
>
> >Please, take a look at this piece. Have I understood you correctly
> >in terms of how to use a call to strchr?
>
> You are still in love with unnecessary processing.
I have not yet seen your previous comments when I posted
this new version. I see that you have mentioned strpbrk
function, which I have never yet encountered; I will read
about it and see how to use it. I will be back with this.
> >The while loop:
> >//Read each line from the file, store in the buffer
> > while(fgets(buffer, sizeof(buffer), input_file) != NULL)
> > {
> >
> > //If CR is found, its index is less than LF index
>
> Still an unjustified assertion.
Same as above - not yet seen your comments before
posting this piece.
>
> > if ((found_char = strchr(buffer, newline_r)) != NULL
> > && (set_index(buffer, &index, &found_char) == true))
>
> You do not need index or set_index at all. But if you did, there
> would be no reason to use &found_char when found_char is just as
> effective.
>
> > {
> > buffer[index] = '\0';
>
> Why not the simpler
> *found_char = '\0';
Yes, I have understood this today after getting the hint
posted by Manfred )
But I still believe I need the index:
- to be able to traverse
through the buffer and truncate all trailing commas, as
I do in the code;
- check if the buffer has any values at all apart from the
newline character, as I do in the set_index function - EDIT
I see now your comment below on this part. Thank you!
Indeed, if buffer[0] = '\0' it would be at the same address
pointed to by found_char. Got it.
Still the trailing commas theme holds.
>
> > //DEBUG
> > printf("CR found; buffer ends at [%li]:: %s\n", index, buffer);
>
> You persist in using the wrong format for a size_t.
Nope, I do not - see above; I have not seen your comment before
posting; and honestly I have no idea how could %li sneak into my
code; it should have been %zu, I used that everywhere. Thank you
for showing me this.
>
> > }
> > else if ((found_char = strchr(buffer, newline_n)) != NULL
> > && (set_index(buffer, &index, &found_char) == true))
> > {
> > buffer[index] = '\0';
> > //DEBUG
> > printf("LF found; buffer ends at [%li]:: %s\n", index, buffer);
> > }
> > else
> > puts("The newline character is not found");
> >
> > //Delete any trailing commas
> > if(buffer[index-1] == ',')
> > {
> > index--;
> > while(!isdigit(buffer[index]) && buffer[index] == ',')
>
> Never use a single test when you can waste resources with a double
> test. The isdigit test contributes nothing to the result.
)))) Not seen a comment. Thank you - I see that !isdigit is redundant.
>
> > index--;
> > buffer[index+1] = '\0';
> > //DEBUG
> > printf("Comma found; buffer ends at [%li]:: %s\n", index+1, buffer);
> > }
> > //Check for any other unprintable characters
> > if(unprintable(buffer))
> > {
> > puts("CSV file contains unprintable characters");
> > puts("Please, correct the file and try again");
> > return false;
> > }
> > }
> >
> >/** Set index at the end of the line **/
> >bool set_index(char *buffer, size_t *index, char **found_char)
>
> If you used found_char in the call to this function, the parameter
> would be char *found_char
>
My mistake. Indeed. I do not need a pointer to a pointer here.
Thank you.
> >{
> > *index = *found_char - buffer;
>
> and this would be found_char - buffer
>
> > //DEBUG
> > printf("found %p, buffer %p\n", (void*)*found_char, (void *) buffer);
>
> and this would be (void*)found_char
>
> > printf("index = %li\n", *index);
> > //If array is empty
> > if(*index == 0)
>
> If you really need this test, you can achieve the same result after
> calling strchr with a simple
> if (found_char == buffer)
>
> > {
> > buffer[*index] = '\0';
> > printf("Buffer is empty; please, check the input data\n");
> > return false;
> > }
> > //DEBUG
> > buffer[*index] = '&';
> > printf("Buffer [%zu]:: %s\n", *index, buffer);
> > return true;
> >}
>
> --
> Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-28 10:11 -0800 |
| Message-ID | <de209e90-5c1e-4ab9-9ba0-fd4533335ad8@googlegroups.com> |
| In reply to | #100345 |
On Tuesday, December 27, 2016 at 9:56:54 PM UTC+3, Barry Schwarz wrote:
> On Tue, 27 Dec 2016 09:59:57 -0800 (PST), Alla _
> <modelling.data@gmail.com> wrote:
>
> <snip>
>
> >Please, take a look at this piece. Have I understood you correctly
> >in terms of how to use a call to strchr?
>
> You are still in love with unnecessary processing.
<snip>
I still have not implemented strpbrk, but, please, take a look at
what I have achieved. It looks good to me, even if it have over-
processing features. What do you think? Is it better in terms of
program structure and logic? To avoid too much visual noise,
I have deleted in this code the majority of debugging printf I use.
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <string.h>
#include <stdbool.h>
#define BUFFER_SIZE 100
#define INCOME_STATEMENT "../files/income_test.csv"
bool get_line (FILE *input_file);
bool unprintable(char *buffer);
bool found_newline(char *buffer, 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] : INCOME_STATEMENT;
FILE *fp = fopen(data_file, "r");
if ( fp )
{
if( !get_line(fp) )
{
puts("Reading csv file failed");
return EXIT_FAILURE;
}
fclose(fp);
return EXIT_SUCCESS;
}
//Couldn't open the file
else
{
perror(data_file);
}
return EXIT_FAILURE;
}
/** Function to read and process the data
from the file line by line
**/
bool get_line (FILE *input_file)
{
char buffer[BUFFER_SIZE] = "";
size_t line = 0;
size_t index;
//Read each line from the file, store in the buffer
while(fgets(buffer, sizeof(buffer), input_file) != NULL)
{
line++;
//DEBUG
puts("*****************************");
printf("Buffer beg:: %s\n", buffer);
//Check for CR
if ( !found_newline(buffer, &index) )
puts("The newline character is not found");
//Check for any other unprintable characters
if(unprintable(buffer))
{
puts("CSV file contains unprintable characters");
puts("Please, correct the file and try again");
return false;
}
//Delete any trailing commas
if(buffer[index-1] == ',')
{
index--;
while(buffer[index] == ',')
index--;
buffer[index+1] = '\0';
//DEBUG
printf("Comma found; buffer ends at [%zu]:: %s\n", index+1, buffer);
}
}
if (ferror(input_file))
{
puts("Something went wrong with the provided file\n");
return false;
}
return true;
}
/** Find unprintable characters in array
other than LF and CR
**/
bool unprintable(char *buffer)
{
while(*buffer != '\0')
{
if(!isprint(*buffer))
return true;
buffer++;
}
return false;
}
/** Find the newline character **/
bool found_newline(char *buffer, size_t *index)
{
char *found_r = NULL;
char *found_n = NULL;
char *found_char = NULL;
const char newline_r = '\r';
const char newline_n = '\n';
//Check for CR or LF
if ( ((found_r = strchr(buffer, newline_r)) != NULL)
|| ((found_n = strchr(buffer, newline_n)) != NULL) )
{
found_char = (found_r) ? found_r : found_n;
*index = found_char - buffer;
if(buffer == found_char)
{
printf("Buffer is empty; please, check the input data\n");
return false;
}
*found_char = '\0';
return true;
}
return false;
}
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-29 00:20 -0800 |
| Message-ID | <c1ce8212-7cd6-4744-a1be-ba07d47633da@googlegroups.com> |
| In reply to | #100454 |
On Wednesday, December 28, 2016 at 10:57:24 PM UTC+3, Manfred wrote:
> On 12/28/2016 7:11 PM, Alla _ wrote:
> > On Tuesday, December 27, 2016 at 9:56:54 PM UTC+3, Barry Schwarz wrote:
> <snip>
<snip>
> Your found_newline function does not always set index, and when this
> happens the next statement leads to unpredictable results.
Here is how I can solve the index mistake: if the newline is not found,
than the fgets puts '\0' at the end of the line; I compute the length of the
line with strlen, which returns the length - 1 (one for the last '\0').
//Check for newline
if ( !found_newline(buffer, &index) )
{
puts("The newline character is not found");
index = strlen(buffer) - 1;
}
> Still I am not convinced that removing the trailing commas here is a
> good idea.
> Finally (for this stage) depending on how many times you want the debug
> message to be printed, the following could be a bit more straightforward
> and compact
> > //Delete any trailing commas
> > if(buffer[index-1] == ',')
> > {
> > index--;
> > while(buffer[index] == ',')
> > index--;
> > buffer[index+1] = '\0';
> > //DEBUG
> > printf("Comma found; buffer ends at [%zu]:: %s\n", index+1, buffer);
> > }
> > }
> >
> <snip>
> Now, this. The function has a bug and an important design flaw.
> I'll describe the the bug later at its point, and the flaw here:
> You are using 4 (four) different variables to represent the same program
> element, i.e. the line terminator, namely:
> - index
> - found_r
> - found_n
> - found_char
> Isn't it overcomplicating things? Obviously it requires much more effort
> (and a mistake is easier to make) to manage four variables that one!
> > /** Find the newline character **/
> > bool found_newline(char *buffer, size_t *index)
> > {
> > char *found_r = NULL;
> > char *found_n = NULL;
> > char *found_char = NULL;
> > const char newline_r = '\r';
> > const char newline_n = '\n';
> >
> > //Check for CR or LF
> This logic works, but you see here already that instead of using
> found_r, found_n and found_char you could use one variable for all of
> them, and if you did so...
> > if ( ((found_r = strchr(buffer, newline_r)) != NULL)
> > || ((found_n = strchr(buffer, newline_n)) != NULL) )
> > {
> ...the next statement would not be needed
> > found_char = (found_r) ? found_r : found_n;
> > *index = found_char - buffer;
> >
> > if(buffer == found_char)
> > {
> > printf("Buffer is empty; please, check the input data\n");
> > return false;
> > }
> > *found_char = '\0';
> >
> > return true;
> > }
> Here is the bug: if buffer has no CR/LF, then 'index' is not set.
> Since you used 4 variables to represent the line terminator, it is no
> surprise that you missed to ensure that one of them was properly set.
> Unfortunately it is the one that you are returning to the caller.
> > return false;
> > }
> >
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2016-12-29 14:56 +0100 |
| Message-ID | <o434n8$f33$1@gioia.aioe.org> |
| In reply to | #100468 |
On 12/29/2016 9:20 AM, Alla _ wrote:
This is now superseded, but still the remark holds:
> Here is how I can solve the index mistake: if the newline is not found,
> than the fgets puts '\0' at the end of the line; I compute the length of the
> line with strlen, which returns the length - 1 (one for the last '\0').
> //Check for newline
> if ( !found_newline(buffer, &index) )
> {
> puts("The newline character is not found");
What if strlen returns 0?
> index = strlen(buffer) - 1;
> }
>> Still I am not convinced that removing the trailing commas here is a
>> good idea.
>> Finally (for this stage) depending on how many times you want the debug
>> message to be printed, the following could be a bit more straightforward
>> and compact
>>> //Delete any trailing commas
Before you access buffer[index-1] you should ensure that the subscript
is valid. What if index is 0?
>>> if(buffer[index-1] == ',')
>>> {
>>> index--;
>>> while(buffer[index] == ',')
>>> index--;
>>> buffer[index+1] = '\0';
>>> //DEBUG
>>> printf("Comma found; buffer ends at [%zu]:: %s\n", index+1, buffer);
>>> }
>>> }
>>>
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-29 22:35 -0800 |
| Message-ID | <1e25e90b-156f-448d-8709-7deb4ebae1f5@googlegroups.com> |
| In reply to | #100581 |
On Thursday, December 29, 2016 at 4:57:04 PM UTC+3, Manfred wrote:
> On 12/29/2016 9:20 AM, Alla _ wrote:
> This is now superseded, but still the remark holds:
>
> > Here is how I can solve the index mistake: if the newline is not found,
> > than the fgets puts '\0' at the end of the line; I compute the length of the
> > line with strlen, which returns the length - 1 (one for the last '\0').
> > //Check for newline
> > if ( !found_newline(buffer, &index) )
> > {
> > puts("The newline character is not found");
> What if strlen returns 0?
> > index = strlen(buffer) - 1;
I have inserted the following right after this index phrase:
if(index <= 1)
{
printf("The line[%zu] contains no input\n", line);
puts("Please, check the input data");
return false;
}
> > }
> >> Still I am not convinced that removing the trailing commas here is a
> >> good idea.
> >> Finally (for this stage) depending on how many times you want the debug
> >> message to be printed, the following could be a bit more straightforward
> >> and compact
> >>> //Delete any trailing commas
> Before you access buffer[index-1] you should ensure that the subscript
> is valid. What if index is 0?
> >>> if(buffer[index-1] == ',')
> >>> {
This one should be better if((index > 0) && buffer[index-1] == ',')
<snip>
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2016-12-30 22:45 +0100 |
| Message-ID | <o46khh$cqj$1@gioia.aioe.org> |
| In reply to | #100627 |
On 12/30/2016 7:35 AM, Alla _ wrote:
>>> //Check for newline
>>> if ( !found_newline(buffer, &index) )
>>> {
>>> puts("The newline character is not found");
>> What if strlen returns 0?
>>> index = strlen(buffer) - 1;
> I have inserted the following right after this index phrase:
There is a trap here - if I remember correctly index was a size_t, thus
unsigned.
Basically, you can't test for wrap around after it has occurred.
> if(index <= 1)
> {
> printf("The line[%zu] contains no input\n", line);
> puts("Please, check the input data");
> return false;
> }
<snip>
>> is valid. What if index is 0?
>>>>> if(buffer[index-1] == ',')
>>>>> {
> This one should be better if((index > 0) && buffer[index-1] == ',')
This looks indeed better.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-31 00:01 +0000 |
| Message-ID | <87ful5ge4y.fsf@bsb.me.uk> |
| In reply to | #100700 |
Manfred <noname@invalid.add> writes:
> On 12/30/2016 7:35 AM, Alla _ wrote:
>>>> //Check for newline
>>>> if ( !found_newline(buffer, &index) )
>>>> {
>>>> puts("The newline character is not found");
>>> What if strlen returns 0?
>>>> index = strlen(buffer) - 1;
>> I have inserted the following right after this index phrase:
> There is a trap here - if I remember correctly index was a size_t,
> thus unsigned.
Yes, it is.
> Basically, you can't test for wrap around after it has occurred.
Yes you can. It might be odd to do so, but you certainly *can* test for
wrap around after a simple strlen(buffer) - 1. index would be ==
(size_t)-1 if the arithmetic had wrapped.
What you can't do (portably) is test for signed integer overflow after
it has occurred.
>> if(index <= 1)
I think your point is that this test does not include the case where
buffer was empty. That's true (index will be a very large number in
that case) but I'm not sure if that case can ever occur in this program.
If the buffer is filled by fgets, it will contain at least a newline or,
in the case of an empty file, fgets will have returned NULL. Of course,
all bets are off if the file has null bytes in it, but I'm assuming
that's not the case.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2016-12-31 03:19 +0100 |
| Message-ID | <o474j9$158n$1@gioia.aioe.org> |
| In reply to | #100719 |
On 12/31/2016 1:01 AM, Ben Bacarisse wrote: > Manfred <noname@invalid.add> writes: >> There is a trap here - if I remember correctly index was a size_t, >> thus unsigned. > > Yes, it is. > >> Basically, you can't test for wrap around after it has occurred. > > Yes you can. It might be odd to do so, but you certainly *can* test for > wrap around after a simple strlen(buffer) - 1. index would be == > (size_t)-1 if the arithmetic had wrapped. True, but what I meant was that if you wrap the value around zero by decrementing it you can't test if it is less than zero (or less than one) - so this test is flawed. Your test for equality == (size_t)-1 is correct, but I think that better practice would have been to use index = strlen(buffer) and use this value in the following. > > What you can't do (portably) is test for signed integer overflow after > it has occurred. Also true. > >>> if(index <= 1) > > I think your point is that this test does not include the case where > buffer was empty. That's true (index will be a very large number in > that case) but I'm not sure if that case can ever occur in this program. > If the buffer is filled by fgets, it will contain at least a newline or, > in the case of an empty file, fgets will have returned NULL. Of course, > all bets are off if the file has null bytes in it, but I'm assuming > that's not the case. Also true, but in the code that I have seen so far in this example there are still measures to replace \n with \0. Obviously if/when this will to be dropped it will be different. > > <snip> >
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-31 00:20 -0800 |
| Message-ID | <dab93d6b-e3cd-49c0-a57c-924ea19ee04d@googlegroups.com> |
| In reply to | #100700 |
On Saturday, December 31, 2016 at 12:45:31 AM UTC+3, Manfred wrote:
> On 12/30/2016 7:35 AM, Alla _ wrote:
> >>> //Check for newline
> >>> if ( !found_newline(buffer, &index) )
> >>> {
> >>> puts("The newline character is not found");
> >> What if strlen returns 0?
> >>> index = strlen(buffer) - 1;
> > I have inserted the following right after this index phrase:
> There is a trap here - if I remember correctly index was a size_t, thus
> unsigned.
> Basically, you can't test for wrap around after it has occurred.
Theoretically, given the csv line, can index every get below zero, and thus
due to unsigned format become wrapped around? What can lead to
a negative index in this particular case?
> > if(index <= 1)
> > {
> > printf("The line[%zu] contains no input\n", line);
> > puts("Please, check the input data");
> > return false;
> > }
>
> <snip>
> >> is valid. What if index is 0?
> >>>>> if(buffer[index-1] == ',')
> >>>>> {
> > This one should be better if((index > 0) && buffer[index-1] == ',')
> This looks indeed better.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-31 00:23 -0800 |
| Message-ID | <68a8bbbc-1f8f-4178-9fe0-dc1c814fc4a9@googlegroups.com> |
| In reply to | #100700 |
On Saturday, December 31, 2016 at 12:45:31 AM UTC+3, Manfred wrote:
> On 12/30/2016 7:35 AM, Alla _ wrote:
> >>> //Check for newline
> >>> if ( !found_newline(buffer, &index) )
> >>> {
> >>> puts("The newline character is not found");
> >> What if strlen returns 0?
> >>> index = strlen(buffer) - 1;
> > I have inserted the following right after this index phrase:
> There is a trap here - if I remember correctly index was a size_t, thus
> unsigned.
Please, ignore my previous question; completely inappropriate - the
answer is more than clear ) sorry
> Basically, you can't test for wrap around after it has occurred.
> > if(index <= 1)
> > {
> > printf("The line[%zu] contains no input\n", line);
> > puts("Please, check the input data");
> > return false;
> > }
>
> <snip>
> >> is valid. What if index is 0?
> >>>>> if(buffer[index-1] == ',')
> >>>>> {
> > This one should be better if((index > 0) && buffer[index-1] == ',')
> This looks indeed better.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-31 00:29 -0800 |
| Message-ID | <56dc6cbf-c0e6-486d-8d28-72fbf622dd60@googlegroups.com> |
| In reply to | #100700 |
On Saturday, December 31, 2016 at 12:45:31 AM UTC+3, Manfred wrote:
> On 12/30/2016 7:35 AM, Alla _ wrote:
> >>> //Check for newline
> >>> if ( !found_newline(buffer, &index) )
> >>> {
> >>> puts("The newline character is not found");
> >> What if strlen returns 0?
> >>> index = strlen(buffer) - 1;
> > I have inserted the following right after this index phrase:
> There is a trap here - if I remember correctly index was a size_t, thus
> unsigned.
This was my yet another mistake. Here is what I should have added
before subtracting 1 from the value strlen() returned:
index = strlen(buffer);
if(strlen(buffer) > 0)
index--;
And only then comes the test below.
> Basically, you can't test for wrap around after it has occurred.
> > if(index <= 1)
> > {
> > printf("The line[%zu] contains no input\n", line);
> > puts("Please, check the input data");
> > return false;
> > }
>
> <snip>
> >> is valid. What if index is 0?
> >>>>> if(buffer[index-1] == ',')
> >>>>> {
> > This one should be better if((index > 0) && buffer[index-1] == ',')
> This looks indeed better.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-31 11:10 +0000 |
| Message-ID | <871swogxqs.fsf@bsb.me.uk> |
| In reply to | #100728 |
Alla _ <modelling.data@gmail.com> writes:
> On Saturday, December 31, 2016 at 12:45:31 AM UTC+3, Manfred wrote:
>> On 12/30/2016 7:35 AM, Alla _ wrote:
>> >>> //Check for newline
>> >>> if ( !found_newline(buffer, &index) )
>> >>> {
>> >>> puts("The newline character is not found");
>> >> What if strlen returns 0?
>> >>> index = strlen(buffer) - 1;
>> > I have inserted the following right after this index phrase:
>> There is a trap here - if I remember correctly index was a size_t, thus
>> unsigned.
> This was my yet another mistake. Here is what I should have added
> before subtracting 1 from the value strlen() returned:
>
> index = strlen(buffer);
> if(strlen(buffer) > 0)
> index--;
> And only then comes the test below.
I don't think this is the right way to fix this. First, there may in
fact be no problem at all, since, in a loop that uses fgets, there will
always be at least one character in the buffer. (It's not entirely
clear because I'm not sure I can find the exact program these changes
relate to.)
Secondly, you are trying to fix a problem that you have created. There
is no need to subtract one from index here so the simplest solution is
simply not to do that. I don't mean that just removing the code will
just make things work, I mean that you can almost always do what you
want by in some other way.
Thirdly, what is the point of this code? I.e. why are you looking for a
newline in the first place? You seem to want to remove it by replacing
it with a null (\0) but I don't know why. Your program is about finding
names and numbers on a line, not about finding newlines.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-31 10:53 -0800 |
| Message-ID | <e6921ad1-4cb8-440d-9e8e-1240e37aaf8c@googlegroups.com> |
| In reply to | #100730 |
On Saturday, December 31, 2016 at 2:10:44 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> > On Saturday, December 31, 2016 at 12:45:31 AM UTC+3, Manfred wrote:
> >> On 12/30/2016 7:35 AM, Alla _ wrote:
> >> >>> //Check for newline
> >> >>> if ( !found_newline(buffer, &index) )
> >> >>> {
> >> >>> puts("The newline character is not found");
> >> >> What if strlen returns 0?
> >> >>> index = strlen(buffer) - 1;
> >> > I have inserted the following right after this index phrase:
> >> There is a trap here - if I remember correctly index was a size_t, thus
> >> unsigned.
> > This was my yet another mistake. Here is what I should have added
> > before subtracting 1 from the value strlen() returned:
> >
> > index = strlen(buffer);
> > if(strlen(buffer) > 0)
> > index--;
> > And only then comes the test below.
>
> I don't think this is the right way to fix this. First, there may in
> fact be no problem at all, since, in a loop that uses fgets, there will
> always be at least one character in the buffer. (It's not entirely
> clear because I'm not sure I can find the exact program these changes
> relate to.)
>
> Secondly, you are trying to fix a problem that you have created. There
> is no need to subtract one from index here so the simplest solution is
> simply not to do that. I don't mean that just removing the code will
> just make things work, I mean that you can almost always do what you
> want by in some other way.
>
> Thirdly, what is the point of this code? I.e. why are you looking for a
> newline in the first place? You seem to want to remove it by replacing
> it with a null (\0) but I don't know why. Your program is about finding
> names and numbers on a line, not about finding newlines.
Yes yes, we have discussed that, but I am fixing what I have already written,
while I am learning a correct, i.e. positive approach, as I call it because it
checks the input for success, not failure )
>
> <snip>
> --
> Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-31 20:24 +0000 |
| Message-ID | <87o9zrrgnq.fsf@bsb.me.uk> |
| In reply to | #100734 |
Alla _ <modelling.data@gmail.com> writes:
> On Saturday, December 31, 2016 at 2:10:44 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>
>> > On Saturday, December 31, 2016 at 12:45:31 AM UTC+3, Manfred wrote:
>> >> On 12/30/2016 7:35 AM, Alla _ wrote:
>> >> >>> //Check for newline
>> >> >>> if ( !found_newline(buffer, &index) )
>> >> >>> {
>> >> >>> puts("The newline character is not found");
>> >> >> What if strlen returns 0?
>> >> >>> index = strlen(buffer) - 1;
>> >> > I have inserted the following right after this index phrase:
>> >> There is a trap here - if I remember correctly index was a size_t, thus
>> >> unsigned.
>> > This was my yet another mistake. Here is what I should have added
>> > before subtracting 1 from the value strlen() returned:
>> >
>> > index = strlen(buffer);
>> > if(strlen(buffer) > 0)
>> > index--;
>> > And only then comes the test below.
>>
>> I don't think this is the right way to fix this. First, there may in
>> fact be no problem at all, since, in a loop that uses fgets, there will
>> always be at least one character in the buffer. (It's not entirely
>> clear because I'm not sure I can find the exact program these changes
>> relate to.)
>>
>> Secondly, you are trying to fix a problem that you have created. There
>> is no need to subtract one from index here so the simplest solution is
>> simply not to do that. I don't mean that just removing the code will
>> just make things work, I mean that you can almost always do what you
>> want by in some other way.
>>
>> Thirdly, what is the point of this code? I.e. why are you looking for a
>> newline in the first place? You seem to want to remove it by replacing
>> it with a null (\0) but I don't know why. Your program is about finding
>> names and numbers on a line, not about finding newlines.
> Yes yes, we have discussed that, but I am fixing what I have already
> written,
Sure, but what does foxing it mean? I not really sure (because I don't
know what the program should do and I'm only seeing fragments here), but
I am fairly sure that what you've added is not fixing it.
To find the newline and, if there, replace it with \0 you should use
strchr.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2016-12-29 00:53 -0800 |
| Message-ID | <u0j96chg27n29uf4t7dis8rt5sdcm5gtj8@4ax.com> |
| In reply to | #100454 |
On Wed, 28 Dec 2016 23:16:55 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:
>On Wednesday, December 28, 2016 at 10:57:24 PM UTC+3, Manfred wrote:
>> On 12/28/2016 7:11 PM, Alla _ wrote:
>> > On Tuesday, December 27, 2016 at 9:56:54 PM UTC+3, Barry Schwarz wrote:
>> <snip>
><snip>
>> <snip>
>> Now, this. The function has a bug and an important design flaw.
>> I'll describe the the bug later at its point, and the flaw here:
>> You are using 4 (four) different variables to represent the same program
>> element, i.e. the line terminator, namely:
>> - index
>> - found_r
>> - found_n
>> - found_char
>> Isn't it overcomplicating things? Obviously it requires much more effort
>> (and a mistake is easier to make) to manage four variables that one!
>> > /** Find the newline character **/
>> > bool found_newline(char *buffer, size_t *index)
>> > {
>> > char *found_r = NULL;
>> > char *found_n = NULL;
>> > char *found_char = NULL;
>> > const char newline_r = '\r';
>> > const char newline_n = '\n';
>> >
>> > //Check for CR or LF
>> This logic works, but you see here already that instead of using
>> found_r, found_n and found_char you could use one variable for all of
>> them, and if you did so...
>That's what I can't see; I have no idea how to use only one
>variable if I need to find either CR or LF at the end of the line.
>How can that be only one variable?
Well, if you used strpbrk, it would find the first occurrence of any
set of characters you specify. You would be left with a single
pointer to that character regardless of which one it was.
But even that is unnecessary. Correct me if I'm wrong but the whole
purpose of this limited program you have been laboring over for weeks
is to place a terminal '\0' after the last digit in your input line.
You don't really care what follows the last digit. You have made some
assumptions that there might be 0 or more commas, 0 or 1 CRs, and 1
NL. You don't need any of these assumptions. If you use strlen to
find the end of the string, then back track until you find a digit,
and finally substitute a '\0' for the character immediately after the
digit, you will have achieved your goal. Notice that this works
regardless of the how many commas, CRs, or NLs follow the last digit.
And for completeness, if some of your lines end in valid non-numeric
fields, instead of looking for a digit use isalnum declared in ctype.h
to find the last "valid" character.
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-29 01:28 -0800 |
| Message-ID | <0a962d23-1896-4441-aa9b-dcabe0205fc2@googlegroups.com> |
| In reply to | #100511 |
On Thursday, December 29, 2016 at 11:53:29 AM UTC+3, Barry Schwarz wrote:
> On Wed, 28 Dec 2016 23:16:55 -0800 (PST), Alla _
> <modelling.data@gmail.com> wrote:
>
> >On Wednesday, December 28, 2016 at 10:57:24 PM UTC+3, Manfred wrote:
> >> On 12/28/2016 7:11 PM, Alla _ wrote:
> >> > On Tuesday, December 27, 2016 at 9:56:54 PM UTC+3, Barry Schwarz wrote:
> >> <snip>
> ><snip>
> >> <snip>
> >> Now, this. The function has a bug and an important design flaw.
> >> I'll describe the the bug later at its point, and the flaw here:
> >> You are using 4 (four) different variables to represent the same program
> >> element, i.e. the line terminator, namely:
> >> - index
> >> - found_r
> >> - found_n
> >> - found_char
> >> Isn't it overcomplicating things? Obviously it requires much more effort
> >> (and a mistake is easier to make) to manage four variables that one!
> >> > /** Find the newline character **/
> >> > bool found_newline(char *buffer, size_t *index)
> >> > {
> >> > char *found_r = NULL;
> >> > char *found_n = NULL;
> >> > char *found_char = NULL;
> >> > const char newline_r = '\r';
> >> > const char newline_n = '\n';
> >> >
> >> > //Check for CR or LF
> >> This logic works, but you see here already that instead of using
> >> found_r, found_n and found_char you could use one variable for all of
> >> them, and if you did so...
> >That's what I can't see; I have no idea how to use only one
> >variable if I need to find either CR or LF at the end of the line.
> >How can that be only one variable?
>
> Well, if you used strpbrk, it would find the first occurrence of any
> set of characters you specify. You would be left with a single
> pointer to that character regardless of which one it was.
>
> But even that is unnecessary. Correct me if I'm wrong but the whole
> purpose of this limited program you have been laboring over for weeks
> is to place a terminal '\0' after the last digit in your input line.
> You don't really care what follows the last digit. You have made some
> assumptions that there might be 0 or more commas, 0 or 1 CRs, and 1
> NL. You don't need any of these assumptions. If you use strlen to
> find the end of the string, then back track until you find a digit,
> and finally substitute a '\0' for the character immediately after the
> digit, you will have achieved your goal. Notice that this works
> regardless of the how many commas, CRs, or NLs follow the last digit.
>
> And for completeness, if some of your lines end in valid non-numeric
> fields, instead of looking for a digit use isalnum declared in ctype.h
> to find the last "valid" character.
Yes, you know what I am after; this is completely true. To be honest, the
first version I did, was with the strlen, but then the whole conversation turned
into finding newlines and other unprintable, and I was advised to use
strchr to find those, so I did.
I have finally written the same piece with strpbrk just now. Still big because
of those indexing staff, but it does look much better: as you said, only
two lines, if no index-finding staff is added.
I will now follow your advice and rewrite this piece using only strlen,
and finishing at the first digit, and this version will go into my number
converting part (with strtol) - I believe that now I will not face any issues
there )
NB: using strchr, looking for \r and \n, etc. did a good job anyway - it is a
great practice; just see how I have started and what I get at the end )
So the issue of how to use only one variable, if I search for \r and \n,
still holds: I would like to know that.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2016-12-29 14:48 +0100 |
| Message-ID | <o4346t$e9k$1@gioia.aioe.org> |
| In reply to | #100549 |
On 12/29/2016 10:28 AM, Alla _ wrote:
> So the issue of how to use only one variable, if I search for \r and \n,
> still holds: I would like to know that.
I am answering to this, for the sake of curiosity, although others have
already pointed out that using strlen may be better (I didn't because I
was following your rationale instead of giving my preferred solution,
which I doubt now if it was not more confusing that helpful - sorry)
On 12/28/2016 8:57 PM, Manfred wrote:
> This logic works, but you see here already that instead of using
> found_r, found_n and found_char you could use one variable for all of
> them, and if you did so...
>> if ( ((found_r = strchr(buffer, newline_r)) != NULL)
>> || ((found_n = strchr(buffer, newline_n)) != NULL) )
>> {
> ...the next statement would not be needed
>> found_char = (found_r) ? found_r : found_n;
>> *index = found_char - buffer;
char* found_char; // this might be as well initialized to NULL
// although here it is irrelevant
if ( ((found_char = strchr(buffer, newline_r)) != NULL)
|| ((found_char = strchr(buffer, newline_n)) != NULL) )
{
*index = found_char - buffer;
This makes use of this language rule (6.5.14, clause 4):
in the expression
(expr1 || expr2)
expr1 is evaluated first, and expr2 is evaluated only if expr1 is zero.
So in the condition expression above the assignment to found_char is
executed for strchr(buffer, newline_r) first; only if this results NULL
the second assignment is executed; if neither \r nor \n are found,
found_char is set to NULL by this last assignment, and the dependent
block is not entered.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-29 22:19 -0800 |
| Message-ID | <cdf089d4-8ce9-4443-be23-6c204f5834e3@googlegroups.com> |
| In reply to | #100576 |
On Thursday, December 29, 2016 at 4:48:20 PM UTC+3, Manfred wrote: > On 12/29/2016 10:28 AM, Alla _ wrote: > > So the issue of how to use only one variable, if I search for \r and \n, > > still holds: I would like to know that. > I am answering to this, for the sake of curiosity, although others have > already pointed out that using strlen may be better (I didn't because I > was following your rationale instead of giving my preferred solution, > which I doubt now if it was not more confusing that helpful - sorry) > Please, don't be sorry - you did help me a lot, and, especially I liked the way your were guiding me by not giving out a solution, but asking a question and/or hinting; it's great ) And as I have mentioned, I am confident that this whole work was very useful for me - I have learned something new and I have practiced C and program structuring. It's all great, even if this has consumed so much time. It's me who is truly sorry for taking your time and effort.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-29 01:55 -0800 |
| Message-ID | <ded05c4e-af42-4b8e-bc90-e3aa13d30c58@googlegroups.com> |
| In reply to | #100511 |
On Thursday, December 29, 2016 at 11:53:29 AM UTC+3, Barry Schwarz wrote:
> On Wed, 28 Dec 2016 23:16:55 -0800 (PST), Alla _
> <modelling.data@gmail.com> wrote:
>
> >On Wednesday, December 28, 2016 at 10:57:24 PM UTC+3, Manfred wrote:
> >> On 12/28/2016 7:11 PM, Alla _ wrote:
> >> > On Tuesday, December 27, 2016 at 9:56:54 PM UTC+3, Barry Schwarz wrote:
> >> <snip>
> ><snip>
> >> <snip>
> >> Now, this. The function has a bug and an important design flaw.
> >> I'll describe the the bug later at its point, and the flaw here:
> >> You are using 4 (four) different variables to represent the same program
> >> element, i.e. the line terminator, namely:
> >> - index
> >> - found_r
> >> - found_n
> >> - found_char
> >> Isn't it overcomplicating things? Obviously it requires much more effort
> >> (and a mistake is easier to make) to manage four variables that one!
> >> > /** Find the newline character **/
> >> > bool found_newline(char *buffer, size_t *index)
> >> > {
> >> > char *found_r = NULL;
> >> > char *found_n = NULL;
> >> > char *found_char = NULL;
> >> > const char newline_r = '\r';
> >> > const char newline_n = '\n';
> >> >
> >> > //Check for CR or LF
> >> This logic works, but you see here already that instead of using
> >> found_r, found_n and found_char you could use one variable for all of
> >> them, and if you did so...
> >That's what I can't see; I have no idea how to use only one
> >variable if I need to find either CR or LF at the end of the line.
> >How can that be only one variable?
>
> Well, if you used strpbrk, it would find the first occurrence of any
> set of characters you specify. You would be left with a single
> pointer to that character regardless of which one it was.
>
> But even that is unnecessary. Correct me if I'm wrong but the whole
> purpose of this limited program you have been laboring over for weeks
> is to place a terminal '\0' after the last digit in your input line.
> You don't really care what follows the last digit. You have made some
> assumptions that there might be 0 or more commas, 0 or 1 CRs, and 1
> NL. You don't need any of these assumptions. If you use strlen to
> find the end of the string, then back track until you find a digit,
> and finally substitute a '\0' for the character immediately after the
> digit, you will have achieved your goal. Notice that this works
> regardless of the how many commas, CRs, or NLs follow the last digit.
>
> And for completeness, if some of your lines end in valid non-numeric
> fields, instead of looking for a digit use isalnum declared in ctype.h
> to find the last "valid" character.
Please, take a look at this version. I don't need any non-numeric characters
after digital ones, therefore I do not use isalnum here.
I now intend to use this version in my values converting function. Is it all right?
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <string.h>
#include <stdbool.h>
#define BUFFER_SIZE 100
#define INCOME_STATEMENT "../files/income_test.csv"
bool get_line (FILE *input_file);
bool unprintable(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] : INCOME_STATEMENT;
FILE *fp = fopen(data_file, "r");
if ( fp )
{
if( !get_line(fp) )
{
puts("Reading csv file failed");
return EXIT_FAILURE;
}
fclose(fp);
return EXIT_SUCCESS;
}
//Couldn't open the file
else
{
perror(data_file);
}
return EXIT_FAILURE;
}
/** Function to read and process the data
from the file line by line
**/
bool get_line (FILE *input_file)
{
char buffer[BUFFER_SIZE] = "";
size_t line = 0;
size_t index;
//Read each line from the file, store in the buffer
while(fgets(buffer, sizeof(buffer), input_file) != NULL)
{
line++;
//DEBUG
puts("*****************************");
printf("Buffer beg:: %s\n", buffer);
index = strlen(buffer) - 1;
/* Finish the buffer at the last digit
in the line */
while(!isdigit(buffer[index]))
index--;
buffer[index+1] = '\0';
/* Check for any unprintable characters
within the line */
if(unprintable(buffer))
{
puts("CSV file contains unprintable characters");
puts("Please, correct the file and try again");
return false;
}
printf("Buffer end:: %s\n", buffer);
}
if (ferror(input_file))
{
puts("Something went wrong with the provided file\n");
return false;
}
return true;
}
/** Find unprintable characters in array
other than LF and CR
**/
bool unprintable(char *buffer)
{
while(*buffer != '\0')
{
if(!isprint(*buffer))
return true;
buffer++;
}
return false;
}
[toc] | [prev] | [next] | [standalone]
Page 5 of 13 — ← Prev page 1 … 3 4 [5] 6 7 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web