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 1 of 13 [1] 2 3 … 13 Next page →
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-26 00:31 -0800 |
| Subject | Reading lines from a file, eliminating CR and LF |
| Message-ID | <db0a37d6-520a-48c9-8f29-4c153e73d073@googlegroups.com> |
Hello!
Please, take a look at the small program that reads each line from
a csv file, checks if there are newlines, and/or carriage returns, and
other unprintable characters. The program puts '\0' at the place
of CR or LF, depending which one has lower address value; and
terminates if any other unprintable characters are found in the line.
Is it correct in terms of structure, logic and implementation? I don't
get any errors from compiler, nor do I see any problems in the output.
Input:
Years,2011,2012,2013,2014,2015
Sales,1062,1252,1587,1934,2519
Cost of Goods Sold,654,814,1009,1190,1499
Gross Profit,408,438,578,744,1020
"Selling, General, and Admin Exp",254,271,364,454,576
Operating Income before Depr,154,167,214,290,444
Depreciation and Amortization,25,31,38,52,70
Operating Profit,129,136,176,238,374
Interest Expense,4,3,3,1,4
Other Gains and Losses,0,7,10,0,-1
Pretax Income,125,126,163,237,371
Income Tax Expense,55,52,65,92,141
Net Income,70,74,98,145,230
Output (part):
*****************************
Buffer beg:: Years,2011,2012,2013,2014,2015,
The CR is not found
Buffer_n[30]:: Years,2011,2012,2013,2014,2015%
Buffer ends at [30]:: Years,2011,2012,2013,2014,2015
*****************************
Buffer beg:: Sales,1062,1252,1587,1934,2519,
The CR is not found
Buffer_n[30]:: Sales,1062,1252,1587,1934,2519%
Buffer ends at [30]:: Sales,1062,1252,1587,1934,2519
*****************************
Buffer beg:: Cost of Goods Sold,654,814,1009,1190,1499,
Buffer_r[41]:: Cost of Goods Sold,654,814,1009,1190,1499&
Buffer_n[42]:: Cost of Goods Sold,654,814,1009,1190,1499&%
Buffer ends at [41]:: Cost of Goods Sold,654,814,1009,1190,1499
*****************************
Buffer beg:: Gross Profit,408,438,578,744,1020,
Buffer_r[35]:: Gross Profit,408,438,578,744,1020&
Buffer_n[36]:: Gross Profit,408,438,578,744,1020&%
Buffer ends at [35]:: Gross Profit,408,438,578,744,1020
*****************************
Program:
#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 find_cr(char *buffer, size_t *index_r);
bool find_lf(char *buffer, size_t *index_n);
int main(int argc, char *argv[])
{
//Check for correct number of arguments
if(argc > 2)
{
fputs("Sorry, the program processes only one file.\n", stderr);
return EXIT_FAILURE;
}
//Determine a file to use
const char *data_file = (argc == 2)? argv[1] : 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_n, index_r;
//Read each line from the file, store in the buffer
while(fgets(buffer, sizeof(buffer), input_file) != NULL)
{
line++;
puts("*****************************");
printf("Buffer beg:: %s\n", buffer);
//If CR is found, its index is less than LF index
if (find_cr(buffer, &index_r) && find_lf(buffer, &index_n))
{
//Double check the CR index < LF index
if(index_r < index_n)
{
buffer[index_r - 1] = '\0';
printf("Buffer ends at [%li]:: %s\n", index_r-1, buffer);
}
}
else if(find_lf(buffer, &index_n))
{
buffer[index_n - 1] = '\0';
printf("Buffer ends at [%li]:: %s\n", index_n-1, buffer);
}
if(unprintable(buffer))
{
puts("CSV file contains unprintable characters");
puts("Please, correct the file and try again");
return false;
}
}
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 CR at the end of the line **/
bool find_cr(char *buffer, size_t *index_r)
{
const char newline_r = '\r';
char *found_r = strchr(buffer, newline_r);
if(found_r != NULL)
{
*index_r = found_r - buffer;
//If array is empty
if(*index_r == 0)
{
buffer[*index_r] = '\0';
printf("Buffer is empty; please, check the input data\n");
return false;
}
//DEBUG
buffer[*index_r-1] = '&';
printf("Buffer_r[%zu]:: %s\n", *index_r-1, buffer);
return true;
}
else
puts("The CR is not found");
return false;
}
/** Find LF at the end of the line **/
bool find_lf(char *buffer, size_t *index_n)
{
const char newline_n = '\n';
char *found_n = strchr(buffer, newline_n);
if(found_n != NULL)
{
*index_n = found_n - buffer;
//If array is empty
if(*index_n == 0)
{
buffer[*index_n] = '\0';
printf("Buffer is empty; please, check the input data\n");
return false;
}
//DEBUG
buffer[*index_n-1] = '%';
printf("Buffer_n[%zu]:: %s\n", *index_n-1, buffer);
return true;
}
else
puts("The LF is not found");
return false;
}
Thank you!
[toc] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2016-12-26 01:19 -0800 |
| Message-ID | <ojn16c12bln627vu9vkq6uj8qkdjjms97p@4ax.com> |
| In reply to | #100280 |
On Mon, 26 Dec 2016 00:31:11 -0800 (PST), Alla _ <modelling.data@gmail.com> wrote: >Please, take a look at the small program that reads each line from >a csv file, checks if there are newlines, and/or carriage returns, and >other unprintable characters. The program puts '\0' at the place >of CR or LF, depending which one has lower address value; and >terminates if any other unprintable characters are found in the line. You get points for addressing a single aspect of the problem in contrast to your previous attempts to solve the whole thing all at once. >Is it correct in terms of structure, logic and implementation? I don't >get any errors from compiler, nor do I see any problems in the output. The output not matching the input seems like a problem to me. >Input: > >Years,2011,2012,2013,2014,2015 >Sales,1062,1252,1587,1934,2519 >Cost of Goods Sold,654,814,1009,1190,1499 > Gross Profit,408,438,578,744,1020 >"Selling, General, and Admin Exp",254,271,364,454,576 > Operating Income before Depr,154,167,214,290,444 >Depreciation and Amortization,25,31,38,52,70 > Operating Profit,129,136,176,238,374 >Interest Expense,4,3,3,1,4 >Other Gains and Losses,0,7,10,0,-1 > Pretax Income,125,126,163,237,371 >Income Tax Expense,55,52,65,92,141 > Net Income,70,74,98,145,230 > >Output (part): >***************************** >Buffer beg:: Years,2011,2012,2013,2014,2015, Where did that terminal comma come from? >The CR is not found >Buffer_n[30]:: Years,2011,2012,2013,2014,2015% > >Buffer ends at [30]:: Years,2011,2012,2013,2014,2015 Given that your data has no '\r', you scan each line a minimum of 3 times. It's not exactly an error but it certainly is inefficient and unnecessary. You should be doing some analysis and design before rushing to type in code. -- Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-26 02:25 -0800 |
| Message-ID | <a4c40717-1257-4886-991b-d4d20ae2c7f3@googlegroups.com> |
| In reply to | #100281 |
On Monday, December 26, 2016 at 12:19:54 PM UTC+3, Barry Schwarz wrote:
> On Mon, 26 Dec 2016 00:31:11 -0800 (PST), Alla _
> <modelling.data@gmail.com> wrote:
>
> >Please, take a look at the small program that reads each line from
> >a csv file, checks if there are newlines, and/or carriage returns, and
> >other unprintable characters. The program puts '\0' at the place
> >of CR or LF, depending which one has lower address value; and
> >terminates if any other unprintable characters are found in the line.
>
> You get points for addressing a single aspect of the problem in
> contrast to your previous attempts to solve the whole thing all at
> once.
>
Thank you, though I did address each issue separately before
combining - I simply didn't show all attempts here not to inundate
the group with all those pieces of code and thus not to vex everyone;
but it turned out to be the opposite - I do cause much more irritation when
I post larger pieces I try to come up with myself upon testing smaller
ones on my own. Given lack of skill, my tests lie to me.
> >Is it correct in terms of structure, logic and implementation? I don't
> >get any errors from compiler, nor do I see any problems in the output.
>
> The output not matching the input seems like a problem to me.
>
I showed not the input I have processed with the program: I have two
csv files, one of which is has more additional empty fields than the other.
Sorry for constantly mixing those files.
> >The CR is not found
> >Buffer_n[30]:: Years,2011,2012,2013,2014,2015%
> >
> >Buffer ends at [30]:: Years,2011,2012,2013,2014,2015
>
> Given that your data has no '\r', you scan each line a minimum of 3
> times. It's not exactly an error but it certainly is inefficient and
> unnecessary. You should be doing some analysis and design before
> rushing to type in code.
>
Oh, I do - I never start coding before I have the concept on paper;
I can't imaging writing any code without the script at hand.
Please, take a look at the while loop, which makes only two calls
to functions to scan the line for \r, and only if that is not found, it
scans the line for \n. But with this approach I have to be sure
that, if \r exists, it always comes before \n. Is it a correct assumption,
and shouldn't I always double check?
//Read each line from the file, store in the buffer
while(fgets(buffer, sizeof(buffer), input_file) != NULL)
{
line++;
puts("*****************************");
printf("Buffer beg:: %s\n", buffer);
//If CR is found, its index is less than LF index
if (find_cr(buffer, &index_r))
{
buffer[index_r - 1] = '\0';
printf("Buffer ends at [%li]:: %s\n", index_r-1, buffer);
}
else if (find_lf(buffer, &index_n))
{
buffer[index_n - 1] = '\0';
printf("Buffer ends at [%li]:: %s\n", index_n-1, buffer);
}
if(unprintable(buffer))
{
puts("CSV file contains unprintable characters other than CR and LF");
puts("Please, correct the file and try again");
return false;
}
}
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2016-12-26 14:04 -0800 |
| Message-ID | <c2436ctnv57ivs6gc60mpi2rlrqvuf2bjd@4ax.com> |
| In reply to | #100282 |
On Mon, 26 Dec 2016 02:25:11 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:
>On Monday, December 26, 2016 at 12:19:54 PM UTC+3, Barry Schwarz wrote:
<snip>
>> The output not matching the input seems like a problem to me.
>>
>I showed not the input I have processed with the program: I have two
>csv files, one of which is has more additional empty fields than the other.
>Sorry for constantly mixing those files.
Our attempts to help you are not going to bear fruit if we don't know
which program you are executing or which data you are processing.
>> Given that your data has no '\r', you scan each line a minimum of 3
>> times. It's not exactly an error but it certainly is inefficient and
>> unnecessary. You should be doing some analysis and design before
>> rushing to type in code.
>>
>Oh, I do - I never start coding before I have the concept on paper;
> I can't imaging writing any code without the script at hand.
>Please, take a look at the while loop, which makes only two calls
>to functions to scan the line for \r, and only if that is not found, it
>scans the line for \n. But with this approach I have to be sure
>that, if \r exists, it always comes before \n. Is it a correct assumption,
>and shouldn't I always double check?
Why do you care which one comes first? You have decide that you will
shorten the string at the first point either occurs. Standard
function strpbrk will identify that point with only a single scan of
the line.
>//Read each line from the file, store in the buffer
> while(fgets(buffer, sizeof(buffer), input_file) != NULL)
> {
> line++;
> puts("*****************************");
> printf("Buffer beg:: %s\n", buffer);
>
> //If CR is found, its index is less than LF index
This may be true for your current system but what makes you think it
is true for all systems or even for the next time you make any update
to your system?
> if (find_cr(buffer, &index_r))
> {
> buffer[index_r - 1] = '\0';
> printf("Buffer ends at [%li]:: %s\n", index_r-1, buffer);
In your last post that had the complete function, index_r had type
size_t. %li is not the correct format for a size_t. Obviously this
is not the same program that started this thread. What else have you
changed that you have not told us about?
> }
> else if (find_lf(buffer, &index_n))
> {
> buffer[index_n - 1] = '\0';
> printf("Buffer ends at [%li]:: %s\n", index_n-1, buffer);
> }
>
> if(unprintable(buffer))
> {
> puts("CSV file contains unprintable characters other than CR and LF");
> puts("Please, correct the file and try again");
> return false;
> }
> }
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-26 12:04 +0000 |
| Message-ID | <o3r0ua$c6m$1@dont-email.me> |
| In reply to | #100280 |
On 26/12/2016 08:31, Alla _ wrote: > Is it correct in terms of structure, logic and implementation? I don't > get any errors from compiler, nor do I see any problems in the output. > > Input: > > Years,2011,2012,2013,2014,2015 > Sales,1062,1252,1587,1934,2519 > Cost of Goods Sold,654,814,1009,1190,1499 > Gross Profit,408,438,578,744,1020 > "Selling, General, and Admin Exp",254,271,364,454,576 > Operating Income before Depr,154,167,214,290,444 > Depreciation and Amortization,25,31,38,52,70 > Operating Profit,129,136,176,238,374 > Interest Expense,4,3,3,1,4 > Other Gains and Losses,0,7,10,0,-1 > Pretax Income,125,126,163,237,371 > Income Tax Expense,55,52,65,92,141 > Net Income,70,74,98,145,230 > > Output (part): > ***************************** > Buffer beg:: Years,2011,2012,2013,2014,2015, > > The CR is not found > Buffer_n[30]:: Years,2011,2012,2013,2014,2015% > > Buffer ends at [30]:: Years,2011,2012,2013,2014,2015 What OS did you run it on? What was exactly in the input; does it contain CR/LF or just LF? On Windows, CR/LF is converted to LF by the C system. However, I get the same results on Windows which uses CR/LF in the input, and on Linux which uses LF: ***************************** Buffer beg:: Years,2011,2012,2013,2014,2015 The CR is not found Buffer_n[29]:: Years,2011,2012,2013,2014,201% Buffer ends at [29]:: Years,2011,2012,2013,2014,201 ***************************** That probably figures because in both cases, only LF-endings are being seen in the program logic. But this is different from your output. (I seem to remember you're on a MAC; in that case I'm not sure what line endings are expected. That dump program that was discussed will tell you. Even the simplest one that reads the first 50 characters from a file and outputs them as 50 integers.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-26 05:49 -0800 |
| Message-ID | <049b5f2e-d51a-49f3-8681-47771084c82d@googlegroups.com> |
| In reply to | #100284 |
<snip> > What OS did you run it on? What was exactly in the input; does it > contain CR/LF or just LF? > Mac OS, but I do have huge problems with csv files. See below too. > On Windows, CR/LF is converted to LF by the C system. However, I get the > same results on Windows which uses CR/LF in the input, and on Linux > which uses LF: > > ***************************** > Buffer beg:: Years,2011,2012,2013,2014,2015 > > The CR is not found > Buffer_n[29]:: Years,2011,2012,2013,2014,201% > > Buffer ends at [29]:: Years,2011,2012,2013,2014,201 > ***************************** > > That probably figures because in both cases, only LF-endings are being > seen in the program logic. Why so? I don't understand ( If there is no \r, then the program tests for \n. > > But this is different from your output. (I seem to remember you're on a > MAC; in that case I'm not sure what line endings are expected. That dump > program that was discussed will tell you. Even the simplest one that > reads the first 50 characters from a file and outputs them as 50 integers.) Here is the problem: 1) I truly need help to understand how to avoid inefficiency Barry has pointed out; I don't see the good way out; 2) given two different csv files (one, converted by me from excel file on my system, another one - a normal csv file, but it still ends with \r\n). This same program produces different results for both, and the main problem I see is - indexing. And I don't understand how can that be. I am very confused, and honestly this whole csv thing frustrates me a lot, has caused so much trouble and bogged me down significantly. (1) First version with a normal input (see below) For example, the first line ends has \r at ...ce, and the buffer starts at ...b0, so ...ce - ...b0 does indeed equal 30. But every array starts with 0 index, so if I want to find the 30th position in the array I need to use buffer[29], and that is somehow the value of the last digit, and buffer[30] has the \r value. How can that be? First version of input (good csv but with \r\n at the end of each line) (I show 4 first lines): Years,2011,2012,2013,2014,2015 Sales,1062,1252,1587,1934,2519 Cost of Goods Sold,654,814,1009,1190,1499 Gross Profit,408,438,578,744,1020 Output (only first two lines): ***************************** Buffer beg:: Years,2011,2012,2013,2014,2015 found_r 0x7fff5b6f7ace, buffer 0x7fff5b6f7ab0 index_r = 30 Buffer_r[29]:: Years,2011,2012,2013,2014,201& found_r 0x7fff5b6f7acf, buffer 0x7fff5b6f7ab0 index_n = 31 Buffer_n[30]:: Years,2011,2012,2013,2014,201&% Buffer ends at [29]:: Years,2011,2012,2013,2014,201 ***************************** Buffer beg:: Sales,1062,1252,1587,1934,2519 found_r 0x7fff5b6f7ace, buffer 0x7fff5b6f7ab0 index_r = 30 Buffer_r[29]:: Sales,1062,1252,1587,1934,251& found_r 0x7fff5b6f7acf, buffer 0x7fff5b6f7ab0 index_n = 31 Buffer_n[30]:: Sales,1062,1252,1587,1934,251&% Buffer ends at [29]:: Sales,1062,1252,1587,1934,251 ***************************** (2) Second version with another input I don't have such indexing problems at all. All values are computed correctly: if I get the index_n = 31, then the \n is indeed at buffer[30], i.e. buffer[index_n-1]. Input (first 4 lines): Years,2011,2012,2013,2014,2015, Sales,1062,1252,1587,1934,2519, Cost of Goods Sold,654,814,1009,1190,1499, Gross Profit,408,438,578,744,1020, Output: ***************************** Buffer beg:: Years,2011,2012,2013,2014,2015, The CR is not found found_n 0x7fff5a83daef, buffer 0x7fff5a83dad0 index_n = 31 Buffer_n[30]:: Years,2011,2012,2013,2014,2015% Buffer ends at [30]:: Years,2011,2012,2013,2014,2015 ***************************** Buffer beg:: Sales,1062,1252,1587,1934,2519, The CR is not found found_n 0x7fff5a83daef, buffer 0x7fff5a83dad0 index_n = 31 Buffer_n[30]:: Sales,1062,1252,1587,1934,2519% Buffer ends at [30]:: Sales,1062,1252,1587,1934,2519 ***************************** Buffer beg:: Cost of Goods Sold,654,814,1009,1190,1499, found_r 0x7fff5a83dafa, buffer 0x7fff5a83dad0 index_r = 42 Buffer_r[41]:: Cost of Goods Sold,654,814,1009,1190,1499& found_n 0x7fff5a83dafb, buffer 0x7fff5a83dad0 index_n = 43 Buffer_n[42]:: Cost of Goods Sold,654,814,1009,1190,1499&% Buffer ends at [41]:: Cost of Goods Sold,654,814,1009,1190,1499 ***************************** Thank you!
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-26 15:20 +0000 |
| Message-ID | <o3rccu$grt$1@dont-email.me> |
| In reply to | #100285 |
On 26/12/2016 13:49, Alla _ wrote:
> <snip>
>> What OS did you run it on? What was exactly in the input; does it
>> contain CR/LF or just LF?
>>
> Mac OS, but I do have huge problems with csv files. See below too.
>> On Windows, CR/LF is converted to LF by the C system. However, I get the
>> same results on Windows which uses CR/LF in the input, and on Linux
>> which uses LF:
>>
>> *****************************
>> Buffer beg:: Years,2011,2012,2013,2014,2015
>>
>> The CR is not found
>> Buffer_n[29]:: Years,2011,2012,2013,2014,201%
>>
>> Buffer ends at [29]:: Years,2011,2012,2013,2014,201
>> *****************************
>>
>> That probably figures because in both cases, only LF-endings are being
>> seen in the program logic.
> Why so? I don't understand ( If there is no \r, then the program tests for \n.
On Windows, the two-line file:
ABC
DEF
is stored as:
A B C CR LF D E F CR LF
But is read by C file functions (for files opened in text mode) as the
sequence:
A B C LF D E F LF
On Linux, it is stored as:
A B C LF D E F LF
and read by C as the same sequence, identically to how C reads it under
Windows. So the results of your program should be the same, as they
were. Yet your results were different!
> Here is the problem:
> 1) I truly need help to understand how to avoid inefficiency Barry has pointed out;
> I don't see the good way out;
There's that too but I was intrigued as to how you got your results. No
point in being efficient if there is something wrong!
> 2) given two different csv files (one, converted by me from excel file
I'll have a look at this later. But I suggest you shorten the input
files to just two lines, or maybe even one, enough to show the
discrepancy (then the output doesn't scroll off the screen making it
harder to compare).
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-26 07:31 -0800 |
| Message-ID | <38f3e06f-8995-425d-91c9-241ddd3478f4@googlegroups.com> |
| In reply to | #100288 |
On Monday, December 26, 2016 at 6:20:30 PM UTC+3, Bart wrote: > On 26/12/2016 13:49, Alla _ wrote: > > <snip> > >> What OS did you run it on? What was exactly in the input; does it > >> contain CR/LF or just LF? > >> <snip> >But I suggest you shorten the input > files to just two lines, or maybe even one, enough to show the > discrepancy (then the output doesn't scroll off the screen making it > harder to compare). > Yes, I have done that too. I am so confused by these results. Thank you for trying to help out. > -- > Bartc
[toc] | [prev] | [next] | [standalone]
| From | Manfred <mx2927@gmail.com> |
|---|---|
| Date | 2016-12-26 16:44 +0100 |
| Message-ID | <o3rds7$ojp$1@gioia.aioe.org> |
| In reply to | #100288 |
On 12/26/2016 04:20 PM, BartC wrote:
>
> On Windows, the two-line file:
>
> ABC
> DEF
>
> is stored as:
>
> A B C CR LF D E F CR LF
>
> But is read by C file functions (for files opened in text mode) as the
> sequence:
>
> A B C LF D E F LF
This is only true if you open the file in text mode, but only Microsoft
compilers have the explicit text mode flag ("t" for fopen) - or anyway
at least the "t" flag is not part of the POSIX standard (I made the same
mixup earlier)
>
> On Linux, it is stored as:
>
> A B C LF D E F LF
>
> and read by C as the same sequence, identically to how C reads it under
> Windows. So the results of your program should be the same, as they
> were. Yet your results were different!
Her file is appearently generated by MS-Excel with CRLF endings, and
this is why she is getting the pair inside her buffer.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-26 08:00 -0800 |
| Message-ID | <f11bc519-fe8d-4716-8f0c-a55fa630d7e5@googlegroups.com> |
| In reply to | #100291 |
On Monday, December 26, 2016 at 6:44:15 PM UTC+3, Manfred wrote:
> On 12/26/2016 04:20 PM, BartC wrote:
> >
> > On Windows, the two-line file:
> >
> > ABC
> > DEF
> >
> > is stored as:
> >
> > A B C CR LF D E F CR LF
> >
> > But is read by C file functions (for files opened in text mode) as the
> > sequence:
> >
> > A B C LF D E F LF
>
> This is only true if you open the file in text mode, but only Microsoft
> compilers have the explicit text mode flag ("t" for fopen) - or anyway
> at least the "t" flag is not part of the POSIX standard (I made the same
> mixup earlier)
>
> >
> > On Linux, it is stored as:
> >
> > A B C LF D E F LF
> >
> > and read by C as the same sequence, identically to how C reads it under
> > Windows. So the results of your program should be the same, as they
> > were. Yet your results were different!
> Her file is appearently generated by MS-Excel with CRLF endings, and
> this is why she is getting the pair inside her buffer.
But it is not the question about the pair. I try to take out any such endings
with this code. The question is why I get such different results and why
indexing changes so drastically. What is wrong with my indexing?
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-26 17:43 +0000 |
| Message-ID | <o3rkp9$cp8$1@dont-email.me> |
| In reply to | #100291 |
On 26/12/2016 15:44, Manfred wrote:
> On 12/26/2016 04:20 PM, BartC wrote:
>>
>> On Windows, the two-line file:
>>
>> ABC
>> DEF
>>
>> is stored as:
>>
>> A B C CR LF D E F CR LF
>>
>> But is read by C file functions (for files opened in text mode) as the
>> sequence:
>>
>> A B C LF D E F LF
>
> This is only true if you open the file in text mode, but only Microsoft
> compilers have the explicit text mode flag ("t" for fopen) - or anyway
> at least the "t" flag is not part of the POSIX standard (I made the same
> mixup earlier)
>
>>
>> On Linux, it is stored as:
>>
>> A B C LF D E F LF
>>
>> and read by C as the same sequence, identically to how C reads it under
>> Windows. So the results of your program should be the same, as they
>> were. Yet your results were different!
> Her file is appearently generated by MS-Excel with CRLF endings, and
> this is why she is getting the pair inside her buffer.
>
If I try a CRLF file in Linux, I get this
*****************************
Buffer beg:: Years,2011,2012,2013,2014,2015
Buffer_r[29]:: Years,2011,2012,2013,2014,201&
Buffer_n[30]:: Years,2011,2012,2013,2014,201&%
Buffer ends at [29]:: Years,2011,2012,2013,2014,201
which is different yet again from both my results and the OP's.
(And the line spacing suggests there are extra newlines on the output; a
dump shows CR LF LF is output. Sp perhaps anything printed out by the
program should be displayed by code such as that below, rather than via
an "%s" format which hides the control characters.
Eg:
printf ("S= %s\n",s);
becomes:
printf ("S="); showstringln(s)
-----------------------------------
void showstringln(char* s) {
showstring(s);
puts("");
}
void showstring(char* s) {
char c;
while ((c=*s++)) {
if (c>=' ' && c<127)
printf("%c",c);
else if (c=='\r')
printf("\\r");
else if (c=='\n')
printf("\\n");
else if (c=='\t')
printf("\\t");
else if (c=='\b')
printf("\\b");
else if (c=='\\')
printf("\\");
else
printf("\\x%02X",c);
}
}
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-26 12:03 -0800 |
| Message-ID | <lno9zy8nm0.fsf@kst-u.example.com> |
| In reply to | #100291 |
Manfred <mx2927@gmail.com> writes:
> On 12/26/2016 04:20 PM, BartC wrote:
>>
>> On Windows, the two-line file:
>>
>> ABC
>> DEF
>>
>> is stored as:
>>
>> A B C CR LF D E F CR LF
>>
>> But is read by C file functions (for files opened in text mode) as the
>> sequence:
>>
>> A B C LF D E F LF
>
> This is only true if you open the file in text mode, but only Microsoft
> compilers have the explicit text mode flag ("t" for fopen) - or anyway
> at least the "t" flag is not part of the POSIX standard (I made the same
> mixup earlier)
POSIX doesn't have the "t" flag because it's not necessary.
If you call fopen() with a mode argument of "r", it opens the file
in text mode. With a mode argument of "rb", it uses binary mode.
Microsoft adds a "t" flag because they provide a non-standard
_set_fmode function that causes "r" to open files in binary mode;
you then have to use "rt" to use text mode. (You can also set a
global variable called _fmode.)
fopen:
https://msdn.microsoft.com/en-us/library/yeby3zcb.aspx
text and binary modes:
https://msdn.microsoft.com/en-us/library/ktss1a9b.aspx
>> On Linux, it is stored as:
>>
>> A B C LF D E F LF
>>
>> and read by C as the same sequence, identically to how C reads it under
>> Windows. So the results of your program should be the same, as they
>> were. Yet your results were different!
> Her file is appearently generated by MS-Excel with CRLF endings, and
> this is why she is getting the pair inside her buffer.
Apparently MS Excel on MacOS can also create CSV files with CR line
endings (the format used by pre-OSX MacOS). If you want to deal with
such files as text, it's probably best to translate the CR characters to
LF before feeding the file to your program.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-27 23:56 -0800 |
| Message-ID | <02d8ff38-24bb-4d4d-820c-09f2ed6d6650@googlegroups.com> |
| In reply to | #100306 |
On Monday, December 26, 2016 at 11:01:58 PM UTC+3, Keith Thompson wrote: > Manfred <mx2927@gmail.com> writes: > > On 12/26/2016 04:20 PM, BartC wrote: > >> <snip> > Apparently MS Excel on MacOS can also create CSV files with CR line > endings (the format used by pre-OSX MacOS). If you want to deal with > such files as text, it's probably best to translate the CR characters to > LF before feeding the file to your program. > What's truly surprising is that I get two first lines of each csv file ending with only one newline character '\n', and the rest 10 lines ending with CRLF together. Again, it is not a C issue, so I can't allow myself to continue asking these questions here, but it is still an interesting issue.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-28 09:33 +0000 |
| Message-ID | <o400qc$o3j$1@dont-email.me> |
| In reply to | #100397 |
On 28/12/16 07:56, Alla _ wrote: > On Monday, December 26, 2016 at 11:01:58 PM UTC+3, Keith Thompson wrote: >> Manfred <mx2927@gmail.com> writes: >>> On 12/26/2016 04:20 PM, BartC wrote: >>>> > <snip> >> Apparently MS Excel on MacOS can also create CSV files with CR line >> endings (the format used by pre-OSX MacOS). If you want to deal with >> such files as text, it's probably best to translate the CR characters to >> LF before feeding the file to your program. >> > What's truly surprising is that I get two first lines of each csv file ending > with only one newline character '\n', and the rest 10 lines ending with > CRLF together. Again, it is not a C issue, so I can't allow myself to > continue asking these questions here, but it is still an interesting issue. It is an issue for which I provided a complete (and really easy) solution weeks ago. So I don't see how it continues to be interesting. Did you even bother to look at the solution I posted to your \r problem? -- 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 | Manfred <mx2927@gmail.com> |
|---|---|
| Date | 2016-12-26 17:06 +0100 |
| Message-ID | <o3rf6j$qcs$1@gioia.aioe.org> |
| In reply to | #100280 |
On 12/26/2016 09:31 AM, Alla _ wrote:
> Output (part):
> *****************************
> Buffer beg:: Years,2011,2012,2013,2014,2015,
Note the trailing comma is still there, but this is not related with
your CR/LF problem, so let's park it for now, except that you need to
handle these two issues separately: trailing comma /and/ CR/LF line
endings. In the code below you are accidentally mixing these two issues up.
<snip>
> /** 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_n, index_r;
>
> //Read each line from the file, store in the buffer
> while(fgets(buffer, sizeof(buffer), input_file) != NULL)
> {
> line++;
> puts("*****************************");
> printf("Buffer beg:: %s\n", buffer);
>
What your intent is in the following lines is substantially:
as long as the last char in the line is CR or LF, then chop that
character off the line.
This could be coded in a much more straightforward (and less error
prone) way
> //If CR is found, its index is less than LF index
> if (find_cr(buffer, &index_r) && find_lf(buffer, &index_n))
> {
> //Double check the CR index < LF index
> if(index_r < index_n)
> {
> buffer[index_r - 1] = '\0';
Here you are chopping off the character /before/ CR - which happens to
be the trailing comma!
> printf("Buffer ends at [%li]:: %s\n", index_r-1, buffer);
> }
> }
> else if(find_lf(buffer, &index_n))
> {
> buffer[index_n - 1] = '\0';
Here you are chopping off the character /before/ LF
> printf("Buffer ends at [%li]:: %s\n", index_n-1, buffer);
> }
>
The following is an extra check not strictly related with CR/LF, anyway
it does no harm here
> if(unprintable(buffer))
> {
> puts("CSV file contains unprintable characters");
> puts("Please, correct the file and try again");
> return false;
> }
<snip>
Two comments on the following 2 functions:
1) Decomposing code into functions of decreasing complexity is good
practice, and your intent here is good; at the same time it looks to me
that the following functions are a bit overdone. As said above, this
logic could be coded in a much simpler way.
Anyway, this is not, strictly speaking, a mistake.
2) The two functions are doing substantially the same job, only
difference being the search for \r or \n. If you want to keep this
function, instead of replicating the code, it would be better to make
this a parameter of a single function.
> /** Find CR at the end of the line **/
> bool find_cr(char *buffer, size_t *index_r)
> {
> const char newline_r = '\r';
> char *found_r = strchr(buffer, newline_r);
> if(found_r != NULL)
> {
> *index_r = found_r - buffer;
>
> //If array is empty
> if(*index_r == 0)
> {
> buffer[*index_r] = '\0';
> printf("Buffer is empty; please, check the input data\n");
> return false;
> }
> //DEBUG
Here you are marking the character /before/ the CR
> buffer[*index_r-1] = '&';
> printf("Buffer_r[%zu]:: %s\n", *index_r-1, buffer);
> return true;
> }
> else
> puts("The CR is not found");
> return false;
> }
>
> /** Find LF at the end of the line **/
> bool find_lf(char *buffer, size_t *index_n)
> {
> const char newline_n = '\n';
> char *found_n = strchr(buffer, newline_n);
> if(found_n != NULL)
> {
> *index_n = found_n - buffer;
>
> //If array is empty
> if(*index_n == 0)
> {
> buffer[*index_n] = '\0';
> printf("Buffer is empty; please, check the input data\n");
> return false;
> }
>
> //DEBUG
Here you are marking the character /before/ the CR
> buffer[*index_n-1] = '%';
> printf("Buffer_n[%zu]:: %s\n", *index_n-1, buffer);
> return true;
> }
> else
> puts("The LF is not found");
> return false;
> }
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-26 09:48 -0800 |
| Message-ID | <9a6e5204-d031-4070-88cb-8132072c5c68@googlegroups.com> |
| In reply to | #100296 |
On Monday, December 26, 2016 at 7:06:51 PM UTC+3, Manfred wrote:
> On 12/26/2016 09:31 AM, Alla _ wrote:
> > Output (part):
> > *****************************
> Here you are marking the character /before/ the CR
> > buffer[*index_n-1] = '%';
Yes, it turns out. But my question was exactly about this index:
why was incorrect, if all arrays are zero indexed; therefore,
if I have say 10 elements, to access the 10th element I do
array[9], not array[10], which will have '\0' values.
If this index were a value of the address, I would have understood
that, but this is an integer value, which represents the difference
between two addresses, i.e. how many steps need to be done
to reach from one point to another, and if all arrays are zero indexed,
then the value of the last step should be array[step-1] - sorry,
I am repeating myself.
> > printf("Buffer_n[%zu]:: %s\n", *index_n-1, buffer);
> > return true;
> > }
> > else
> > puts("The LF is not found");
> > return false;
> > }
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2016-12-26 19:03 +0100 |
| Message-ID | <o3rm1p$15cl$1@gioia.aioe.org> |
| In reply to | #100299 |
On 12/26/2016 6:48 PM, Alla _ wrote:
> On Monday, December 26, 2016 at 7:06:51 PM UTC+3, Manfred wrote:
>> Here you are marking the character /before/ the CR
>>> buffer[*index_n-1] = '%';
> Yes, it turns out. But my question was exactly about this index:
> why was incorrect, if all arrays are zero indexed; therefore,
> if I have say 10 elements, to access the 10th element I do
> array[9], not array[10],
Recall how you found out index_n in find_lf():
*index_n = found_n - buffer;
index_n is the difference between two pointers, so it is already
zero-based: if found_n points at the 10th element of buffer, then
found_n-buffer yields 9;
> which will have '\0' values.
> If this index were a value of the address, I would have understood
> that, but this is an integer value, which represents the difference
> between two addresses, i.e. how many steps need to be done
> to reach from one point to another, and if all arrays are zero indexed,
> then the value of the last step should be array[step-1] - sorry,
> I am repeating myself.
(I don't want to repeat myself either, but if the logic were coded in a
simpler way, there would have been less chance to make this mistake.)
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-26 10:39 -0800 |
| Message-ID | <7285df88-1603-4edb-abba-b9c5e4172d34@googlegroups.com> |
| In reply to | #100300 |
On Monday, December 26, 2016 at 9:03:46 PM UTC+3, Manfred wrote:
> On 12/26/2016 6:48 PM, Alla _ wrote:
> > On Monday, December 26, 2016 at 7:06:51 PM UTC+3, Manfred wrote:
> >> Here you are marking the character /before/ the CR
> >>> buffer[*index_n-1] = '%';
> > Yes, it turns out. But my question was exactly about this index:
> > why was incorrect, if all arrays are zero indexed; therefore,
> > if I have say 10 elements, to access the 10th element I do
> > array[9], not array[10],
> Recall how you found out index_n in find_lf():
> *index_n = found_n - buffer;
> index_n is the difference between two pointers, so it is already
> zero-based: if found_n points at the 10th element of buffer, then
> found_n-buffer yields 9;
I see. Indeed, as all addresses start with 0, hence the result accounts
for the zero. Thank you.
>
> > which will have '\0' values.
> > If this index were a value of the address, I would have understood
> > that, but this is an integer value, which represents the difference
> > between two addresses, i.e. how many steps need to be done
> > to reach from one point to another, and if all arrays are zero indexed,
> > then the value of the last step should be array[step-1] - sorry,
> > I am repeating myself.
>
> (I don't want to repeat myself either, but if the logic were coded in a
> simpler way, there would have been less chance to make this mistake.)
I should disagree here ) I have made this mistake not because my
code is too cluttered, but because, as you have correctly pointed out,
I missed the fact that I count the difference between two addresses,
and all addresses are zero based.
Please, take a look at this version. Is it better? Have I correctly understood
the notion of simplification?
I have also added the part that deletes any unwanted trailing commas.
Is it better now?
#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_char(char *buffer, size_t *index, const char *newline);
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;
const char newline_r = '\r';
const char newline_n = '\n';
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);
//If CR is found, its index is less than LF index
if (found_char(buffer, &index, &newline_r))
{
buffer[index] = '\0';
//DEBUG
printf("CR found; buffer ends at [%li]:: %s\n", index, buffer);
}
else if (found_char(buffer, &index, &newline_n))
{
buffer[index] = '\0';
//DEBUG
printf("LF found; buffer ends at [%li]:: %s\n", index, buffer);
}
//Delete any trailing commas
if(buffer[index-1] == ',')
{
index--;
while(!isdigit(buffer[index]) && buffer[index] == ',')
index--;
buffer[index+1] = '\0';
//DEBUG
printf("Comma found; buffer ends at [%li]:: %s\n", index+1, buffer);
}
//Check for any other unprintable characters
if(unprintable(buffer))
{
puts("CSV file contains unprintable characters");
puts("Please, correct the file and try again");
return false;
}
}
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 CR at the end of the line **/
bool found_char(char *buffer, size_t *index, const char *newline)
{
char *found = strchr(buffer, *newline);
if(found != NULL)
{
*index = found - buffer;
//DEBUG
printf("found %p, buffer %p\n", (void*)found, (void *) buffer);
printf("index = %li\n", *index);
//If array is empty
if(*index == 0)
{
buffer[*index] = '\0';
printf("Buffer is empty; please, check the input data\n");
return false;
}
//DEBUG
buffer[*index] = '&';
printf("Buffer [%zu]:: %s\n", *index, buffer);
return true;
}
else
puts("The newline character is not found");
return false;
}
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-26 19:49 +0000 |
| Message-ID | <o3rs56$55n$1@dont-email.me> |
| In reply to | #100302 |
On 26/12/2016 18:39, Alla _ wrote:
> //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);
>
> //If CR is found, its index is less than LF index
> if (found_char(buffer, &index, &newline_r))
> {
> buffer[index] = '\0';
> //DEBUG
> printf("CR found; buffer ends at [%li]:: %s\n", index, buffer);
> }
> else if (found_char(buffer, &index, &newline_n))
> {
> buffer[index] = '\0';
> //DEBUG
> printf("LF found; buffer ends at [%li]:: %s\n", index, buffer);
> }
Are these mutually exclusive? You might have CR /and/ LF. (When CRLF is
read in binary mode, or on a Linux-like system, or the file happens to
contain CRCRLF).
But it they are exclusive, then finding CR should be rare enough that it
might be better to search for LF first, otherwise most of the time it
will do a fruitless search for CR.
> //Delete any trailing commas
> if(buffer[index-1] == ',')
(Presumably index is set by found_char() to be the length of the string
in the buffer [or the offset of the first CR character?], and can't be
zero? I think you should define more clearly what index is at this point.)
> /** Find CR at the end of the line **/
> bool found_char(char *buffer, size_t *index, const char *newline)
> {
> char *found = strchr(buffer, *newline);
If you're only ever using the first character within the newline string,
you might as well just pass a char rather than a string.
It's not clear what the purpose of the program is. Is it to strip any
newline characters from the end of the line that has been read? In that
case just have a routine that does exactly that!
void stripnewline(char* line){...}
This can work by just writing the 0 terminator one or two characters
earlier. Unless you pass the length, then it can adjust that as well.
(For text read from text mode files, the end of the line will have:
* xxx LF In most cases
* xxx CRLF For Windows files read in binary mode, or Windows
files read on a non-Windows system
* xxx When the buffer is too small to contain the entire
line
* xxx CR The same CRLF example but the buffer is one char
too small to contain both CR and LF
* xxCRxxx LF/etc Rarely, files will have embedded CR unrelated to
newlines
There are probably other combinations, but I think these are the main
ones. When I read text files, I trim any consecutive combination of CR
and LF from the end of the line. If the line didn't end with LF, it was
probably truncated.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2016-12-26 20:56 +0100 |
| Message-ID | <o3rsm8$1g86$1@gioia.aioe.org> |
| In reply to | #100302 |
On 12/26/2016 7:39 PM, Alla _ wrote:
>> (I don't want to repeat myself either, but if the logic were coded in a
>> simpler way, there would have been less chance to make this mistake.)
>
> I should disagree here ) I have made this mistake not because my
> code is too cluttered, but because, as you have correctly pointed out,
> I missed the fact that I count the difference between two addresses,
> and all addresses are zero based.
Don't understand me wrong. I didn't say your code is too cluttered. I
said it is more complex than it could be, and so it is easier to make
this kind of mistakes.
> Please, take a look at this version. Is it better?
For one part - code replication - yes. See below. And (not to be
neglected) indexes seem right, so that part might work (I didn't run it)
Have I correctly understood
> the notion of simplification?
Now, this is a big statement. Simplification (more properly: complexity
management) is a huge subject (as part of it Richard Heathfield
mentioned earlier that functional decomposition is a skill, and he is
right), so well beyond what can be handled here.
Yet this tiny example shows (I think) some of its importance.
> I have also added the part that deletes any unwanted trailing commas.
> Is it better now?
The trailing comma is a valid element of the CSV file: it means that
there is a last field in the line which is an empty field. In your case
it happens to be unexpected, but I would not consider this as
"corrupted" input, so I would not handle it the way you do.
I mentioned earlier that you have to make a decision here (you are lucky
that you can decide what you want):
- either you consider any extra field to be invalid, and therefore you
fix the input file (in addition to having your program report that input
is invalid); I gave you some hint on how to fix the spreadsheet.
- or you allow the input lines to have additional fields after the ones
you need/expect, and therefore simply ignore them and stop scanning the
line after you successfully get the fields you need.
(I didn't compile or run the code, so I may have missed some)
<snip>
>
> /** 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;
> const char newline_r = '\r';
> const char newline_n = '\n';
> 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);
>
> //If CR is found, its index is less than LF index
See how this call does substantially the same job as strchr?
> if (found_char(buffer, &index, &newline_r))
> {
> buffer[index] = '\0';
> //DEBUG
> printf("CR found; buffer ends at [%li]:: %s\n", index, buffer);
> }
And this too
> else if (found_char(buffer, &index, &newline_n))
> {
> buffer[index] = '\0';
> //DEBUG
> printf("LF found; buffer ends at [%li]:: %s\n", index, buffer);
> }
>
<snip>
Good that you eliminated the code replication.
> /** Find CR at the end of the line **/
The newline argument points in fact to a single char, so why not making
it a char instead of a const char* ?
> bool found_char(char *buffer, size_t *index, const char *newline)
> {
> char *found = strchr(buffer, *newline);
> if(found != NULL)
> {
> *index = found - buffer;
> //DEBUG
> printf("found %p, buffer %p\n", (void*)found, (void *) buffer);
> printf("index = %li\n", *index);
> //If array is empty
> if(*index == 0)
> {
> buffer[*index] = '\0';
> printf("Buffer is empty; please, check the input data\n");
> return false;
> }
> //DEBUG
> buffer[*index] = '&';
> printf("Buffer [%zu]:: %s\n", *index, buffer);
> return true;
> }
> else
Just to mention this: no newline should not be an error condition: you
may have a line with no newline at the end of the file. Still such a
(last) line is a valid one.
(This was already mentioned by some else)
> puts("The newline character is not found");
> return false;
> }
[toc] | [prev] | [next] | [standalone]
Page 1 of 13 [1] 2 3 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web