Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #77859 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2015-12-04 16:06 -0800 |
| Last post | 2015-12-10 10:00 -0800 |
| Articles | 20 on this page of 400 — 31 participants |
Back to article view | Back to comp.lang.c
Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-04 16:06 -0800
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-05 13:15 +1300
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-04 16:19 -0800
Re: Prefix and postfix Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 01:18 +0000
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-04 20:33 -0500
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-05 07:55 -0800
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-05 09:09 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-05 11:40 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-06 23:33 +0100
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-06 23:10 +0000
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-06 15:34 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 10:14 +0100
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-06 16:11 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 00:27 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 01:15 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 00:13 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 01:26 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-07 14:51 +1300
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 02:25 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-07 15:55 +1300
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 11:13 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 11:32 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 12:55 +0100
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 12:14 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 12:29 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 13:49 +0100
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 13:47 +0100
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-07 14:11 +0000
Re: Prefix and postfix Waldek Hebisch <hebisch@antispam.uni.wroc.pl> - 2015-12-13 00:39 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-13 01:17 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-12 18:21 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-13 08:31 +0000
Re: Prefix and postfix Udyant Wig <udyantw@gmail.com> - 2015-12-13 15:12 +0530
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-13 03:40 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-13 11:41 +0000
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-07 12:55 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-07 11:46 -0800
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-08 01:07 +0000
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-07 09:11 -0500
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 15:26 +0100
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-07 08:25 -0500
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-07 13:59 +0000
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-07 09:06 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 14:12 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-07 08:36 -0800
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-07 21:01 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-07 15:16 -0800
Re: Prefix and postfix Ken Brody <kenbrody@spamcop.net> - 2015-12-08 13:58 -0500
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-07 12:11 -0500
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 11:06 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 13:02 +0100
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 14:37 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 15:17 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 21:39 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 23:04 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-08 01:19 +0000
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-08 01:12 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-08 09:11 +0100
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 17:19 +0100
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 22:50 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-08 01:26 +0100
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-08 01:27 +0000
Re: Prefix and postfix Udyant Wig <udyantw@gmail.com> - 2015-12-09 17:22 +0530
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-09 13:15 +0100
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-09 13:07 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-08 07:54 +1300
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 23:41 +0100
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-07 17:50 -0500
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-07 19:43 -0500
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 23:14 +0000
Re: Prefix and postfix David Thompson <dave.thompson2@verizon.net> - 2015-12-22 06:45 -0500
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-07 12:00 -0500
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 09:04 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 19:59 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 12:14 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 12:45 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 19:56 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 01:58 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 11:48 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 19:09 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 19:41 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 23:26 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 11:38 +0100
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 02:52 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 13:04 +0100
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 05:10 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 13:57 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 08:20 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 08:42 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 17:19 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 09:27 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 17:41 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 09:46 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 09:50 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 18:09 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 10:17 -0800
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-07 10:21 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 15:33 +0100
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 08:50 -0800
Re: Prefix and postfix Richard Damon <Richard@Damon-Family.org> - 2015-12-07 13:43 -0500
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 10:54 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 11:00 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 13:07 +0100
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-07 04:19 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 13:58 +0100
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 12:32 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 20:57 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-08 00:10 +0100
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-07 15:40 -0800
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-08 12:55 +1300
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-08 00:43 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-08 01:28 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-08 01:53 +0000
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-08 16:44 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-08 17:47 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-08 10:46 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-08 19:27 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-08 12:30 -0800
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-08 12:37 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-08 21:47 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-08 23:20 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-09 01:15 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-09 02:07 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-09 13:24 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-09 14:54 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-09 15:20 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-09 07:59 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-09 21:43 +0000
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-09 08:45 -0800
Re: Prefix and postfix David Thompson <dave.thompson2@verizon.net> - 2015-12-22 06:45 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-08 19:20 -0800
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-10 21:01 +0000
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-10 16:31 -0500
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-10 14:03 -0800
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-11 02:16 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 10:20 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-11 02:24 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 10:39 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-11 03:20 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 12:02 +0000
Re: Prefix and postfix Ken Brody <kenbrody@spamcop.net> - 2015-12-11 13:06 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-10 21:46 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-11 10:57 +1300
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-10 22:09 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-11 11:22 +1300
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-10 17:27 -0500
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-10 23:07 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 00:11 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 00:25 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 01:42 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 02:36 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 02:55 +0000
Re: Prefix and postfix Udyant Wig <udyantw@gmail.com> - 2015-12-11 20:04 +0530
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-11 02:22 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 10:33 +0000
Re: Prefix and postfix Ken Brody <kenbrody@spamcop.net> - 2015-12-11 13:28 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-11 12:30 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 11:23 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 12:38 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 14:21 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 14:55 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 15:19 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 15:28 +0000
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-11 08:46 -0800
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-11 12:18 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-11 12:27 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-11 17:30 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-11 08:51 -0800
Re: Prefix and postfix Philip Lantz <prl@canterey.us> - 2015-12-17 10:55 -0800
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-17 11:24 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-11 18:04 +0100
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-12 08:58 +1300
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 22:08 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-12 11:32 +1300
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 22:48 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-12 11:57 +1300
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-11 15:33 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 23:43 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-11 20:37 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-11 23:23 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-12 00:01 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-12 02:15 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-12 11:15 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-13 00:52 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-13 02:05 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-12 18:35 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-13 13:35 +0000
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-13 11:48 -0800
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-13 20:36 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-13 13:14 -0800
Re: Prefix and postfix Gareth Owen <gwowen@gmail.com> - 2015-12-13 21:38 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-13 22:35 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-13 14:48 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-13 23:05 +0000
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-13 18:08 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-13 15:44 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-14 00:42 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-13 19:48 -0800
Re: Prefix and postfix Gareth Owen <gwowen@gmail.com> - 2015-12-14 06:58 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-14 00:04 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 12:12 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-14 08:07 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 17:23 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-14 10:58 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-14 12:29 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 14:52 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-14 19:37 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 20:33 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-15 09:45 +1300
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-14 13:16 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 21:34 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-14 21:45 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 22:00 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-14 22:23 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-14 14:41 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 23:38 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 00:50 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-14 17:00 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-15 01:20 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 11:41 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-15 04:03 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 12:47 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-15 05:42 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 14:11 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-15 06:24 -0800
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-15 17:13 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-15 08:57 -0800
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-15 11:05 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 03:52 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-16 05:38 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-15 22:30 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-16 11:17 +0100
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-16 05:38 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-16 15:02 +0100
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-16 06:10 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-16 14:47 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-16 07:09 -0800
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 08:11 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-16 09:04 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-16 09:21 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 15:19 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-16 07:33 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 15:34 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 15:54 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 21:11 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 22:36 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 15:33 -0800
Re: Prefix and postfix ais523 <ais523@nethack4.org> - 2015-12-24 09:02 +0000
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-25 09:12 -0800
Re: Prefix and postfix ais523 <ais523@nethack4.org> - 2015-12-28 07:15 +0000
Re: Prefix and postfix Philip Lantz <prl@canterey.us> - 2015-12-27 18:40 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-17 00:39 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-17 02:22 +0000
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-16 11:00 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 16:06 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 08:52 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 21:24 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 16:04 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-17 00:55 +0000
Re: Prefix and postfix Gareth Owen <gwowen@gmail.com> - 2015-12-17 19:45 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-17 01:54 +0000
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-16 22:43 -0500
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-17 04:34 +0000
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-17 08:46 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 23:45 -0800
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-17 16:14 -0500
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-17 14:12 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-17 22:42 +0000
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-17 18:21 -0500
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-17 18:43 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-18 00:21 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-17 17:01 -0800
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-16 22:38 -0500
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-17 06:25 -0800
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-17 17:10 -0500
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-17 15:04 -0800
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-17 17:24 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 12:26 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 14:46 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-16 07:14 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-16 07:28 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 15:28 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-16 07:40 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-16 16:58 +0100
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-16 09:02 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-17 13:58 +0100
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-17 09:38 -0800
Re: Prefix and postfix Les Cargill <lcargill99@comcast.com> - 2015-12-17 12:31 -0600
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-17 21:07 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-18 11:35 +0100
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-18 11:12 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-19 15:08 +0100
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-19 19:36 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-19 21:08 +0100
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-20 00:48 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-20 09:51 +0100
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-19 12:09 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-19 23:13 +0100
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-19 14:50 -0800
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-19 17:18 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-19 14:56 -0800
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-19 18:04 -0500
Re: Prefix and postfix David Thompson <dave.thompson2@verizon.net> - 2015-12-28 05:12 -0500
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-19 21:42 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-20 09:42 +0100
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-20 08:54 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-21 17:04 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-21 18:34 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-22 15:47 +1300
Re: Prefix and postfix Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2015-12-22 07:09 +0100
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-22 21:56 +1300
Re: Prefix and postfix Melzzzzz <mel@zzzzz.com> - 2015-12-22 12:12 +0100
Re: Prefix and postfix Paul <nospam@needed.com> - 2015-12-22 06:49 -0500
Re: Prefix and postfix Melzzzzz <mel@zzzzz.com> - 2015-12-22 14:44 +0100
Re: Prefix and postfix David Thompson <dave.thompson2@verizon.net> - 2015-12-28 05:13 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-20 21:45 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-20 19:04 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-21 10:51 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-21 12:22 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-20 21:49 +1300
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-20 06:36 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-20 18:42 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-20 15:28 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-20 09:17 -0800
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-21 08:10 +1300
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-21 08:06 +1300
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-20 19:58 +0000
Re: Prefix and postfix "D. Lowe" <d.lowe@openmailbox.org> - 2015-12-20 21:16 +0000
Re: Prefix and postfix "D. Lowe" <d.lowe@openmailbox.org> - 2015-12-20 21:22 +0000
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-20 16:39 -0500
Re: Prefix and postfix "D. Lowe" <d.lowe@openmailbox.org> - 2015-12-20 21:57 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-18 11:18 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-18 11:50 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-18 04:04 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-18 22:56 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-18 20:28 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-19 22:13 +0000
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-18 09:31 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-18 08:44 -0800
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-19 12:44 -0800
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-19 11:59 +1300
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-19 15:18 +0100
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-20 11:32 +1300
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-20 09:58 +0100
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 17:05 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-16 21:27 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-17 02:39 -0800
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 08:20 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 15:52 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 18:51 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 08:19 -0800
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-17 00:16 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-15 11:07 +1300
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-14 19:53 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 01:14 +0000
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-14 20:42 -0500
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-14 20:50 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 02:00 +0000
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-14 21:27 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 10:45 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-15 03:20 -0800
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-15 08:25 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 14:38 +0000
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-15 11:12 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-15 08:53 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 18:10 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-15 11:50 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 20:13 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-15 13:21 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 22:13 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-15 16:40 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 01:48 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-15 23:56 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 11:38 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 14:11 +0000
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-15 17:23 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 02:51 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-14 08:18 -0800
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-14 09:10 -0800
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-14 09:22 -0800
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-14 12:28 -0500
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-14 09:41 -0800
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-14 11:13 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-14 12:42 -0800
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-14 09:05 -0800
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-13 12:24 -0800
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-13 13:17 -0800
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-11 19:56 -0500
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-11 20:09 -0500
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-11 12:44 -0500
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-11 21:52 +0000
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-13 20:25 +0000
Re: Prefix and postfix Ken Brody <kenbrody@spamcop.net> - 2015-12-11 12:58 -0500
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-08 11:54 -0800
Re: Prefix and postfix Tim Rentsch <txr@alumni.caltech.edu> - 2015-12-09 11:59 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-08 09:41 +0100
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-08 09:45 +0100
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 00:31 +0000
Re: Prefix and postfix John Bode <jfbode1029@gmail.com> - 2015-12-10 08:56 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-10 10:00 -0800
Page 19 of 20 — ← Prev page 1 … 17 18 [19] 20 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-12-15 03:20 -0800 |
| Message-ID | <fe84dc50-efd4-4bd5-8efb-882a6d2f13c7@googlegroups.com> |
| In reply to | #78740 |
Bart wrote: > I just can't win. Victory is achieved only in truth. If you know you are correct, be content within that knowing. Try and teach and lift those around you by the knowledge and vision you possess, but also realize that some people will never understand despite the use of many words and examples, because their goals are not in understanding, but in arguing and in confrontation. It takes a firm resolve and solid self-assurance to state that which is true in the face of opposition, and then to be content within that truth simply knowing you are correct, and that you tried honestly and earnestly to educate others. Some people will never grab hold of that which is right because they aren't right-seeking, and are purposefully desiring to walk in wrongness. Be strong ... and walk within that which you know. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-15 08:25 -0500 |
| Message-ID | <n4p475$i6k$1@dont-email.me> |
| In reply to | #78740 |
On 12/15/2015 5:45 AM, BartC wrote: > On 15/12/2015 02:27, Jerry Stuckle wrote: >> On 12/14/2015 9:00 PM, BartC wrote: > >>> >>> Well, I've been using it for years without much problem. The only issue >>> I know of is a possible change of state between eof() returning False, >>> and a subsequent read (when eof status might have become True). But all >>> i/o routines will still do their own checking (so fread returns 0, fgetc >>> returns EOF etc). >>> >> >> Well, you might want to pay more attention to what others have been >> telling you. > > In the discussion I pointed out that many other languages use exactly > the same technique, including Ada. > > But Ada was dismissed as being an old-fashioned clone of Pascal! All > obsolete languages of no significance. > > I introduced that eof() check into the debate because someone didn't > like the way I used 'break' within a loop (I think it was originally > about cramming too much into a while condition.) > > I then again pointed many languages using the exactly the same > technique. Again that was dismissed. > > I just can't win. > Just because something is done, in C or another language, doesn't mean it is right or good code. I've seen a lot of bad code in close to 20 languages and over 45 years of programming. Unfortunately, with the internet, many of these bad coding styles are being promoted by poor programmers on unsuspecting newbies. Instead of arguing that your way is "right", please try to understand what others are telling you. It will make you a better programmer in the long run. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-15 14:38 +0000 |
| Message-ID | <n4p8ho$2t2$1@dont-email.me> |
| In reply to | #78749 |
On 15/12/2015 13:25, Jerry Stuckle wrote: > On 12/15/2015 5:45 AM, BartC wrote: >> In the discussion I pointed out that many other languages use exactly >> the same technique, including Ada. > Just because something is done, in C or another language, doesn't mean > it is right or good code. I've seen a lot of bad code in close to 20 > languages and over 45 years of programming. The fact remains that Ada has a function that can check for end-of-file ahead of an attempt to perform a read on a file. The same kind of function that people here are telling me can't possibly work. > Unfortunately, with the internet, many of these bad coding styles are > being promoted by poor programmers on unsuspecting newbies. > > Instead of arguing that your way is "right", I'm a little concerned about too much Unix-isms being promoted here. The majority of people giving advice seem to be doing to so from a Unix point of view. I try and be a little different. please try to understand > what others are telling you. It will make you a better programmer in > the long run. A bit late to change I think. I have a history of creating my own *simple* languages to program in. I try and avoid C except that it is sometimes a target of one of those languages, or I need to use a C library or API, or sometimes a bit of language design comes up that is discussed here. I also have never worked in Unix and don't want to. Perhaps that makes me a little receptive to lessons in coding style from C/Unix programmers... -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-15 11:12 -0500 |
| Message-ID | <n4pe02$ouv$1@dont-email.me> |
| In reply to | #78753 |
On 12/15/2015 9:38 AM, BartC wrote: > On 15/12/2015 13:25, Jerry Stuckle wrote: >> On 12/15/2015 5:45 AM, BartC wrote: > >>> In the discussion I pointed out that many other languages use exactly >>> the same technique, including Ada. > >> Just because something is done, in C or another language, doesn't mean >> it is right or good code. I've seen a lot of bad code in close to 20 >> languages and over 45 years of programming. > > The fact remains that Ada has a function that can check for end-of-file > ahead of an attempt to perform a read on a file. > > The same kind of function that people here are telling me can't possibly > work. > This is not ADA. And feof() only tells you when you've read past EOF, as others have told you. >> Unfortunately, with the internet, many of these bad coding styles are >> being promoted by poor programmers on unsuspecting newbies. >> >> Instead of arguing that your way is "right", > > I'm a little concerned about too much Unix-isms being promoted here. The > majority of people giving advice seem to be doing to so from a Unix > point of view. I try and be a little different. > This has nothing to do with Unix. It's how the C libraries work. > please try to understand >> what others are telling you. It will make you a better programmer in >> the long run. > > A bit late to change I think. I have a history of creating my own > *simple* languages to program in. > > I try and avoid C except that it is sometimes a target of one of those > languages, or I need to use a C library or API, or sometimes a bit of > language design comes up that is discussed here. I also have never > worked in Unix and don't want to. > Once again, it has nothing to do with Unix. It's how the C libraries work. > Perhaps that makes me a little receptive to lessons in coding style from > C/Unix programmers... > Maybe you should learn from C programmers and forget about Windows vs. Linux. And while I program both Windows and Unix/Linux, and have worked with teams on both, I have found that on the whole, *nix programmers are better programmers than Windows programmers are. Before posting here I read through the last 10K or so messages. I didn't find any of the better programmers here giving you a single piece of bad advice. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-15 08:53 -0800 |
| Message-ID | <ln60zzd56f.fsf@kst-u.example.com> |
| In reply to | #78753 |
BartC <bc@freeuk.com> writes:
> On 15/12/2015 13:25, Jerry Stuckle wrote:
>> On 12/15/2015 5:45 AM, BartC wrote:
>>> In the discussion I pointed out that many other languages use exactly
>>> the same technique, including Ada.
>
>> Just because something is done, in C or another language, doesn't mean
>> it is right or good code. I've seen a lot of bad code in close to 20
>> languages and over 45 years of programming.
>
> The fact remains that Ada has a function that can check for end-of-file
> ahead of an attempt to perform a read on a file.
>
> The same kind of function that people here are telling me can't possibly
> work.
Who said it "can't possibly work"?
Here's an excerpt from the book "Ada: An Advanced Introduction" by
Narain Gehani (any typos are mine, asterisks denote italics):
Interactive input in Ada suffers from a problem similar to one
in Pascal [Feuer & Gehani 1982]. Using the paradigm
while not END_OF_FILE (STANDARD_INPUT) loop
*request data from user;*
*read data;*
...
end loop;
to read input interactively from a terminal is troublesome.
Function END_OF_FILE cannot be evaluated when there is no data
because it cannot determine whether the data has been exhausted
or that the data has not been supplied as yet. Consequently,
evaluation of END_OF_FILE will be delayed until the user
supplied the data -- but the user has no way of knowing that
the program is waiting for the data because the prompt will
not be printed.
This problem can be avoided by using the following paradigm
[Wetherell 1983]:
loop
*request data from user;*
exit when END_OF_FILE(STANDARD_INPUT);
*read data;*
...
end loop;
C's input functions are designed differently, with the intention that
the result of each input function is checked to determine whether it
succeeded or not.
If you prefer Ada-style input, you can certainly implement it in C
-- and then if you want to do interactive input, you need the same
kind of workaround described above (checking end-of-file immediately
before attempting to read input). Your eof() function that you
posted previously has the side effect of potentially waiting for
input; I'm surprised that doesn't bother you. (It also interferes
with any other usage of ungetc().)
[...]
> I'm a little concerned about too much Unix-isms being promoted here. The
> majority of people giving advice seem to be doing to so from a Unix
> point of view. I try and be a little different.
I suggest that style of input handling being discussed is a C-ism, not
necessarily a Unix-ism. Admittedly C and Unix evolved together, but C
code like
while ((c = getchar()) != EOF) { /* ... */ }
should work reasonably well on any system, Unix or otherwise.
(FWIW, I have Ada and Pascal compilers on my Linux system, though
I don't use them much.)
[...]
--
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 | 2015-12-15 18:10 +0000 |
| Message-ID | <n4pkvi$mlt$1@dont-email.me> |
| In reply to | #78757 |
On 15/12/2015 16:53, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> The fact remains that Ada has a function that can check for end-of-file
>> ahead of an attempt to perform a read on a file.
>>
>> The same kind of function that people here are telling me can't possibly
>> work.
>
> Who said it "can't possibly work"?
>
> Here's an excerpt from the book "Ada: An Advanced Introduction" by
> Narain Gehani (any typos are mine, asterisks denote italics):
> while not END_OF_FILE (STANDARD_INPUT) loop
It looks like it's picked up an affliction of standard-input-itis from C!
I'm going to try and show that my use of an advance-checking eof()
function can work, whether for a file, stdin or for a keyboard used to
emulate a file. (Obviously I would prefer that a keyboard isn't subject
to these ignominious 'end_of_file' checks, but I'll set that aside.)
Here's how I might process input from file F a character at a time:
while (!eof(F)) {
c = fgetc(F);
*p++ = c; // do something with c
}
Here's how everyone is telling me I ought to write that loop:
while ((c=fgetc(F))!=EOF) {
*p++ = c;
}
Let's take that last loop and write it a little differently:
while (1) {
c=fgetc(F);
if (c==EOF) break;
*p++ = c
}
You agree that this is the same, but a slightly different style? OK, now
look carefully, because I will put some extra statements in that loop:
while (1) {
c=fgetc(F);
if (c==EOF) break;
ungetc(c,F);
c=fgetc(F);
if (c==EOF) break;
*p++ = c
}
The fgetc(c)/ungetc() sequence is odd, but would it stop anything
working as before?
Now for the next step. You notice there are now two checks for EOF, but
is the second one needed? Because the second fgetc only fetches the
non-EOF character that has just been passed to ungetc. Then it is
possible to change the loop to:
while (1) {
c=fgetc(F);
if (c==EOF) break;
ungetc(c,F);
c=fgetc(F);
*p++ = c
}
Now there is one more transformation, which is to extract the
fgetc/ungetc sequence into a function like this:
int eof(FILE* F) {
int c;
c = fgetc(F);
if (c==EOF) return 1;
ungetc(c,F);
return 0;
}
And the loop now becomes:
while (!eof(F)) {
c = fgetc(F);
*p++ = c
}
Exactly the same as my eof()-checking version!
Have I missed anything? Is there any reason why it won't work if there
was fread or fgets in the body of the loop rather than fgetc? It seems
to be that we know there is at least one character waiting to be read.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-15 11:50 -0800 |
| Message-ID | <lnsi33bieb.fsf@kst-u.example.com> |
| In reply to | #78763 |
BartC <bc@freeuk.com> writes:
> On 15/12/2015 16:53, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> The fact remains that Ada has a function that can check for end-of-file
>>> ahead of an attempt to perform a read on a file.
>>>
>>> The same kind of function that people here are telling me can't possibly
>>> work.
>>
>> Who said it "can't possibly work"?
>>
>> Here's an excerpt from the book "Ada: An Advanced Introduction" by
>> Narain Gehani (any typos are mine, asterisks denote italics):
>
>> while not END_OF_FILE (STANDARD_INPUT) loop
>
> It looks like it's picked up an affliction of standard-input-itis from C!
So reading from standard input is a bad thing? There's a reason it's
called *standard* input.
> I'm going to try and show that my use of an advance-checking eof()
> function can work, whether for a file, stdin or for a keyboard used to
> emulate a file. (Obviously I would prefer that a keyboard isn't subject
> to these ignominious 'end_of_file' checks, but I'll set that aside.)
>
> Here's how I might process input from file F a character at a time:
>
> while (!eof(F)) {
> c = fgetc(F);
> *p++ = c; // do something with c
> }
>
> Here's how everyone is telling me I ought to write that loop:
>
> while ((c=fgetc(F))!=EOF) {
> *p++ = c;
> }
That's how everyone is telling you that loop is normally written. You
can write it any way you like.
> Let's take that last loop and write it a little differently:
>
> while (1) {
> c=fgetc(F);
> if (c==EOF) break;
> *p++ = c
> }
>
> You agree that this is the same, but a slightly different style?
Yes. (I'll just mention that I don't think it's an improvement. I
understand why someone might dislike the usual idiom, but you only have
to learn it once.)
> OK, now
> look carefully, because I will put some extra statements in that loop:
>
> while (1) {
> c=fgetc(F);
> if (c==EOF) break;
> ungetc(c,F);
>
> c=fgetc(F);
> if (c==EOF) break;
> *p++ = c
> }
>
> The fgetc(c)/ungetc() sequence is odd, but would it stop anything
> working as before?
Possibly; see below.
> Now for the next step. You notice there are now two checks for EOF, but
> is the second one needed? Because the second fgetc only fetches the
> non-EOF character that has just been passed to ungetc. Then it is
> possible to change the loop to:
>
> while (1) {
> c=fgetc(F);
> if (c==EOF) break;
> ungetc(c,F);
>
> c=fgetc(F);
> *p++ = c
> }
>
> Now there is one more transformation, which is to extract the
> fgetc/ungetc sequence into a function like this:
>
> int eof(FILE* F) {
> int c;
> c = fgetc(F);
> if (c==EOF) return 1;
> ungetc(c,F);
> return 0;
> }
>
> And the loop now becomes:
>
> while (!eof(F)) {
> c = fgetc(F);
> *p++ = c
> }
>
> Exactly the same as my eof()-checking version!
>
> Have I missed anything? Is there any reason why it won't work if there
> was fread or fgets in the body of the loop rather than fgetc? It seems
> to be that we know there is at least one character waiting to be read.
The standard only guarantees one character of pushback. The user (the
person writing the body of the loop) can't safely call ungetc() because
you've called it yourself, and you've hidden the call inside your eof()
function. Any file positioning function discards any pushed-back
characters. The file position indicator is unspecified after a call to
ungetc() until all pushed-back characters have been read or discarded.
You don't check whether ungetc() succeeded, or whether the subsequent
call to fgetc() returned EOF; both of those are *probably* safe, but
they make me nervous.
On the other hand, the conventional
while ((c = fgetc(F)) != EOF) {
/* ... */
}
is idiomatic C (not specific to any operating system), and it works
without having to define any additional functions.
Apart from that, sure, your eof() function *can* work. You can build
your moderately complex infrastructure on top of C's I/O facilities to
make them look more like your preferred model. I just don't see what
benefit you get from this exercise that's worth the added complexity.
I'm not saying you can't do this. I'm just wondering why you'd want 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-15 20:13 +0000 |
| Message-ID | <n4ps4u$mnm$1@dont-email.me> |
| In reply to | #78770 |
On 15/12/2015 19:50, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> while (!eof(F)) {
>> c = fgetc(F);
>> *p++ = c; // do something with c
>> }
>> Have I missed anything? Is there any reason why it won't work if there
>> was fread or fgets in the body of the loop rather than fgetc? It seems
>> to be that we know there is at least one character waiting to be read.
>
> The standard only guarantees one character of pushback.
OK. So someone can't ungetc any arbitrary character within the body of
the loop, not unless it was paired to a previous fgetc or other read
operation.
> The user (the
> person writing the body of the loop) can't safely call ungetc() because
> you've called it yourself, and you've hidden the call inside your eof()
> function.
After reading this from MSDN docs, what I do doesn't seem so bad:
"After a call to fscanf, a call to ungetc may fail unless another read
operation (such as getc) has been performed. This is because fscanf
itself calls ungetc."
> Any file positioning function discards any pushed-back
> characters. The file position indicator is unspecified after a call to
> ungetc() until all pushed-back characters have been read or discarded.
> You don't check whether ungetc() succeeded,
The only error return is EOF, and that is checked.
> Apart from that, sure, your eof() function *can* work. You can build
> your moderately complex infrastructure on top of C's I/O facilities to
> make them look more like your preferred model. I just don't see what
> benefit you get from this exercise that's worth the added complexity.
>
> I'm not saying you can't do this. I'm just wondering why you'd want to.
One or two people have expressed doubts and others have made it clear
they don't like it. The advantage is more user-friendly access to files
(usually expressed via a higher level language).
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-15 13:21 -0800 |
| Message-ID | <lnk2ofbe6w.fsf@kst-u.example.com> |
| In reply to | #78771 |
BartC <bc@freeuk.com> writes:
> On 15/12/2015 19:50, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> while (!eof(F)) {
>>> c = fgetc(F);
>>> *p++ = c; // do something with c
>>> }
>
>>> Have I missed anything? Is there any reason why it won't work if there
>>> was fread or fgets in the body of the loop rather than fgetc? It seems
>>> to be that we know there is at least one character waiting to be read.
>>
>> The standard only guarantees one character of pushback.
>
> OK. So someone can't ungetc any arbitrary character within the body of
> the loop, not unless it was paired to a previous fgetc or other read
> operation.
>
>> The user (the
>> person writing the body of the loop) can't safely call ungetc() because
>> you've called it yourself, and you've hidden the call inside your eof()
>> function.
>
> After reading this from MSDN docs, what I do doesn't seem so bad:
>
> "After a call to fscanf, a call to ungetc may fail unless another read
> operation (such as getc) has been performed. This is because fscanf
> itself calls ungetc."
It seems worse to me. It means your eof() function can interfere with
fscanf().
>> Any file positioning function discards any pushed-back
>> characters. The file position indicator is unspecified after a call to
>> ungetc() until all pushed-back characters have been read or discarded.
>> You don't check whether ungetc() succeeded,
>
> The only error return is EOF, and that is checked.
Here's your eof() function:
int eof(FILE* F) {
int c;
c = fgetc(F);
if (c==EOF) return 1;
ungetc(c,F);
return 0;
}
You discard the value returned by ungetc().
>> Apart from that, sure, your eof() function *can* work. You can build
>> your moderately complex infrastructure on top of C's I/O facilities to
>> make them look more like your preferred model. I just don't see what
>> benefit you get from this exercise that's worth the added complexity.
>>
>> I'm not saying you can't do this. I'm just wondering why you'd want to.
>
> One or two people have expressed doubts and others have made it clear
> they don't like it. The advantage is more user-friendly access to files
> (usually expressed via a higher level language).
I don't agree that it's more user-friendly. It's more similar to the
model used in some other languages, but as we've discussed that model
causes some real problems with interactive input, problems that the
usual C idiom does not have.
In your version of the input loop:
while (!eof(F)) {
c = fgetc(F);
*p++ = c;
}
you assume that fgetc(F) returns a non-EOF result. That's likely to be
a valid assumption, since the previous operation was a call to ungetc(),
but I can imagine errors that might cause it to return EOF and set the
error indicator. If that happens, you do the equivalent of `*p++ =
EOF;`.
In the usual idiom:
while ((c = fgetc(F)) != EOF) {
*p++ = c;
}
we don't assume that fgetc() cannot fail in certain circumstances. We
always check, and that check is what controls the termination of the
loop.
--
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 | 2015-12-15 22:13 +0000 |
| Message-ID | <n4q379$j2a$1@dont-email.me> |
| In reply to | #78774 |
On 15/12/2015 21:21, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> On 15/12/2015 19:50, Keith Thompson wrote:
>>> The user (the
>>> person writing the body of the loop) can't safely call ungetc() because
>>> you've called it yourself, and you've hidden the call inside your eof()
>>> function.
>>
>> After reading this from MSDN docs, what I do doesn't seem so bad:
>>
>> "After a call to fscanf, a call to ungetc may fail unless another read
>> operation (such as getc) has been performed. This is because fscanf
>> itself calls ungetc."
>
> It seems worse to me. It means your eof() function can interfere with
> fscanf().
I don't think so. Presumably fscanf() will have done a read before doing
ungetc(). Otherwise fscanf would interfere with fscanf.
(And fscanf can't interefere with eof() because the latter does a read
first.)
>>> You don't check whether ungetc() succeeded,
>>
>> The only error return is EOF, and that is checked.
>
> Here's your eof() function:
>
> int eof(FILE* F) {
> int c;
> c = fgetc(F);
> if (c==EOF) return 1;
> ungetc(c,F);
> return 0;
> }
>
> You discard the value returned by ungetc().
Oh, OK. That needs a slightly different return arrangement then
(although secretly I don't think it's a problem; a character is being
put back into a buffer, that's all, it's not getting back to the
physical device.
> I don't agree that it's more user-friendly. It's more similar to the
> model used in some other languages, but as we've discussed that model
> causes some real problems with interactive input, problems that the
> usual C idiom does not have.
But C seems to have a problem defining what interactive input actually
is. That's all been discussed. Since I'm most likely to be using these
functions from outside the language, eof() checking will done for actual
files, while interactive input won't bother with eof at all, since there
is no actual 'end-of-file' associated with a keyboard.
(In fact, the way I use the C file functions, because I tend to use a
second, dynamic invocation of the runtime library, I have trouble
obtaining the value of stdin, and might not be able to access stdin to
pick up a redirected file, but those are not techniques I use.)
> we don't assume that fgetc() cannot fail in certain circumstances. We
> always check, and that check is what controls the termination of the
> loop.
Yes, but in interactive input, you have to 'crash out' of the loop by
pressing some key that emulates end-of-file. That's not so hot either.
But I think if my eof() function is documented, then these problems can
be overcome. (The most common use I think is for reading a line at a
time, that operation can contain an extra check.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-15 16:40 -0800 |
| Message-ID | <ln4mfjb4z9.fsf@kst-u.example.com> |
| In reply to | #78776 |
BartC <bc@freeuk.com> writes:
> On 15/12/2015 21:21, Keith Thompson wrote:
[...]
>> Here's your eof() function:
>>
>> int eof(FILE* F) {
>> int c;
>> c = fgetc(F);
>> if (c==EOF) return 1;
>> ungetc(c,F);
>> return 0;
>> }
>>
>> You discard the value returned by ungetc().
>
> Oh, OK. That needs a slightly different return arrangement then
> (although secretly I don't think it's a problem; a character is being
> put back into a buffer, that's all, it's not getting back to the
> physical device.
It's *probably* safe to assume that ungetc() immediately after a
successful fgetc() will succeed. It's absolutely 100% safe to assume
that an ungetc() won't fail if it's never called.
>> I don't agree that it's more user-friendly. It's more similar to the
>> model used in some other languages, but as we've discussed that model
>> causes some real problems with interactive input, problems that the
>> usual C idiom does not have.
>
> But C seems to have a problem defining what interactive input actually
> is.
N1570 5.1.2.3p6:
The input and output dynamics of interactive devices shall take
place as specified in 7.21.3. The intent of these requirements is
that unbuffered or line-buffered output appear as soon as possible,
to ensure that prompting messages actually appear prior to a program
waiting for input.
p7: What constitutes an interactive device is implementation-defined.
> That's all been discussed. Since I'm most likely to be using these
> functions from outside the language, eof() checking will done for actual
> files, while interactive input won't bother with eof at all, since there
> is no actual 'end-of-file' associated with a keyboard.
I really don't know what you mean by that last sentence. Typing Ctrl-Z
on Windows or Ctrl-D on Unix triggers and end-of-file condition when
reading from a keyboard. I know you know that; it's been discussed to
death in this very thread. I just don't know what assumption you're
making that lets you ignore it.
[...]
>> we don't assume that fgetc() cannot fail in certain circumstances. We
>> always check, and that check is what controls the termination of the
>> loop.
>
> Yes, but in interactive input, you have to 'crash out' of the loop by
> pressing some key that emulates end-of-file. That's not so hot either.
In Unix, typing Ctrl-D is a perfectly normal way to indicate that you've
reached the end of keyboard input. A program can very easily use some
other input (say, the word "quit") as another way to terminate input,
but if it doesn't also deal with EOF, it's going to have problems. If
you program pretends that getchar() will never return EOF and I type
Ctrl-D, it's likely to go into an infinite loop.
> But I think if my eof() function is documented, then these problems can
> be overcome. (The most common use I think is for reading a line at a
> time, that operation can contain an extra check.)
Yes, you can probably overcome most or all of the problems you're
creating. Have fun with that.
--
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 | 2015-12-16 01:48 +0000 |
| Message-ID | <n4qfq9$slu$1@dont-email.me> |
| In reply to | #78784 |
On 16/12/2015 00:40, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> That's all been discussed. Since I'm most likely to be using these >> functions from outside the language, eof() checking will done for actual >> files, while interactive input won't bother with eof at all, since there >> is no actual 'end-of-file' associated with a keyboard. > > I really don't know what you mean by that last sentence. Typing Ctrl-Z > on Windows or Ctrl-D on Unix triggers and end-of-file condition when > reading from a keyboard. I know you know that; it's been discussed to > death in this very thread. I just don't know what assumption you're > making that lets you ignore it. >> But I think if my eof() function is documented, then these problems can >> be overcome. (The most common use I think is for reading a line at a >> time, that operation can contain an extra check.) > > Yes, you can probably overcome most or all of the problems you're > creating. Have fun with that. I think I've been using this form of eof() checking for as long as I can remember. For files. Since the mid-90s, it's been implemented on top of the C runtime. I think if it had given problems, I would have switched to some OS functions instead. With the keyboard, I have *never* associated an end-of-file with it (why should I, it's just a keyboard and never runs out!). But hadn't realised how much of a big deal it is in C until this thread. And your comments are worrying: so someone can spend a long time typing stuff in, in a program with a proper "exit" method, but someone hits ^Z or ^D by accident, and the keyboard locks up? In that it won't deliver any more getchar or fgets inputs once it's in an eof state. Even if this is one corner of the application and there's lots more work to do. This is not desirable. Fortunately I think most serious programs of mine (which are not GUI anyway), use their own line-buffering based on getting individual keyboard events, or they just use key events anyway (for editors for example). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-15 23:56 -0800 |
| Message-ID | <lnzixaakt9.fsf@kst-u.example.com> |
| In reply to | #78785 |
BartC <bc@freeuk.com> writes:
[...]
> And your comments are worrying: so someone can spend a long time
> typing stuff in, in a program with a proper "exit" method, but someone
> hits ^Z or ^D by accident, and the keyboard locks up? In that it won't
> deliver any more getchar or fgets inputs once it's in an eof
> state. Even if this is one corner of the application and there's lots
> more work to do.
I just tried a quick experiment. In a simple program that reads
characters from stdin, typing Ctrl-D causes getchar() to return EOF --
but the *next* call to getchar() returns whatever was typed after the
Ctrl-D. I'm not sure whether that's conforming behavior or not, but
means that a program reading from stdin doesn't *have* to quit when you
type Ctrl-D.
And if you don't want Ctrl-D to terminate your program, you can
reconfigure the tty settings so Ctrl-D doesn't trigger and end-of-file
condition. (That's why Ctrl-D is able to scroll down half a screen in
vim, or delete a character in emacs.)
Not all programs are text filters, and nobody has said that all programs
*have* to be text filters. Do you object to the fact that *some*
programs are text filters?
[...]
--
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 | 2015-12-16 11:38 +0000 |
| Message-ID | <n4ribh$ou2$1@dont-email.me> |
| In reply to | #78790 |
On 16/12/2015 07:56, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
> [...]
>> And your comments are worrying: so someone can spend a long time
>> typing stuff in, in a program with a proper "exit" method, but someone
>> hits ^Z or ^D by accident, and the keyboard locks up? In that it won't
>> deliver any more getchar or fgets inputs once it's in an eof
>> state. Even if this is one corner of the application and there's lots
>> more work to do.
>
> I just tried a quick experiment. In a simple program that reads
> characters from stdin, typing Ctrl-D causes getchar() to return EOF --
> but the *next* call to getchar() returns whatever was typed after the
> Ctrl-D. I'm not sure whether that's conforming behavior or not, but
> means that a program reading from stdin doesn't *have* to quit when you
> type Ctrl-D.
I tried this code:
do {
c=getchar();
printf("%d\n",c);
} while (1);
On Windows, when Ctrl Z is typed at the start of a line**, then it
continuously prints -1s. I have to type Ctrl Z, then zero or more other
characters, then Enter. Once in the eof state, I don't need to press
Enter again.
On Linux, when I type Ctrl D at start of line, then I got a single -1
immediately (no Enter needed), but then it's receptive to more inputs.
Ctrl D at the end of a line has the same effect as Enter.
This is more reassuring, but raises more questions about what
end-of-file for a keyboard really means. And it brings up operating
differences between Linux and Windows, but also between a file and keyboard:
If I redirect a file to stdin, then the above loop continuously prints
-1 when it gets to the actual end-of-file. (I suppose that's one way of
telling the difference between file and keyboard entry!)
Suppose this is the input from any source (on a keyboard, ^D or ^Z Enter
is used to 'inject' the EOF):
('A', 'B', '\n', EOF)
And that input is read via this code:
getchar(); // 65
getchar(); // 66
getchar(); // 10
getchar(); // -1
c=getchar(): // ?
What value will c have? It will invariably be -1 except when reading
from an actual keyboard (or console) on Linux. Then it can't be
determined. (It will also have to wait for the next line input.)
(** Or immediately after the previous line, if anyone is confused.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-16 14:11 +0000 |
| Message-ID | <87twnisct6.fsf@bsb.me.uk> |
| In reply to | #78793 |
BartC <bc@freeuk.com> writes:
> On 16/12/2015 07:56, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>> [...]
>>> And your comments are worrying: so someone can spend a long time
>>> typing stuff in, in a program with a proper "exit" method, but someone
>>> hits ^Z or ^D by accident, and the keyboard locks up? In that it won't
>>> deliver any more getchar or fgets inputs once it's in an eof
>>> state. Even if this is one corner of the application and there's lots
>>> more work to do.
>>
>> I just tried a quick experiment. In a simple program that reads
>> characters from stdin, typing Ctrl-D causes getchar() to return EOF --
>> but the *next* call to getchar() returns whatever was typed after the
>> Ctrl-D. I'm not sure whether that's conforming behavior or not,
I am pretty sure that the way it's done (with the end of file indicator
set) is not conforming. See below for a bit more about that.
>> but
>> means that a program reading from stdin doesn't *have* to quit when you
>> type Ctrl-D.
>
> I tried this code:
>
> do {
> c=getchar();
> printf("%d\n",c);
> } while (1);
>
<snip>
> On Linux, when I type Ctrl D at start of line, then I got a single -1
> immediately (no Enter needed), but then it's receptive to more
> inputs. Ctrl D at the end of a line has the same effect as Enter.
Nit: ^D (in that position) flushes the input buffer so the program can see
it. Enter flushes the buffer *and* inserts a newline character, so not
exactly the same.
> This is more reassuring, but raises more questions about what
> end-of-file for a keyboard really means. And it brings up operating
> differences between Linux and Windows, but also between a file and
> keyboard:
>
> If I redirect a file to stdin, then the above loop continuously prints
> -1 when it gets to the actual end-of-file. (I suppose that's one way
> of telling the difference between file and keyboard entry!)
>
> Suppose this is the input from any source (on a keyboard, ^D or ^Z
> Enter is used to 'inject' the EOF):
>
> ('A', 'B', '\n', EOF)
>
> And that input is read via this code:
>
> getchar(); // 65
> getchar(); // 66
> getchar(); // 10
> getchar(); // -1
> c=getchar(): // ?
>
> What value will c have? It will invariably be -1 except when reading
> from an actual keyboard (or console) on Linux.
It's -1 on a conforming implementation, but Linux+gclibc is not
conforming in this case. The standard says:
If the end-of-file indicator for the stream is set, or if the stream
is at end-of-file, the end-of-file indicator for the stream is set and
the fgetc function returns EOF.
You'll see (if your system is like mine) that feof(stdin) returns 1
after the first EOF return and it "sticks" -- i.e. subsequent characters
are read and returned even though the eof indicator on the stream is
set. Thus getchar (a wrapper around fgetc) *should* return EOF but it
does not. This is by design, I think.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-12-15 17:23 +0000 |
| Message-ID | <56704c4f.9511078@news.xs4all.nl> |
| In reply to | #78753 |
BartC <bc@freeuk.com> wrote: > I try and avoid C Why are you here, then, constantly arguing that it should be the way you think it is rather than the way people who actually use it regularly _know_ it is? ichard
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-16 02:51 +0000 |
| Message-ID | <877fkft5ga.fsf@bsb.me.uk> |
| In reply to | #78740 |
BartC <bc@freeuk.com> writes: > On 15/12/2015 02:27, Jerry Stuckle wrote: >> On 12/14/2015 9:00 PM, BartC wrote: > >>> >>> Well, I've been using it for years without much problem. The only issue >>> I know of is a possible change of state between eof() returning False, >>> and a subsequent read (when eof status might have become True). But all >>> i/o routines will still do their own checking (so fread returns 0, fgetc >>> returns EOF etc). >>> >> >> Well, you might want to pay more attention to what others have been >> telling you. > > In the discussion I pointed out that many other languages use exactly > the same technique, including Ada. > > But Ada was dismissed as being an old-fashioned clone of Pascal! All > obsolete languages of no significance. Both have been very influential, and Ada is still very much alive and used (and a language I rather like, despite the IO model it has). It's hard to see how they could have been dismissed as of no significance since at least one commentator (me) was decrying their influence. <snip> > I then again pointed many languages using the exactly the same > technique. Again that was dismissed. No, I went through them all (didn't I?) -- it certainly took some time. If you are going to say that I dismiss your points even when I take time to rebut, then I might as well start doing that. I made a technical claim by which I stand: that the IO model at least partly present in C has become the one favoured in more modern language designs. This is the basic idea that you try the input operation and you get told if it worked (and you may then find out why by calling other functions to find out). The Pascal model is characterised by two things: that read is a procedure not a function (so you don't get told, directly, when it fails), and that EOF is true *before* the last data item (which need not be a byte in the case of Pascal) is read. To know for sure we should pick a set of influential languages, characterise which model they seem to use, and see if there is a statistically significant correlation with their ages. I've not done that and I don't think you have either. What's more, I don't think either of is *going* to do that, so let's just leave it as something we disagree about. If anyone else cares about this claim, they can just read the examples already discussed (and can use our posting histories as a guide to reliability and so on) and make their own mind up. > I just can't win. Yes, you can. Someone can read what you've written and decide that you have made a better case than I have. Winning readers over by using argument and evidence is the best sort of win. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-14 08:18 -0800 |
| Message-ID | <lnbn9tdmw5.fsf@kst-u.example.com> |
| In reply to | #78615 |
BartC <bc@freeuk.com> writes:
[...]
> We just insist that the input comes from a keyboard.
How are you going to "insist" on that?
If you want to write a program that takes text input and restricts
lines to 4K characters, nobody is going to stop you. If you document
the restriction, that's even better. But you're deliberately
limiting (perhaps only slightly) the usefulness of your program
compared to a version that accepts arbitrarily long lines.
--
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 | 2015-12-14 09:10 -0800 |
| Message-ID | <31fca9c7-3308-4db5-9c99-3b80dcd0510c@googlegroups.com> |
| In reply to | #78589 |
On Sunday, December 13, 2015 at 9:48:51 PM UTC-6, Keith Thompson wrote: > And because allowing for arbitrarily long lines is not difficult enough > to justify taking shortcuts, at least in production quality code. Sometimes it's easy; sometimes it's not. If a program feeds "grep z" two-gigabytes of data which end with "z\n" but don't contain either of those characters prior to that point, should a machine keep trying to malloc more and more memory to hold the incoming data, even if that grossly degrades the performance of all other processes on the machine, or should it do something else?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-12-14 09:22 -0800 |
| Message-ID | <b64b24d2-cbc3-4c2f-8836-f97f496a4536@googlegroups.com> |
| In reply to | #78658 |
On Monday, December 14, 2015 at 5:10:45 PM UTC, supe...@casperkitty.com wrote: > On Sunday, December 13, 2015 at 9:48:51 PM UTC-6, Keith Thompson wrote: > > And because allowing for arbitrarily long lines is not difficult enough > > to justify taking shortcuts, at least in production quality code. > > Sometimes it's easy; sometimes it's not. If a program feeds "grep z" > two-gigabytes of data which end with "z\n" but don't contain either of > those characters prior to that point, should a machine keep trying to > malloc more and more memory to hold the incoming data, even if that > grossly degrades the performance of all other processes on the machine, > or should it do something else? > It should keep on asking for memory until the OS refuses. it's the system's job to ration resources out. Agreed that we need more modern user interfaces where the user can say "This program is running my attempt to solve protein folding, give it all the resources you can except a tiny amount to keep the web browser and other services running. That program is currently under development, if it asks for more than a couple of megabytes it must be a bug, just refuse".
[toc] | [prev] | [next] | [standalone]
Page 19 of 20 — ← Prev page 1 … 17 18 [19] 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web