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 213 — 23 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 raltbos@xs4all.nl (Richard Bos) - 2016-12-27 20:19 +0000
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 Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 13:27 -0800
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 13:41 -0800
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-29 13:57 -0800
Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2016-12-29 22:55 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-29 15:34 -0800
Re: while loop vs do while loop reading from the file issue Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 02:51 -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 Les Cargill <lcargill99@comcast.com> - 2016-12-26 14:30 -0600
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 03:48 +0000
Re: while loop vs do while loop reading from the file issue Les Cargill <lcargill99@comcast.com> - 2016-12-28 07:15 -0600
Re: while loop vs do while loop reading from the file issue Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 01:05 -0800
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-29 13:25 -0800
Re: while loop vs do while loop reading from the file issue Ian Collins <ian-news@hotmail.com> - 2016-12-30 10:48 +1300
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 16:46 -0800
Re: while loop vs do while loop reading from the file issue Ian Collins <ian-news@hotmail.com> - 2016-12-30 13:51 +1300
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 17:22 -0800
Re: while loop vs do while loop reading from the file issue Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 02:45 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-30 01:01 +0000
Re: while loop vs do while loop reading from the file issue Ian Collins <ian-news@hotmail.com> - 2016-12-30 14:04 +1300
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 17:23 -0800
Re: while loop vs do while loop reading from the file issue asetofsymbols@gmail.com - 2016-12-30 00:56 -0800
Re: while loop vs do while loop reading from the file issue Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 02:41 -0800
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 09:59 -0800
Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2017-01-13 18:48 +0000
Re: while loop vs do while loop reading from the file issue Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 12:08 -0800
Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2017-01-15 23:09 +0000
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2017-01-15 23:18 +0000
Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2017-01-15 23:37 +0000
Re: while loop vs do while loop reading from the file issue raltbos@xs4all.nl (Richard Bos) - 2017-01-18 11:32 +0000
Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2017-01-18 21:25 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2017-01-13 11:54 -0800
Re: while loop vs do while loop reading from the file issue Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 11:58 -0800
Re: while loop vs do while loop reading from the file issue Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 12:05 -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 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-14 10:03 +0100 |
| Message-ID | <o2r1pj$k59$1@dont-email.me> |
| In reply to | #99304 |
On 14/12/16 03:33, Richard Heathfield wrote:
> On 14/12/16 01:56, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> On 14/12/2016 00:08, Ben Bacarisse wrote:
>>>> BartC <bc@freeuk.com> writes:
>> [...]
>>>>> p = (buffer+n)-1;
>>>>
>>>> Why the brackets?
>>>
>> [...]
>>> And I just noticed you called them brackets. I think I'll do that from
>>> now on too. A lot easier to type.)
>>
>> Calling these: () "brackets" seems to be UK usage.
>
> Perhaps, but not in all parts of the UK. I use (parentheses),
> [brackets], and {braces}, as you do.
>
I think that is one of these program/programme things. For British
English speakers, it is common (but not universal) to call ()
"parentheses" in programming contexts, following the American wording.
But in other contexts, such as mathematics, the traditional British term
is "brackets" (with "square brackets" and "round brackets" used if there
is a need to distinguish them).
If I were writing about programming and making an effort to be clear,
I'd write (parentheses). But when speaking, or writing informally,
where the context and the type of brackets is clear, I might well write
(brackets). It's easier to spell :-)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-14 02:09 +0000 |
| Message-ID | <87k2b38dod.fsf@bsb.me.uk> |
| In reply to | #99300 |
BartC <bc@freeuk.com> writes:
> On 14/12/2016 00:08, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>> <snip>
>>
>>> int myeof (FILE * f) {
>>> int c;
>>> c = fgetc(f);
>>> if (c == EOF) {
>>> return 1;
>>> }
>>> ungetc(c,f);
>>> return 0;
>>> }
>>>
>>> void myfgets(char * buffer,int size, FILE* handle) {
>>
>> Just be making myfgets return a status (or count or other useful
>> information) you can shorten your program by one line and a whole
>> pointless function. No need to switch to fgets if you don't like its
>> behaviour, you can use your and still have a simpler, more idiomatic
>> program.
>
> Yes, maybe a return value can be added for a more general function
> (the original was only called in one place). And the result can
> sometimes be used in place of discrete myeof and mygets calls.
In what situations can a properly written myfgets call /not/ be used in
place of the myeof/myfgets pair? You say "sometimes" like it might
occur now and then, but with a significant number of cases where you
can't use it in place of the pair.
>> For anyone learning C, a tip: it is rare to write "void functions".
>> When you do write one, think about whether you are wasting an
>> opportunity to tell your caller something useful -- a success/failure
>> indication, a count, or maybe just a value that might be useful for
>> chaining calls. You will sometimes conclude there is nothing but you
>> might be surprised how rare it it.
>
> I find void functions useful. (Actually outside of C I call them
> 'procs' instead of 'functions'.)
>
> They make me think harder about what a routine is doing, and whether
> it ought to be returning a value or not.
Yup. That's my point exactly. What hard thought led you to decide that
myfgets ought not to return a value? I come to exactly the opposite
conclusion (as you know).
> A void function can't be called inside an expression which can be
> another advantage.
>
>>> p = (buffer+n)-1;
>>
>> Why the brackets?
>
> (They used to have an extra set all round that I removed manually. The
> parentheses-suppressing code of my translator had only been added to
> normal add/sub operators, not addptr/subptr which are handled
> separately.
Ah, right. You skipped the question about the mysterious -2 in the size
passed to fgets. Is that some odd translation artefact too? It's
significant because it may lead to too small a size being passed.
>
> And I just noticed you called them brackets. I think I'll do that from
> now on too. A lot easier to type.)
>
>>
>>> while (p >= buffer && (*p == 13 || *p == 10)) {
>>> *p-- = 0;
>>> }
>>
>> This has undefined behaviour when, for example, the buffer has only a
>> newline in it (amongst other cases). It's "only" technically undefined,
>> so maybe you don't mind.
>
> You mean when p-- ends up pointing before the buffer? OK.
Yup.
<snip>
>> why do you remove CR characters that are /not/ part of the line ending?
>
> I don't allow for individual CR or LF within a line.
I'm not sure what "allow for" means. You remove some lone CRs that are
not part of the line ending and not others.
<snip>
> Anyway I get rid of all these controls where I can, but I'm not going
> to search the entire buffer for stray CRs.
Yes, but why? It seems odd to me. Generally I prefer input functions
to do as little alteration as possible and removing some CR character
that are not part of the line ending (but, as you say, not all CRs)
seems very peculiar. (I would not even remove the line ending.)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-14 12:24 +0000 |
| Message-ID | <o2rdk1$qjr$1@dont-email.me> |
| In reply to | #99302 |
On 14/12/2016 02:09, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> Yes, maybe a return value can be added for a more general function >> (the original was only called in one place). And the result can >> sometimes be used in place of discrete myeof and mygets calls. > > In what situations can a properly written myfgets call /not/ be used in > place of the myeof/myfgets pair? You say "sometimes" like it might > occur now and then, but with a significant number of cases where you > can't use it in place of the pair. Where the body of the loop doesn't always read a line of text. It might be reading characters, blocks of bytes, using scanf, or it might be mixed. Or you just don't know so myeof() is a good starting point while you're developing the code. But look here: https://www.rosettacode.org/wiki/Read_a_file_line_by_line Out of 100 or so languages, about 20% of them are using an explicit pre-read EOF check. Including most of the Basics and Pascals. I don't think it's a coincidence either that those were amongst the easiest to understand. (Half of the rest, I'd hadn't a clue what was going on.) And this was specifically a task to read a line at a time and write it out again, ideal for using an fgets/myfgets approach where the line is read and that produces a status. Many of the rest did just that. > Ah, right. You skipped the question about the mysterious -2 in the size > passed to fgets. Is that some odd translation artefact too? It's been there for years. Maybe I just didn't trust fgets enough. Or maybe the original was pre-fgets and I was working by reading blocks of bytes looking for possible newlines. Basically, I don't know. But I do like my margins. > I'm not sure what "allow for" means. You remove some lone CRs that are > not part of the line ending and not others. Figuring out which were part of the line ending would take too long (having to do strlen is bad enough). I don't want stray CRs anyway. > (I would not even remove the line ending.) That figures! You start with strings "one", "two", "three" - notice no newlines - and you want to write them to a file so they can be recalled later. However, they would be written as "onetwothree", so you need a separator. 'newline' fills the role and is compatible with other viewers and readers of the file which will tidily show the contents on separate lines. Now you them back in. But you don't want to end up with "one\n", "two\n" and possibly "three\n". (For one thing, if you write this data out again, and read it in again, you might get "one\n", "\n", "two\n" etc.) So newlines are often just an unneeded artefact. (Every bit of Python line reading code I see seems to have a '\n'-stripping step added to it.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-14 13:00 +0000 |
| Message-ID | <o2rfmb$228$1@dont-email.me> |
| In reply to | #99331 |
On 14/12/2016 12:24, BartC wrote: > On 14/12/2016 02:09, Ben Bacarisse wrote: >> (I would not even remove the line ending.) > > That figures! And see the thread "Why is this outputting alternate blank lines?" where the newline returned by fgets contributes to the problem.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-14 08:54 -0800 |
| Message-ID | <lnlgvio3hm.fsf@kst-u.example.com> |
| In reply to | #99335 |
BartC <bc@freeuk.com> writes:
> On 14/12/2016 12:24, BartC wrote:
>> On 14/12/2016 02:09, Ben Bacarisse wrote:
>>> (I would not even remove the line ending.)
>>
>> That figures!
>
> And see the thread "Why is this outputting alternate blank lines?" where
> the newline returned by fgets contributes to the problem.
Yes -- a problem trivially solved by not printing an extra newline on
output. Or slightly less trivially solved by stripping the newline on
input.
--
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-14 17:01 +0000 |
| Message-ID | <o2rtr3$kfr$2@dont-email.me> |
| In reply to | #99353 |
On 14/12/16 16:54, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 14/12/2016 12:24, BartC wrote: >>> On 14/12/2016 02:09, Ben Bacarisse wrote: >>>> (I would not even remove the line ending.) >>> >>> That figures! >> >> And see the thread "Why is this outputting alternate blank lines?" where >> the newline returned by fgets contributes to the problem. > > Yes -- a problem trivially solved by not printing an extra newline on > output. That would only solve one of the output problems in that program, which was actually printing /two/ extra lines after each datum, not just one. > Or slightly less trivially solved by stripping the newline on > input. That would have solved both output problems in one go. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-14 17:27 +0000 |
| Message-ID | <87d1gu774w.fsf@bsb.me.uk> |
| In reply to | #99331 |
BartC <bc@freeuk.com> writes:
> On 14/12/2016 02:09, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>
>
>>> Yes, maybe a return value can be added for a more general function
>>> (the original was only called in one place). And the result can
>>> sometimes be used in place of discrete myeof and mygets calls.
>>
>> In what situations can a properly written myfgets call /not/ be used in
>> place of the myeof/myfgets pair? You say "sometimes" like it might
>> occur now and then, but with a significant number of cases where you
>> can't use it in place of the pair.
>
> Where the body of the loop doesn't always read a line of text.
I don't follow. You said in place of discrete myeof and mygets calls.
If you have the discrete calls you are reading a line of text. At least
that's what I took you to mean. To be clear, the return value lets you
replace your pair
while (!myeof()) {
myfgets(&line); /* I don't recall the interface. */
...
}
with
while (myfgets(&line)) {
...
}
Simpler, and one less function to get wrong.
There are, of course, other situations where you can't use myfgets even
if it returns a status. In those, you should (usually) also ditch the
myeof function and use the return status of whatever other input
operation are being used.
<snip>
> But look here:
>
> https://www.rosettacode.org/wiki/Read_a_file_line_by_line
>
> Out of 100 or so languages, about 20% of them are using an explicit
> pre-read EOF check. Including most of the Basics and Pascals.
OK. Given the number of languages that old ones like Pascal have
spawned I'm a little surprised it's only 20%.
> I don't think it's a coincidence either that those were amongst the
> easiest to understand. (Half of the rest, I'd hadn't a clue what was
> going on.)
Do you find
while (fgets(...)) ...
or
while ((ch = getchar()) != EOF) ...
hard to understand? The others may be easier (I don't think so -- just
ask a student for a prompt + input loop in Pascal!) but since the C
idiom is not hard to follow, that's the way to go in C.
<snip>
>> Ah, right. You skipped the question about the mysterious -2 in the size
>> passed to fgets. Is that some odd translation artefact too?
>
> It's been there for years. Maybe I just didn't trust fgets enough. Or
> maybe the original was pre-fgets and I was working by reading blocks
> of bytes looking for possible newlines. Basically, I don't know. But I
> do like my margins.
OK, but it reduces the margin on the other side of the call. More small
buffer sizes are erroneous.
>> I'm not sure what "allow for" means. You remove some lone CRs that are
>> not part of the line ending and not others.
>
> Figuring out which were part of the line ending would take too long
No it wouldn't. In your case it would just be a CR directly before a
newline.
> (having to do strlen is bad enough). I don't want stray CRs anyway.
>
>> (I would not even remove the line ending.)
>
> That figures!
Yes. I like input functions to do the input and scanning/parsing
function to do the parsing (you recall you accused me of wanting to mix
them up but it's you that does that). A line reading function that
trims the terminator makes it impossible to tell if there was one and
you sometimes care about that. With fgets, you care because it may mean
the line is over long.
Note, however, that you are doing more that stripping the line ending.
> You start with strings "one", "two", "three" - notice no newlines -
> and you want to write them to a file so they can be recalled
> later. However, they would be written as "onetwothree", so you need a
> separator.
>
> 'newline' fills the role and is compatible with other viewers and
> readers of the file which will tidily show the contents on separate
> lines.
>
> Now you [read] them back in. But you don't want to end up with "one\n",
> "two\n" and possibly "three\n". (For one thing, if you write this data
> out again, and read it in again, you might get "one\n", "\n", "two\n"
> etc.)
Yes, you might. It is always possible to come up with a scenario where
not changing some part of a program, despite changes in other parts,
will cause problems.
> So newlines are often just an unneeded artefact. (Every bit of Python
> line reading code I see seems to have a '\n'-stripping step added to
> it.)
Ah, good -- separating the input from the scanning/parsing. You remember
you were a fan of that before?
Unfortunately you cut what is probably the only really interesting part
of my post where I asked you explain your thinking. I think I've
explained why I like input functions to report a status but you said of
void functions:
| They make me think harder about what a routine is doing, and whether
| it ought to be returning a value or not.
which suggests you thought hard about it and decided that the line
reading function should remain void. I'm struggling to see why. I
probably won't agree with your thought processes, but currently I can't
even imagine what they might have been. This is about the only
conceptual part of the exchange and it seems a shame to skip it.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-14 20:24 +0000 |
| Message-ID | <o2s9mr$3gu$1@dont-email.me> |
| In reply to | #99359 |
On 14/12/2016 17:27, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> Out of 100 or so languages, about 20% of them are using an explicit >> pre-read EOF check. Including most of the Basics and Pascals. > > OK. Given the number of languages that old ones like Pascal have > spawned I'm a little surprised it's only 20%. A lot don't use an explicit per-line check, for example by making a file object some sort of iterator. The ones that attempt a line read that check a result or some status do it diverse ways. But 'eof' or 'iseof' or 'ateof' can't really mean much else (other than C's feof of course which has to be different, leading to confusion in that code in the OP's book). My original eof() function actually checked whether the current file position was at the end of a file. That's a simple concept. You can imagine a corresponding bof() function if you happened to be reading the file backwards. >> Figuring out which were part of the line ending would take too long > > No it wouldn't. In your case it would just be a CR directly before a > newline. If part of a line has been read, then a CR could appear the end of the buffer. It could be a lone CR, or it could be half of a truncated CR/LF pair of a file open in binary mode. >>> (I would not even remove the line ending.) >> >> That figures! > > Yes. I like input functions to do the input and scanning/parsing > function to do the parsing (you recall you accused me of wanting to mix > them up but it's you that does that). A line reading function that > trims the terminator makes it impossible to tell if there was one and > you sometimes care about that. With fgets, you care because it may mean > the line is over long. The over-long line check is done before the trimming. >> So newlines are often just an unneeded artefact. (Every bit of Python >> line reading code I see seems to have a '\n'-stripping step added to >> it.) > > Ah, good -- separating the input from the scanning/parsing. You remember > you were a fan of that before? Here the "\n" is just unwanted junk. It may have been added explicitly with "\n" in printf, or implicitly with puts (or Python's 'print'), but usually you don't want to read it back. It's like 'break' in C's switch to avoid fall-through, as 99% of the time you don't want fall-through. Your argument is that it is important we keep '\n' for the 1% of the time it is actually wanted. > | They make me think harder about what a routine is doing, and whether > | it ought to be returning a value or not. > > which suggests you thought hard about it and decided that the line > reading function should remain void. I'm struggling to see why. I > probably won't agree with your thought processes, but currently I can't > even imagine what they might have been. This is about the only > conceptual part of the exchange and it seems a shame to skip it. I thought I'd explained. The original 'readlinen' was a dedicated function used only in one place, and there was no need for a return value. What I didn't explain about my comment was that all my functions are either prefixed with "function " or with "proc " (even when I was writing a lot of C when they are just empty macros) to further highlight what a routine is doing. (Otherwise C function definitions tend to blend not only into each other but with other kinds of declarations.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-15 10:47 +0000 |
| Message-ID | <8737hp5v0i.fsf@bsb.me.uk> |
| In reply to | #99407 |
Apologies if this is duplicate. Little hiccup at my end...
BartC <bc@freeuk.com> writes:
> On 14/12/2016 17:27, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> Out of 100 or so languages, about 20% of them are using an explicit
>>> pre-read EOF check. Including most of the Basics and Pascals.
>>
>> OK. Given the number of languages that old ones like Pascal have
>> spawned I'm a little surprised it's only 20%.
>
> A lot don't use an explicit per-line check, for example by making a
> file object some sort of iterator. The ones that attempt a line read
> that check a result or some status do it diverse ways.
>
> But 'eof' or 'iseof' or 'ateof' can't really mean much else (other
> than C's feof of course which has to be different, leading to
> confusion in that code in the OP's book).
The code in the book was correct (from what I saw); it just wasn't
idiomatic C.
As a rule, programming by analogy with other languages is a very bad
plan. I try not to assume that any function, no matter how beguiling
its name, does what a similarly named function does in some other
language I may know. I'm happy to assume that C's feof does something
related to EOF checking, but you really need to find out what it
actually does to use it in a program.
> My original eof() function actually checked whether the current file
> position was at the end of a file. That's a simple concept. You can
> imagine a corresponding bof() function if you happened to be reading
> the file backwards.
How do you tell that the position it at the end with interactive input?
C's method allows you to write programs that work with interactive input
as easily as file input (and streams, and network connections etc, etc).
Even your new eof function is not necessarily intuitive. A student, not
previously exposed the anachronism that is Pascal's IO model, might
write:
while (!eof(stdin)) {
printf("Enter a temperatue in C: ");
double t;
if (scanf("%lf", &t) == 1)
printf("%gC is %gF\n", t, t * 1.8 + 32);
}
They would have to read and absorb what eof() really does to see the
mistake.
>>> Figuring out which were part of the line ending would take too long
>>
>> No it wouldn't. In your case it would just be a CR directly before a
>> newline.
>
> If part of a line has been read, then a CR could appear the end of the
> buffer. It could be a lone CR, or it could be half of a truncated
> CR/LF pair of a file open in binary mode.
Yes, that's a point I missed but my beef was that you remove '\r'
characters that can not possibly by part of a line ending.
Only the system can do it property by taking account of the open mode,
so if you are goint to to this at all (and it's a debate we've had
before) you have to simply declare that the sequence \r\n is a line
ending and, if you are removing line endings, both characters have to
go.
This gives you three logical strategies when process a simple fgets loop
as in your posted code: (a) remove /all/ '\r's whatsoever; (b) remove
only ones that you /know/ are part of a line ending (the ones I was,
rather simplistically, suggesting above), or (c) remove those that
/might/ by part of a line ending. These are those in (b) plus a lone
'\r' at the end of the buffer.
You've chosen a fourth which is (c) plus removing some others that
immediately precede the possible line ending. That looks very odd to me
and I don't think it's any simpler that doing (b) or (c). (Doing (a) is
a bit more complex.)
>>>> (I would not even remove the line ending.)
>>>
>>> That figures!
>>
>> Yes. I like input functions to do the input and scanning/parsing
>> function to do the parsing (you recall you accused me of wanting to mix
>> them up but it's you that does that). A line reading function that
>> trims the terminator makes it impossible to tell if there was one and
>> you sometimes care about that. With fgets, you care because it may mean
>> the line is over long.
>
> The over-long line check is done before the trimming.
Where? Not in the C code you posted. How is the result communicated?
How does that help with detecting a line not terminated by a newline
(which, logically, can only the the last)?
>>> So newlines are often just an unneeded artefact. (Every bit of Python
>>> line reading code I see seems to have a '\n'-stripping step added to
>>> it.)
>>
>> Ah, good -- separating the input from the scanning/parsing. You remember
>> you were a fan of that before?
>
> Here the "\n" is just unwanted junk. It may have been added explicitly
> with "\n" in printf, or implicitly with puts (or Python's 'print'),
> but usually you don't want to read it back.
>
> It's like 'break' in C's switch to avoid fall-through, as 99% of the
> time you don't want fall-through. Your argument is that it is
> important we keep '\n' for the 1% of the time it is actually wanted.
>
>> | They make me think harder about what a routine is doing, and whether
>> | it ought to be returning a value or not.
>>
>> which suggests you thought hard about it and decided that the line
>> reading function should remain void. I'm struggling to see why. I
>> probably won't agree with your thought processes, but currently I can't
>> even imagine what they might have been. This is about the only
>> conceptual part of the exchange and it seems a shame to skip it.
>
> I thought I'd explained. The original 'readlinen' was a dedicated
> function used only in one place, and there was no need for a return
> value.
Ah. So presumably you agree with the general point that it would be
more useful if it did signal the status like C's input functions tend to
do. And the reason strtofloat and readfloat don't indicate a status is
also, presumably, because they were purpose written for a program that
does not care if there is numerical data there or not. I thought they
were general purpose support functions, and their behaviour was an
artefact of an IO model like Pascal's that simply does not let you find
out these things from the input operations themselves.
As far as C goes, I think we are in agreement, don't you?
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-15 11:54 +0000 |
| Message-ID | <o2u07h$rr3$1@dont-email.me> |
| In reply to | #99476 |
On 15/12/2016 10:47, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> My original eof() function actually checked whether the current file >> position was at the end of a file. > How do you tell that the position it at the end with interactive input? > C's method allows you to write programs that work with interactive input > as easily as file input (and streams, and network connections etc, > etc). You mean Unix's method. I deal separately with files and interactive input. >> If part of a line has been read, then a CR could appear the end of the >> buffer. It could be a lone CR, or it could be half of a truncated >> CR/LF pair of a file open in binary mode. > Only the system can do it property by taking account of the open mode, I'm not sure it can. If a file using CR as newline, and has embedded LF characters, is read using fgets() in binary mode, then it will assume lines are separated with LF. > This gives you three logical strategies when process a simple fgets loop > as in your posted code: (a) remove /all/ '\r's whatsoever; (b) remove > only ones that you /know/ are part of a line ending (the ones I was, > rather simplistically, suggesting above), or (c) remove those that > /might/ by part of a line ending. These are those in (b) plus a lone > '\r' at the end of the buffer. It's easier than that. Just assume that stray CR and LF characters which haven't been removed from the end of the line buffer returned from fgets are input errors. In practice, you're never going to see them. >> The over-long line check is done before the trimming. > > Where? Not in the C code you posted. I took it out as it would probably have spawned another subthread. Also in that demo I said lines could be assumed to have a fixed limit. > How is the result communicated? That depends on what action is taken. The idea of using a wrapper around fgets is to make life easier for the caller of that wrapper function. That includes not having to worry about over-long lines. One action is to abort. Another is truncate the line (so extra fgets calls are done to get to the physical end of the line). (And maybe an error flag can be set in a global location or inside the function that can be retrieved with a special call.) Yet another, the natural behaviour of fgets, is to chop up long lines into a series of shorter, buffer-size ones. Then, removing the eventual line ending makes then all compatible. While another could be to allocate a bigger buffer, but that will need a different interface. But what you want to avoid is user-code /having/ to deal with the problem (compared with opting to deal with it). > How does that help with detecting a line not terminated by a newline > (which, logically, can only the the last)? If this is of significance then the program should do its own fgets processing. That would be the case in applications that need to treat the file contents more literally. (Eg. editors, or where you want to append one file to another so that the last line of file A joins directly to the start of the first line of file B. Then you might work in character mode.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-15 04:02 -0800 |
| Message-ID | <02812eb4-84f9-49c3-a961-0220c1ad7857@googlegroups.com> |
| In reply to | #99482 |
On Thursday, December 15, 2016 at 11:54:54 AM UTC, Bart wrote: > > But what you want to avoid is user-code /having/ to deal with the > problem (compared with opting to deal with it). > I think you've got to remember that fgets() is very old. It's natural to call it with a buffer on the stack, which is faster and more reliable than calling malloc(). But modern machines aren't going to notice allocating a line.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-15 07:40 -0800 |
| Message-ID | <7384d308-c72b-4f04-ad0b-8fed84030627@googlegroups.com> |
| In reply to | #99482 |
On Thursday, December 15, 2016 at 5:54:54 AM UTC-6, Bart wrote: > You mean Unix's method. > > I deal separately with files and interactive input. It may be worth noting that it's possible for systems to support piping while still treating files and interactive input differently. The idea that they should be treated the same works to the detriment of the user interface, since it makes it necessary for the system to accept and echo keyboard input before it knows what to do with it. If a system has separate calls for character reads and line reads, and if the line-read calls specify the maximum length and allowable character set, the system can squawk instantly at attempts to enter excess or invalid characters. Such feedback is not possible under the Unix model unless a program uses its own line buffering in conjunction with "raw" TTY mode, since the system can't make any part of an input line available to the application until the user presses return or control-D, and all the system will know while waiting for the user to do one of those things is that the program will want at least one character of input.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-15 11:48 -0800 |
| Message-ID | <ln7f71m0s1.fsf@kst-u.example.com> |
| In reply to | #99482 |
BartC <bc@freeuk.com> writes:
> On 15/12/2016 10:47, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>> My original eof() function actually checked whether the current file
>>> position was at the end of a file.
>
>> How do you tell that the position it at the end with interactive input?
>> C's method allows you to write programs that work with interactive input
> > as easily as file input (and streams, and network connections etc,
> > etc).
>
> You mean Unix's method.
I'm pretty sure he means C's method (which, historically, is closely
tied to Unix, but works on non-Unix systems).
> I deal separately with files and interactive input.
C's I/O model is designed so that you don't have to.
[...]
--
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 | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-12-27 20:19 +0000 |
| Message-ID | <5862cc86.11418593@news.xs4all.nl> |
| In reply to | #99552 |
Keith Thompson <kst-u@mib.org> wrote: > BartC <bc@freeuk.com> writes: > > I deal separately with files and interactive input. > > C's I/O model is designed so that you don't have to. However, it's also designed so that you _can_ if you want or need to. Remember that it's not just the programming language which determines how programs interact with their users. The user's requirements are much more important, and most users don't like to be seen as a set of lines. Richard
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-16 01:52 +0000 |
| Message-ID | <87twa43ajz.fsf@bsb.me.uk> |
| In reply to | #99482 |
BartC <bc@freeuk.com> writes: > On 15/12/2016 10:47, Ben Bacarisse wrote: > >> BartC <bc@freeuk.com> writes: > >>> My original eof() function actually checked whether the current file >>> position was at the end of a file. > >> How do you tell that the position it at the end with interactive input? >> C's method allows you to write programs that work with interactive input >> as easily as file input (and streams, and network connections etc, >> etc). > > You mean Unix's method. No, I meant what I said: C's method. > I deal separately with files and interactive input. Always? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-16 11:09 +0000 |
| Message-ID | <o30htu$4v7$1@dont-email.me> |
| In reply to | #99595 |
On 16/12/2016 01:52, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> On 15/12/2016 10:47, Ben Bacarisse wrote: >> >>> BartC <bc@freeuk.com> writes: >> >>>> My original eof() function actually checked whether the current file >>>> position was at the end of a file. >> >>> How do you tell that the position it at the end with interactive input? >>> C's method allows you to write programs that work with interactive input >>> as easily as file input (and streams, and network connections etc, >>> etc). >> >> You mean Unix's method. > > No, I meant what I said: C's method. > >> I deal separately with files and interactive input. > > Always? Unless the user redirects 'interactive' input to come from a file. That's their choice. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-13 18:35 -0800 |
| Message-ID | <1dddd670-cfeb-447c-93e7-ce480b862cbe@googlegroups.com> |
| In reply to | #99295 |
On Wednesday, December 14, 2016 at 12:08:54 AM UTC, Ben Bacarisse wrote:
>
> For anyone learning C, a tip: it is rare to write "void functions".
> When you do write one, think about whether you are wasting an
> opportunity to tell your caller something useful -- a success/failure
> indication, a count, or maybe just a value that might be useful for
> chaining calls. You will sometimes conclude there is nothing but you
> might be surprised how rare it it.
>
It's often better to have "sticky" errors.
For example my (C++) JSON parser works like this
int err = 0;
JParser jparser("{\"fieldname\":100}");
int x = jparser.getInteger("fieldname", &err);
std:string str = jparser.getString("nonexistent", &err);
assert(err == 0);
That code fragment will assert fail because we've asked for
a string which the JSON does not contain. The error flag must
be initialised to zero, but will go to non-zero for any error
(asking for non-existent data, asking for a numerical field
when you have a string, etc).
However there's only one test, which keeps the code clean.
It has never happened, but if you wanted optional fields
you could of course treat err as normal flow control.
Mismatches between the JSON generated by the scripting
language and the C++ which needs to accept it are quite
common, however. Unlike a C++ struct, there is no compile-time
enforcement of field matching.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-13 20:18 +0000 |
| Message-ID | <o2pl0t$n23$2@dont-email.me> |
| In reply to | #99238 |
On 13/12/16 19:30, Keith Thompson wrote: <snip> > So your eof() method returns a bogus empty line when there's nothing > more to be read. Presumably one is supposed to check eof() before processing the line. If eof() yields truth, one may discard the line. It seems a little clumsy, but it could be made to work. > As opposed to the usual idiomatic C way to read text, > which clearly distinguishes between an empty line (which is valid input) > and either end-of-file or an error condition. Yes. That's the most sensible way. BartC's way is perhaps not so terrible as you seem to be suggesting, but it seems odd that he should champion it over the usual way, given that the usual way works so much more transparently. -- 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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-13 20:14 +0000 |
| Message-ID | <o2pko4$n23$1@dont-email.me> |
| In reply to | #99228 |
On 13/12/16 19:03, BartC wrote: > On 13/12/2016 18:34, Richard Heathfield wrote: >> On 13/12/16 18:26, BartC wrote: > >>> If an empty buffer results after getc/ungetc has established there is at >>> least one character waiting, that must mean it /does/ strip newline. >>> >>> Which my routines in fact do. >> >> So if you have the following input (line numbers and colons are NOT part >> of the input): >> >> 1:TO:Prime Minister >> 2:FROM:Ministry of Defence >> 3:SUBJECT:Intelligence Report >> 4:PRIORITY:Urgent >> 5:DATE:13/12/2016 >> 6:---------------- >> 7:No intercepts from Russian military units in Ukraine. This means >> 8:they are maintaining radio silence. >> 9: >> 10:Almost certainly they are preparing to attack. Request permission >> 11:to take defensive precautions. >> >> line 9 will be read as an empty string, so you say your next eof check >> will be true, and so the program will never report lines 10 and 11, and >> so we lose the war. Okay... > > You misunderstood. I don't think I misunderstood what you wrote. I am, however, happy to accept that I have misunderstood your intended meaning. > A input line can be empty because it's empty (after newline is stripped) > or due to an error. > > An eof() will only return true at eof or on error. Nothing to do with > the input line. Fair enough. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-13 20:15 +0000 |
| Message-ID | <87a8bza8ly.fsf@bsb.me.uk> |
| 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. Then I got the name wrong. I meant your language's way of reading three numbers (I did write "readLn x, y, z" and we are talking about exactly that sort of input). Here, I think, errors reading x, y and z are ignored you just supply some default. <snip> > 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. I bet on another day you might post about some daft Linux program where you wasted hours trying to find what was wrong when it turned out the code just ignored errors like O.356 and blithely assumed zero. You'll want it when I say it doesn't matter and you'll accuse me demanding perfection when I say I want it. Anyway, maybe your language /can/ report an error with numerical input, but your C code does, not and we are talking about how to process input in C here. It's trivial to report the error, and just as trivial to pay no attention in those cases where it would be too fussy to do so. I can't see what you wouldn't want to do it. >> (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). I'm not happy with that. You code uses a daft test for numerical input. If it sees a digit or +, -, or . you assume there's data. To me, a line with just ----------------------------------- on it is just as worthy of being skipped as one that says The data points are: which you program does skip (as per the spec.). When you said "use common sense", I took that to mean that lines with things like ++++ or .... on them should be ignored. Your idea of common sense apparently takes them to mean "assume three zeros and record another data line". If you were reporting averages, you'd notice. (And by the way, your code does not state that zero should be returned when numerical input is malformed. I'm sure you tested that, but testing does not always reveal all bugs.) > Otherwise, how do you represent several possibilities (parsing error, > range overflow etc) in a floating point return value? Ah, there's the politician coming out. I suggest that you really should detect errors (even if you later don't take notice of them) and you ask me to say how all the different errors should be distinguished. You write the code so that can at least report an, and then we can talk about distinguishing them all. > (For that matter, how does atol() do it?) It doesn't. That why I didn't use it. You, however, could have used atof because you don't want to report an error on malformed input. >>> 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. Nonsense. Languages vary hugely in how they implement IO, and using the language's IO system properly is just good programming. If you don't accept that, the whole sub-thread has been carried out under false pretences. <snip> >> 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. Hence the bugs. Two other cases of undefined behaviour in your code might well not be detected by just running it, and just running it did not, it seems, find the buffer overrun. <snip> >> 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. I did not know these were the ground rules. I though you were asking for correct code, not something thrown together as a demo. I'd have just done a sketch if I'd known. But I'm now curious as I thought the code was automatically generated. Aren't these function the ones you use to implement your language? And if they aren't, why not use the real ones? > But the extra support functions needed to make this work only need > writing - and debugging - once. Yes, but they would still be wrong because they would not allow the simple implementation of other input schemes. You can fix the bug in strtofloat, but unless you arrange for it to be able to report errors you can't use it even for something as simple as reading and summing lines that really do have three numbers on them (rather than lines that look like they might have one and assuming zero if they are missing). You are complaining about my detailed comments (details like bugs and so on) but you are not engaging with the big picture stuff I am also talking about. I explained how to switch my code to this other interpretation of your specification and you've not addressed how you would do that with your program at all. >> 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. Yes, that's the C way to do it. It's fewer lines and one less function. Why is using more code better? Regardless, I hope you will suggest this plan to other people who might post about learning to do input in C. > Everything within the body of the loop then is working with in-memory > strings and can forget about file errors. But not always data errors. > (I tend not to use that in interpreted code because my line-reading > function returns the line itself, not an eof/error status.) Some languages (esoteric ones I think you call them) can return either a line or a failure status (and some, less esoteric ones, just return both). -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web