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 10 of 20 — ← Prev page 1 … 8 9 [10] 11 12 … 20 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-12 00:01 +0000 |
| Message-ID | <n4fo1c$eab$1@dont-email.me> |
| In reply to | #78471 |
On 11/12/2015 23:23, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > <snip> >> The issue was how to get EOF into a program. > > You can't get EOF "into" a program. You can get some part of the > software between the program and the keyboard to cause C's IO operations > to fail as if the stream is at end-of-file. They usually fail by > returning a negative integer value EOF, but not always (fgets, for > example, does not). I mean doing whatever it takes to make getchar() etc to return the EOF value. I guess that would also make fgets() fail. I'm not sure what fread would do but I suppose it would have to return 0. >> Apparently, it's Ctrl D >> on Unix (at the START of the line). > > Not at the start of a line but (almost the same thing) when the line > buffer is empty. When the buffer is not empty, ^D flushes it so that > your program can read the data. As a result, a second ^D (immediately > following the first) will close the input because the buffer is now > empty. OK. (Actually your explanation in a previous post was quite enlightening.) > <snip> >> While on Windows, it's the opposite way, and both Ctrl Z and Ctrl C >> can deliver the EOF character, while Ctrl D does little. > > It works quite differently. For one thing, if I remember properly, with > plain C input you have to type enter. ^C does not "deliver the EOF > character" on any system that I know about. With a getchar() loop that prints the returned value, typing in Ctrl C (in Windows) will print -1 (and also break, even if the loop doesn't test for EOF! But from within my IDE, Ctrl C returns EOF but won't break because it's disabled.) >> This introduces a little problem: Suppose I want the program to >> display something like this, in a platform-neutral manner? >> >> Press ? when you've finished entering data. >> >> what do I write for "?"? > > A common choice is something like "a single dot on a line by itself", or > "an empty line". You mean that the program can of course choose any kind of exit command? I had in mind the sort of loops of which there were many examples including yours, which were only looking at EOF. And especially testing my eof() routines, that's where getting that 'EOF' into the character stream became important! I would usually manage it with /some/ combination of the break keys, at various points on a line, and it just had to give the same results as not using eof(). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-12 02:15 +0000 |
| Message-ID | <87wpskpg3q.fsf@bsb.me.uk> |
| In reply to | #78475 |
BartC <bc@freeuk.com> writes: > On 11/12/2015 23:23, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> <snip> >>> The issue was how to get EOF into a program. >> >> You can't get EOF "into" a program. You can get some part of the >> software between the program and the keyboard to cause C's IO operations >> to fail as if the stream is at end-of-file. They usually fail by >> returning a negative integer value EOF, but not always (fgets, for >> example, does not). > > I mean doing whatever it takes to make getchar() etc to return the EOF > value. I guess that would also make fgets() fail. I'm not sure what > fread would do but I suppose it would have to return 0. I knew what you meant, I was just trying to clarify you confusing wording. Signalling the end of the data does not make fgets fail or fread to return zero, though both are possible outcomes. The behaviour of both fgets and fread are defined in terms of successive calls to fgetc so there should be no mystery when using them. <snip> >> [...] ^C does not "deliver the EOF >> character" on any system that I know about. > > With a getchar() loop that prints the returned value, typing in Ctrl C > (in Windows) will print -1 (and also break, even if the loop doesn't > test for EOF! But from within my IDE, Ctrl C returns EOF but won't > break because it's disabled.) I'm not sure what you mean here, but it does not seem to contradict what I said. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-12 11:15 +0000 |
| Message-ID | <n4gvg8$ndm$1@dont-email.me> |
| In reply to | #78478 |
On 12/12/2015 02:15, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>> On 11/12/2015 23:23, Ben Bacarisse wrote:
>>> [...] ^C does not "deliver the EOF
>>> character" on any system that I know about.
>>
>> With a getchar() loop that prints the returned value, typing in Ctrl C
>> (in Windows) will print -1 (and also break, even if the loop doesn't
>> test for EOF! But from within my IDE, Ctrl C returns EOF but won't
>> break because it's disabled.)
>
> I'm not sure what you mean here, but it does not seem to contradict what
> I said.
I think it does contradict it. But I suspect your quibble is about what
'delivering the EOF character' actually means.
I've tried the test again and am getting different results (or maybe
there was a glitch** yesterday). This first program is run on Windows:
#include <stdio.h>
int main(void) {
int c;
puts("Press whatever key is needed "
"so that getchar() receives EOF.");
do {
c=getchar();
printf("%d\n",c);
} while (c!=EOF);
puts("I've received the EOF code!");
}
Here, ^C will just break (^Z pressed at the right spot will give the
requisite EOF and break the loop, and the program exits normally).
But written like this (now this will only run on Windows):
#include <stdio.h>
#include <windows.h>
int main(void) {
int c;
SetConsoleCtrlHandler(0,1);
puts("Press whatever key is needed "
"so that getchar() receives EOF.");
do {
c=getchar();
printf("%d\n",c);
} while (c!=EOF);
puts("I've received the EOF code!");
}
Now pressing ^C anywhere will 'deliver' the EOF. That set routine I
think disables ^C's normal job of acting as Break.
(** I thought this might be a bug in console output which sometimes
picks up previously printed text. But it could be an actual glitch.
Running that first program again, and typing ^C produces:
^C
and it quits. Repeated twice more, same thing. Fourth time, it shows:
-1
^C
That -1 is definitely from the program as I then 'decorated' the output
to make it clear. Yet it doesn't manage to proceed further.
It looks very much like ^C /always/ injects the EOF character, but its
default behaviour as being also the Break key normally abandons the
program before it can be acted on. But sometimes, there is a little delay.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-13 00:52 +0000 |
| Message-ID | <877fkj41bo.fsf@bsb.me.uk> |
| In reply to | #78484 |
BartC <bc@freeuk.com> writes:
> On 12/12/2015 02:15, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>> On 11/12/2015 23:23, Ben Bacarisse wrote:
>
>>>> [...] ^C does not "deliver the EOF
>>>> character" on any system that I know about.
>>>
>>> With a getchar() loop that prints the returned value, typing in Ctrl C
>>> (in Windows) will print -1 (and also break, even if the loop doesn't
>>> test for EOF! But from within my IDE, Ctrl C returns EOF but won't
>>> break because it's disabled.)
>>
>> I'm not sure what you mean here, but it does not seem to contradict what
>> I said.
>
> I think it does contradict it. But I suspect your quibble is about
> what 'delivering the EOF character' actually means.
No, I was not quibbling about words. I don't like your words, but that
was not my point.
<snip>
> But written like this (now this will only run on Windows):
>
> #include <stdio.h>
> #include <windows.h>
>
> int main(void) {
> int c;
>
> SetConsoleCtrlHandler(0,1);
>
> puts("Press whatever key is needed "
> "so that getchar() receives EOF.");
>
> do {
> c=getchar();
> printf("%d\n",c);
> } while (c!=EOF);
>
> puts("I've received the EOF code!");
> }
>
> Now pressing ^C anywhere will 'deliver' the EOF.
You seems to be deliberately using vague language -- deliver in scare
quotes and "the EOF code".
You've disabled the usual signal processing so I'm not sure exactly what
the chain of events is but getchar returning EOF does not mean end of
file. I suspect that the getchar call is being interrupted, but I don't
have a system I can test on. Try this:
printf("getchar returned EOF because of %s\n",
ferror(stdin) ? "an error" : "end of file");
> That set routine I
> think disables ^C's normal job of acting as Break.
Yes.
<snip>
> It looks very much like ^C /always/ injects the EOF character,
What does that even mean? EOF is not a character but a negative integer
which is, by design, different to any character that is input via
getchar. ASCII has and eof character. Do you think Windows puts that
in the input stream when you type ^C? I doubt it very much.
> but its
> default behaviour as being also the Break key normally abandons the
> program before it can be acted on. But sometimes, there is a little
> delay.)
I suspect that ^C makes getchar report an error, but your example
program could not tell the difference.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-13 02:05 +0000 |
| Message-ID | <n4ijl3$r9s$1@dont-email.me> |
| In reply to | #78508 |
On 13/12/2015 00:52, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>> Now pressing ^C anywhere will 'deliver' the EOF.
>
> You seems to be deliberately using vague language -- deliver in scare
> quotes and "the EOF code".
>
> You've disabled the usual signal processing so I'm not sure exactly what
> the chain of events is but getchar returning EOF does not mean end of
> file. I suspect that the getchar call is being interrupted, but I don't
> have a system I can test on. Try this:
>
> printf("getchar returned EOF because of %s\n",
> ferror(stdin) ? "an error" : "end of file");
That shows "end of file" in all cases. (I also print ferror(stdin) next
to the char code, and that shows 0 in the case where I have to catch it.)
>> It looks very much like ^C /always/ injects the EOF character,
>
> What does that even mean? EOF is not a character but a negative integer
> which is, by design, different to any character that is input via
> getchar. ASCII has and eof character. Do you think Windows puts that
> in the input stream when you type ^C? I doubt it very much.
I feel like I'm walking on eggshells because whatever I say, I'm going
to say the wrong thing. If I use quotes (to show it might not be that
exact term) it's a problem, and without them I'm taken literally.
From a C perspective, getchar() is a routine that returns character
after character until it returns the magic code EOF, ie -1 in all the
versions I've seen, if some terminating condition happens.
Presumably that gets put in there by some C runtime function, so it's
not Windows. I can create a getchar-like function like this:
int my_getchar(void) {
int c = getch(); // non-standard
if (c==27) return EOF;
return c;
}
This version breaks on Escape (I've already made it more
platform-independent! Apart from the getc() of course. And it's more
responsive because it's not buffered).
With the recent bunch of simple exercises that read words etc from
stdin, those mainly seem to be character-reading loops that break on EOF
being encountered.
Trying those wasn't a comfortable experience. It seemed to be character
oriented, yet was also line-buffered. Sometimes Enter would give you
some output, sometimes not until the end. But what /was/ the end? It was
rather ill-defined, from the user's point of view, with this vague EOF
concept. Usually I managed it with random presses of ^D, ^Z and ^C at
various locations. (I usually associated ^C with aborting rather than
graceful exits from programs.)
I just thought it was messy. Everyone else, naturally, disagreed.
I realise it's not a big deal, a real program would code around it with
well-defined termination schemes and more precise instructions. But I
was also testing my eof() idea.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-12 18:35 -0800 |
| Message-ID | <lnmvtff53e.fsf@kst-u.example.com> |
| In reply to | #78515 |
BartC <bc@freeuk.com> writes:
[...]
> With the recent bunch of simple exercises that read words etc from
> stdin, those mainly seem to be character-reading loops that break on EOF
> being encountered.
>
> Trying those wasn't a comfortable experience. It seemed to be character
> oriented, yet was also line-buffered. Sometimes Enter would give you
> some output, sometimes not until the end. But what /was/ the end? It was
> rather ill-defined, from the user's point of view, with this vague EOF
> concept. Usually I managed it with random presses of ^D, ^Z and ^C at
> various locations. (I usually associated ^C with aborting rather than
> graceful exits from programs.)
If stdin is line-buffered (as it typically is when reading from the
keyboard), then getchar() isn't going to return anything until you type
Enter. After you do that, it will return successive characters of the
line, including the '\n' at the end.
(If stdin were not line-buffered, you wouldn't be able to use fix an
incorrectly typed character. A program *can* handle '\b' itself;
line-buffering means it doesn't need to.)
Typing Ctrl-D (on Unix-like systems) or Ctrl-Z (on Windows) immediately
after Enter causes getchar() to return EOF, which indicates the end of
the input.
Typing Ctrl-C on either system will most likely terminate the program
without giving getchar() a chance to return anything. You've shown some
examples indicating some odd behavior for Ctrl-C on Windows; I don't
know enough about Windows to comment on that.
Is any of that unclear?
> I just thought it was messy. Everyone else, naturally, disagreed.
The differing ways to singal end-of-file on Unix vs. on Windows is
messy -- and is not something C can do anything about.
> I realise it's not a big deal, a real program would code around it with
> well-defined termination schemes and more precise instructions. But I
> was also testing my eof() idea.
--
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-13 13:35 +0000 |
| Message-ID | <n4js2t$cre$1@dont-email.me> |
| In reply to | #78522 |
On 13/12/2015 02:35, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> Trying those wasn't a comfortable experience. It seemed to be character >> oriented, yet was also line-buffered. Sometimes Enter would give you >> some output, sometimes not until the end. But what /was/ the end? It was >> rather ill-defined, from the user's point of view, with this vague EOF >> concept. Usually I managed it with random presses of ^D, ^Z and ^C at >> various locations. (I usually associated ^C with aborting rather than >> graceful exits from programs.) > > If stdin is line-buffered (as it typically is when reading from the > keyboard), then getchar() isn't going to return anything until you type > Enter. After you do that, it will return successive characters of the > line, including the '\n' at the end. > > (If stdin were not line-buffered, you wouldn't be able to use fix an > incorrectly typed character. A program *can* handle '\b' itself; > line-buffering means it doesn't need to.) > > Typing Ctrl-D (on Unix-like systems) or Ctrl-Z (on Windows) immediately > after Enter causes getchar() to return EOF, which indicates the end of > the input. > > Typing Ctrl-C on either system will most likely terminate the program > without giving getchar() a chance to return anything. You've shown some > examples indicating some odd behavior for Ctrl-C on Windows; I don't > know enough about Windows to comment on that. > > Is any of that unclear? Just that until last week I hadn't properly come across Ctrl Z to officially terminate a console program in Windows (not just abort it). The above I suppose makes sense when you list it like that. But put yourself in the position of someone who runs a new program. They start it, and nothing happens. Presumably it's waiting for input. So they type a line and press Enter. Still nothing. How to signal the end of input? They might suspect it's one of these Unix jobs that terminate with ^D and start playing with that (partly in panic mode now). But they don't particularly want to terminate the program, they want it to do something with that they've typed! It really makes for a very unfriendly interface. Outside Unix we like things a bit less hit-and-miss. This is why, when there is some sample code that used a getchar or fgetc loop, I prefer a solution using a line buffer within the program. Then terminating conditions are easier to define. (And leave the fgetc/EOF loops for when we know we're dealing with a non-interactive file, when it is much more well-behaved. Why Unix so desperately wants to conflate keyboard and file I really don't know. Does it do the same with a mouse?!) > If stdin is line-buffered (as it typically is when reading from the > keyboard), then getchar() isn't going to return anything until you > type So how does stdin solve the line buffer problem? Presumably, someone could enter a million characters on the same line, then move the cursor to the start and change it? Or is there a limit? (Which might cause it to break off the end of a word, or split it across two lines.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-13 11:48 -0800 |
| Message-ID | <0994a589-c1ac-48de-bf30-d9f811bd6415@googlegroups.com> |
| In reply to | #78535 |
On Sunday, December 13, 2015 at 7:35:59 AM UTC-6, Bart wrote: > (And leave the fgetc/EOF loops for when we know we're dealing with a > non-interactive file, when it is much more well-behaved. Why Unix so > desperately wants to conflate keyboard and file I really don't know. > Does it do the same with a mouse?!) There are many situations where it is useful for a program to be able to accept input three ways: 1. From the terminal 2. From a file 3. From another program Unix was designed so that programs which need to take input from one such source to do so without having to do anything special; merely accepting input from stdin will accomplish that. Further, it may be worth noting that the idea that a device which expects data from a terminal may receive it from a storage medium predates Unix. The name of the ASR-33 Teletype refers to "automatic send/receive", and it was designed so that it could send characters either from the keyboard or from a paper tape reader; for long-term storage, the cost of punched tape media was far below that of any kind of disk-based storage, and for many applications it was easier to handle than magnetic tape (it's easier to handle a magnetic tape holding a million bytes than to handle 1.5 miles of paper tape, but it's easier to handle 100 paper tapes each holding 10,000 characters (about 100 feet) than to handle 100 separate magnetic tapes each holding the same amount of information). That having been said, I think the Unix I/O paradigm might have been a little better if it recognized a console as a distinct concept from a file and make it possible for a process to connect to the console of a spawned process with fully-sequenced I/O and control operations and an ability to have the originating process force the called process to yield all data that's available to date.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-12-13 20:36 +0000 |
| Message-ID | <566dd6a1.5469468@news.xs4all.nl> |
| In reply to | #78535 |
BartC <bc@freeuk.com> wrote: > On 13/12/2015 02:35, Keith Thompson wrote: > > Typing Ctrl-C on either system will most likely terminate the program > > without giving getchar() a chance to return anything. You've shown some > > examples indicating some odd behavior for Ctrl-C on Windows; I don't > > know enough about Windows to comment on that. > > > > Is any of that unclear? > > Just that until last week I hadn't properly come across Ctrl Z to > officially terminate a console program in Windows (not just abort it). If it's taken you all that time to find out something so basic, which is found in every single DOS manual, you really shouldn't be complaining about how "complicated" things are. RTFM. Richard
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-13 13:14 -0800 |
| Message-ID | <ln6102f3v4.fsf@kst-u.example.com> |
| In reply to | #78535 |
BartC <bc@freeuk.com> writes:
> On 13/12/2015 02:35, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> Trying those wasn't a comfortable experience. It seemed to be character
>>> oriented, yet was also line-buffered. Sometimes Enter would give you
>>> some output, sometimes not until the end. But what /was/ the end? It was
>>> rather ill-defined, from the user's point of view, with this vague EOF
>>> concept. Usually I managed it with random presses of ^D, ^Z and ^C at
>>> various locations. (I usually associated ^C with aborting rather than
>>> graceful exits from programs.)
>>
>> If stdin is line-buffered (as it typically is when reading from the
>> keyboard), then getchar() isn't going to return anything until you type
>> Enter. After you do that, it will return successive characters of the
>> line, including the '\n' at the end.
>>
>> (If stdin were not line-buffered, you wouldn't be able to use fix an
>> incorrectly typed character. A program *can* handle '\b' itself;
>> line-buffering means it doesn't need to.)
>>
>> Typing Ctrl-D (on Unix-like systems) or Ctrl-Z (on Windows) immediately
>> after Enter causes getchar() to return EOF, which indicates the end of
>> the input.
>>
>> Typing Ctrl-C on either system will most likely terminate the program
>> without giving getchar() a chance to return anything. You've shown some
>> examples indicating some odd behavior for Ctrl-C on Windows; I don't
>> know enough about Windows to comment on that.
>>
>> Is any of that unclear?
>
> Just that until last week I hadn't properly come across Ctrl Z to
> officially terminate a console program in Windows (not just abort it).
Ctrl-Z doesn't terminates a Windows console program. It causes the next
call to getchar() to return EOF (or the equivalent for whatever input
function the program happens to be using). The program may or may not
choose to terminate itself when that happens.
> The above I suppose makes sense when you list it like that. But put
> yourself in the position of someone who runs a new program. They start
> it, and nothing happens. Presumably it's waiting for input. So they type
> a line and press Enter. Still nothing. How to signal the end of input?
>
> They might suspect it's one of these Unix jobs that terminate with ^D
> and start playing with that (partly in panic mode now). But they don't
> particularly want to terminate the program, they want it to do something
> with that they've typed!
Perhaps someone should have read the documentation before running a
strange program with unknown behavior.
Programs that read from stdin until end-of-file are much more common on
Unix than on Windows. Anyone using Unix needs to be aware of that, and
of how such programs work.
> It really makes for a very unfriendly interface. Outside Unix we like
> things a bit less hit-and-miss.
It really makes for a very *consistent* interface.
> This is why, when there is some sample code that used a getchar or fgetc
> loop, I prefer a solution using a line buffer within the program. Then
> terminating conditions are easier to define.
>
> (And leave the fgetc/EOF loops for when we know we're dealing with a
> non-interactive file, when it is much more well-behaved. Why Unix so
> desperately wants to conflate keyboard and file I really don't know.
> Does it do the same with a mouse?!)
It's simply a different approach than the one you're used to. I don't
know why that seems to be so painful to you.
(As far as I know the mouse is not usually handled that way. I've
worked on systems that have a "/dev/mouse" device, but I don't remember
how it was handled.)
> > If stdin is line-buffered (as it typically is when reading from the
> > keyboard), then getchar() isn't going to return anything until you
> > type
>
> So how does stdin solve the line buffer problem?
There's a "problem"?
> Presumably, someone
> could enter a million characters on the same line, then move the cursor
> to the start and change it? Or is there a limit? (Which might cause it
> to break off the end of a word, or split it across two lines.)
Ordinary reading from stdin doesn't provide a way to go back to the
beginning of a line and change it without deleting the rest of the
line. Some programs do, often because they use the "readline" library.
But even so, yes, the entered characters have to be stored somewhere.
I think that's handled by the tty driver in the kernel. I don't
know how big the buffer is, but it's typically big enough that I
don't recall seeing it overflow, at least on a modern system.
--
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 | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2015-12-13 21:38 +0000 |
| Message-ID | <87si36do6w.fsf@gmail.com> |
| In reply to | #78574 |
Keith Thompson <kst-u@mib.org> writes: > (As far as I know the mouse is not usually handled that way. I've > worked on systems that have a "/dev/mouse" device, but I don't remember > how it was handled.) POSIX open(), then periodically poll() the file descriptor for events. > But even so, yes, the entered characters have to be stored somewhere. > I think that's handled by the tty driver in the kernel. I don't > know how big the buffer is, but it's typically big enough that I > don't recall seeing it overflow, at least on a modern system. On linux, its been 4096 bytes since time immemorial.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-13 22:35 +0000 |
| Message-ID | <n4krnq$ai4$1@dont-email.me> |
| In reply to | #78577 |
On 13/12/2015 21:38, Gareth Owen wrote: > Keith Thompson <kst-u@mib.org> writes: > >> (As far as I know the mouse is not usually handled that way. I've >> worked on systems that have a "/dev/mouse" device, but I don't remember >> how it was handled.) > > POSIX open(), then periodically poll() the file descriptor for events. > >> But even so, yes, the entered characters have to be stored somewhere. >> I think that's handled by the tty driver in the kernel. I don't >> know how big the buffer is, but it's typically big enough that I >> don't recall seeing it overflow, at least on a modern system. > > On linux, its been 4096 bytes since time immemorial. > It sounds like it knows it's reading from an actual keyboard, with a human pressing the keys, so can get away with a perfectly reasonable buffer size to allow for editing. Something that is apparently denied to someone using fgets() for example who was to assume that stdin is connected to a file or pipe that could have much longer lines, or might not use newlines at all, so it has to allow for arbitrarily long lines. That doesn't seem quite fair. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-12-13 14:48 -0800 |
| Message-ID | <1902e9f1-b379-4c84-88be-dcc52699f5ee@googlegroups.com> |
| In reply to | #78580 |
On Sunday, December 13, 2015 at 10:36:12 PM UTC, Bart wrote: > > Something that is apparently denied to someone using fgets() for example > who was to assume that stdin is connected to a file or pipe that could > have much longer lines, or might not use newlines at all, so it has to > allow for arbitrarily long lines. > SVG is an xml-based vector graphics format. A "path" consists of concatenated cubic beziers, and the svg people decided to store the path data in a string, as an tag attribute. It's natural to have one line per tag. But path data can get very large, automatic tools, such as my own ImagetoSVG (greyscale bitmap to vector converter) can potentially spit out very long paths. A human of course can enter only low tens of points by hand, before getting overwhelmed. But you do need to be able to handle long lines to cover that sort of case. For the input device itself, it's not such a problem, you can impose an arbitrary but reasonable limit. If user exceeds it, then his keyboard stops being responsive to anything except backspace, and the onus is on him to react to the situation.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-13 23:05 +0000 |
| Message-ID | <n4ktgh$kao$1@dont-email.me> |
| In reply to | #78582 |
On 13/12/2015 22:48, Malcolm McLean wrote: > On Sunday, December 13, 2015 at 10:36:12 PM UTC, Bart wrote: >> >> Something that is apparently denied to someone using fgets() for example >> who was to assume that stdin is connected to a file or pipe that could >> have much longer lines, or might not use newlines at all, so it has to >> allow for arbitrarily long lines. >> > SVG is an xml-based vector graphics format. > A "path" consists of concatenated cubic beziers, and the svg people > decided to store the path data in a string, as an tag attribute. (If it's XML, then that figures. Imagine having separate attributes per X,Y then per point then per path.. it would be even more sprawling. (And what an ugly format XML is. I think even Lisp S-expressions look better.)) > It's natural to have one line per tag. But path data can get very large, > automatic tools, such as my own ImagetoSVG (greyscale bitmap to > vector converter) can potentially spit out very long paths. > A human of course can enter only low tens of points by hand, before > getting overwhelmed. > > But you do need to be able to handle long lines to cover that sort > of case. For the input device itself, it's not such a problem, > you can impose an arbitrary but reasonable limit. If user exceeds > it, then his keyboard stops being responsive to anything except > backspace, and the onus is on him to react to the situation. My point was about taking advantage of knowing that input is not from a file and is not machine-generated, then 4K characters is perfectly reasonable. While the sorts of long lines you describe I wouldn't describe as line-oriented text format. Just text format, if line endings are going to be sparse to non-existent. Then you can choose to use a more heavyweight approach, or just read the entire file in one go rather than line by line. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2015-12-13 18:08 -0500 |
| Message-ID | <BTmby.204745$2K.168118@fx09.iad> |
| In reply to | #78580 |
On Sunday December 13 2015 17:35, in comp.lang.c, "BartC" <bc@freeuk.com> wrote: > On 13/12/2015 21:38, Gareth Owen wrote: >> Keith Thompson <kst-u@mib.org> writes: >> >>> (As far as I know the mouse is not usually handled that way. I've >>> worked on systems that have a "/dev/mouse" device, but I don't remember >>> how it was handled.) >> >> POSIX open(), then periodically poll() the file descriptor for events. >> >>> But even so, yes, the entered characters have to be stored somewhere. >>> I think that's handled by the tty driver in the kernel. I don't >>> know how big the buffer is, but it's typically big enough that I >>> don't recall seeing it overflow, at least on a modern system. >> >> On linux, its been 4096 bytes since time immemorial. >> > > It sounds like it knows it's reading from an actual keyboard, with a > human pressing the keys, so can get away with a perfectly reasonable > buffer size to allow for editing. Nah. That buffersize is used by the kernel for almost all I/O operations. It suffices (for keyboard input) because of a couple of factors: 1) in relation to the time the OS and program take to process data entered, human key entry is **extremely** slow. Like, several orders of magnitude slower. The programs can easily keep the buffer drained, no matter how fast the typist. 2) Unless specifically overridden, all program I/O is performed in "blocking" mode. If there is no data ready, the getchar() (actually, the read() that getchar() calls) suspends the process. It only restarts the process and returns data when data is finally available. Thus, (with blocking I/O) you never get a "no data ready" case. Of course, you can go out of your way to "condition" the I/O subsystem to perform non-blocking I/O. A "no data ready" case here returns a specific error condition from read(), which can be programmatically tested and accounted for. > Something that is apparently denied to someone using fgets() for example > who was to assume that stdin is connected to a file or pipe that could > have much longer lines, or might not use newlines at all, so it has to > allow for arbitrarily long lines. I doubt that the designers of fgets() made any conscious assumptions that "stdin is connected to a file or pipe. More likely, they explicitly tried to make no assumptions at all wrt the size of input data lines. Remember, in POSIX systems, all of standard C's "standard I/O" functionality is built on top of the system read() and write() functions. The buffers that Unix programmers talk about wrt keyboard input are OS *kernel* buffers, and apply to /any/ I/O, whether it comes from a keyboard, a disk drive, or a network connection. > That doesn't seem quite fair. -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-13 15:44 -0800 |
| Message-ID | <lnsi35ewwm.fsf@kst-u.example.com> |
| In reply to | #78580 |
BartC <bc@freeuk.com> writes:
> On 13/12/2015 21:38, Gareth Owen wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>> (As far as I know the mouse is not usually handled that way. I've
>>> worked on systems that have a "/dev/mouse" device, but I don't remember
>>> how it was handled.)
>>
>> POSIX open(), then periodically poll() the file descriptor for events.
>>
>>> But even so, yes, the entered characters have to be stored somewhere.
>>> I think that's handled by the tty driver in the kernel. I don't
>>> know how big the buffer is, but it's typically big enough that I
>>> don't recall seeing it overflow, at least on a modern system.
>>
>> On linux, its been 4096 bytes since time immemorial.
>>
>
> It sounds like it knows it's reading from an actual keyboard, with a
> human pressing the keys, so can get away with a perfectly reasonable
> buffer size to allow for editing.
>
> Something that is apparently denied to someone using fgets() for
> example who was to assume that stdin is connected to a file or pipe
> that could have much longer lines, or might not use newlines at all,
> so it has to allow for arbitrarily long lines.
>
> That doesn't seem quite fair.
What does fairness have to do with it?
It's only when you're reading from an actual keyboard that line editing
is relevant. You can enter 1000 characters, then type backspace 1000
times, then enter "foo" followed by newline, and all the program will
see is "foo\n". That's why the tty driver ("tty" stands for "teletype";
it's called that for historical reasons) needs to line-buffer input.
If you're reading from a file or from a pipe, backspaces and other
line-editing characters don't apply; they're just characters. The OS
will undoubtely perform some kind of buffering, but the program needn't
care about it.
For example, if I'm running a program that reads from stdin with its
input coming from a keyboard, and I type "foobar", then Backspace three
times, then Enter, the program will see "foo\n". If I instead run:
printf 'foobar\b\b\b\n' | some_program
the program will see all 10 characters: "foobar\b\b\b\n".
As far as a C program is concerned, if it wants to read a line at a
time it needs to buffer an entire line, however long it is -- and it
can do so regardless of any buffering performed by the OS. If it's
reading a character at a time, buffering is irrelevant (except that
it might affect *when* it's able to read the input characters).
If a program wants to read from a keyboard and do more processing that
is provided by the tty driver (like editing the beginning of a pending
input line without erasing the end of it), it needs to do something
system-specific to set it up. There's no shortage of libraries for that
kind of thing. Programs that are primarily intended for interactive use
(text editors, shells, REPLs for interpreted languages) often do this
kind of thing. Programs that are used mostly for processing arbitrary
text typically do not.
--
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-14 00:42 +0000 |
| Message-ID | <n4l36c$5fr$1@dont-email.me> |
| In reply to | #78585 |
On 13/12/2015 23:44, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> It sounds like it knows it's reading from an actual keyboard, with a
>> human pressing the keys, so can get away with a perfectly reasonable
>> buffer size to allow for editing.
>>
>> Something that is apparently denied to someone using fgets() for
>> example who was to assume that stdin is connected to a file or pipe
>> that could have much longer lines, or might not use newlines at all,
>> so it has to allow for arbitrarily long lines.
>>
>> That doesn't seem quite fair.
>
> What does fairness have to do with it?
>
> It's only when you're reading from an actual keyboard that line editing
> is relevant. You can enter 1000 characters, then type backspace 1000
> times, then enter "foo" followed by newline, and all the program will
> see is "foo\n". That's why the tty driver ("tty" stands for "teletype";
> it's called that for historical reasons) needs to line-buffer input.
>
> If you're reading from a file or from a pipe, backspaces and other
> line-editing characters don't apply; they're just characters. The OS
> will undoubtely perform some kind of buffering, but the program needn't
> care about it.
My comments were about 'getline()' routines that are sometimes discussed
here, where we're not allowed to get away with a fixed-size buffer,
because the input /might/ come from a file with unknown maximum line
lengths.
And what happens when someone types in 4097 characters on the keyboard?
(Or does so programmatically as I'm sure would be possible.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-13 19:48 -0800 |
| Message-ID | <lnoadtelm2.fsf@kst-u.example.com> |
| In reply to | #78586 |
BartC <bc@freeuk.com> writes:
> On 13/12/2015 23:44, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> It sounds like it knows it's reading from an actual keyboard, with a
>>> human pressing the keys, so can get away with a perfectly reasonable
>>> buffer size to allow for editing.
>>>
>>> Something that is apparently denied to someone using fgets() for
>>> example who was to assume that stdin is connected to a file or pipe
>>> that could have much longer lines, or might not use newlines at all,
>>> so it has to allow for arbitrarily long lines.
>>>
>>> That doesn't seem quite fair.
>>
>> What does fairness have to do with it?
>>
>> It's only when you're reading from an actual keyboard that line editing
>> is relevant. You can enter 1000 characters, then type backspace 1000
>> times, then enter "foo" followed by newline, and all the program will
>> see is "foo\n". That's why the tty driver ("tty" stands for "teletype";
>> it's called that for historical reasons) needs to line-buffer input.
>>
>> If you're reading from a file or from a pipe, backspaces and other
>> line-editing characters don't apply; they're just characters. The OS
>> will undoubtely perform some kind of buffering, but the program needn't
>> care about it.
>
> My comments were about 'getline()' routines that are sometimes discussed
> here, where we're not allowed to get away with a fixed-size buffer,
> because the input /might/ come from a file with unknown maximum line
> lengths.
And because allowing for arbitrarily long lines is not difficult enough
to justify taking shortcuts, at least in production quality code.
> And what happens when someone types in 4097 characters on the keyboard?
> (Or does so programmatically as I'm sure would be possible.)
I did some experiments earlier today, and the result seems to be that
the program is able to read all 4097 (or more) characters. It takes a
long time to enter that much input, even with auto-repeat, so I didn't
investigate thoroughly.
I'm actually not sure how the tty driver works, or whether its own line
buffering (needed to permit erase and kill processing) uses some
mechanism other than the usual stdio buffering. My guess is that
exceeding the buffer size would at worst prevent backspacing.
If you can identify an actual problem that you've run into, we can
discuss it. Otherwise, I get the impression that you're grasping at
straws.
--
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 | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2015-12-14 06:58 +0000 |
| Message-ID | <87si35zfcb.fsf@gmail.com> |
| In reply to | #78589 |
Keith Thompson <kst-u@mib.org> writes: > I did some experiments earlier today, and the result seems to be that > the program is able to read all 4097 (or more) characters. gowen@felix$ cat | wc <paste 5000 'a's from emacs> ^D 1 1 4096 which suggests on this ubuntu system that anything over 4k just falls on the floor
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-14 00:04 -0800 |
| Message-ID | <lnk2ohe9ra.fsf@kst-u.example.com> |
| In reply to | #78591 |
Gareth Owen <gwowen@gmail.com> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> I did some experiments earlier today, and the result seems to be that
>> the program is able to read all 4097 (or more) characters.
>
>
> gowen@felix$ cat | wc
> <paste 5000 'a's from emacs>
> ^D
> 1 1 4096
>
> which suggests on this ubuntu system that anything over 4k just falls on
> the floor
The GNU coreutils version of `cat` (the most common version on Linux
systems) doesn't use ordinary stdio operations. I see similar results
to yours, but when I do the same thing with this C program:
#include <stdio.h>
int main(void) {
int c;
while ((c = getchar()) != EOF) {
putchar(c);
}
}
I get different results. When I redirect this program's output to a
file and feed it a 6656-byte input line via copy-and-paste, the output
has the right size but the wrong contents.
When it reads from a file or from a pipe, not surprisingly, it works
correctly.
--
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]
Page 10 of 20 — ← Prev page 1 … 8 9 [10] 11 12 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web