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 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-11 02:25 +0000 |
| Message-ID | <o2idbg$r35$1@dont-email.me> |
| In reply to | #98752 |
On 11/12/2016 01:34, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>> 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.
My eof() also does an input operation where it returns a status
indicating if there are 1 or more characters to read, but that character
stays in the file buffer. fgets returns a similar status and returns the
next line's worth in the local buffer.
But fgets is not as general, there may be other kinds of read to be
done, or it may need some fiddly code when its buffer overflows.
>> 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?
I'd normally write such a loop like this (not C code, but everything is
built on top of C file functions):
while not eof(f) do
readln @f,a, b, c
println a, b, c
od
(This form uses minimal checking, but is line oriented. Missing numbers
on a line, or on a blank line, are zero; extra ones are skipped.
Separators can be anything reasonable.)
(Real example from an old language, one of dozens in a project:
http://pastebin.com/mvJnabKL)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-11 17:11 +0000 |
| Message-ID | <878trmxufh.fsf@bsb.me.uk> |
| In reply to | #98753 |
BartC <bc@freeuk.com> writes:
> On 11/12/2016 01:34, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> 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.
>
> My eof() also does an input operation where it returns a status
> indicating if there are 1 or more characters to read, but that
> character stays in the file buffer.
Sure, but it's just extra complication because it puts the data back.
> fgets returns a similar status and
> returns the next line's worth in the local buffer.
Yes, but it does not put the data back so there is no extra complication
of reading it all again.
If your eof kept the data while indicating success or failure O would
not be complaining about -- I'd just be telling you to call it getc.
> But fgets is not as general, there may be other kinds of read to be
> done, or it may need some fiddly code when its buffer overflows.
Yes, so write your own line input function. My contention has never
been the C's input functions are perfect, just that you should use them
(if you choose to do so) in the simplest, most idiomatic way possible.
And if you do write your better line input function, makes sure it uses
the C pattern of indicating success or failure -- that way you can write
simple loops with no extra testing using your eof function.
>>> 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?
>
> I'd normally write such a loop like this (not C code, but everything
> is built on top of C file functions):
>
> while not eof(f) do
> readln @f,a, b, c
> println a, b, c
> od
>
> (This form uses minimal checking, but is line oriented. Missing
> numbers on a line, or on a blank line, are zero; extra ones are
> skipped. Separators can be anything reasonable.)
Eh? That's not C. You may have found a perfect solution to doing IO,
but I can't even comment on it, let alone write a correct, idiomatic C
version, when I don't have a reference manual for that language.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-11 18:00 +0000 |
| Message-ID | <o2k44t$cbu$1@dont-email.me> |
| In reply to | #98838 |
On 11/12/2016 17:11, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> But fgets is not as general, there may be other kinds of read to be >> done, or it may need some fiddly code when its buffer overflows. > > Yes, so write your own line input function. My contention has never > been the C's input functions are perfect, just that you should use them > (if you choose to do so) in the simplest, most idiomatic way possible. > > And if you do write your better line input function, makes sure it uses > the C pattern of indicating success or failure -- that way you can write > simple loops with no extra testing using your eof function. Suppose you want a line input function that doesn't want to know about a stream? There's this low-level mechanical process to go through to iterate over an file, a character at time, a line at a time, a whole file at a time (or some prefer a unit between a character and a line). And there's the slightly higher level one of extracting your data from that unit. This can work on the bytes already in memory and do not need to concern themselves with i/o errors. >> I'd normally write such a loop like this (not C code, but everything >> is built on top of C file functions): >> >> while not eof(f) do >> readln @f,a, b, c >> println a, b, c >> od > Eh? That's not C. You may have found a perfect solution to doing IO, > but I can't even comment on it, let alone write a correct, idiomatic C > version, when I don't have a reference manual for that language. I agree. How can you possibly work out that it's reading a file by doing an eof check first, then reading a line and extracting 3 values from that line, even when I half-explained what it does! The important thing is the pattern: * Loop over a file while it's not at eof * Read the next line of data * (And here, display that data) There is some fiddly detail to do with extracting data to a certain spec; all I'm saying is, make it separate from the loop logic, and ideally separate from the i/o stuff too (when you're trying to work out if two numbers are separated by a comma or not, you don't want to have to deal with a file error in the middle of that because someone has just pulled out the memory stick!). But it looks like you are a fan of bundling this stuff all together. It makes for a nice, tight solution for a beginner's exercise, but... -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-11 19:44 +0000 |
| Message-ID | <87d1gyw8s6.fsf@bsb.me.uk> |
| In reply to | #98851 |
BartC <bc@freeuk.com> writes:
> On 11/12/2016 17:11, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> But fgets is not as general, there may be other kinds of read to be
>>> done, or it may need some fiddly code when its buffer overflows.
>>
>> Yes, so write your own line input function. My contention has never
>> been the C's input functions are perfect, just that you should use them
>> (if you choose to do so) in the simplest, most idiomatic way possible.
>>
>> And if you do write your better line input function, makes sure it uses
>> the C pattern of indicating success or failure -- that way you can write
>> simple loops with no extra testing using your eof function.
>
> Suppose you want a line input function that doesn't want to know about
> a stream?
I don't know what that means.
> There's this low-level mechanical process to go through to iterate
> over an file, a character at time, a line at a time, a whole file at a
> time (or some prefer a unit between a character and a line).
>
> And there's the slightly higher level one of extracting your data from
> that unit. This can work on the bytes already in memory and do not
> need to concern themselves with i/o errors.
I'm now lost. I don't follow what you are saying here at all.
All I wanted was an actual real-world example -- in C -- where your
eof() function makes the loop simpler (in your eyes). I could then have
a go at writing it in idiomatic C. Other people can the see what they
prefer. I'll get something from it too -- the "best" example where C's
style of IO does not work so well. I suspect it will be somewhat
contrived but so far I've not even a contrived example.
>>> I'd normally write such a loop like this (not C code, but everything
>>> is built on top of C file functions):
>>>
>>> while not eof(f) do
>>> readln @f,a, b, c
>>> println a, b, c
>>> od
>
>> Eh? That's not C. You may have found a perfect solution to doing IO,
>> but I can't even comment on it, let alone write a correct, idiomatic C
>> version, when I don't have a reference manual for that language.
>
> I agree. How can you possibly work out that it's reading a file by
> doing an eof check first, then reading a line and extracting 3 values
> from that line, even when I half-explained what it does!
Please, don't be silly. What are a, b and c? Are they strings,
integers, floating point numbers, S-expressions, unions of all of these?
How are the three "things" recognised? Is there some default parsing
going on? If they are strings, is there a default separator? What if
the separator is missing -- does 'a' get all the line and the code then
prints undefined values? What happens when an IO error occurs? Is
eof(f) really a test for (eof(f) || error(f)) as in your C eof()
function?
Finally, why is that code (whatever it's doing) better than
while readln @f a, b, c do
println a, b, c
od
? It looks simpler to me and I have to guess about fewer things.
So, stop avoiding the key issue and show me a C input loop that is
better using your eof() function. You could also address the question
of whether you agree that at least in the case that started all this
off, the C way is better. And if you don't agree you could show me how
you would write it better using eof().
> The important thing is the pattern:
>
> * Loop over a file while it's not at eof
> * Read the next line of data
> * (And here, display that data)
I don't want a vague pattern, I want a C example. Of course "looping
while not EOF and reading some data" is a simple pattern. It's just
wrong in almost every case for a C input loop.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-11 13:11 -0800 |
| Message-ID | <cbb204c4-0751-4384-b443-1ff5a6bc9cc2@googlegroups.com> |
| In reply to | #98868 |
On Sunday, December 11, 2016 at 1:44:22 PM UTC-6, Ben Bacarisse wrote: > All I wanted was an actual real-world example -- in C -- where your > eof() function makes the loop simpler (in your eyes). I could then have > a go at writing it in idiomatic C. Other people can the see what they > prefer. I'll get something from it too -- the "best" example where C's > style of IO does not work so well. I suspect it will be somewhat > contrived but so far I've not even a contrived example. An ability to determine if a stream has a certain amount of data that is guaranteed to be available can be very useful for things like interactive programs. A text editor, for example, may benefit by deterring many screen updates while input is still pending. If one enters insert mode at the start of a 60-character line and types 10 characters, processing all the screen updates at 1200 baud would take more than 5 seconds. If, however, the editor could defer updates while other characters were still sitting in the input buffer, the updates could complete within a second of when the last character was typed, no matter how quickly or slowly they were output. To be sure, that would likely require not only a means of determining when input characters are available, but also when output characters have reached the far end, but many hardware platforms support such abilities; the only question is how they expose them to programmers.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-11 22:40 +0000 |
| Message-ID | <o2kkir$ea8$1@dont-email.me> |
| In reply to | #98868 |
On 11/12/2016 19:44, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>> Suppose you want a line input function that doesn't want to know about
>> a stream?
>
> I don't know what that means.
That it's only interested in data in memory (numbers and strings) not
grabbing things off some device and having to deal with hardware errors.
>> And there's the slightly higher level one of extracting your data from
>> that unit. This can work on the bytes already in memory and do not
>> need to concern themselves with i/o errors.
>
> I'm now lost. I don't follow what you are saying here at all.
Low level text data from a file is characters or strings.
The next up might be numbers or tokenised strings, names and so on.
>
> All I wanted was an actual real-world example -- in C -- where your
> eof() function makes the loop simpler (in your eyes).
I don't have a C example as I find this stuff impossible in C without
dragging in a bunch of libraries, except for the simplest tasks.
But suppose you show me how it's done with a more typical real-world
example, at least of the sort of files I sometimes deal with.
Then I'll see what I can do, but I already know the loop termination
conditions will be the least of the problems.
Here's a specification:
* You have to read a text file containing 3 floating point numbers per
line and collect them into an array (or three arrays)
* Numbers are separated with spaces, tabs or commas
* Extra white space should be ignored
* Any characters following the three numbers on the rest of a line
should be ignored, but assume the max line length is no more than
100.
* Only lines where the first significant character is the start of a
decimal floating point number contain data. Other lines (blanks, those
starting with # for comment, a keyword, or anything else) should be
ignored
* (I've relaxed a condition that if only one or two numbers are on a
line, the rest should be read as zero. Because there was a bug in
my library when the reading of a FP number encounters a comment.)
Output might be the number of data lines (length of arrays), and perhaps
the sum of each column determined by scanning the array (to
give a reason to keep the data in memory).
Problem areas might be in knowing how many data points there are,
analysing the start of a line to see if it contains data, and ignoring
the stuff that should be ignored.
Example input: http://pastebin.com/UwefwamQ
If this is too much effort just for one of us to make a point, then
leave it.
>> I agree. How can you possibly work out that it's reading a file by
>> doing an eof check first, then reading a line and extracting 3 values
>> from that line, even when I half-explained what it does!
>
> Please, don't be silly. What are a, b and c? Are they strings,
> integers, floating point numbers, S-expressions, unions of all of these?
> How are the three "things" recognised?
You've never come across a Read or Input statement in Basic, Fortran or
Pascal?
(The lot over in c.l.python don't seem to know anything about it either.
You have to read an entire line then use string processing to divide it
up then further work to turn each bit into a number. You'd think reading
numbers from a file is something that may have done before!)
> Is there some default parsing
> going on? If they are strings, is there a default separator? What if
> the separator is missing -- does 'a' get all the line and the code then
> prints undefined values? What happens when an IO error occurs? Is
> eof(f) really a test for (eof(f) || error(f)) as in your C eof()
> function?
'readln' is based on fgets. If there was a read error, then an empty
line would be returned. That would result in 0, 0.0 or "" being read
from the line, and on the next iteration, eof() would return true.
The behaviour happens inside a library, as usually at this level of user
code ('reading a CSV file') hard file errors are not of interest. But
being inside a library, behaviour can be altered without affecting
user-code.
> I don't want a vague pattern, I want a C example. Of course "looping
> while not EOF and reading some data" is a simple pattern. It's just
> wrong in almost every case for a C input loop.
I'm sorry, but unless it's specified as part of the language, then
people can write input loops any way as they like.
I've already explained why I like higher level loops with all the
distinct parts: basic loop control, file errors, character/line reading
and data extraction separated out. And it seems you clearly like to
write this stuff at low-level with everything dealt with in the same place.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-12 02:03 +0000 |
| Message-ID | <87inqpucmw.fsf@bsb.me.uk> |
| In reply to | #98927 |
BartC <bc@freeuk.com> writes:
> On 11/12/2016 19:44, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> Suppose you want a line input function that doesn't want to know about
>>> a stream?
>>
>> I don't know what that means.
>
> That it's only interested in data in memory (numbers and strings) not
> grabbing things off some device and having to deal with hardware
> errors.
OK.
>>> And there's the slightly higher level one of extracting your data from
>>> that unit. This can work on the bytes already in memory and do not
>>> need to concern themselves with i/o errors.
>>
>> I'm now lost. I don't follow what you are saying here at all.
>
> Low level text data from a file is characters or strings.
>
> The next up might be numbers or tokenised strings, names and so on.
I don't see how this relates to input loops.
>> All I wanted was an actual real-world example -- in C -- where your
>> eof() function makes the loop simpler (in your eyes).
>
> I don't have a C example as I find this stuff impossible in C without
> dragging in a bunch of libraries, except for the simplest tasks.
OK, fair enough, but can I then persuade you not to suggest the
technique to people learning C?
> But suppose you show me how it's done with a more typical real-world
> example, at least of the sort of files I sometimes deal with.
>
> Then I'll see what I can do, but I already know the loop termination
> conditions will be the least of the problems.
>
> Here's a specification:
We can do some real C programming! Great. Maybe others would like to
join in too? If so, spoiler alert -- my code is interspersed with the
specification.
> * You have to read a text file containing 3 floating point numbers per
> line and collect them into an array (or three arrays)
I'll assume I can use a fixed maximum number of rows because I don't
think dynamic allocation is what you are asking about. The input is the
issue, not the storage allocation.
Clearly the main program looks like this:
double data[MAX_ROWS][N_COLUMNS];
size_t n_rows = 0;
while (n_rows < MAX_ROWS &&
can_read_numbers(stdin, N_COLUMNS, data[n_rows]))
n_rows += 1;
process_rows(n_rows, N_COLUMNS, data);
> * Numbers are separated with spaces, tabs or commas
Are multiple commas permitted? I'll assume multiple spaces and tabs but
only a maximum of one comma.
> * Extra white space should be ignored
>
> * Any characters following the three numbers on the rest of a line
> should be ignored, but assume the max line length is no more than
> 100.
>
> * Only lines where the first significant character is the start of a
> decimal floating point number contain data. Other lines (blanks, those
> starting with # for comment, a keyword, or anything else) should be
> ignored
That's an odd requirement; the line +++++ meets this specification. Is
that intended? I'm going to assume you want ignore lines that don't
have something that really is a number (i.e. "1" or ".3" or "+2" but not
"-").
That means we get:
bool can_read_numbers(FILE *fp, size_t n_items, double *data)
{
char line[MAX_LINE_LEN + 2]; // for one each for \n and \0
while (fgets(line, sizeof line, fp))
if (find_numbers(line, n_items, data) > 0)
return true;
return false;
}
> * (I've relaxed a condition that if only one or two numbers are on a
> line, the rest should be read as zero. Because there was a bug in
> my library when the reading of a FP number encounters a comment.)
So what should be done with lines that are not ignored but don't have
three numbers? I've chosen to zero the others but it's trivial to
ignore such lines instead:
size_t parse_line(const char *line, size_t n_items, double *data)
{
memset(data, 0, n_items * sizeof *data);
int offset = 0;
size_t n_seen = 0;
while (n_seen < n_items &&
sscanf(line, "%lg %n", &data[n_seen], &offset) == 1) {
line += offset + (line[offset] == ',');
n_seen += 1;
}
return n_seen;
}
> Output might be the number of data lines (length of arrays), and
> perhaps the sum of each column determined by scanning the array (to
> give a reason to keep the data in memory).
You've already said the data should stored in an array. Given the
nature of the problem a stipulation like that is enough
> Problem areas might be in knowing how many data points there are,
> analysing the start of a line to see if it contains data, and ignoring
> the stuff that should be ignored.
>
> Example input: http://pastebin.com/UwefwamQ
Odd. I get slightly different sums, but noticeably so for the third
column. Not sure what's going on. Here's my naive summing function:
void process_rows(size_t rows, size_t cols, double data[rows][cols])
{
double sums[cols];
memset(sums, 0, sizeof sums);
for (size_t r = 0; r < rows; r++)
for (size_t c = 0; c < cols; c++)
sums[c] += data[r][c];
printf("%zu rows. Sums:", rows);
for (size_t c = 0; c < cols; c++)
printf(" %.6f", sums[c]);
putchar('\n');
}
> If this is too much effort just for one of us to make a point, then
> leave it.
Which one of us is making the point? I'm just showing how a program
would be written in (mostly) idiomatic C.
>>> I agree. How can you possibly work out that it's reading a file by
>>> doing an eof check first, then reading a line and extracting 3 values
>>> from that line, even when I half-explained what it does!
>>
>> Please, don't be silly. What are a, b and c? Are they strings,
>> integers, floating point numbers, S-expressions, unions of all of these?
>> How are the three "things" recognised?
>
> You've never come across a Read or Input statement in Basic, Fortran
> or Pascal?
All of them. And in all those cases I could answer my questions but I
can't in this case.
> (The lot over in c.l.python don't seem to know anything about it
> either.
So now you want to be rude? What makes you think I don't know much
about input in Basic, Fortran and Pascal?
> You have to read an entire line then use string processing to
> divide it up then further work to turn each bit into a number. You'd
> think reading numbers from a file is something that may have done
> before!)
>
>> Is there some default parsing
>> going on? If they are strings, is there a default separator? What if
>> the separator is missing -- does 'a' get all the line and the code then
>> prints undefined values? What happens when an IO error occurs? Is
>> eof(f) really a test for (eof(f) || error(f)) as in your C eof()
>> function?
>
> 'readln' is based on fgets. If there was a read error, then an empty
> line would be returned. That would result in 0, 0.0 or "" being read
> from the line, and on the next iteration, eof() would return true.
>
> The behaviour happens inside a library, as usually at this level of
> user code ('reading a CSV file') hard file errors are not of
> interest. But being inside a library, behaviour can be altered without
> affecting user-code.
Well that does not answer my questions, but I suppose that was a long
shot.
>> I don't want a vague pattern, I want a C example. Of course "looping
>> while not EOF and reading some data" is a simple pattern. It's just
>> wrong in almost every case for a C input loop.
>
> I'm sorry, but unless it's specified as part of the language, then
> people can write input loops any way as they like.
Of course they can. But all loops are not good ones simply because they
are not outlawed by the language.
> I've already explained why I like higher level loops with all the
> distinct parts: basic loop control, file errors, character/line
> reading and data extraction separated out. And it seems you clearly
> like to write this stuff at low-level with everything dealt with in
> the same place.
How on earth do you conclude that? I don't think the code I wrote just
now is anything like that.
Now that I've written it, can you show how to improve it, possibly by
testing for eof up front? If not, what was the point of asking how to
do this in C?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-12 12:53 +0000 |
| Message-ID | <o2m6i2$qib$1@dont-email.me> |
| In reply to | #98966 |
On 12/12/2016 02:03, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> I don't have a C example as I find this stuff impossible in C without >> dragging in a bunch of libraries, except for the simplest tasks. > > OK, fair enough, but can I then persuade you not to suggest the > technique to people learning C? I didn't suggest it; the OP's book did, but with an error that I corrected. >> * Numbers are separated with spaces, tabs or commas > > Are multiple commas permitted? I'll assume multiple spaces and tabs but > only a maximum of one comma. Yes, use common sense. The input format is informal; you shouldn't need to use regular-expressions or write a full expression parser. Commas, if used, usually separate things, so ",," suggests there is a missing or empty value. > That's an odd requirement; the line +++++ meets this specification. Is > that intended? I'm going to assume you want ignore lines that don't > have something that really is a number (i.e. "1" or ".3" or "+2" but not > "-"). See above. This type of input is not usually entered by hand, so odd input like this shouldn't be expected. > So what should be done with lines that are not ignored but don't have > three numbers? I've chosen to zero the others but it's trivial to > ignore such lines instead: I made sure all valid lines have three numbers, but zeroing the last one or two numbers is fine. (If the numbers represent 3D points, then often the last might be zero so can space space if suppressed. However the data is random.) > You've already said the data should stored in an array. Given the > nature of the problem a stipulation like that is enough If the size of the input is not known, then you will have issues with creating dynamic storage that grows as the data increases. So you might choose to do two passes, the first of which determines the number of rows. (And you can assume the file doesn't change for the second pass!) But just use hard limits as it's an extra complication that doesn't affect how any one pass scans the file. > Odd. I get slightly different sums, but noticeably so for the third > column. Not sure what's going on. Here's my naive summing function: I tried to run your code but it's missing find_numbers(). Here's what I've assembled so far (altered to read from a file as I found it easier): http://pastebin.com/ePbu67N8 -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-12 13:04 +0000 |
| Message-ID | <o2m767$t5l$1@dont-email.me> |
| In reply to | #99036 |
On 12/12/2016 12:53, BartC wrote: > On 12/12/2016 02:03, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> Odd. I get slightly different sums, but noticeably so for the third >> column. Not sure what's going on. Here's my naive summing function: > > I tried to run your code but it's missing find_numbers(). Here's what > I've assembled so far (altered to read from a file as I found it > easier): http://pastebin.com/ePbu67N8 Hang on, is 'find_numbers' also known as 'parse_line'? That must be it! So leave it with me. But the sums it produces are probably fine. I think the original were summed from the binary, not from the text versions which will have some rounding (and which will have further deviations after converting back to binary). Your results match my own (currently non-C) test code reading from the data. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-12 13:27 +0000 |
| Message-ID | <87fultqnuz.fsf@bsb.me.uk> |
| In reply to | #99036 |
BartC <bc@freeuk.com> writes: > On 12/12/2016 02:03, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> I don't have a C example as I find this stuff impossible in C without >>> dragging in a bunch of libraries, except for the simplest tasks. >> >> OK, fair enough, but can I then persuade you not to suggest the >> technique to people learning C? > > I didn't suggest it; "An eof check at the start of a loop I think is a good way of reading files..." You are clearly suggesting an eof check (including an error check because that's what your eof function does) as a good way of reading files. This whole subthread came about because I don't think you should tell that to people learning C. > the OP's book did, but with an error that I corrected. The book did more than suggest it -- it showed it! All corrections are welcome but it's better to tell people the right way not just a way that's a little bit better. <snip> > Yes, use common sense. Indeed! > I tried to run your code but it's missing find_numbers(). Sorry, I forgot to change the name in the post. There's a function called parse_line that's not being called and a call to find_numbers that is not defines (but takes the same parameters)... By why do you need to run it? The discussion is about the structure of input loops and there is only one of those: while (fgets(line, sizeof line, fp)) ... what would you change about it? And if nothing, what was the point of this example? (I don't mind, I enjoy a bit of coding now and then but it seemed pointless as soon as I saw that the format was line-oriented with a fixed maximum line length.) <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-12 15:16 +0000 |
| Message-ID | <o2meuf$qmg$1@dont-email.me> |
| In reply to | #99040 |
On 12/12/2016 13:27, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > By why do you need to run it? You said there was a difference in the totals. But I also wanted to check if it was all there! (I said in a follow-up that I've now got all the code and managed to run it.) > The discussion is about the structure of > input loops and there is only one of those: > while (fgets(line, sizeof line, fp)) ... > > what would you change about it? Nearly everything? (What else did you expect?) Not helped by being presented as fragments; but even assembled as a whole, I had trouble seeing what was what. It's supposed to be reading a file, but where's the file stuff? I can see one FILE* type somewhere in the middle rather than at one end. Eventually I see this is reading from 'stdin'. (And I forget for a minute exactly how stdin works; will there ever be an eof on stdin if not redirected? If redirected, does input revert to the live console at the end? I suppose it can't do. So at the end of the input, the program can't input anything else, not by any means I can recall. So I changed that to make it read from a file and eliminate that distraction; this.) Then, you say there is one input loop, but the program has two: one calling can_read_numbers(), and a nested one calling fgets(), which I found very confusing. (I discounted the third nested loop where you choose to use a runtime number of columns.) Anyway, I can't follow the logic here, but it appears to work. If I had to make changes though, I'd be stuck. And if nothing, what was the point of > this example? (I don't mind, I enjoy a bit of coding now and then but > it seemed pointless as soon as I saw that the format was line-oriented > with a fixed maximum line length.) (Why would that be pointless? A big proportion of these files ARE line-oriented, and the sensible ones have a reasonable line-length limit (otherwise they are not line-oriented).) Here's a version I made: http://pastebin.com/w5Hwq14N Adapted from auto-generated code, but still not as pretty as I'd've liked. Note that all code below the //-------- line are support functions that would belong in a library. Some are cut-down versions or thrown together for this test. Even so, they are intended to be general purpose, not only useful for this one task. That leaves all the actual logic of the program inside the main function: * Open the file * Scan LINEARLY through the file while we haven't reached the end * If this is a data line, read X,Y,Z otherwise ignore it * Close the file * Scan the data to sum it -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-12 23:00 +0000 |
| Message-ID | <87bmwgpxbs.fsf@bsb.me.uk> |
| In reply to | #99062 |
BartC <bc@freeuk.com> writes: > On 12/12/2016 13:27, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >> By why do you need to run it? > > You said there was a difference in the totals. But I also wanted to > check if it was all there! (I said in a follow-up that I've now got > all the code and managed to run it.) > > >> The discussion is about the structure of >> input loops and there is only one of those: > > >> while (fgets(line, sizeof line, fp)) ... >> >> what would you change about it? > > Nearly everything? (What else did you expect?) I expect you to say how adding an eof() call makes the loop easier to write, but since you can't follow my code I suppose you can't say how. > Not helped by being presented as fragments; but even assembled as a > whole, I had trouble seeing what was what. The input processing is 19 lines of C (22 if you count the function prototypes) so I'm surprised it's a challenge, but I look forward to seeing your clearer version. > It's supposed to be reading a file, but where's the file stuff? There are 19 lines to look at, 5 of which are declarations and 3 are return statements. It's not exactly a needle in haystack, especially as only one function takes a FILE *. I'd start looking there for the file stuff. Now /that/ function is a full 5 line long, 3 of which are either declarations or returns. Where could the file stuff possibly be? Which of those two lines is doing file stuff? One says if (find_numbers(line, n_items, data) > 0) but the FILE pointer is not passed to that function so that's not doing file stuff. Ah, there is is, the other line: while (fgets(line, sizeof line, fp)) > I can > see one FILE* type somewhere in the middle rather than at one > end. Eventually I see this is reading from 'stdin'. > > (And I forget for a minute exactly how stdin works; will there ever be > an eof on stdin if not redirected? If redirected, does input revert to > the live console at the end? I suppose it can't do. So at the end of > the input, the program can't input anything else, not by any means I > can recall. So I changed that to make it read from a file and > eliminate that distraction; this.) You'd have to learn how your C implementation works, but none of that has any impact on the code which is standard C -- it reads a stream in the manner you specified (at least I hope it does). > Then, you say there is one input loop, but the program has two: one > calling can_read_numbers(), and a nested one calling fgets(), which I > found very confusing. The term "input loop" is not very well defined, is it? Feel free to call it two -- one uses C's input primitives the other calls a function the uses C's input primitives. It's a shame you found it confusing but it will be a useful contrast with your version. > (I discounted the third nested loop where you > choose to use a runtime number of columns.) > > Anyway, I can't follow the logic here, but it appears to work. If I > had to make changes though, I'd be stuck. OK, sorry about that but there's no need to change it. Since the task can be done in less than two dozen lines, you might as well start from scratch. >> And if nothing, what was the point of >> this example? (I don't mind, I enjoy a bit of coding now and then but >> it seemed pointless as soon as I saw that the format was line-oriented >> with a fixed maximum line length.) > > (Why would that be pointless? A big proportion of these files ARE > line-oriented, and the sensible ones have a reasonable line-length > limit (otherwise they are not line-oriented).) > Here's a version I made: http://pastebin.com/w5Hwq14N > > Adapted from auto-generated code, but still not as pretty as I'd've > liked. What's the point of posting machine generated code? It's bound to terrible in terms of style. Do you just want to avoid any discussion of readability, style or simplicity? You can't, however, avoid discussion of correctness and your code is buggy and, depending on how your "use common sense" was to be interpreted, it does not even meet the specification. Since it's machine generated, I can't claim that any of the bugs are due to not doing things the C way, but it does look like that on the surface. > Note that all code below the //-------- line are support functions > that would belong in a library. Some are cut-down versions or thrown > together for this test. Even so, they are intended to be general > purpose, not only useful for this one task. > > That leaves all the actual logic of the program inside the main function: > > * Open the file > * Scan LINEARLY through the file while we haven't reached the end > * If this is a data line, read X,Y,Z otherwise ignore it > * Close the file > * Scan the data to sum it Since the code is incorrect, any claims of being clearer or simpler are rather premature. Do you plan to debug this code or start again from scratch? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-13 00:59 +0000 |
| Message-ID | <o2nh3d$tqh$1@dont-email.me> |
| In reply to | #99145 |
On 12/12/2016 23:00, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> Nearly everything? (What else did you expect?) > > I expect you to say how adding an eof() call makes the loop easier to > write, but since you can't follow my code I suppose you can't say how. The structure is wrong in my eyes. >> It's supposed to be reading a file, but where's the file stuff? > > There are 19 lines to look at, 5 of which are declarations and 3 are > return statements. It's not exactly a needle in haystack, especially as > only one function takes a FILE *. I'd start looking there for the file > stuff. There isn't any proper file stuff. You'd usually start off with the name of the file where this data resides. You chose to use stdin which was a little strange. >> Here's a version I made: http://pastebin.com/w5Hwq14N >> >> Adapted from auto-generated code, but still not as pretty as I'd've >> liked. > > What's the point of posting machine generated code? It's bound to > terrible in terms of style. Only in detail. Not overall structure. > Do you just want to avoid any discussion of > readability, style or simplicity? You've got this block of data in a file, how would you give instructions in English to read it? Possibly: 1. Open the file (and do the usual error checks) 2. Are we at the end of the file? If so proceed to step 8 3. Grab the next line 4. Read the first thing on the line 5. If it could be a number, convert it to a number, and read two more. 6. Add the three numbers to a list 7. Repeat from step 2 8. Close the file, sum the data, give the totals Notice that this is nothing like your C version. > You can't, however, avoid discussion of correctness and your code is > buggy I've found two: one due to the unexpected behaviour of strchr() which can add extra data points. The other is not checking whether the arrays overflow. Neither is anything to do with structure. The code was ported from the original here: http://pastebin.com/3M9Ab1DD This pretty much matches my algorithm. > and, depending on how your "use common sense" was to be > interpreted, it does not even meet the specification. Since it's > machine generated The original isn't machine generated, and doesn't have those two bugs (but displays the number of rows that would have helped with the C). IMO that is perfectly straightforward. The task was to port it to C (via another language, but that's a detail) and sort out the support that might be needed. But we've been here a few times before: you post some clever, but impenetrable solution to a task in something like Haskell, which I revolt against and post something perfectly plain and simple in my own language. It does rather strike me that you like to keep things complicated! Or maybe simple code -- that's understandable to everyone not just the conoscenti - is not enough of a challenge. It /has/ to be a head-scratcher. > Since the code is incorrect, any claims of being clearer or simpler are > rather premature. Do you plan to debug this code or start again from > scratch? No, I'm confident that the algorithm is sound. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-13 03:25 +0000 |
| Message-ID | <87mvg0o6hk.fsf@bsb.me.uk> |
| In reply to | #99163 |
BartC <bc@freeuk.com> writes:
> On 12/12/2016 23:00, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> Nearly everything? (What else did you expect?)
>>
>> I expect you to say how adding an eof() call makes the loop easier to
>> write, but since you can't follow my code I suppose you can't say how.
>
> The structure is wrong in my eyes.
>
>>> It's supposed to be reading a file, but where's the file stuff?
>>
>> There are 19 lines to look at, 5 of which are declarations and 3 are
>> return statements. It's not exactly a needle in haystack, especially as
>> only one function takes a FILE *. I'd start looking there for the file
>> stuff.
>
> There isn't any proper file stuff. You'd usually start off with the
> name of the file where this data resides. You chose to use stdin which
> was a little strange.
I try (and probably fail) not to think that everyone has the same
outlook as I do. There's no reason for you to assume that I'd do that
or find using a FILE * as strange. If you want a function that uses a
named file, I would always write the function to process a FILE * and
add a one-line wrapper round it that opens a file.
As for using stdin as the FILE *, I find testing a program by supplying
data on stdin very much easier than testing one that has a hard-wired
file name in it but YMMV.
>>> Here's a version I made: http://pastebin.com/w5Hwq14N
>>>
>>> Adapted from auto-generated code, but still not as pretty as I'd've
>>> liked.
>>
>> What's the point of posting machine generated code? It's bound to
>> terrible in terms of style.
>
> Only in detail. Not overall structure.
I suspect the key issue of this debate (eof testing) is due to that
translation. You source language seems to have input statements rather
than input functions. As a result, you have to write (sketching here)
while not eof:
readLn x, y, z
...
done
That style therefore carries over into the C code where it's not
idiomatic:
while (!myeof(f)) {
readlinen(f,(char *)&line,1000);
...
}
This could be simplified by removing one line and one whole function if
readlinen returned success/failure:
while (readlinen(f,(char *)&line,1000)) {
...
}
Also, because your readLn statement ignores errors (or seems to at least
-- I have no reference material for this language) the translated C does
so as well. strtofloat and readfloat apparently can't fail so you can't
write the (usually) much more useful pattern of
while (readlinen(f,(char *)&line,1000)) {
if (line does not have three numbers)
continue; /* or break -- your choice */
... process those numbers ...
}
with any ease. I suspect your specification was designed to match what
this language does easily -- try to read a number but press on anyway if
none was found.
My version can also accommodate such a change with only small localised
edits. I think your structure is more rigid that that. I looked, and
it seems quite a few scattered changes would be needed to do this.
<snip>
> But we've been here a few times before: you post some clever, but
> impenetrable solution to a task in something like Haskell, which I
> revolt against and post something perfectly plain and simple in my own
> language.
This is entirely different. Here we are talking about C and how best to
do input. Your language is only relevant in that I think some of the
faults in the the C may come from the translation (I can't be sure), and
I've posted no Haskell at all.
If you did not keep referencing your language, the whole sub-thread
could have remained entirely about C.
> It does rather strike me that you like to keep things complicated! Or
> maybe simple code -- that's understandable to everyone not just the
> conoscenti - is not enough of a challenge. It /has/ to be a
> head-scratcher.
Maybe, but in this case the structure of my code did not come from that.
It came from a step-wise refinement of your specification, and some
considerable experience in trying to write code that I can reason about.
For me, it is important that I can look a few lines and answer questions
like: is the index always in range? Will the code always return a valid
result? The answers to these questions are little informal proofs in my
mind.
I find bugs in reverse -- by failing to prove these things. For
example, when looking at your code:
p = *lineptr;
q = item;
length = 0;
while (*p == ' ' || *p == 9) {
++p;
}
while (1) {
c = *p++;
if ((c==0)) {
--p;
break;
} else if ((c==' ') || (c==9) || (c==',')) {
break;
}
if (length < size) {
*q++ = c;
++length;
}
}
*q = 0;
I wanted to be sure that, here, where *q is written, q-item < size was
bound to be true. If no the access could be out of bounds. I could not
prove that. As I reasoned about the code I could see that
* item does not change.
* q is advanced only when length is advanced.
* length starts at zero as does q-item
* therefore q-item == length (except between two lines).
* If p points to enough digits (zeros will do) then length will be
incremented until it is == size.
* That means *q = 0 can be an out of bounds access.
Not formal, but it usually works well enough.
I would write that function so as to make that proof (the proof that
it's not out of bounds) as simple as possible. It's one reason I like
small scopes and small functions. (You would probably call the result
contrived, so I won't waste the time to do it here.)
>> Since the code is incorrect, any claims of being clearer or simpler are
>> rather premature. Do you plan to debug this code or start again from
>> scratch?
>
> No, I'm confident that the algorithm is sound.
But the program isn't. Surely that matters?
What was the point of setting this example? Wasn't it about writing
correct code that solves a particular problem so that different
approaches can be compared? The fact that you don't yet have a solution
would suggest that your approach is not working that well.
But I could cut to the chase: remove the eof function altogether, make
readlinen return a status and move the call of it into the while loop.
Your program will then be simpler and more idiomatic. In that sense,
the bugs don't matter other than as a measure of the complexity of the
rest of the code.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-13 13:08 +0000 |
| Message-ID | <o2orq4$p06$1@dont-email.me> |
| In reply to | #99172 |
On 13/12/2016 03:25, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > Also, because your readLn statement ignores errors If there's anything wrong then an empty string is produced. At this point, one character is known to be ready, but it's possible the next line is a billion characters and there are a number of things that could go wrong before it's read all billion of them: * The input buffer gets full, assuming there's no scheme to extend it * If there is, then memory is exhausted * There is a hard file error. Or disk error. Or network error. The thing is, in a program that reads a 20-line configuration file, you don't really want to deal comprehensively with all those possibilities. > (or seems to at least > -- I have no reference material for this language) the translated C does > so as well. strtofloat and readfloat apparently can't fail Fail in what way? Either a bunch of characters contain something that can be interpreted as a floating point number at the start, or they don't. If not then I'm happy with a return value of 0.0 (perhaps set when sscanf returns 0). Otherwise, how do you represent several possibilities (parsing error, range overflow etc) in a floating point return value? (For that matter, how does atol() do it?) >> But we've been here a few times before... > This is entirely different. Here we are talking about C and how best to > do input. I don't think it should be tied so much to a language. Reading stuff from a file is reading stuff from a file. > If you did not keep referencing your language, the whole sub-thread > could have remained entirely about C. My dynamic language (most such languages actually - except your esoteric ones) tends to correspond with the pseudo-code someone might write to do a task. That needs to be adapted a little for a lower-level one like C. But you're suggesting the nature of such a language means the pseudo-code should be entirely different? > I find bugs in reverse -- by failing to prove these things. For > example, when looking at your code: > ... As I reasoned about the code I could see that > > * item does not change. > * q is advanced only when length is advanced. > * length starts at zero as does q-item > * therefore q-item == length (except between two lines). > * If p points to enough digits (zeros will do) then length will be > incremented until it is == size. > * That means *q = 0 can be an out of bounds access. > > Not formal, but it usually works well enough. I would just print the values of q+1-item, and size, and try with very small values of 'size', if I wanted to test corner cases. I don't reason with code, I just run it. (And you're right, the code doesn't take account of space for the terminator, so I'd have to use 'size-1' with a stipulation that size is at least 1. For this test, I just made item[] large enough to make it work without hassle. That I bothered to pass a 'size' parameter at all obviously didn't impress you!) > What was the point of setting this example? Wasn't it about writing > correct code that solves a particular problem so that different > approaches can be compared? The fact that you don't yet have a solution > would suggest that your approach is not working that well. There is still nothing wrong with this approach. You don't discount it altogether just because my hastily thrown-together demo had bugs in some details. Maybe someone else would have produced something with the same structure - the same 'main' function - and used proven library functions or took more care in testing. But the extra support functions needed to make this work only need writing - and debugging - once. > But I could cut to the chase: remove the eof function altogether, make > readlinen return a status and move the call of it into the while loop. Yes, that's another general-purpose option, to have the loop condition deliver the next line as a string (ideally, with cr/lf stripped), and to itself return a status. Everything within the body of the loop then is working with in-memory strings and can forget about file errors. (I tend not to use that in interpreted code because my line-reading function returns the line itself, not an eof/error status.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-13 05:56 -0800 |
| Message-ID | <aedc5918-91dc-4830-9bd6-1445aadab492@googlegroups.com> |
| In reply to | #99185 |
On Tuesday, December 13, 2016 at 1:08:47 PM UTC, Bart wrote: > On 13/12/2016 03:25, Ben Bacarisse wrote: > > The thing is, in a program that reads a 20-line configuration file, you > don't really want to deal comprehensively with all those possibilities. > The real question is who maintains the config file. If the config file always resides in the same place as the program source which is accessible to a C compiler, you don't need to worry about malice or accidental "corrupt everything" situations, because the attacker can just as easily add malware to your C program. If the config file is maintained by non-technical users, and is the only thing remotely code-like that they are expected to work with, someone has made a poor design choice, and as programmer you need to mitigate that as much as possible by being very comprehensive in flagging up problems in the config file and directing the users to help. > > Otherwise, how do you represent several possibilities (parsing error, > range overflow etc) in a floating point return value? (For that matter, > how does atol() do it?) > The number should be represented as NaN. If possible, the reason should also be reported (French users might not understand that comma is not a decimal point, scientific users might think exponent notation is supported when it isn't etc).
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-13 15:31 +0000 |
| Message-ID | <o2p469$nti$1@dont-email.me> |
| In reply to | #99198 |
On 13/12/2016 13:56, Malcolm McLean wrote: > On Tuesday, December 13, 2016 at 1:08:47 PM UTC, Bart wrote: >> On 13/12/2016 03:25, Ben Bacarisse wrote: >> >> The thing is, in a program that reads a 20-line configuration file, you >> don't really want to deal comprehensively with all those possibilities. >> > The real question is who maintains the config file. > If the config file always resides in the same place as the > program source which is accessible to a C compiler, you don't > need to worry about malice or accidental "corrupt everything" > situations, because the attacker can just as easily add > malware to your C program. > > If the config file is maintained by non-technical users, and > is the only thing remotely code-like that they are expected to > work with, someone has made a poor design choice, and as > programmer you need to mitigate that as much as possible by > being very comprehensive in flagging up problems in the config > file and directing the users to help. Verifying the integrity of the file is a different matter. Suppose the contents of the file were read in by a convenient, general purpose function that presented them as an array of strings, and a length (number of strings or lines). (With file errors denoted by a negative length if you like.) Then any verification you might do will have nothing whatever to do with file errors, any more than a missing semicolon on line 617 of a C file should be lumped together with 'illegal filename' kinds of errors. (Some file formats might be designed to be processed while being transmitted; a video stream perhaps. Then content and transmission errors may be linked. But you wouldn't really use a simple while !eof() loop for that.) >> Otherwise, how do you represent several possibilities (parsing error, >> range overflow etc) in a floating point return value? (For that matter, >> how does atol() do it?) >> > The number should be represented as NaN. If possible, the reason > should also be reported. Conversion in both the programs in this sub-thread are done by sscanf. I'd have to look at the docs to see what FP value that gives you. But I understand it will return status 0 instead of 1 if it fails to convert a string to a float. Apart from that I've never used or checked for NaN; I like to live dangerously! (The first software FP library I think did use the encoding for infinity for some types of error, and I used that later on too. I don't know when NaN came along.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-13 08:27 -0800 |
| Message-ID | <lnmvfzpzef.fsf@kst-u.example.com> |
| In reply to | #99185 |
BartC <bc@freeuk.com> writes:
> On 13/12/2016 03:25, Ben Bacarisse wrote:
> > BartC <bc@freeuk.com> writes:
>
> > Also, because your readLn statement ignores errors
>
> If there's anything wrong then an empty string is produced.
Isn't an empty string also a valid result?
> At this point, one character is known to be ready, but it's possible the
> next line is a billion characters and there are a number of things that
> could go wrong before it's read all billion of them:
>
> * The input buffer gets full, assuming there's no scheme to extend it
>
> * If there is, then memory is exhausted
>
> * There is a hard file error. Or disk error. Or network error.
>
> The thing is, in a program that reads a 20-line configuration file, you
> don't really want to deal comprehensively with all those possibilities.
And that's where exploits come from. If I can break your program by
providing a config file with very long lines, you could have a security
hole.
> > (or seems to at least
> > -- I have no reference material for this language) the translated C does
> > so as well. strtofloat and readfloat apparently can't fail
>
> Fail in what way? Either a bunch of characters contain something that
> can be interpreted as a floating point number at the start, or they
> don't. If not then I'm happy with a return value of 0.0 (perhaps set
> when sscanf returns 0).
So you're happy not bothering to distinguish between an invalid
floating-point number and a valid floating-point number with the
value 0.0. I wouldn't be.
> Otherwise, how do you represent several possibilities (parsing error,
> range overflow etc) in a floating point return value? (For that matter,
> how does atol() do it?)
atol() doesn't do it; the ato*() functions don't detect errors. Use the
strto*() functions for that.
[snip]
--
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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-13 18:07 +0000 |
| Message-ID | <o2pdb2$qqr$1@dont-email.me> |
| In reply to | #99216 |
On 13/12/2016 16:27, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 13/12/2016 03:25, Ben Bacarisse wrote: >> > BartC <bc@freeuk.com> writes: >> >> > Also, because your readLn statement ignores errors >> >> If there's anything wrong then an empty string is produced. > > Isn't an empty string also a valid result? It can be. But then nothing can be read from it, and the next eof check will be true. >> The thing is, in a program that reads a 20-line configuration file, you >> don't really want to deal comprehensively with all those possibilities. > > And that's where exploits come from. If I can break your program by > providing a config file with very long lines, you could have a security > hole. Actually it's more likely to be broken by a line-reading routine that just allocates as much memory as those long lines demands. My code (not shown in the examples) checks for such lines. (Exactly what it does will vary, but this is not intended to be a preoccupation of the typical line-by-line-reading user-code. If this is part of an interpreted language's library, it might choose to generate an exception that user code can catch. For static code, anything I might do along those lines needs to be implementable in C. I think that C's setjump/longjmp can just about manage some exception processing, but I don't think user code in C will be readable. At the moment it just aborts. Then I just step up the buffer size and try again! A size of 1MB deals with most files that are 'line-oriented') Have a look at the Rosetta Code 'read a file line-by-line' task: https://www.rosettacode.org/wiki/Read_a_file_line_by_line Very few of the examples worry about such matters. The read a line, and write it out again. Although whoever did the C example clearly had some difficulty as it has this note: "This is not easy to do, because the C library is so primitive." I don't think it's that bad! I suspect many of the other examples will also have some difficulty if asked to deal with billion-character lines. >> Fail in what way? Either a bunch of characters contain something that >> can be interpreted as a floating point number at the start, or they >> don't. If not then I'm happy with a return value of 0.0 (perhaps set >> when sscanf returns 0). > So you're happy not bothering to distinguish between an invalid > floating-point number and a valid floating-point number with the > value 0.0. I wouldn't be. Well, then you have to code appropriately if you're after a zero-tolerance approach as though you were strictly compiling source code for a language. This task is just re-reading groups of numbers that were probably written by another program within an informal file layout. Sometimes you have to know how far to go with these things. But it seems that reading data from a file is one of those tasks that, in c.l.c, nothing other than absolute perfection is tolerated: * Pseudo-random number generation * Reading a line of text that could conceivably be of any length (no matter if it brings down the machine) * And now, reading a number. (Of course, reading spurious data due to someone typing * is not an issue! But the "123" in "123ABC" must be wrong.) > atol() doesn't do it; the ato*() functions don't detect errors. That's fine then. Some of my functions don't detect errors either and therefore shouldn't be used in mission-critical programs. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-13 18:12 +0000 |
| Message-ID | <o2pdiu$rsc$1@dont-email.me> |
| In reply to | #99220 |
On 13/12/16 18:07, BartC wrote: > On 13/12/2016 16:27, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: >>> On 13/12/2016 03:25, Ben Bacarisse wrote: >>> > BartC <bc@freeuk.com> writes: >>> >>> > Also, because your readLn statement ignores errors >>> >>> If there's anything wrong then an empty string is produced. >> >> Isn't an empty string also a valid result? > > It can be. But then nothing can be read from it, and the next eof check > will be true. In which case, presumably you don't strip the newline from the input. This makes the function a little less convenient than it might otherwise be. <snip> > Although whoever did the C example clearly had some difficulty as it has > this note: > > "This is not easy to do, because the C library is so primitive." Ha! "I had to write some code. Poor me." My heart bleedeth. > But it seems that reading data from a file is one of those tasks that, > in c.l.c, nothing other than absolute perfection is tolerated: Would you want it any other way? -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
Page 3 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