Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #98254 > unrolled thread
| Started by | Alla _ <modelling.data@gmail.com> |
|---|---|
| First post | 2016-12-07 05:08 -0800 |
| Last post | 2016-12-10 13:49 -0800 |
| Articles | 20 on this page of 180 — 22 participants |
Back to article view | Back to comp.lang.c
while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 05:08 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 13:46 +0000
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 07:27 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 16:17 +0000
Re: while loop vs do while loop reading from the file issue Norbert_Paul <norbertpauls_spambin@yahoo.com> - 2016-12-07 14:54 +0100
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 07:29 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 17:20 +0000
Re: while loop vs do while loop reading from the file issue "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-12-08 01:24 +0800
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 22:51 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 07:30 +0000
Re: while loop vs do while loop reading from the file issue Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-07 12:45 -0500
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 17:50 +0000
Re: while loop vs do while loop reading from the file issue Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-07 12:56 -0500
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-07 11:09 -0800
Re: while loop vs do while loop reading from the file issue Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-07 14:38 -0500
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 23:29 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 07:35 +0000
Re: while loop vs do while loop reading from the file issue Manfred <noname@invalid.add> - 2016-12-08 16:57 +0100
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-10 03:45 -0800
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-09 01:08 -0800
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-09 01:30 -0800
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-09 01:50 -0800
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-10 02:34 -0800
Re: while loop vs do while loop reading from the file issue fir <profesor.fir@gmail.com> - 2016-12-10 03:18 -0800
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-10 07:43 -0800
Re: while loop vs do while loop reading from the file issue Manfred <noname@invalid.add> - 2016-12-10 18:21 +0100
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 10:08 +0000
Re: while loop vs do while loop reading from the file issue Manfred <noname@invalid.add> - 2016-12-09 19:19 +0100
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-10 03:56 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-10 12:39 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 14:58 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-10 16:01 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 19:47 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-10 20:16 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 21:11 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-10 22:33 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 23:50 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-11 00:35 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-10 16:52 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 01:34 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-11 02:25 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 17:11 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-11 18:00 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 19:44 +0000
Re: while loop vs do while loop reading from the file issue supercat@casperkitty.com - 2016-12-11 13:11 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-11 22:40 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 02:03 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-12 12:53 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-12 13:04 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 13:27 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-12 15:16 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 23:00 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 00:59 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-13 03:25 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 13:08 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 05:56 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 15:31 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-13 08:27 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 18:07 +0000
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-13 18:12 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 18:26 +0000
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-13 18:34 +0000
Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2016-12-13 18:39 +0000
Re: while loop vs do while loop reading from the file issue Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-13 13:47 -0500
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 19:03 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-13 11:30 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 20:10 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-13 12:42 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 21:29 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-13 14:27 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 22:56 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-13 16:13 -0800
Re: while loop vs do while loop reading from the file issue supercat@casperkitty.com - 2016-12-14 07:33 -0800
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-14 09:05 -0800
Re: while loop vs do while loop reading from the file issue supercat@casperkitty.com - 2016-12-13 12:48 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 21:37 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-14 00:08 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-14 01:24 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-13 17:56 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-14 02:33 +0000
Re: while loop vs do while loop reading from the file issue David Brown <david.brown@hesbynett.no> - 2016-12-14 10:03 +0100
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-14 02:09 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-14 12:24 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-14 13:00 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-14 08:54 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-14 17:01 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-14 17:27 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-14 20:24 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-15 10:47 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-15 11:54 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 04:02 -0800
Re: while loop vs do while loop reading from the file issue supercat@casperkitty.com - 2016-12-15 07:40 -0800
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-15 11:48 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 01:52 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-16 11:09 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 18:35 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-13 20:18 +0000
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-13 20:14 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-13 20:15 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 22:26 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-14 02:19 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-14 12:45 +0000
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-14 14:00 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-14 20:59 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-14 21:59 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-15 02:42 +0000
Re: while loop vs do while loop reading from the file issue asetofsymbols@gmail.com - 2016-12-15 01:20 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 09:28 +0000
Re: while loop vs do while loop reading from the file issue asetofsymbols@gmail.com - 2016-12-15 01:42 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 09:53 +0000
Re: while loop vs do while loop reading from the file issue asetofsymbols@gmail.com - 2016-12-15 01:55 -0800
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 02:03 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 10:13 +0000
Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2016-12-15 22:05 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 14:15 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-15 10:44 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 03:31 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 01:11 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-16 06:16 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 17:24 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-16 09:53 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 20:38 +0000
Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2016-12-16 21:13 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 21:50 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-16 14:19 -0800
Re: while loop vs do while loop reading from the file issue supercat@casperkitty.com - 2016-12-16 15:03 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 02:20 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-17 02:21 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 12:14 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-17 04:56 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 19:28 +0000
Re: while loop vs do while loop reading from the file issue Ike Naar <ike@iceland.freeshell.org> - 2016-12-17 22:51 +0000
Re: while loop vs do while loop reading from the file issue Les Cargill <lcargill99@comcast.com> - 2016-12-17 11:45 -0600
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 19:42 +0000
Re: while loop vs do while loop reading from the file issue Les Cargill <lcargill99@comcast.com> - 2016-12-17 20:39 -0600
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-18 10:49 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-16 09:41 -0800
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-16 10:01 -0800
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-16 12:31 -0800
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-16 13:33 -0800
Re: while loop vs do while loop reading from the file issue Ian Collins <ian-news@hotmail.com> - 2016-12-17 11:12 +1300
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-16 14:30 -0800
Re: while loop vs do while loop reading from the file issue raltbos@xs4all.nl (Richard Bos) - 2016-12-20 11:16 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 03:29 -0800
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 16:13 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-13 01:09 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-10 16:08 -0800
Re: while loop vs do while loop reading from the file issue Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2016-12-11 01:31 +0100
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 14:52 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-11 15:26 +0000
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 16:22 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-11 16:42 +0000
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 16:56 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-11 12:56 -0800
Re: while loop vs do while loop reading from the file issue supercat@casperkitty.com - 2016-12-11 08:55 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 17:19 +0000
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-10 04:09 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 15:18 +0000
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-10 07:30 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 15:43 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-10 14:56 -0800
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-10 07:57 -0800
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-09 11:40 -0800
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-10 03:19 -0800
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-10 07:49 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 16:11 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-10 14:45 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 22:59 +0000
Re: while loop vs do while loop reading from the file issue Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-08 11:26 -0500
Re: while loop vs do while loop reading from the file issue Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-08 11:48 -0500
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-11 23:33 -0800
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 23:09 -0800
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-07 09:53 -0800
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-07 11:26 -0800
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-07 11:50 -0800
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 23:12 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 07:31 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 11:00 +0000
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-09 00:48 -0800
Re: while loop vs do while loop reading from the file issue Siri Cruise <chine.bleu@yahoo.com> - 2016-12-10 13:49 -0800
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2016-12-09 01:30 -0800 |
| Message-ID | <q0uk4ch2hrddm1g8jisu2p0a2rc73go63n@4ax.com> |
| In reply to | #98464 |
On Fri, 9 Dec 2016 01:08:50 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:
>To make things clear, and to do so, let's forget about the 'do-while' loop story for now
>(it's solved anyway):
>
>1) The program I have posted is from D&D; hence all fscanf, and other functions, and their
>formats are not my invention.
>2) This particular program is the second one in the chain of file i/o programs.
>3) Therefore the program before it was the one that has created that csv file. See below
>under I.
>4) The only thing I have changed in the original program is, indeed, the file extension:
>I have used .csv, while D&D use .dat.
>5) I did manage to get the result I have posted in my original message: the file was created
>with the content I showed and then this content has been read successfully (I am again referring
>to the note I wrote before this explanation - nothing to do with the do-while topic).
>
>Now I wonder does it mean that the file format change has caused the gibberish that
>you get when running the program? I have now tried another program, which has almost
>same steps (see below under II) and it indeed writes a nonsensical data into the created csv file.
>
>Note: the style of commenting is not mine either
>
>( I ) two original programs: one creates a file, another reads from that file.
>
>// Fig. 11.2: fig11_02.c
>// Creating a sequential file
>
>#include <stdio.h>
>
>int main( void )
>{
> unsigned int account; // account number
> char name[ 30 ]; // account name
> double balance; // account balance
>
> FILE *cfPtr; // cfPtr = clients.csv file pointer
>
> // fopen opens file. Exit program if unable to create file
> if ( (cfPtr = fopen( "clients.csv", "w")) == NULL )
> {
> puts( "File could not be opened" );
> } // end if
> else
> {
> puts( "Enter the account, name, and balance." );
> puts( "Enter EOF to end input." );
> printf( "%s", "? " );
> scanf( "%d%29s%lf", &account, name, &balance );
>
> // write account, name and balance into file with fprintf
> while ( !feof( stdin ) )
> {
> fprintf( cfPtr, "%d %s %.2f\n", account, name, balance );
>
> /**
> fprintf( stdout, "%d %s %.2f\n", account, name, balance );
> to print the data to the standard output
> **/
>
> printf( "%s", "? " );
> scanf( "%d%29s%lf", &account, name, &balance );
> } // end while
>
> fclose( cfPtr ); // fclose closes file
>
> } // end else
>} // end main
Did you notice that nowhere in this program is a comma written to the
output file clients.csv. Despite the file name (or the extension), it
is not a file of comma separated values. In fact it is a file of
white space separated values which is exactly what the second program
expects.
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2016-12-09 01:50 -0800 |
| Message-ID | <ohuk4c9ndgab3m8nq2bj34r6r3mrhtv3t2@4ax.com> |
| In reply to | #98464 |
On Fri, 9 Dec 2016 01:08:50 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:
>Now I wonder does it mean that the file format change has caused the gibberish that
>you get when running the program? I have now tried another program, which has almost
>same steps (see below under II) and it indeed writes a nonsensical data into the created csv file.
There is a fair bit of nonsense at the end of your message but none of
the data in the file is nonsensical.
<snip>
>(II) // Fig. 11.10: fig11_10.c2
>// Creating a random-access file sequentially
>#include <stdio.h>
>
>// clientData structure definition
>struct clientData {
> unsigned int acctNum; // account number
> char lastName[ 15 ]; // account last name
> char firstName[ 10 ]; // account first name
> double balance; // account balance
>}; // end structure clientData
>
>int main( void )
>{
> // counter used to count from 1-100
> unsigned int i;
>
> // create clientData with default information
> struct clientData blankClient = { 0, "", "", 0.0 };
>
> // credit.csv file pointer
> FILE *cfPtr;
>
> // fopen opens the file; exits if file cannot be opened
> if ( ( cfPtr = fopen( "credit.csv", "wb") ) == NULL )
> {
> puts( "File could not be opened." );
> }
> else
> {
> // output 100 blank records to file
> for ( i = 1; i <= 100; ++i )
> {
> fwrite( &blankClient, sizeof( struct clientData ), 1, cfPtr );
> }
> fclose(cfPtr);
> }
>}
>
>// Fig. 11.11: fig11_11.c
>// Writing data randomly to a random-access file
>#include <stdio.h>
>
>// clientData structure definition
>struct clientData {
> unsigned int acctNum; // account number
> char lastName[ 15 ]; // account last name
> char firstName[ 10 ]; // account first name
> double balance; // account balance
>};
>
>int main( void )
>{
>
> FILE *cfPtr; // credit.csv file pointer
>
> // create clientData with default information
> struct clientData client = { 0, "", "", 0.0 };
>
> // fopen opens the file; exits if file cannot be opened
> if ( ( cfPtr = fopen( "credit.csv", "rb+" ) ) == NULL )
> {
> puts( "File could not be opened." );
> }
> else
> {
> // require user to specify account number
> printf( "%s", "Enter account number"
> " ( 1 to 100, 0 to end input )\n? " );
> scanf( "%d", &client.acctNum );
>
> // user enters information, which is copied into file
> while ( client.acctNum != 0 )
> {
> // user enters last name, first name and balance
> printf( "%s", "Enter lastname, firstname, balance\n? " );
>
> // set record lastName, firstName and balance value
> fscanf( stdin, "%14s%9s%lf", client.lastName,
> client.firstName, &client.balance );
>
> // seek position in file to user-specified record
> fseek( cfPtr, ( client.acctNum - 1 ) *
> sizeof( struct clientData ), SEEK_SET );
> // write user-specified information in file
> fwrite( &client, sizeof( struct clientData ), 1, cfPtr );
>
> // enable user to input another account number
> printf( "%s", "Enter account number\n? " );
> scanf( "%d", &client.acctNum );
> }
> fclose(cfPtr);
> }
>}
>
>I ran the second program with the following input:
>Enter account number ( 1 to 100, 0 to end input )
>? 37
>Enter lastname, firstname, balance
>? Barker Doug 0.00
>Enter account number
>? 29
>Enter lastname, firstname, balance
>? Brown Nancy -24.53
>Enter account number
>? 0
>
>And the result in csv file is:
> BrownNancyHáz®‡8À%BarkerDoug
Since the first program wrote 100 "records" to the file, there is
considerably more data than you chose to show us. In fact, there are
exactly 100 records, each occupying a minimum of 31 bytes (and more
likely occupying at least 40 bytes).
Perhaps part of the problem is the nonsensical decision to use a text
editor to look at a binary file. Consider that you wrote the entire
structure containing Brown's data do the file.
The first member of the structure is an int. This int must
occupy at least 2 bytes (probably 4, maybe 8). You don't show them.
The second member is an array of 15 char. It contains the string
"Brown". Where in your output is the '\0' that must follow the 'n'?
In fact, we know there are 10 '\0' characters following the 'n'. You
don't show any of them. We do know that the 'N' is not immediately
after the 'n'.
You get the idea.
Since the file contains binary data, the csv extension is very
misleading.
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-10 02:34 -0800 |
| Message-ID | <8293e565-c2e6-4b49-9a98-8b199175cbd5@googlegroups.com> |
| In reply to | #98470 |
On Friday, December 9, 2016 at 12:50:17 PM UTC+3, Barry Schwarz wrote:
> On Fri, 9 Dec 2016 01:08:50 -0800 (PST), Alla _
> <modelling.data@gmail.com> wrote:
>
> >Now I wonder does it mean that the file format change has caused the gibberish that
> >you get when running the program? I have now tried another program, which has almost
> >same steps (see below under II) and it indeed writes a nonsensical data into the created csv file.
>
> There is a fair bit of nonsense at the end of your message but none of
> the data in the file is nonsensical.
>
> <snip>
>
> >(II) // Fig. 11.10: fig11_10.c2
> >// Creating a random-access file sequentially
> >#include <stdio.h>
> >
> >// clientData structure definition
> >struct clientData {
> > unsigned int acctNum; // account number
> > char lastName[ 15 ]; // account last name
> > char firstName[ 10 ]; // account first name
> > double balance; // account balance
> >}; // end structure clientData
> >
> >int main( void )
> >{
> > // counter used to count from 1-100
> > unsigned int i;
> >
> > // create clientData with default information
> > struct clientData blankClient = { 0, "", "", 0.0 };
> >
> > // credit.csv file pointer
> > FILE *cfPtr;
> >
> > // fopen opens the file; exits if file cannot be opened
> > if ( ( cfPtr = fopen( "credit.csv", "wb") ) == NULL )
> > {
> > puts( "File could not be opened." );
> > }
> > else
> > {
> > // output 100 blank records to file
> > for ( i = 1; i <= 100; ++i )
> > {
> > fwrite( &blankClient, sizeof( struct clientData ), 1, cfPtr );
> > }
> > fclose(cfPtr);
> > }
> >}
> >
> >// Fig. 11.11: fig11_11.c
> >// Writing data randomly to a random-access file
> >#include <stdio.h>
> >
> >// clientData structure definition
> >struct clientData {
> > unsigned int acctNum; // account number
> > char lastName[ 15 ]; // account last name
> > char firstName[ 10 ]; // account first name
> > double balance; // account balance
> >};
> >
> >int main( void )
> >{
> >
> > FILE *cfPtr; // credit.csv file pointer
> >
> > // create clientData with default information
> > struct clientData client = { 0, "", "", 0.0 };
> >
> > // fopen opens the file; exits if file cannot be opened
> > if ( ( cfPtr = fopen( "credit.csv", "rb+" ) ) == NULL )
> > {
> > puts( "File could not be opened." );
> > }
> > else
> > {
> > // require user to specify account number
> > printf( "%s", "Enter account number"
> > " ( 1 to 100, 0 to end input )\n? " );
> > scanf( "%d", &client.acctNum );
> >
> > // user enters information, which is copied into file
> > while ( client.acctNum != 0 )
> > {
> > // user enters last name, first name and balance
> > printf( "%s", "Enter lastname, firstname, balance\n? " );
> >
> > // set record lastName, firstName and balance value
> > fscanf( stdin, "%14s%9s%lf", client.lastName,
> > client.firstName, &client.balance );
> >
> > // seek position in file to user-specified record
> > fseek( cfPtr, ( client.acctNum - 1 ) *
> > sizeof( struct clientData ), SEEK_SET );
> > // write user-specified information in file
> > fwrite( &client, sizeof( struct clientData ), 1, cfPtr );
> >
> > // enable user to input another account number
> > printf( "%s", "Enter account number\n? " );
> > scanf( "%d", &client.acctNum );
> > }
> > fclose(cfPtr);
> > }
> >}
> >
> >I ran the second program with the following input:
> >Enter account number ( 1 to 100, 0 to end input )
> >? 37
> >Enter lastname, firstname, balance
> >? Barker Doug 0.00
> >Enter account number
> >? 29
> >Enter lastname, firstname, balance
> >? Brown Nancy -24.53
> >Enter account number
> >? 0
> >
> >And the result in csv file is:
> > BrownNancyHáz ®‡8À%BarkerDoug
>
> Since the first program wrote 100 "records" to the file, there is
> considerably more data than you chose to show us. In fact, there are
> exactly 100 records, each occupying a minimum of 31 bytes (and more
> likely occupying at least 40 bytes).
Thank you very much for your comments. The above part helped me to
recall the data structure alignment issue (not that I know a lot about it),
which came to my mind upon computing the size of the structure:
please, correct me:
double 8 bytes, unsigned int 4 bytes (typically), char last name 15 bytes
(1 for each character, including the last 15-th '\0'), char fist name 10 bytes,
hence the size of the structure, based only on the sizes of its members,
is 37. You say that it's probably 40: is it because of the padding? I am not
asking to start this new topic here, especially because I don't have enough
knowledge of this matter, yet.
>
> Perhaps part of the problem is the nonsensical decision to use a text
> editor to look at a binary file. Consider that you wrote the entire
> structure containing Brown's data do the file.
> The first member of the structure is an int. This int must
> occupy at least 2 bytes (probably 4, maybe 8). You don't show them.
You lost me here. I don't know the system that well to understand
how I shall show these bytes, and what you mean by saying that I
don't show them.
> The second member is an array of 15 char. It contains the string
> "Brown". Where in your output is the '\0' that must follow the 'n'?
Do you mean that when I write the users input into a csv file, I have
to explicitly write every character that has to be part of the csv file,
including commas as columns separators, etc? Oh. I get it (partially
still) - I have indeed provided only the csv extension, and nothing
to indicate how the program should record the data to produce the
csv format in the output file. Oh.........
> In fact, we know there are 10 '\0' characters following the 'n'. You
> don't show any of them. We do know that the 'N' is not immediately
> after the 'n'.
> You get the idea.
>
> Since the file contains binary data, the csv extension is very
> misleading.
>
> --
> Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-12-10 03:18 -0800 |
| Message-ID | <3f7cc33a-c3dd-40ef-8032-5918dc75dfda@googlegroups.com> |
| In reply to | #98675 |
W dniu sobota, 10 grudnia 2016 11:34:26 UTC+1 użytkownik Alla _ napisał:
> On Friday, December 9, 2016 at 12:50:17 PM UTC+3, Barry Schwarz wrote:
> > On Fri, 9 Dec 2016 01:08:50 -0800 (PST), Alla _
> > <modelling.data@gmail.com> wrote:
> >
> > >Now I wonder does it mean that the file format change has caused the gibberish that
> > >you get when running the program? I have now tried another program, which has almost
> > >same steps (see below under II) and it indeed writes a nonsensical data into the created csv file.
> >
> > There is a fair bit of nonsense at the end of your message but none of
> > the data in the file is nonsensical.
> >
> > <snip>
> >
> > >(II) // Fig. 11.10: fig11_10.c2
> > >// Creating a random-access file sequentially
> > >#include <stdio.h>
> > >
> > >// clientData structure definition
> > >struct clientData {
> > > unsigned int acctNum; // account number
> > > char lastName[ 15 ]; // account last name
> > > char firstName[ 10 ]; // account first name
> > > double balance; // account balance
> > >}; // end structure clientData
> > >
> > >int main( void )
> > >{
> > > // counter used to count from 1-100
> > > unsigned int i;
> > >
> > > // create clientData with default information
> > > struct clientData blankClient = { 0, "", "", 0.0 };
> > >
> > > // credit.csv file pointer
> > > FILE *cfPtr;
> > >
> > > // fopen opens the file; exits if file cannot be opened
> > > if ( ( cfPtr = fopen( "credit.csv", "wb") ) == NULL )
> > > {
> > > puts( "File could not be opened." );
> > > }
> > > else
> > > {
> > > // output 100 blank records to file
> > > for ( i = 1; i <= 100; ++i )
> > > {
> > > fwrite( &blankClient, sizeof( struct clientData ), 1, cfPtr );
> > > }
> > > fclose(cfPtr);
> > > }
> > >}
> > >
> > >// Fig. 11.11: fig11_11.c
> > >// Writing data randomly to a random-access file
> > >#include <stdio.h>
> > >
> > >// clientData structure definition
> > >struct clientData {
> > > unsigned int acctNum; // account number
> > > char lastName[ 15 ]; // account last name
> > > char firstName[ 10 ]; // account first name
> > > double balance; // account balance
> > >};
> > >
> > >int main( void )
> > >{
> > >
> > > FILE *cfPtr; // credit.csv file pointer
> > >
> > > // create clientData with default information
> > > struct clientData client = { 0, "", "", 0.0 };
> > >
> > > // fopen opens the file; exits if file cannot be opened
> > > if ( ( cfPtr = fopen( "credit.csv", "rb+" ) ) == NULL )
> > > {
> > > puts( "File could not be opened." );
> > > }
> > > else
> > > {
> > > // require user to specify account number
> > > printf( "%s", "Enter account number"
> > > " ( 1 to 100, 0 to end input )\n? " );
> > > scanf( "%d", &client.acctNum );
> > >
> > > // user enters information, which is copied into file
> > > while ( client.acctNum != 0 )
> > > {
> > > // user enters last name, first name and balance
> > > printf( "%s", "Enter lastname, firstname, balance\n? " );
> > >
> > > // set record lastName, firstName and balance value
> > > fscanf( stdin, "%14s%9s%lf", client.lastName,
> > > client.firstName, &client.balance );
> > >
> > > // seek position in file to user-specified record
> > > fseek( cfPtr, ( client.acctNum - 1 ) *
> > > sizeof( struct clientData ), SEEK_SET );
> > > // write user-specified information in file
> > > fwrite( &client, sizeof( struct clientData ), 1, cfPtr );
> > >
> > > // enable user to input another account number
> > > printf( "%s", "Enter account number\n? " );
> > > scanf( "%d", &client.acctNum );
> > > }
> > > fclose(cfPtr);
> > > }
> > >}
> > >
> > >I ran the second program with the following input:
> > >Enter account number ( 1 to 100, 0 to end input )
> > >? 37
> > >Enter lastname, firstname, balance
> > >? Barker Doug 0.00
> > >Enter account number
> > >? 29
> > >Enter lastname, firstname, balance
> > >? Brown Nancy -24.53
> > >Enter account number
> > >? 0
> > >
> > >And the result in csv file is:
> > > BrownNancyHáz ®‡8À%BarkerDoug
> >
> > Since the first program wrote 100 "records" to the file, there is
> > considerably more data than you chose to show us. In fact, there are
> > exactly 100 records, each occupying a minimum of 31 bytes (and more
> > likely occupying at least 40 bytes).
> Thank you very much for your comments. The above part helped me to
> recall the data structure alignment issue (not that I know a lot about it),
> which came to my mind upon computing the size of the structure:
> please, correct me:
> double 8 bytes, unsigned int 4 bytes (typically), char last name 15 bytes
> (1 for each character, including the last 15-th '\0'), char fist name 10 bytes,
> hence the size of the structure, based only on the sizes of its members,
> is 37. You say that it's probably 40: is it because of the padding? I am not
> asking to start this new topic here, especially because I don't have enough
> knowledge of this matter, yet.
> >
> > Perhaps part of the problem is the nonsensical decision to use a text
> > editor to look at a binary file. Consider that you wrote the entire
> > structure containing Brown's data do the file.
> > The first member of the structure is an int. This int must
> > occupy at least 2 bytes (probably 4, maybe 8). You don't show them.
> You lost me here. I don't know the system that well to understand
> how I shall show these bytes, and what you mean by saying that I
> don't show them.
> > The second member is an array of 15 char. It contains the string
> > "Brown". Where in your output is the '\0' that must follow the 'n'?
>
> Do you mean that when I write the users input into a csv file, I have
> to explicitly write every character that has to be part of the csv file,
> including commas as columns separators, etc? Oh. I get it (partially
> still) - I have indeed provided only the csv extension, and nothing
> to indicate how the program should record the data to produce the
> csv format in the output file. Oh.........
>
> > In fact, we know there are 10 '\0' characters following the 'n'. You
> > don't show any of them. We do know that the 'N' is not immediately
> > after the 'n'.
> > You get the idea.
> >
> > Since the file contains binary data, the csv extension is very
> > misleading.
> >
reading alla user (a bit only not much) it provokes/leads me to thought how much a problem of assumptions in a life of a human is important
(i once already observed that asumptions probably bring more falsety in humans life than bad reasoning - more to be said on this but later as i probably must rethink this, )
/wwssd
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2016-12-10 07:43 -0800 |
| Message-ID | <sn7o4cp09srbtr8d3eg9vn4oof0fcqg2up@4ax.com> |
| In reply to | #98675 |
On Sat, 10 Dec 2016 02:34:12 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:
>On Friday, December 9, 2016 at 12:50:17 PM UTC+3, Barry Schwarz wrote:
>> On Fri, 9 Dec 2016 01:08:50 -0800 (PST), Alla _
>> <modelling.data@gmail.com> wrote:
<snip>
>> >struct clientData {
>> > unsigned int acctNum; // account number
>> > char lastName[ 15 ]; // account last name
>> > char firstName[ 10 ]; // account first name
>> > double balance; // account balance
>> >}; // end structure clientData
>> >
>> >int main( void )
>> >{
<snip>
>> > struct clientData blankClient = { 0, "", "", 0.0 };
<snip>
>> > for ( i = 1; i <= 100; ++i )
>> > {
>> > fwrite( &blankClient, sizeof( struct clientData ), 1, cfPtr );
<snip>
>> >}
>> >
<snip>
>> >int main( void )
>> >{
<snip>
>> > struct clientData client = { 0, "", "", 0.0 };
<snip>
>> > fseek( cfPtr, ( client.acctNum - 1 ) *
>> > sizeof( struct clientData ), SEEK_SET );
>> > // write user-specified information in file
>> > fwrite( &client, sizeof( struct clientData ), 1, cfPtr );
>> >
<snip>
>> >}
>> >
>> >I ran the second program with the following input:
<snip>
>> >And the result in csv file is:
>> > BrownNancyHáz ®‡8À%BarkerDoug
>>
>> Since the first program wrote 100 "records" to the file, there is
>> considerably more data than you chose to show us. In fact, there are
>> exactly 100 records, each occupying a minimum of 31 bytes (and more
>> likely occupying at least 40 bytes).
>Thank you very much for your comments. The above part helped me to
>recall the data structure alignment issue (not that I know a lot about it),
>which came to my mind upon computing the size of the structure:
>please, correct me:
>double 8 bytes, unsigned int 4 bytes (typically), char last name 15 bytes
>(1 for each character, including the last 15-th '\0'), char fist name 10 bytes,
>hence the size of the structure, based only on the sizes of its members,
You gave typical sizes, I gave minimum. An int can be two bytes. The
records you showed did not contain even the minimum number of bytes.
>is 37. You say that it's probably 40: is it because of the padding? I am not
>asking to start this new topic here, especially because I don't have enough
>knowledge of this matter, yet.
Yes. And there is no need to know how your system pads. If you need
the size of a struct, use the sizeof operator.
>> Perhaps part of the problem is the nonsensical decision to use a text
>> editor to look at a binary file. Consider that you wrote the entire
>> structure containing Brown's data do the file.
>> The first member of the structure is an int. This int must
>> occupy at least 2 bytes (probably 4, maybe 8). You don't show them.
>You lost me here. I don't know the system that well to understand
>how I shall show these bytes, and what you mean by saying that I
>don't show them.
You showed the first bytes as the 'B', 'r', 'o', etc. These are
obviously characters in the array lastname. That member is not the
first member of the struct. There are at least two, more likely four,
bytes in the struct before the 'B'. The do not appear in the output
you showed. Therefore, you did not show them.
>> The second member is an array of 15 char. It contains the string
>> "Brown". Where in your output is the '\0' that must follow the 'n'?
>
>Do you mean that when I write the users input into a csv file, I have
>to explicitly write every character that has to be part of the csv file,
>including commas as columns separators, etc? Oh. I get it (partially
You did not write the user's input to the file. You wrote structures
to the file. (Yes, you populated the members of the structure with
the user's.) Your call to fwrite specified sizeof(struct clientData)
as the number of bytes to write. Therefore, each record in your file
will contain the entire structure, including the unused parts of the
two arrays. You did not show any of these bytes but they are
obviously present in the file.
>still) - I have indeed provided only the csv extension, and nothing
>to indicate how the program should record the data to produce the
>csv format in the output file. Oh.........
This file does not comply with any csv format.
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2016-12-10 18:21 +0100 |
| Message-ID | <o2hdjh$jl4$1@gioia.aioe.org> |
| In reply to | #98701 |
On 12/10/2016 4:43 PM, Barry Schwarz wrote: >> is 37. You say that it's probably 40: is it because of the padding? I am not >> asking to start this new topic here, especially because I don't have enough >> knowledge of this matter, yet. > Yes. And there is no need to know how your system pads. If you need > the size of a struct, use the sizeof operator. > This is only true if you are sure that the data that is written will be read only by the same program or one that is compiled with exactly the same architecture, padding, int size etc. Data written this way is substantially non-portable. This is a different topic, and only applies to binary I/O, but just to mention, types from <stdint.h> would better serve the purpose in this case (besides padding control).
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-09 10:08 +0000 |
| Message-ID | <o2dvo8$j82$1@dont-email.me> |
| In reply to | #98464 |
On 09/12/16 09:08, Alla _ wrote:
> On Thursday, December 8, 2016 at 10:35:42 AM UTC+3, Richard Heathfield wrote:
>> On 08/12/16 07:29, Alla _ wrote:
>>> On Wednesday, December 7, 2016 at 10:38:21 PM UTC+3, Lew Pitcher wrote:
>>>> On Wednesday December 7 2016 14:09, in comp.lang.c, "Barry Schwarz"
>>>> <schwarzb@dqel.com> wrote:
>>>>
>>>>> On Wed, 07 Dec 2016 12:56:08 -0500, Lew Pitcher
>>>>> <lew.pitcher@digitalfreehold.ca> wrote:
>>>>>
>>>>>> On Wednesday December 7 2016 12:50, in comp.lang.c, "Richard Heathfield"
>>>>>> <rjh@cpax.org.uk> wrote:
>>>>>>
>>>>>>> On 07/12/16 17:45, Lew Pitcher wrote:
>>>>>>>
>>>>>>> <snip>
>>>>>>>
>>>>>>>> Like Richard, I get an infinite loop of ill-formed data.
>>>>>>>
>>>>>>> This is almost certainly because the code was not, despite Alla's claim,
>>>>>>> written to handle CSV files. There is no CSV-parsing logic whatsoever in
>>>>>>> either her program or the original.
>>>>>>>
> <snip>
>> Well, you /said/ it was /already/ in csv format, so why would you need
>> to convert it? But if it's already in csv format, why doesn't your
>> program cope with csv files, and why do you obviously think it /does/
>> cope with them?
>>
>> More 'why' questions, I see. Sorry about that.
>
> I am totally fine with 'why's - they are very helpful and provocative;
> some sort of a socratic method )
That's good, but you do need to take note of the questions and to learn
from them.
> Based on your questions and questions posted by Lew in his helpful answer (below),
> I have understood that I did not make myself 100% clear about the versions I posted here.
> I did hope that my initial explanations are suffice.
It seems not.
> To make things clear, and to do so, let's forget about the 'do-while' loop story for now
> (it's solved anyway):
I hope the solution you arrived at was that the do-while loop was a bad
idea in this case. That doesn't mean it's always a bad idea, but for an
input loop a simple while is better.
> 1) The program I have posted is from D&D; hence all fscanf, and other functions, and their
> formats are not my invention.
All right. It's not how I would do it, but yes, it can be done that way.
> 2) This particular program is the second one in the chain of file i/o programs.
> 3) Therefore the program before it was the one that has created that csv file.
There wasn't really a CSV file, was there?
> See below under I.
Please understand that C has no magical way of knowing what format your
file is in. It doesn't care about file extensions. It only cares about
the bytes in the file. The most you can hope for is a little minor magic
with text-oriented streams, whereby the C runtime can convert Windows
\r\n sequences into \n on the way in, and convert \n back to \r\n on the
way out again. Anything more than that, you have to do for yourself.
Calling a file ".csv" doesn't make it a CSV (comma-separated values)
file. What makes it a CSV file is the separation of values by commas.
But if you /do/ call it a ".csv" file, you can perhaps understand why
people assume you are talking about a comma-separated values file.
> 4) The only thing I have changed in the original program is, indeed, the file extension:
> I have used .csv, while D&D use .dat.
That's fine, albeit misleading. C doesn't care either way. But your
readers may well be fooled into thinking you had a comma-separated
values file as your input. Since you didn't actually post your input
file, how were we to know?
> 5) I did manage to get the result I have posted in my original message: the file was created
> with the content I showed and then this content has been read successfully (I am again referring
> to the note I wrote before this explanation - nothing to do with the do-while topic).
>
> Now I wonder does it mean that the file format change has caused the gibberish that
> you get when running the program?
Because you didn't post your data file, we had to construct our own.
Because you said ".csv", we used a CSV format. That wasn't the format
your program had been written to expect. And so, when your program read
our files (mine and Lew Pitcher's), it couldn't make sense of them. Why
should it? Our data were separated by commas, whereas your data were
constructed in a different way.
> I have now tried another program, which has almost
> same steps (see below under II) and it indeed writes a nonsensical data into the created csv file.
Then let's try to find out why.
> Note: the style of commenting is not mine either
>
> ( I ) two original programs: one creates a file, another reads from that file.
>
> // Fig. 11.2: fig11_02.c
> // Creating a sequential file
>
> #include <stdio.h>
>
> int main( void )
> {
> unsigned int account; // account number
> char name[ 30 ]; // account name
> double balance; // account balance
>
> FILE *cfPtr; // cfPtr = clients.csv file pointer
>
> // fopen opens file. Exit program if unable to create file
> if ( (cfPtr = fopen( "clients.csv", "w")) == NULL )
> {
> puts( "File could not be opened" );
> } // end if
> else
> {
> puts( "Enter the account, name, and balance." );
> puts( "Enter EOF to end input." );
> printf( "%s", "? " );
> scanf( "%d%29s%lf", &account, name, &balance );
What if this call fails? How would you know? You haven't checked the
return value. And why are you using %d for an unsigned int?
> // write account, name and balance into file with fprintf
> while ( !feof( stdin ) )
Correct me if I'm wrong, but haven't you already been told that feof is
a lousy way to control an input loop?
Is this Deitel & Deitel telling you to do it like this? If so, they just
went down in my estimation.
Here is how you do it:
while(data-reading function got some data)
{
process that data
}
For example, to echo the input but insert a '#' at the start of every line:
while(fgets(line, sizeof line, stdin) != NULL)
{
printf("#%s", line);
}
No feof() call in that loop! The point of feof() is that you can call it
/after/ the loop, to find out whether you processed all the data.
if(feof(stdin))
{
you got everything, so it's probably fine
}
else
{
maybe something went wrong
if(ferror(stdin))
{
something DID go wrong!
}
}
> {
> fprintf( cfPtr, "%d %s %.2f\n", account, name, balance );
(Why are you using %d to print an unsigned int?)
Note that this line does *not* write CSV data. Now, nobody's saying you
/have/ to write CSV data, but if you do want to write CSV data this
isn't the way to do it. Instead, you would write:
fprintf( cfPtr, "%d,%s,%.2f\n", account, name, balance );
Do you see the difference?
Now, given that your second program doesn't know how to read CSV data,
you don't actually want your first program to write CSV data. Rather,
you want your first program to write the data in a way that the second
program understands. And this you do appear to have done. The problem
arose because, right at the start, you introduced this CSV red herring
into the discussion.
> And the result in csv file is:
But it's not a CSV file, is it? Not really.
> BrownNancyHáz®‡8À%BarkerDoug
Okay. Look at the data. First, I note that the leading account number is
not present. Did your file-creating program check that it had a valid
account number? Second, the strange characters suggest either that you
have exceeded the bounds of an array used for storing a string or that
you have attempted to interpret some other data type as if it were a
pointer to the first character of a string.
--
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 <noname@invalid.add> |
|---|---|
| Date | 2016-12-09 19:19 +0100 |
| Message-ID | <o2esjk$168m$1@gioia.aioe.org> |
| In reply to | #98472 |
On 12/9/2016 11:08 AM, Richard Heathfield wrote: > On 09/12/16 09:08, Alla _ wrote: > >> And the result in csv file is: > > But it's not a CSV file, is it? Not really. > >> BrownNancyHáz®‡8À%BarkerDoug > > Okay. Look at the data. First, I note that the leading account number is > not present. Did your file-creating program check that it had a valid > account number? Second, the strange characters suggest either that you > have exceeded the bounds of an array used for storing a string or that > you have attempted to interpret some other data type as if it were a > pointer to the first character of a string. > You know that there could not be a valid account number printed in text here, example II does an fseek+fwrite of a struct directly from memory to disk, so its contents could not be examined meaningfully by means of its printed text (as Barry correctly pointed out) Moreover, the input had account numbers 37 and 29, which means that due to the fseek's data is only written at the corresponding offsets, the initial part of the file (is this what is shown?) is not explicitly written to in the program. It might be leftover from previous runs. The output of this program cannot be examined in text mode.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-10 03:56 -0800 |
| Message-ID | <5d68da29-653c-42f5-8dbe-c11d3b304322@googlegroups.com> |
| In reply to | #98472 |
On Friday, December 9, 2016 at 1:08:32 PM UTC+3, Richard Heathfield wrote:
> On 09/12/16 09:08, Alla _ wrote:
> > On Thursday, December 8, 2016 at 10:35:42 AM UTC+3, Richard Heathfield wrote:
> >> On 08/12/16 07:29, Alla _ wrote:
> >>> On Wednesday, December 7, 2016 at 10:38:21 PM UTC+3, Lew Pitcher wrote:
> >>>> On Wednesday December 7 2016 14:09, in comp.lang.c, "Barry Schwarz"
> >>>> <schwarzb@dqel.com> wrote:
> >>>>
> >>>>> On Wed, 07 Dec 2016 12:56:08 -0500, Lew Pitcher
> >>>>> <lew.pitcher@digitalfreehold.ca> wrote:
> >>>>>
> >>>>>> On Wednesday December 7 2016 12:50, in comp.lang.c, "Richard Heathfield"
> >>>>>> <rjh@cpax.org.uk> wrote:
> >>>>>>
> >>>>>>> On 07/12/16 17:45, Lew Pitcher wrote:
> >>>>>>>
> >>>>>>> <snip>
> >>>>>>>
> >>>>>>>> Like Richard, I get an infinite loop of ill-formed data.
> >>>>>>>
> >>>>>>> This is almost certainly because the code was not, despite Alla's claim,
> >>>>>>> written to handle CSV files. There is no CSV-parsing logic whatsoever in
> >>>>>>> either her program or the original.
> >>>>>>>
> > <snip>
> >> Well, you /said/ it was /already/ in csv format, so why would you need
> >> to convert it? But if it's already in csv format, why doesn't your
> >> program cope with csv files, and why do you obviously think it /does/
> >> cope with them?
> >>
> >> More 'why' questions, I see. Sorry about that.
> >
> > I am totally fine with 'why's - they are very helpful and provocative;
> > some sort of a socratic method )
>
> That's good, but you do need to take note of the questions and to learn
> from them.
>
> > Based on your questions and questions posted by Lew in his helpful answer (below),
> > I have understood that I did not make myself 100% clear about the versions I posted here.
> > I did hope that my initial explanations are suffice.
>
> It seems not.
>
> > To make things clear, and to do so, let's forget about the 'do-while' loop story for now
> > (it's solved anyway):
>
> I hope the solution you arrived at was that the do-while loop was a bad
> idea in this case. That doesn't mean it's always a bad idea, but for an
> input loop a simple while is better.
>
> > 1) The program I have posted is from D&D; hence all fscanf, and other functions, and their
> > formats are not my invention.
>
> All right. It's not how I would do it, but yes, it can be done that way.
>
> > 2) This particular program is the second one in the chain of file i/o programs.
> > 3) Therefore the program before it was the one that has created that csv file.
>
> There wasn't really a CSV file, was there?
>
> > See below under I.
>
> Please understand that C has no magical way of knowing what format your
> file is in. It doesn't care about file extensions. It only cares about
> the bytes in the file. The most you can hope for is a little minor magic
> with text-oriented streams, whereby the C runtime can convert Windows
> \r\n sequences into \n on the way in, and convert \n back to \r\n on the
> way out again. Anything more than that, you have to do for yourself.
> Calling a file ".csv" doesn't make it a CSV (comma-separated values)
> file. What makes it a CSV file is the separation of values by commas.
> But if you /do/ call it a ".csv" file, you can perhaps understand why
> people assume you are talking about a comma-separated values file.
>
> > 4) The only thing I have changed in the original program is, indeed, the file extension:
> > I have used .csv, while D&D use .dat.
>
> That's fine, albeit misleading. C doesn't care either way. But your
> readers may well be fooled into thinking you had a comma-separated
> values file as your input. Since you didn't actually post your input
> file, how were we to know?
>
> > 5) I did manage to get the result I have posted in my original message: the file was created
> > with the content I showed and then this content has been read successfully (I am again referring
> > to the note I wrote before this explanation - nothing to do with the do-while topic).
> >
> > Now I wonder does it mean that the file format change has caused the gibberish that
> > you get when running the program?
>
> Because you didn't post your data file, we had to construct our own.
> Because you said ".csv", we used a CSV format. That wasn't the format
> your program had been written to expect. And so, when your program read
> our files (mine and Lew Pitcher's), it couldn't make sense of them. Why
> should it? Our data were separated by commas, whereas your data were
> constructed in a different way.
>
> > I have now tried another program, which has almost
> > same steps (see below under II) and it indeed writes a nonsensical data into the created csv file.
>
> Then let's try to find out why.
>
> > Note: the style of commenting is not mine either
> >
> > ( I ) two original programs: one creates a file, another reads from that file.
> >
> > // Fig. 11.2: fig11_02.c
> > // Creating a sequential file
> >
> > #include <stdio.h>
> >
> > int main( void )
> > {
> > unsigned int account; // account number
> > char name[ 30 ]; // account name
> > double balance; // account balance
> >
> > FILE *cfPtr; // cfPtr = clients.csv file pointer
> >
> > // fopen opens file. Exit program if unable to create file
> > if ( (cfPtr = fopen( "clients.csv", "w")) == NULL )
> > {
> > puts( "File could not be opened" );
> > } // end if
> > else
> > {
> > puts( "Enter the account, name, and balance." );
> > puts( "Enter EOF to end input." );
> > printf( "%s", "? " );
> > scanf( "%d%29s%lf", &account, name, &balance );
>
> What if this call fails? How would you know? You haven't checked the
> return value. And why are you using %d for an unsigned int?
>
> > // write account, name and balance into file with fprintf
> > while ( !feof( stdin ) )
>
> Correct me if I'm wrong, but haven't you already been told that feof is
> a lousy way to control an input loop?
>
Answering this and above question: I have noted many times, but you
keep ignoring it (sorry for saying this) and keep asking me these why's -
it is not my program, I have copied it word for word from D&D (except for
insignificant change in the file format). Yes, thanks to comments I have
received in this post, I understand that a few parts, suggested by D&D,
are not the best choice and I have to avoid them. But my goal here was
to show the original version and thus to learn why it doesn't do the job,
and not the corrected one - that would be misleading )
> Is this Deitel & Deitel telling you to do it like this? If so, they just
> went down in my estimation.
>
> Here is how you do it:
>
> while(data-reading function got some data)
> {
> process that data
> }
>
> For example, to echo the input but insert a '#' at the start of every line:
>
> while(fgets(line, sizeof line, stdin) != NULL)
> {
> printf("#%s", line);
> }
>
> No feof() call in that loop! The point of feof() is that you can call it
> /after/ the loop, to find out whether you processed all the data.
>
> if(feof(stdin))
> {
> you got everything, so it's probably fine
> }
> else
> {
> maybe something went wrong
> if(ferror(stdin))
> {
> something DID go wrong!
> }
> }
>
>
> > {
> > fprintf( cfPtr, "%d %s %.2f\n", account, name, balance );
>
> (Why are you using %d to print an unsigned int?)
>
> Note that this line does *not* write CSV data. Now, nobody's saying you
> /have/ to write CSV data, but if you do want to write CSV data this
> isn't the way to do it. Instead, you would write:
>
> fprintf( cfPtr, "%d,%s,%.2f\n", account, name, balance );
>
> Do you see the difference?
>
> Now, given that your second program doesn't know how to read CSV data,
> you don't actually want your first program to write CSV data. Rather,
> you want your first program to write the data in a way that the second
> program understands. And this you do appear to have done. The problem
> arose because, right at the start, you introduced this CSV red herring
> into the discussion.
>
> > And the result in csv file is:
>
> But it's not a CSV file, is it? Not really.
>
> > BrownNancyHáz ®‡8À%BarkerDoug
>
> Okay. Look at the data. First, I note that the leading account number is
> not present. Did your file-creating program check that it had a valid
> account number? Second, the strange characters suggest either that you
> have exceeded the bounds of an array used for storing a string or that
> you have attempted to interpret some other data type as if it were a
> pointer to the first character of a string.
>
> --
> 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-10 12:39 +0000 |
| Message-ID | <o2gsv2$qqp$1@dont-email.me> |
| In reply to | #98679 |
On 10/12/2016 11:56, Alla _ wrote:
> On Friday, December 9, 2016 at 1:08:32 PM UTC+3, Richard Heathfield wrote:
>>> // write account, name and balance into file with fprintf
>>> while ( !feof( stdin ) )
>>
>> Correct me if I'm wrong, but haven't you already been told that feof is
>> a lousy way to control an input loop?
>>
> Answering this and above question: I have noted many times, but you
> keep ignoring it (sorry for saying this) and keep asking me these why's -
> it is not my program, I have copied it word for word from D&D (except for
> insignificant change in the file format). Yes, thanks to comments I have
> received in this post, I understand that a few parts, suggested by D&D,
> are not the best choice and I have to avoid them. But my goal here was
> to show the original version and thus to learn why it doesn't do the job,
> and not the corrected one - that would be misleading )
An eof check at the start of a loop I think is a good way of reading
files (depending on how paranoid you are about unlikely changes to the
file while it is being read).
But feof() is not suitable because it gives you a status /after/ a read
attempt has been made. I use a version like this:
int eof(FILE* f) {
int c;
c=fgetc(f);
if (c==EOF) return 1;
ungetc(c,f);
return 0;
}
Then you just use eof() instead of feof().
People don't like it because something could happen to the file between
calling eof(), and doing the read in your loop, so that the eof status
becomes out of date.
(But then, if a file is changing while you're trying to read it, then
you might as well give up.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-10 14:58 +0000 |
| Message-ID | <87pokz3k5x.fsf@bsb.me.uk> |
| In reply to | #98682 |
BartC <bc@freeuk.com> writes:
> On 10/12/2016 11:56, Alla _ wrote:
>> On Friday, December 9, 2016 at 1:08:32 PM UTC+3, Richard Heathfield wrote:
>
>>>> // write account, name and balance into file with fprintf
>>>> while ( !feof( stdin ) )
>>>
>>> Correct me if I'm wrong, but haven't you already been told that feof is
>>> a lousy way to control an input loop?
>>>
>> Answering this and above question: I have noted many times, but you
>> keep ignoring it (sorry for saying this) and keep asking me these why's -
>> it is not my program, I have copied it word for word from D&D (except for
>> insignificant change in the file format). Yes, thanks to comments I have
>> received in this post, I understand that a few parts, suggested by D&D,
>> are not the best choice and I have to avoid them. But my goal here was
>> to show the original version and thus to learn why it doesn't do the job,
>> and not the corrected one - that would be misleading )
>
> An eof check at the start of a loop I think is a good way of reading
> files (depending on how paranoid you are about unlikely changes to the
> file while it is being read).
This is bad advice. It's bad because EOF is not the only reason that
input can go wrong, and it's particularly bad advice in the specific
case here because quite complex input is being done and that can fail
for even more reasons.
It is almost always better to read while and input operation was
successful, than to try to test for the various ways the input can fail.
C's input functions tell you if they worked or not for this reason.
> But feof() is not suitable because it gives you a status /after/ a
> read attempt has been made. I use a version like this:
>
> int eof(FILE* f) {
> int c;
>
> c=fgetc(f);
> if (c==EOF) return 1;
>
> ungetc(c,f);
> return 0;
> }
>
> Then you just use eof() instead of feof().
>
> People don't like it because something could happen to the file
> between calling eof(), and doing the read in your loop, so that the
> eof status becomes out of date.
Maybe some do, but I think that's a rather esoteric objection. I can
only think of very obscure cases where this could matter.
I don't like it because its 6 extra lines of C wrapped up in a function
that will make your input loops look odd to a C programmer. Where
possible one should write programs idiomatically -- C program should use
common C idioms.
What's more, it does not help in this case. Using your extra function
simply complicates the code compared to the idiomatic C version since
you still have to test the result from fscanf. Can you give an example
where it simplifies the code?
> (But then, if a file is changing while you're trying to read it, then
> you might as well give up.)
Taken literally, I don't think that's right -- lots of programs cope
perfectly well reading input that is changing. What specific changes
make you think one should give up? Maybe our opinions about when it's
worth giving up are simply different.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-10 16:01 +0000 |
| Message-ID | <o2h8r6$1ju$1@dont-email.me> |
| In reply to | #98693 |
On 10/12/2016 14:58, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 10/12/2016 11:56, Alla _ wrote:
>>> On Friday, December 9, 2016 at 1:08:32 PM UTC+3, Richard Heathfield wrote:
>>
>>>>> // write account, name and balance into file with fprintf
>>>>> while ( !feof( stdin ) )
>>>>
>>>> Correct me if I'm wrong, but haven't you already been told that feof is
>>>> a lousy way to control an input loop?
>>>>
>>> Answering this and above question: I have noted many times, but you
>>> keep ignoring it (sorry for saying this) and keep asking me these why's -
>>> it is not my program, I have copied it word for word from D&D (except for
>>> insignificant change in the file format). Yes, thanks to comments I have
>>> received in this post, I understand that a few parts, suggested by D&D,
>>> are not the best choice and I have to avoid them. But my goal here was
>>> to show the original version and thus to learn why it doesn't do the job,
>>> and not the corrected one - that would be misleading )
>>
>> An eof check at the start of a loop I think is a good way of reading
>> files (depending on how paranoid you are about unlikely changes to the
>> file while it is being read).
>
> This is bad advice. It's bad because EOF is not the only reason that
> input can go wrong, and it's particularly bad advice in the specific
> case here because quite complex input is being done and that can fail
> for even more reasons.
>
> It is almost always better to read while and input operation was
> successful, than to try to test for the various ways the input can fail.
> C's input functions tell you if they worked or not for this reason.
An eof() function called in advance is desirable (in the absence of
exceptions). Someone, knowing they are going to be reading sequentially
through a file f, can start writing code immediately:
while (!eof(f)) {
....
}
before they even know what's going to go in the loop.
Yes, further checking might be needed, because the eof() has only
verified that there /was/ at least one character left in the file;
nothing else.
>> But feof() is not suitable because it gives you a status /after/ a
>> read attempt has been made. I use a version like this:
>>
>> int eof(FILE* f) {
>> int c;
>>
>> c=fgetc(f);
>> if (c==EOF) return 1;
>>
>> ungetc(c,f);
>> return 0;
>> }
>>
>> Then you just use eof() instead of feof().
> What's more, it does not help in this case. Using your extra function
> simply complicates the code compared to the idiomatic C version since
> you still have to test the result from fscanf. Can you give an example
> where it simplifies the code?
It simplifies the body of a loop as it no longer needs to worry as much
about an end of file condition.
There might be some setup code or some print statements, that need to be
done just before the next read. This is now easier to write as you don't
need to do that setup, or don't need to undo it, and you don't have to
put the print statements into a condition:
while (!eof()) {
A;
B; //read stuff
C;
}
Instead of:
A;
while (B==cond){
C;
A;
}
Or you can take B, whatever that is, and put it into a function. Or you
can be A;B;C; into a function. It's just .... easier.
>> (But then, if a file is changing while you're trying to read it, then
>> you might as well give up.)
>
> Taken literally, I don't think that's right -- lots of programs cope
> perfectly well reading input that is changing. What specific changes
> make you think one should give up? Maybe our opinions about when it's
> worth giving up are simply different.
Just about anything? A file doesn't usually consist of random bytes of
data; there is usually a relationship between one part of a file and
another.
If you pause halfway through reading one file (say it's ASCII art), run
another program which updates it (with a chapter from a novel), then
continue with the first program, it will now be reading nonsense. (And
may go wrong because it expected so many lines and the file is now
shorter. Or earlier parts of the file contained offsets to now
non-existent portions.)
Obviously this can work if it is intended for a file to be updated while
being accessed by multiple programs. But files that are read serially
are not usually like that.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-10 19:47 +0000 |
| Message-ID | <8737hv36ta.fsf@bsb.me.uk> |
| In reply to | #98708 |
BartC <bc@freeuk.com> writes:
> On 10/12/2016 14:58, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> On 10/12/2016 11:56, Alla _ wrote:
>>>> On Friday, December 9, 2016 at 1:08:32 PM UTC+3, Richard Heathfield wrote:
>>>
>>>>>> // write account, name and balance into file with fprintf
>>>>>> while ( !feof( stdin ) )
>>>>>
>>>>> Correct me if I'm wrong, but haven't you already been told that feof is
>>>>> a lousy way to control an input loop?
>>>>>
>>>> Answering this and above question: I have noted many times, but you
>>>> keep ignoring it (sorry for saying this) and keep asking me these why's -
>>>> it is not my program, I have copied it word for word from D&D (except for
>>>> insignificant change in the file format). Yes, thanks to comments I have
>>>> received in this post, I understand that a few parts, suggested by D&D,
>>>> are not the best choice and I have to avoid them. But my goal here was
>>>> to show the original version and thus to learn why it doesn't do the job,
>>>> and not the corrected one - that would be misleading )
>>>
>>> An eof check at the start of a loop I think is a good way of reading
>>> files (depending on how paranoid you are about unlikely changes to the
>>> file while it is being read).
>>
>> This is bad advice. It's bad because EOF is not the only reason that
>> input can go wrong, and it's particularly bad advice in the specific
>> case here because quite complex input is being done and that can fail
>> for even more reasons.
>>
>> It is almost always better to read while and input operation was
>> successful, than to try to test for the various ways the input can fail.
>> C's input functions tell you if they worked or not for this reason.
>
> An eof() function called in advance is desirable (in the absence of
> exceptions). Someone, knowing they are going to be reading
> sequentially through a file f, can start writing code immediately:
>
> while (!eof(f)) {
> ....
> }
>
> before they even know what's going to go in the loop.
It's not desirable to be able to start writing a bad loop immediately.
You must first make the case that these loops are better.
> Yes, further checking might be needed, because the eof() has only
> verified that there /was/ at least one character left in the file;
> nothing else.
Yes, there will be more checking (except in the case of single byte
reads). There's no "might" about it. If you are talking about C
programs that don't check the actual input, we're not talking about the
same thing at all.
>>> But feof() is not suitable because it gives you a status /after/ a
>>> read attempt has been made. I use a version like this:
>>>
>>> int eof(FILE* f) {
>>> int c;
>>>
>>> c=fgetc(f);
>>> if (c==EOF) return 1;
>>>
>>> ungetc(c,f);
>>> return 0;
>>> }
>>>
>>> Then you just use eof() instead of feof().
>
>> What's more, it does not help in this case. Using your extra function
>> simply complicates the code compared to the idiomatic C version since
>> you still have to test the result from fscanf. Can you give an example
>> where it simplifies the code?
>
> It simplifies the body of a loop as it no longer needs to worry as
> much about an end of file condition.
>
> There might be some setup code or some print statements, that need to
> be done just before the next read. This is now easier to write as you
> don't need to do that setup, or don't need to undo it, and you don't
> have to put the print statements into a condition:
>
> while (!eof()) {
> A;
> B; //read stuff
> C;
> }
>
> Instead of:
>
> A;
> while (B==cond){
> C;
> A;
> }
You need to give an actual example or I can't show the simpler idiomatic
C version, can I? Here you just have two bits of code that do different
things (at least it looks like that from what little detail is given).
This discussion is not a zero-sum, win/loose exchange because I'm not
saying that EOF testing is never better, only that it almost never is.
If you can give an actual example, I'll have a "canonical" exception to
my point and I think you'll find that these cases are rarer than you
thought. We both get something from it.
<snip>
>>> (But then, if a file is changing while you're trying to read it, then
>>> you might as well give up.)
>>
>> Taken literally, I don't think that's right -- lots of programs cope
>> perfectly well reading input that is changing. What specific changes
>> make you think one should give up? Maybe our opinions about when it's
>> worth giving up are simply different.
>
> Just about anything? A file doesn't usually consist of random bytes of
> data; there is usually a relationship between one part of a file and
> another.
>
> If you pause halfway through reading one file (say it's ASCII art),
> run another program which updates it (with a chapter from a novel),
> then continue with the first program, it will now be reading
> nonsense.
Right. And the same thing can happen if the program is presented with
junk data to start with. In what way is "input that changes" different
to "input"? In one case you read, verify and process, but in the other
"you might as well give up"? I don't see it. You just read, verify and
process in all cases.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-10 20:16 +0000 |
| Message-ID | <o2hnp0$mkq$1@dont-email.me> |
| In reply to | #98729 |
On 10/12/2016 19:47, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> If you pause halfway through reading one file (say it's ASCII art), >> run another program which updates it (with a chapter from a novel), >> then continue with the first program, it will now be reading >> nonsense. > > Right. And the same thing can happen if the program is presented with > junk data to start with. In what way is "input that changes" different > to "input"? In one case you read, verify and process, but in the other > "you might as well give up"? I don't see it. You just read, verify and > process in all cases. It's not the same at all. How would you verify my example of an ASCII art file? Or a text file containing a story? Or a C source file which still compiles but the earlier content is now somewhat different? There is a limit to what can be verified with the error codes from a file read function. Suppose you're verifying that a file consists entirely of letter 'A's. The simplest method is to read a character at a time and check that is is 'A'. But how do you know that since you've been reading it, another process has changed a previously read 'A' to a 'B'? If you allow that a file being read is continually changing, then you can't really do anything, even if you managed to detect such a change. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-10 21:11 +0000 |
| Message-ID | <87lgvn1obu.fsf@bsb.me.uk> |
| In reply to | #98730 |
BartC <bc@freeuk.com> writes: > On 10/12/2016 19:47, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> If you pause halfway through reading one file (say it's ASCII art), >>> run another program which updates it (with a chapter from a novel), >>> then continue with the first program, it will now be reading >>> nonsense. >> >> Right. And the same thing can happen if the program is presented with >> junk data to start with. In what way is "input that changes" different >> to "input"? In one case you read, verify and process, but in the other >> "you might as well give up"? I don't see it. You just read, verify and >> process in all cases. > > It's not the same at all. How would you verify my example of an ASCII > art file? Or a text file containing a story? Or a C source file which > still compiles but the earlier content is now somewhat different? > > There is a limit to what can be verified with the error codes from a > file read function. That's not the point. If you can verify the input you do. If you can't you just process it. The point is that you can't tell if the input is changing or was simply wrong to start with. You have to handle (or ignore or process -- your choice) whatever data you get. There is, in this case, nothing special about changing data. > Suppose you're verifying that a file consists entirely of letter > 'A's. The simplest method is to read a character at a time and check > that is is 'A'. But how do you know that since you've been reading it, > another process has changed a previously read 'A' to a 'B'? > > If you allow that a file being read is continually changing, then you > can't really do anything, even if you managed to detect such a change. But there is no need to "give up". You report that the data you saw was either all As or it was not all As. Anyone reading the output should know the program is simply reporting on what it saw at the time. If you meant to say that simple C programs can't give you strong temporal assertion about data it once saw, then no, they can't. But that such a trivial fact it hardly bears stating. When 'cat f' shows me that f contains "hello", I don't assume it still does; I just assume that cat read those characters. The file may change during or after the execution of the cat program, but that makes no difference to me or to the program. There are cases where change causes unique problems but I didn't think we were talking about special cases. Your "if the data changes you might as well give up" sounded very general, but in the vast majority of cases, not only do you not need to give up, you don't even need to do anything special. (Have you got an example of a loop that's simpler with pre-EOF testing yet? I don't want that interesting point to slip away.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-10 22:33 +0000 |
| Message-ID | <o2hvof$hu3$1@dont-email.me> |
| In reply to | #98734 |
On 10/12/2016 21:11, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 10/12/2016 19:47, Ben Bacarisse wrote:
>>> BartC <bc@freeuk.com> writes:
>>
>>>> If you pause halfway through reading one file (say it's ASCII art),
>>>> run another program which updates it (with a chapter from a novel),
>>>> then continue with the first program, it will now be reading
>>>> nonsense.
>>>
>>> Right. And the same thing can happen if the program is presented with
>>> junk data to start with. In what way is "input that changes" different
>>> to "input"? In one case you read, verify and process, but in the other
>>> "you might as well give up"? I don't see it. You just read, verify and
>>> process in all cases.
>>
>> It's not the same at all. How would you verify my example of an ASCII
>> art file? Or a text file containing a story? Or a C source file which
>> still compiles but the earlier content is now somewhat different?
>>
>> There is a limit to what can be verified with the error codes from a
>> file read function.
>
> That's not the point.
The point I think is that past discussions of the usefulness of a
pre-read eof-check have mentioned that the status can be out of date by
the time a read proper takes place. But the same can happen with any
other read in a loop (as can be appreciated if the loop is paused for a
week, for example. By the next read, a lot can have changed).
> There are cases where change causes unique problems but I didn't think
> we were talking about special cases. Your "if the data changes you
> might as well give up" sounded very general, but in the vast majority of
> cases, not only do you not need to give up, you don't even need to do
> anything special.
I assume files don't change while I'm reading them. (Especially as I
usually read entire files so it would be less likely.) I also assume
that an eof status hasn't changed between calling my eof() and a
subsequent read.
> (Have you got an example of a loop that's simpler with pre-EOF testing
> yet? I don't want that interesting point to slip away.)
This is just going to be your opinion versus mine. Last time this was
discussed, you favoured putting as much as possible into a while
condition; I preferred keeping the conditional minimal, except in the
simplest case (reading a character at a time).
To me, divorcing the eof check and the main loop terminating logic from
the actual processing that is done, is a benefit:
while (!eof(f)) {
read stuff...
}
I can see at a glance that this is probably iterating over a file. I can
see that it will definitely end as soon eof() returns true.
It's just an idiom I use a lot (in fact I could go through a pile of
code looking for such while loops, in a way I couldn't do if the loop
condition was always different).
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-10 23:50 +0000 |
| Message-ID | <874m2b1h03.fsf@bsb.me.uk> |
| In reply to | #98742 |
BartC <bc@freeuk.com> writes:
> On 10/12/2016 21:11, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> On 10/12/2016 19:47, Ben Bacarisse wrote:
>>>> BartC <bc@freeuk.com> writes:
>>>
>>>>> If you pause halfway through reading one file (say it's ASCII art),
>>>>> run another program which updates it (with a chapter from a novel),
>>>>> then continue with the first program, it will now be reading
>>>>> nonsense.
>>>>
>>>> Right. And the same thing can happen if the program is presented with
>>>> junk data to start with. In what way is "input that changes" different
>>>> to "input"? In one case you read, verify and process, but in the other
>>>> "you might as well give up"? I don't see it. You just read, verify and
>>>> process in all cases.
>>>
>>> It's not the same at all. How would you verify my example of an ASCII
>>> art file? Or a text file containing a story? Or a C source file which
>>> still compiles but the earlier content is now somewhat different?
>>>
>>> There is a limit to what can be verified with the error codes from a
>>> file read function.
>>
>> That's not the point.
>
> The point I think is that past discussions of the usefulness of a
> pre-read eof-check have mentioned that the status can be out of date
> by the time a read proper takes place.
I was debating what you said about giving up in the face a changes.
I don't want to defend a position I don't hold and you don't agree with
this out-of-date-status notion either, do you?
<snip>
>> There are cases where change causes unique problems but I didn't think
>> we were talking about special cases. Your "if the data changes you
>> might as well give up" sounded very general, but in the vast majority of
>> cases, not only do you not need to give up, you don't even need to do
>> anything special.
>
> I assume files don't change while I'm reading them.
Or you can assume that they do change. It makes no difference. You
read data and you do stuff with it. Neither assumption should make you
just give up.
> (Especially as I
> usually read entire files so it would be less likely.) I also assume
> that an eof status hasn't changed between calling my eof() and a
> subsequent read.
It can't in any sense that matters. The char you read is there waiting
to be read. Your function reports a true state of affairs but programs
don't usually have access to a time-line that can used to tell the
difference between when that was true and "now".
>> (Have you got an example of a loop that's simpler with pre-EOF testing
>> yet? I don't want that interesting point to slip away.)
>
> This is just going to be your opinion versus mine.
And that of anyone who forms an opinion by reading what gets written.
> Last time this was
> discussed, you favoured putting as much as possible into a while
> condition; I preferred keeping the conditional minimal, except in the
> simplest case (reading a character at a time).
But still no example! And despite my penchant for complex conditions,
you don't have to put it there to get the benefit of fewer tests:
while (1) {
double x, y, z
int n = scanf("....", ...);
if (n != 3 || x < y) break;
...
}
But it's /still/ simpler than adding an extra test for eof() because you
have to do the other tests as well.
> To me, divorcing the eof check and the main loop terminating logic
> from the actual processing that is done, is a benefit:
>
> while (!eof(f)) {
> read stuff...
> }
To me it is detrimental since you have to test the input as well, and
C's input functions report all kinds of failure including running out of
data. Is it a coincidence that your example says "read stuff..." but
with no indication of how you test if the read was successful?
> I can see at a glance that this is probably iterating over a file. I
> can see that it will definitely end as soon eof() returns true.
But that's not interesting. The loop may never end (even with finite
input) depending on what "read stuff" does, and we need to look at "read
stuff" to make sure it includes checks that data was properly read. In
other words the eof() is a distraction. That's why C puts the "read
stuff" front and centre -- in the condition -- because it's what
matters.
Your sketch does not even show this crucial test of the input operation,
so there's no way to show how much more complex your loop would really be.
It's the key to why your solution if not optimal.
> It's just an idiom I use a lot (in fact I could go through a pile of
> code looking for such while loops, in a way I couldn't do if the loop
> condition was always different).
That you use it a lot is not in dispute. My gripe is that you advocate
it's use in situations like Alla_'s. Do you at least agree that in this
sort of situation it's better simply to write:
while (scanf("%d,%d,%d", &a, &b, &c) == 3) {
... use a, b and c ...
}
than any solution using your extra eof() function?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-11 00:35 +0000 |
| Message-ID | <o2i6tb$142$1@dont-email.me> |
| In reply to | #98747 |
On 10/12/2016 23:50, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>> It's just an idiom I use a lot (in fact I could go through a pile of
>> code looking for such while loops, in a way I couldn't do if the loop
>> condition was always different).
>
> That you use it a lot is not in dispute.
That suggests that it works!
> My gripe is that you advocate
> it's use in situations like Alla_'s.
The OP's example used feof() as the test. I suggested that, with that
form of loop, it would be better to use a pre-read test similar to my
example.
> Do you at least agree that in this
> sort of situation it's better simply to write:
>
> while (scanf("%d,%d,%d", &a, &b, &c) == 3) {
> ... use a, b and c ...
> }
>
> than any solution using your extra eof() function?
OK, I tried this code on a file containing some numeric triples then
other unrelated unformatted numbers:
int a,b,c,n;
FILE* f;
f=fopen("kkk1","r");
printf("F=%p\n",f);
while ((n=fscanf(f,"%d,%d,%d", &a, &b, &c)) == 3) {
printf("ABC= %d %d %d\n",a,b,c);
}
fclose(f);
printf("N=%d\n",n);
There were no output, but N was given as 1. So I noticed then it was
expecting commas, so put those in. Now it gave some output for this
input file, stopping when it got to the 300:
10,20,30
40,50,60
70,80,90
100,110,120
130,
140,150
160,170,180
190,
200,
210
220,
230,
240
250,260,270 280,290,300
-1
-2
....
I know scanf has some limitations, but that fact that it made sense of
this lax layout was a little surprising. A blank line is ignored, and it
doesn't care if triples are split across lines, or all appear on one
line. But it /does/ care if the last of a triple is followed by a comma,
then it will break out of the loop.
It seems fragile, if the input is supposed to be line-oriented, such as
a CSV file that was mentioned, and won't cope if input can be comma, tab
or space-separated.
And the thing is, I can't see what's happening. The first thing I'd try
is this:
while (fgets(buffer,sizeof(buffer),f)) {
printf("<%.*s>\n",strlen(buffer)-1,buffer);
}
Now it will print out exactly what's in the file, and I can see it
includes blank lines, and conveniently stops at eof (also I'd deleted my
eof function...).
With more confidence, I can instead apply scanf to the buffer, rather
than input, without it reading newlines of its own accord, with this
addition to the loop:
a=b=c=9999;
n=sscanf(buffer,"%d,%d,%d", &a, &b, &c);
printf("ABC= %d %d %d N=%d\n",a,b,c,n);
Now I'm in a position to decide what to do about lines that are blank,
contain a comment, or don't conform to the expected format, without
necessarily aborting the read.
Maybe you might see the benefit of taking the fiddly decision making
logic out of the loop condition, and making the latter worry mainly
about hitting the end of the file. (Here, it will also present the
contents of the next line as a string, in a form that can be processed
by other code that can handle strings, that doesn't even need to know
the data just came from a file.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-10 16:52 -0800 |
| Message-ID | <lnshpvuw0z.fsf@kst-u.example.com> |
| In reply to | #98750 |
BartC <bc@freeuk.com> writes:
> On 10/12/2016 23:50, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>> It's just an idiom I use a lot (in fact I could go through a pile of
>>> code looking for such while loops, in a way I couldn't do if the loop
>>> condition was always different).
>>
>> That you use it a lot is not in dispute.
>
> That suggests that it works!
>
>> My gripe is that you advocate
>> it's use in situations like Alla_'s.
>
> The OP's example used feof() as the test. I suggested that, with that
> form of loop, it would be better to use a pre-read test similar to my
> example.
>
>> Do you at least agree that in this
>> sort of situation it's better simply to write:
>>
>> while (scanf("%d,%d,%d", &a, &b, &c) == 3) {
>> ... use a, b and c ...
>> }
>>
>> than any solution using your extra eof() function?
>
> OK, I tried this code on a file containing some numeric triples then
> other unrelated unformatted numbers:
>
> int a,b,c,n;
> FILE* f;
>
> f=fopen("kkk1","r");
> printf("F=%p\n",f);
>
> while ((n=fscanf(f,"%d,%d,%d", &a, &b, &c)) == 3) {
> printf("ABC= %d %d %d\n",a,b,c);
>
> }
> fclose(f);
>
> printf("N=%d\n",n);
>
> There were no output, but N was given as 1. So I noticed then it was
> expecting commas, so put those in. Now it gave some output for this
> input file, stopping when it got to the 300:
>
> 10,20,30
> 40,50,60
> 70,80,90
>
> 100,110,120
> 130,
> 140,150
> 160,170,180
> 190,
> 200,
> 210
> 220,
> 230,
> 240
> 250,260,270 280,290,300
>
> -1
> -2
> ....
>
> I know scanf has some limitations, but that fact that it made sense of
> this lax layout was a little surprising. A blank line is ignored, and it
> doesn't care if triples are split across lines, or all appear on one
> line. But it /does/ care if the last of a triple is followed by a comma,
> then it will break out of the loop.
This would be surprising to someone who doesn't know how scanf() works.
Using scanf() for line-oriented input is not the best choice. It
generally skips leading white space -- including, among other things,
blanks, tabs, and newlines. The commas in the format string are
required to match literally.
Using scanf("%d,%d,%d", &a, &b, &c) to read CSV input where each line
contains three integer fields can work -- but it fails to detect a lot
of errors. It's good enough for a quick and dirty program, but it's not
robuts. And IMHO the worst problem is that the behavior is undefined if
the scanned value is not within the range of int.
Using fgets() to read a line at a time, then sscanf() to parse the
input, is more robuts. Using fgets() and strtol() is even better; it
lets you detect and handle numeric overflow. Using something that can
handle overly long lines would be even better. The more you want to do,
the more complicated it gets.
> It seems fragile, if the input is supposed to be line-oriented, such as
> a CSV file that was mentioned, and won't cope if input can be comma, tab
> or space-separated.
Correct.
> And the thing is, I can't see what's happening. The first thing I'd try
> is this:
>
> while (fgets(buffer,sizeof(buffer),f)) {
> printf("<%.*s>\n",strlen(buffer)-1,buffer);
> }
And now you're testing the value returned by the input function to
determine when there's no more input. Good.
[...]
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-11 01:34 +0000 |
| Message-ID | <87y3znz1rw.fsf@bsb.me.uk> |
| In reply to | #98750 |
BartC <bc@freeuk.com> writes:
> On 10/12/2016 23:50, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> It's just an idiom I use a lot (in fact I could go through a pile of
>>> code looking for such while loops, in a way I couldn't do if the loop
>>> condition was always different).
>>
>> That you use it a lot is not in dispute.
>
> That suggests that it works!
That, too, has not been in dispute. The dispute is about the benefit.
Despite using it a lot you won't give examples showing that supposed
benefit.
>> My gripe is that you advocate
>> it's use in situations like Alla_'s.
>
> The OP's example used feof() as the test. I suggested that, with that
> form of loop, it would be better to use a pre-read test similar to my
> example.
But it would be best to fix the loop to do the input correctly. That
your suggestion is not as bad as some other code does not make it the
right suggestion to make to someone learning C.
>> Do you at least agree that in this
>> sort of situation it's better simply to write:
>>
>> while (scanf("%d,%d,%d", &a, &b, &c) == 3) {
>> ... use a, b and c ...
>> }
>>
>> than any solution using your extra eof() function?
>
> OK, I tried this code on a file containing some numeric triples then
> other unrelated unformatted numbers:
Will you answer my question? If you don't agree, show me how you write
it better using your eof().
<snip code>
> I know scanf has some limitations, but that fact that it made sense of
> this lax layout was a little surprising.
That's neither surprising nor relevant.
Lots of people don't like scanf, but even if you write your own input
functions you should still write the loop the C way and not the Pascal
way (though you have to write C-style input function that report success
or failure).
> ... The first thing I'd
> try is this:
>
> while (fgets(buffer,sizeof(buffer),f)) {
> printf("<%.*s>\n",strlen(buffer)-1,buffer);
> }
Excellent. You are now looping while an input operation succeeds --
that's the C idiom.
> Now it will print out exactly what's in the file, and I can see it
> includes blank lines, and conveniently stops at eof
... and on input errors.
> (also I'd deleted my eof function...).
Right. And you would not try to make the loop better by adding it back,
would you?
> With more confidence, I can instead apply scanf to the buffer, rather
> than input, without it reading newlines of its own accord, with this
> addition to the loop:
>
> a=b=c=9999;
> n=sscanf(buffer,"%d,%d,%d", &a, &b, &c);
> printf("ABC= %d %d %d N=%d\n",a,b,c,n);
>
> Now I'm in a position to decide what to do about lines that are blank,
> contain a comment, or don't conform to the expected format, without
> necessarily aborting the read.
>
> Maybe you might see the benefit of taking the fiddly decision making
> logic out of the loop condition, and making the latter worry mainly
> about hitting the end of the file. (Here, it will also present the
> contents of the next line as a string, in a form that can be processed
> by other code that can handle strings, that doesn't even need to know
> the data just came from a file.)
Your example has only one input operation and you put it in the right
place. Some people might opt to put some of the processing of the data
(the line in this case) in the condition as well, but that's beside the
point.
I'm not sure what I am now supposed to see since you've written the loop
exactly right. (Well, I presume so -- I can't be sure what the end
result you want is -- but looks exactly right.)
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web