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 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-13 18:26 +0000 |
| Message-ID | <o2pef2$vbl$1@dont-email.me> |
| In reply to | #99221 |
On 13/12/2016 18:12, Richard Heathfield wrote: > On 13/12/16 18:07, BartC wrote: >> On 13/12/2016 16:27, Keith Thompson wrote: >>> 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. 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. >> 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? With random numbers, I only require them to pass the wallpaper test. (With the set of numbers used as the test input up-thread, they make a nice cube-shaped cloud of points if plotted, although it looks better with 100K points rather than 1K. They were generated with rand().) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-13 18:34 +0000 |
| Message-ID | <o2peta$1dm$1@dont-email.me> |
| In reply to | #99223 |
On 13/12/16 18:26, BartC wrote: > On 13/12/2016 18:12, Richard Heathfield wrote: >> On 13/12/16 18:07, BartC wrote: >>> On 13/12/2016 16:27, Keith Thompson wrote: > >>>> 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. > > 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... -- 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 | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-12-13 18:39 +0000 |
| Message-ID | <871sxbznae.fsf@gmail.com> |
| In reply to | #99224 |
Richard Heathfield <rjh@cpax.org.uk> writes: > 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... Bart doesn't read the daily intelligence briefs because he's, you know, a smart guy.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2016-12-13 13:47 -0500 |
| Message-ID | <o2pfkt$4c7$1@dont-email.me> |
| In reply to | #99224 |
On Tuesday December 13 2016 13:34, in comp.lang.c, "Richard Heathfield" <rjh@cpax.org.uk> wrote: > On 13/12/16 18:26, BartC wrote: >> On 13/12/2016 18:12, Richard Heathfield wrote: >>> On 13/12/16 18:07, BartC wrote: >>>> On 13/12/2016 16:27, Keith Thompson wrote: >> >>>>> 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. >> >> 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... Nyet, comrade. We /win/ the war. ;-) -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-13 19:03 +0000 |
| Message-ID | <o2pgk4$85d$1@dont-email.me> |
| In reply to | #99224 |
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. 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. But if some error occurs while reading the line, after eof returns false, then a blank line is returned (due to fgets returning NULL). The /next/ eof() will then return true, assuming the error persists. I get this output with a simple loop controlled by eof(); the first number is the length of the line, not including the gap or newline: 17 TO:Prime Minister 24 FROM:Ministry of Defence 27 SUBJECT:Intelligence Report 15 PRIORITY:Urgent 15 DATE:13/12/2016 16 ---------------- 64 No intercepts from Russian military units in Ukraine. This means 35 they are maintaining radio silence. 0 65 Almost certainly they are preparing to attack. Request permission 30 to take defensive precautions. And there should be an END-OF-TRANSMISSION line at the end of the message, otherwise how do you know there isn't anything further? It might be subject to the 'python' syndrome. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-13 11:30 -0800 |
| Message-ID | <lninqnpqxu.fsf@kst-u.example.com> |
| In reply to | #99228 |
BartC <bc@freeuk.com> writes:
[...]
> You misunderstood.
>
> 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.
>
> But if some error occurs while reading the line, after eof returns
> false, then a blank line is returned (due to fgets returning NULL). The
> /next/ eof() will then return true, assuming the error persists.
>
> I get this output with a simple loop controlled by eof(); the first
> number is the length of the line, not including the gap or newline:
>
> 17 TO:Prime Minister
> 24 FROM:Ministry of Defence
> 27 SUBJECT:Intelligence Report
> 15 PRIORITY:Urgent
> 15 DATE:13/12/2016
> 16 ----------------
> 64 No intercepts from Russian military units in Ukraine. This means
> 35 they are maintaining radio silence.
> 0
> 65 Almost certainly they are preparing to attack. Request permission
> 30 to take defensive precautions.
>
> And there should be an END-OF-TRANSMISSION line at the end of the
> message, otherwise how do you know there isn't anything further? It
> might be subject to the 'python' syndrome.
So your eof() method returns a bogus empty line when there's nothing
more to be read. 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.
I'm having trouble seeing how your eof() method is an improvement over
controlling an input loop by checking the result returned by the input
function.
And since you *still* haven't shown a example of a C program using your
eof() method, this will probably never be resolved.
--
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 20:10 +0000 |
| Message-ID | <o2pkg7$msl$1@dont-email.me> |
| In reply to | #99238 |
On 13/12/2016 19:30, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> 17 TO:Prime Minister
>> 24 FROM:Ministry of Defence
>> 27 SUBJECT:Intelligence Report
>> 15 PRIORITY:Urgent
>> 15 DATE:13/12/2016
>> 16 ----------------
>> 64 No intercepts from Russian military units in Ukraine. This means
>> 35 they are maintaining radio silence.
>> 0
>> 65 Almost certainly they are preparing to attack. Request permission
>> 30 to take defensive precautions.
> So your eof() method returns a bogus empty line when there's nothing
> more to be read.
What makes you come to that conclusion? Do you see a bogus empty line in
the output above?
> 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.
This empty line is a red herring. The body of the loop is not interested
in errors, but in the unlikely event of there being one while doing
fgets, what should be the contents of the buffer?
AN EMPTY LINE DOES NOT MEAN ERROR. It just happens to be empty IF there
is an error, as I found that just putting random quotations from
Shakespeare in there, or a message like "DO NOT READ THIS LINE", didn't
really work.
> I'm having trouble seeing how your eof() method is an improvement over
> controlling an input loop by checking the result returned by the input
> function.
Did you look at that link? Why does the poor C programmer needed to be
lumbered with all this palaver when hardly any of the other languages
bother?
(BTW the Ada example also uses a loop with a pre-reading EOF check. I
guess it's OK when a well-respected other language does it. But if /I/
suggest it, it /must/ be wrong!)
> And since you *still* haven't shown a example of a C program using your
> eof() method, this will probably never be resolved.
Read further up the thread.
Meanwhile here's some code you can try out. Change 'filename' to the
name of some input text (preferably RH's message), or arrange for the
filename to come from the command line or read from stdin if you like:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define filename "KKK1"
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) {
char* p;
int n;
*buffer = 0;
if (fgets(buffer,size-2,handle) == 0) {
return;
}
n = strlen(buffer);
if (n == 0) {
return;
}
p = (buffer+n)-1;
while (p >= buffer && (*p == 13 || *p == 10)) {
*p-- = 0;
}
}
int main (void) {
FILE* f;
char line[1000];
f = fopen(filename, "r");
if (f == 0) {
printf("Can't open %s\n", filename);
exit(1);
}
puts("--------- start of file --------");
while (!myeof(f)) {
myfgets(line, sizeof line, f);
puts(line);
}
fclose(f);
puts("--------- end of file ----------");
}
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-13 12:42 -0800 |
| Message-ID | <ln60mnpnld.fsf@kst-u.example.com> |
| In reply to | #99248 |
BartC <bc@freeuk.com> writes:
> On 13/12/2016 19:30, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> 17 TO:Prime Minister
>>> 24 FROM:Ministry of Defence
>>> 27 SUBJECT:Intelligence Report
>>> 15 PRIORITY:Urgent
>>> 15 DATE:13/12/2016
>>> 16 ----------------
>>> 64 No intercepts from Russian military units in Ukraine. This means
>>> 35 they are maintaining radio silence.
>>> 0
>>> 65 Almost certainly they are preparing to attack. Request permission
>>> 30 to take defensive precautions.
>
>> So your eof() method returns a bogus empty line when there's nothing
>> more to be read.
>
> What makes you come to that conclusion? Do you see a bogus empty line in
> the output above?
I came to that conclusion from your description upthread:
But if some error occurs while reading the line, after eof
returns false, then a blank line is returned (due to fgets
returning NULL). The /next/ eof() will then return true,
assuming the error persists.
>> 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.
>
> This empty line is a red herring. The body of the loop is not interested
> in errors, but in the unlikely event of there being one while doing
> fgets, what should be the contents of the buffer?
fgets returns a null pointer on an error or end-of-file.
[...]
>> I'm having trouble seeing how your eof() method is an improvement over
>> controlling an input loop by checking the result returned by the input
>> function.
>
> Did you look at that link?
No, I didn't. I just checked half a dozen or so parent articles, and
found this:
https://www.rosettacode.org/wiki/Read_a_file_line_by_line
Is that the link you're referring to? That points to over 100 sample
programs, 3 of them in C. Please be specific.
> Why does the poor C programmer needed to be
> lumbered with all this palaver when hardly any of the other languages
> bother?
"All this palaver" actually works.
> (BTW the Ada example also uses a loop with a pre-reading EOF check. I
> guess it's OK when a well-respected other language does it. But if /I/
> suggest it, it /must/ be wrong!)
You do sarcasm slightly better than jacob does, but not by much.
Nobody is saying there aren't alternatives. Most of us are simply
saying that *in C*, the most reliable way to read input is by checking
the return value of the input function, not by calling some eof()
function before attempting a read.
>> And since you *still* haven't shown a example of a C program using your
>> eof() method, this will probably never be resolved.
>
> Read further up the thread.
>
> Meanwhile here's some code you can try out. Change 'filename' to the
> name of some input text (preferably RH's message), or arrange for the
> filename to come from the command line or read from stdin if you like:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
>
> #define filename "KKK1"
>
> 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) {
> char* p;
> int n;
> *buffer = 0;
> if (fgets(buffer,size-2,handle) == 0) {
> return;
> }
> n = strlen(buffer);
> if (n == 0) {
> return;
> }
> p = (buffer+n)-1;
> while (p >= buffer && (*p == 13 || *p == 10)) {
> *p-- = 0;
> }
> }
>
> int main (void) {
> FILE* f;
> char line[1000];
> f = fopen(filename, "r");
> if (f == 0) {
> printf("Can't open %s\n", filename);
> exit(1);
> }
>
> puts("--------- start of file --------");
> while (!myeof(f)) {
> myfgets(line, sizeof line, f);
> puts(line);
> }
> fclose(f);
> puts("--------- end of file ----------");
> }
Ok. Here's my program with the same functionality.
#include <stdio.h>
#include <stdlib.h>
#define filename "KKK1"
int main(void) {
char line[1000];
FILE *f = fopen(filename, "r");
if (f == NULL) {
fprintf(stderr, "Can't open %s\n", filename);
exit(EXIT_FAILURE);
}
puts("--------- start of file --------");
while (fgets(line, sizeof line, f) != NULL) {
fputs(line, stdout);
}
fclose(f);
puts("--------- end of file ----------");
}
Are you claiming your approach is simpler?
--
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 21:29 +0000 |
| Message-ID | <o2pp55$8d1$1@dont-email.me> |
| In reply to | #99253 |
On 13/12/2016 20:42, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
> Ok. Here's my program with the same functionality.
>
> #include <stdio.h>
> #include <stdlib.h>
>
> #define filename "KKK1"
>
> int main(void) {
> char line[1000];
> FILE *f = fopen(filename, "r");
> if (f == NULL) {
> fprintf(stderr, "Can't open %s\n", filename);
> exit(EXIT_FAILURE);
> }
> puts("--------- start of file --------");
> while (fgets(line, sizeof line, f) != NULL) {
> fputs(line, stdout);
> }
> fclose(f);
> puts("--------- end of file ----------");
> }
>
> Are you claiming your approach is simpler?
Your program doesn't do the same thing.
I noticed you cleverly used fputs instead of puts to hide the fact that
newline hasn't been stripped from the ends of the input lines.
Fix that and see if it's still that much simpler.
Yes, you can get away without eof(), if you substitute another
non-standard routine that delivers a status and presents the next result
in a buffer.
However that is not a general solution (I'm sure I've said all this
already). Maybe the body of the loop isn't reading a line at a time.
Maybe sometimes you need full dynamic line buffering, sometimes not.
Every loop condition will be a bit different. That's why I think 'while
(!eof(f)) {}' if a fine starting pattern for sequential file reading.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-13 14:27 -0800 |
| Message-ID | <ln1sxbpirl.fsf@kst-u.example.com> |
| In reply to | #99265 |
BartC <bc@freeuk.com> writes:
> On 13/12/2016 20:42, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>> Ok. Here's my program with the same functionality.
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> #define filename "KKK1"
>>
>> int main(void) {
>> char line[1000];
>> FILE *f = fopen(filename, "r");
>> if (f == NULL) {
>> fprintf(stderr, "Can't open %s\n", filename);
>> exit(EXIT_FAILURE);
>> }
>> puts("--------- start of file --------");
>> while (fgets(line, sizeof line, f) != NULL) {
>> fputs(line, stdout);
>> }
>> fclose(f);
>> puts("--------- end of file ----------");
>> }
>>
>> Are you claiming your approach is simpler?
>
> Your program doesn't do the same thing.
I believe it does, with one exception that I'm now aware of. I tested
your version and mine with your program's source code as input, and with
an empty input file. The output was identical in both cases.
Just now I tried both with an input file containing a single line *not*
terminated by a newline. Your version added a newline; mine did not.
I prefer my version's behavior, but if I want to match yours it's an
easy fix.
> I noticed you cleverly used fputs instead of puts to hide the fact that
> newline hasn't been stripped from the ends of the input lines.
>
> Fix that and see if it's still that much simpler.
I didn't *hide* anything. I was simply aware that fgets doesn't strip
newlines, and since the output should contain those same newlines I
didn't do anything about them. As noted, this creates a minor
difference in behavior in one corner case.
(Oh, and I also decided to print the error message to stdout rather than
stderr, and to use exit(EXIT_FAILURE) rather than exit(EXIT_SUCCESS).
In both cases, I prefer my program's behavior, but duplicating your
would be easy.)
> Yes, you can get away without eof(), if you substitute another
> non-standard routine that delivers a status and presents the next result
> in a buffer.
I got away without eof() by using only standard routines, and using them
in the way they're intended. The result was a smaller, and in my
opinion cleaner, program.
Here's another version that more closely duplicates your program's
behavior, including printing an extra trailing '\n' even if there isn't
one in the input.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define filename "KKK1"
int main(void) {
char line[1000];
FILE *f = fopen(filename, "r");
if (f == NULL) {
printf("Can't open %s\n", filename);
exit(1);
}
puts("--------- start of file --------");
while (fgets(line, sizeof line, f) != NULL) {
char *nl = strrchr(line, '\n');
if (nl != NULL) {
*nl = '\0';
}
puts(line);
}
fclose(f);
puts("--------- end of file ----------");
}
I believe this is functionally identical to your original program. If
you think otherwise, please demonstrate an input file for which it
behaves differently.
> However that is not a general solution (I'm sure I've said all this
> already). Maybe the body of the loop isn't reading a line at a time.
> Maybe sometimes you need full dynamic line buffering, sometimes not.
>
> Every loop condition will be a bit different. That's why I think 'while
> (!eof(f)) {}' if a fine starting pattern for sequential file reading.
Sure, different programs have different requirements.
You've presented just one example that I've seen (I might have missed
something) of a C program that uses your approach of testing for
eof() at the top of the input loop. I've produced an equivalent
program, using more common C idioms, that behaves identically
(if I'm not mistaken), that is shorter, and that in my opinion is
substantially cleaner and simpler.
If you think your (!eof(f)) approach is superior in some other case,
please demonstrate by posting a program that uses that approach.
It's likely that a rewrite using common C idiom will, again, be
shorter, cleaner, and simpler, with the same functionality.
And if you still think the 50-line program you posted upthread
is superior to the 24-line replacement I posted, I invite you
to persuade me. (I am not claiming that a smaller line count is
a measure of quality, but I do assert that it is a contributing
factor.)
Oh, and if you could avoid using "KKK1" or something similar as the
input file name, I'd appreciate it. I presume it wasn't intended
to refer to a certain organization. I'd recommend getting the file name
from the command line, but that's a side issue.
--
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 22:56 +0000 |
| Message-ID | <o2pu7u$q9l$1@dont-email.me> |
| In reply to | #99283 |
On 13/12/2016 22:27, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> Your program doesn't do the same thing.
>
> I believe it does, with one exception that I'm now aware of. I tested
> your version and mine with your program's source code as input, and with
> an empty input file. The output was identical in both cases.
>
> Just now I tried both with an input file containing a single line *not*
> terminated by a newline. Your version added a newline; mine did not.
> I prefer my version's behavior, but if I want to match yours it's an
> easy fix.
The idea is to present a text file as a series of discrete strings. The
newline characters which in the file which separate out the lines are
not necessary at the end of each string. (If they are important, then
the file might be read as one string; another technique.)
When the strings are printed out, they have a newline added at the end
for display only, otherwise you'd get "ONETWOTHREE" instead
of:
ONE
TWO
THREE
If it took account of whether the last line of the file was terminated
by a newline or not, it would appear as:
THREE--------- end of file ----------
But that information is lost.
> I didn't *hide* anything.
OK.
> Here's another version that more closely duplicates your program's
> behavior, including printing an extra trailing '\n' even if there isn't
> one in the input.
> while (fgets(line, sizeof line, f) != NULL) {
> char *nl = strrchr(line, '\n');
> if (nl != NULL) {
> *nl = '\0';
> }
> puts(line);
> }
> I believe this is functionally identical to your original program.
Close. (I think mine deals with separators of CR, CR/LF and LF as my
text files are all mixed up now thanks to downloads and copying to/from
Linux. I also tend to read even text files as binary.)
I'm not disputing that you can write small, tight code without using a
dedicated eof() function, and by putting any special requirements into
the main loop.
> And if you still think the 50-line program you posted upthread
> is superior to the 24-line replacement I posted, I invite you
> to persuade me. (I am not claiming that a smaller line count is
> a measure of quality, but I do assert that it is a contributing
> factor.)
You're measuring wrong. That 50 lines (I haven't counted them)
presumably include the myeof/myfgets code. But those, or equivalents,
are written once and put into a library.
With your code, if you had a hundred file-reading programs each of which
needed newline stripped from the input, would require those extra 4
lines replicated 100 times.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-13 16:13 -0800 |
| Message-ID | <lntwa7nz9c.fsf@kst-u.example.com> |
| In reply to | #99290 |
BartC <bc@freeuk.com> writes:
> On 13/12/2016 22:27, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> Your program doesn't do the same thing.
>>
>> I believe it does, with one exception that I'm now aware of. I tested
>> your version and mine with your program's source code as input, and with
>> an empty input file. The output was identical in both cases.
>>
>> Just now I tried both with an input file containing a single line *not*
>> terminated by a newline. Your version added a newline; mine did not.
>> I prefer my version's behavior, but if I want to match yours it's an
>> easy fix.
>
> The idea is to present a text file as a series of discrete strings. The
> newline characters which in the file which separate out the lines are
> not necessary at the end of each string. (If they are important, then
> the file might be read as one string; another technique.)
>
> When the strings are printed out, they have a newline added at the end
> for display only, otherwise you'd get "ONETWOTHREE" instead
> of:
>
> ONE
> TWO
> THREE
You strip the newline and then re-add it for output. I prefer to strip
it only if I'm not going to want it later. Same results.
> If it took account of whether the last line of the file was terminated
> by a newline or not, it would appear as:
>
> THREE--------- end of file ----------
>
> But that information is lost.
Yes, and IMHO losing that information is a bad thing. (A Unix /bin/cat
program that quietly appends a trailing newline whether it's in the
input or not would be unacceptably buggy.)
>> I didn't *hide* anything.
>
> OK.
>
>> Here's another version that more closely duplicates your program's
>> behavior, including printing an extra trailing '\n' even if there isn't
>> one in the input.
>
>> while (fgets(line, sizeof line, f) != NULL) {
>> char *nl = strrchr(line, '\n');
>> if (nl != NULL) {
>> *nl = '\0';
>> }
>> puts(line);
>> }
>
>> I believe this is functionally identical to your original program.
>
> Close. (I think mine deals with separators of CR, CR/LF and LF as my
> text files are all mixed up now thanks to downloads and copying to/from
> Linux. I also tend to read even text files as binary.)
Ah, I didn't notice your handling of CR and LF characters, perhaps in
part because you used magic numbers 13 and 10 rather than character
constants '\r' and '\n'.
I note that fgets(), which you use, don't treat '\r' characters
specially. In the unlikely event that you have a text file that uses
just CR to terminate lines (as on pre-OSX MacOS), the first fgets call
will attempt to slurp the entire file. This affects both your program
and mine.
I prefer to assume that input is text, correctly represented for the
system I'm running on. Allowing for other representations is moderately
complex and often not worth the effort.
> I'm not disputing that you can write small, tight code without using a
> dedicated eof() function, and by putting any special requirements into
> the main loop.
>
>> And if you still think the 50-line program you posted upthread
>> is superior to the 24-line replacement I posted, I invite you
>> to persuade me. (I am not claiming that a smaller line count is
>> a measure of quality, but I do assert that it is a contributing
>> factor.)
>
> You're measuring wrong.
No, I'm measuring differently.
> That 50 lines (I haven't counted them)
> presumably include the myeof/myfgets code. But those, or equivalents,
> are written once and put into a library.
And if I want an fgets-like function that strips the terminating
newline, I can put that into a library. Though I likely wouldn't
bother; the code to strip the terminating '\n' is straightforward
enough that I find it reasonable to leave it as inline code.
And I don't have your functions in any library on my system.
> With your code, if you had a hundred file-reading programs each of which
> needed newline stripped from the input, would require those extra 4
> lines replicated 100 times.
Not necessarily.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-14 07:33 -0800 |
| Message-ID | <30a033dd-0646-4474-add3-afb1c0638fe1@googlegroups.com> |
| In reply to | #99298 |
On Tuesday, December 13, 2016 at 6:12:43 PM UTC-6, Keith Thompson wrote: > Yes, and IMHO losing that information is a bad thing. (A Unix /bin/cat > program that quietly appends a trailing newline whether it's in the > input or not would be unacceptably buggy.) Such a program would differ from the documented and expected behavior of /bin/cat. On the other hand, if the input file foo this<newline> moo foo that<eof> were fed to grep "foo" it would generally probably be more helpful to have it output foo this<newline> foo that<newline> <eof> than to have it output foo this<newline> foo that<eof> There would be room for argument as to whether EOF should match a $, but I think having the output always end with a newline would be desirable in any case. For a more extreme example, consider "sort". What should that do if the last line doesn't have a newline after it?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-14 09:05 -0800 |
| Message-ID | <lnh966o30h.fsf@kst-u.example.com> |
| In reply to | #99342 |
supercat@casperkitty.com writes:
> On Tuesday, December 13, 2016 at 6:12:43 PM UTC-6, Keith Thompson wrote:
>> Yes, and IMHO losing that information is a bad thing. (A Unix /bin/cat
>> program that quietly appends a trailing newline whether it's in the
>> input or not would be unacceptably buggy.)
>
> Such a program would differ from the documented and expected behavior of
> /bin/cat. On the other hand, if the input file
>
> foo this<newline>
> moo
> foo that<eof>
>
> were fed to
>
> grep "foo"
>
> it would generally probably be more helpful to have it output
>
> foo this<newline>
> foo that<newline>
> <eof>
>
> than to have it output
>
> foo this<newline>
> foo that<eof>
I have no strong opinion in which is preferable, but in practice GNU
Coretuils grep treats the input as if it had a trailing newline, but the
Solaris 9 version of grep does not.
> There would be room for argument as to whether EOF should match a $, but
> I think having the output always end with a newline would be desirable in
> any case. For a more extreme example, consider "sort". What should that
> do if the last line doesn't have a newline after it?
GNU sort quietly adds a newline to the last line. Solaris 9 sort also
adds a newline, but it prints a message to stderr:
sort: missing NEWLINE added at end of input file tmp
The POSIX requirements for sort and grep require a newline character on
the end of each line; a no-empty file with no newline at the very end is
not considered to be a text file. I don't believe it defines the
behavior when the input is not a text file.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-13 12:48 -0800 |
| Message-ID | <1a9435d3-a169-4931-8eea-fb656574ee25@googlegroups.com> |
| In reply to | #99248 |
On Tuesday, December 13, 2016 at 2:10:10 PM UTC-6, Bart wrote: > (BTW the Ada example also uses a loop with a pre-reading EOF check. I > guess it's OK when a well-respected other language does it. But if /I/ > suggest it, it /must/ be wrong!) Different platforms have different "natural" methods of performing I/O, and some languages use I/O semantics which fit better with their abilities than would be possible in others. Some languages like Pascal let a program "peek" at the next character of a stream without consuming it--an operation which is roughly analogous to doing a fgetc followed by a ungetc. If a platform has a non-consuming "peek" function, code written to use that may work out more smoothly than code which uses fgetc/ungetc (especially if it has to operate on a stream owned by code written in another language). I think C's approach is often more convenient, but if a C function performs a fgetc followed by an ungetc and the next read is done by code in another language, it may be impossible to avoid having the put-back character appear at the proper spot in the stream.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-13 21:37 +0000 |
| Message-ID | <o2ppjs$a46$1@dont-email.me> |
| In reply to | #99255 |
On 13/12/2016 20:48, supercat@casperkitty.com wrote:
> On Tuesday, December 13, 2016 at 2:10:10 PM UTC-6, Bart wrote:
>> (BTW the Ada example also uses a loop with a pre-reading EOF check. I
>> guess it's OK when a well-respected other language does it. But if /I/
>> suggest it, it /must/ be wrong!)
>
> Different platforms have different "natural" methods of performing I/O, and
> some languages use I/O semantics which fit better with their abilities than
> would be possible in others. Some languages like Pascal let a program "peek"
> at the next character of a stream without consuming it--an operation which
> is roughly analogous to doing a fgetc followed by a ungetc. If a platform
> has a non-consuming "peek" function, code written to use that may work out
> more smoothly than code which uses fgetc/ungetc (especially if it has to
> operate on a stream owned by code written in another language). I think
> C's approach is often more convenient, but if a C function performs a
> fgetc followed by an ungetc and the next read is done by code in another
> language, it may be impossible to avoid having the put-back character appear
> at the proper spot in the stream.
>
Funny you should say that. If I write in my interpreted language:
while not eof(f) do
readln @f, a,b,c
od
Then the 'eof' is implemented in the same language, and built on top of
fgetc/ungetc from a dynamic version of msvcrt.dll/libc.so.6.
But 'readln' is built-in, and uses fgets from the C runtime statically
linked to the interpreter.
However, file handles such as 'f' are incompatible across the two! Even
if they start with the same msvcrt.dll file. I think because the two
instances have different sets of file descriptor tables.
(This was fixed but I can't remember how.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-14 00:08 +0000 |
| Message-ID | <87y3zj8j94.fsf@bsb.me.uk> |
| In reply to | #99248 |
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.
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.
> char* p;
> int n;
> *buffer = 0;
> if (fgets(buffer,size-2,handle) == 0) {
Why -2?
> return;
> }
> n = strlen(buffer);
> if (n == 0) {
> return;
> }
> p = (buffer+n)-1;
Why the brackets?
> 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.
I'll put aside the fact that you are trying to handle CRLF yourself
(that's another massive thread where all other C programmers are doing
it wrong), but (a) why 10 and 13 rather than character constants? and
why do you remove CR characters that are /not/ part of the line ending?
> }
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-14 01:24 +0000 |
| Message-ID | <o2q6ub$ns5$1@dont-email.me> |
| In reply to | #99295 |
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.
> 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.
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.
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.
> I'll put aside the fact that you are trying to handle CRLF yourself
> (that's another massive thread where all other C programmers are doing
> it wrong), but (a) why 10 and 13 rather than character constants?
Sometimes I define cr and lf, and sometimes I don't. For example, I
might use 13 and 10 for a quick test, then the code becomes permanent.
>and
> 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 expect newline sequences to be either CR/LF or LF (I no longer support
CR and have never come across LF/CR).
CR/LF read under Windows I think converts to LF in the buffer. Under
Linux as CR/LF.
LF read under Linux is just LF; under Windows ... I'm not sure but fgets
seems to have no trouble reading separate lines using just LF.
Anyway I get rid of all these controls where I can, but I'm not going to
search the entire buffer for stray CRs.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-13 17:56 -0800 |
| Message-ID | <lnpokvnui7.fsf@kst-u.example.com> |
| In reply to | #99300 |
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.
In the US, the usual terms are (parentheses), [brackets], {braces}.
If ease of typing is an issue, you might consider "parens".
In any case, please think about the possibility of ambiguity --
for example you might use [square brackets] and {curly braces}.
And perhaps (round brackets) if you choose to use that word.
[...]
>> I'll put aside the fact that you are trying to handle CRLF yourself
>> (that's another massive thread where all other C programmers are doing
>> it wrong), but (a) why 10 and 13 rather than character constants?
>
> Sometimes I define cr and lf, and sometimes I don't. For example, I
> might use 13 and 10 for a quick test, then the code becomes permanent.
You don't need to define identifiers, just use the standard character
constants '\r' and '\n'.
> >and
> > 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 expect newline sequences to be either CR/LF or LF (I no longer support
> CR and have never come across LF/CR).
>
> CR/LF read under Windows I think converts to LF in the buffer. Under
> Linux as CR/LF.
>
> LF read under Linux is just LF; under Windows ... I'm not sure but fgets
> seems to have no trouble reading separate lines using just LF.
A line ending sequence, whatever it is, is translated to a single '\n'
character on input from a text stream. It's not surpising that on
Windows, and untranslated LF character (not necessarily recognized
explicitly as an end-of-line marker) would appear as '\n'.
> Anyway I get rid of all these controls where I can, but I'm not going to
> search the entire buffer for stray CRs.
My advice: Treat text as text. If you need to read text in some foreign
format, translate it before feeding it to your program.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-14 02:33 +0000 |
| Message-ID | <o2qaul$p4j$1@dont-email.me> |
| In reply to | #99301 |
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.
--
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 4 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