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 11 of 20 — ← Prev page 1 … 9 10 [11] 12 13 … 20 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-14 12:12 +0000 |
| Message-ID | <87oadt1b64.fsf@bsb.me.uk> |
| In reply to | #78592 |
Keith Thompson <kst-u@mib.org> writes:
> 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 get the same result without the cat. Of course wc may also bypass
stdio, but I can't see how that would bypass the tty driver and it's
buffer limit.
> 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.
I can't duplicate this. I get the same results in all of these cases:
cat | wc
wc
./cat | wc
./cat >saved
(./cat is your getchar/putchar loop). In all cases I get 4096 (or 4095
about which see later) bytes when pasting many more than that
(specifically 6656 bytes) into gnome-terminal (in case that matters).
The 4096/4095 difference is curious. I get 4095 when I paste and close
the input with ^D^D. I get 4096 when I paste the input, hit enter and
then ^D. Something about the first flushing ^D takes up space in the
buffer maybe?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-14 08:07 -0800 |
| Message-ID | <lnfuz5dnf5.fsf@kst-u.example.com> |
| In reply to | #78612 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
>> 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 get the same result without the cat. Of course wc may also bypass
> stdio, but I can't see how that would bypass the tty driver and it's
> buffer limit.
>
>> 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.
>
> I can't duplicate this. I get the same results in all of these cases:
>
> cat | wc
> wc
> ./cat | wc
> ./cat >saved
>
> (./cat is your getchar/putchar loop). In all cases I get 4096 (or 4095
> about which see later) bytes when pasting many more than that
> (specifically 6656 bytes) into gnome-terminal (in case that matters).
>
> The 4096/4095 difference is curious. I get 4095 when I paste and close
> the input with ^D^D. I get 4096 when I paste the input, hit enter and
> then ^D. Something about the first flushing ^D takes up space in the
> buffer maybe?
You get 4095 when you *don't* type Enter. You get 4096 when you *do*
type Enter. The character count includes the newline.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-14 17:23 +0000 |
| Message-ID | <8737v5yme3.fsf@bsb.me.uk> |
| In reply to | #78648 |
Keith Thompson <kst-u@mib.org> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> 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 get the same result without the cat. Of course wc may also bypass
>> stdio, but I can't see how that would bypass the tty driver and it's
>> buffer limit.
>>
>>> 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.
>>
>> I can't duplicate this. I get the same results in all of these cases:
>>
>> cat | wc
>> wc
>> ./cat | wc
>> ./cat >saved
>>
>> (./cat is your getchar/putchar loop). In all cases I get 4096 (or 4095
>> about which see later) bytes when pasting many more than that
>> (specifically 6656 bytes) into gnome-terminal (in case that matters).
>>
>> The 4096/4095 difference is curious. I get 4095 when I paste and close
>> the input with ^D^D. I get 4096 when I paste the input, hit enter and
>> then ^D. Something about the first flushing ^D takes up space in the
>> buffer maybe?
>
> You get 4095 when you *don't* type Enter. You get 4096 when you *do*
> type Enter.
I've read and re-read what I wrote and we're saying the same thing
aren't we? Your emphasis on *don't* suggests disagreement.
> The character count includes the newline.
So the driver reserves a place for one that it never uses when there is
over-long input without one? That seems plausible.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-14 10:58 -0800 |
| Message-ID | <lny4cwdfi6.fsf@kst-u.example.com> |
| In reply to | #78661 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> You get 4095 when you *don't* type Enter. You get 4096 when you *do*
>> type Enter.
>
> I've read and re-read what I wrote and we're saying the same thing
> aren't we? Your emphasis on *don't* suggests disagreement.
We're not quite saying the same thing. What you were saying was
actually coherent. When I posted, I somehow managed to ignore the fact
that some of the input is being discarded.
[...]
--
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 12:29 +0000 |
| Message-ID | <n4mcji$oo4$1@dont-email.me> |
| In reply to | #78589 |
On 14/12/2015 03:48, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> 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. > 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. No problem. On the contrary, it might help make life easier. Next time there is some code being posted that takes input from the console, then we can have a line-buffered version that has a fixed-size buffer (no smaller than 4K characters). We just insist that the input comes from a keyboard. Then nobody can say, suppose some types or pastes 5000 characters? Because that can't happen. Not on Linux anyway. (Windows 7 allows 8K characters, but I don't think it works properly as it goes wrong if you try and edit that.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-14 14:52 +0000 |
| Message-ID | <871tap13ry.fsf@bsb.me.uk> |
| In reply to | #78615 |
BartC <bc@freeuk.com> writes: > On 14/12/2015 03:48, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: > >>> 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. > >> 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. > > No problem. On the contrary, it might help make life easier. Next time > there is some code being posted that takes input from the console, > then we can have a line-buffered version that has a fixed-size buffer > (no smaller than 4K characters). How will you know? wc, for example, was written so as not to care. I can use it to count the characters in the file I used to test the tty driver buffer limit. That's useful. > We just insist that the input comes from a keyboard. Ah. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-14 19:37 +0000 |
| Message-ID | <n4n5l9$2fa$1@dont-email.me> |
| In reply to | #78627 |
On 14/12/2015 14:52, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> On 14/12/2015 03:48, Keith Thompson wrote: >>> BartC <bc@freeuk.com> writes: >> >>>> 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. >> >>> 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. >> >> No problem. On the contrary, it might help make life easier. Next time >> there is some code being posted that takes input from the console, >> then we can have a line-buffered version that has a fixed-size buffer >> (no smaller than 4K characters). > > How will you know? Well, this is one of the disadvantages of mixing up files and keyboards! The stdin keyboard driver, on the other hand, has the luxury of setting arbitrary limits, despite not knowing whether the data is significant or not. User programs don't. > wc, for example, was written so as not to care. I > can use it to count the characters in the file I used to test the tty > driver buffer limit. That's useful. > >> We just insist that the input comes from a keyboard. > > Ah. So C makes it impossible to read specifically from a keyboard? Whose fault is that? Not mine anyway. At least we can just insist that one is used. If someone doesn't want to cooperate, that's up to them. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-14 20:33 +0000 |
| Message-ID | <87fuz4ydly.fsf@bsb.me.uk> |
| In reply to | #78676 |
BartC <bc@freeuk.com> writes: > On 14/12/2015 14:52, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 14/12/2015 03:48, Keith Thompson wrote: >>>> BartC <bc@freeuk.com> writes: >>> >>>>> 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. >>> >>>> 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. >>> >>> No problem. On the contrary, it might help make life easier. Next time >>> there is some code being posted that takes input from the console, >>> then we can have a line-buffered version that has a fixed-size buffer >>> (no smaller than 4K characters). >> >> How will you know? > > Well, this is one of the disadvantages of mixing up files and > keyboards! Are you seriously advocating making the source of some data be explicitly from something you call "a keyboard"? Explicitly in the program itself I mean? > The stdin keyboard driver, on the other hand, has the luxury of > setting arbitrary limits, despite not knowing whether the data is > significant or not. User programs don't. > >> wc, for example, was written so as not to care. I >> can use it to count the characters in the file I used to test the tty >> driver buffer limit. That's useful. >> >>> We just insist that the input comes from a keyboard. >> >> Ah. > > So C makes it impossible to read specifically from a keyboard? Whose > fault is that? Not mine anyway. At least we can just insist that one > is used. If someone doesn't want to cooperate, that's up to them. Lots of programs like to know what they are talking to, but C does not standardise this. There are lots of system-dependant things that C does not standardise. On Unix-like systems, a program can open a tty directly and it can ask if an input stream is or is not a tty, but, OSes being what they are, all of these can be defeated by attaching the program an input that just *pretends* to be a tty. For every program that someone has limited to being tty-driven, there are ten people who've wanted to automate it's use through a pseudo-tty. I don't understand why you are so worked up about this. No one is making you write these hyper-flexible programs that seem to irritate you so much. You can put limits on input line lengths to your heart's content. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-12-15 09:45 +1300 |
| Message-ID | <dd8o3sFh4lcU1@mid.individual.net> |
| In reply to | #78678 |
Ben Bacarisse wrote: > > I don't understand why you are so worked up about this. No one is > making you write these hyper-flexible programs that seem to irritate you > so much. You can put limits on input line lengths to your heart's > content. This is Usenet Ben. We can't have reason getting in the way of a good rant, can we? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-12-14 13:16 -0800 |
| Message-ID | <4af3a268-2076-4457-af1f-d0c1d55100a1@googlegroups.com> |
| In reply to | #78678 |
On Monday, December 14, 2015 at 8:33:46 PM UTC, Ben Bacarisse wrote: > Are you seriously advocating making the source of some data be > explicitly from something you call "a keyboard"? Explicitly in the > program itself I mean? > Often you want to treat the space bar as the "fire" button. There's more to programming computers than writing applications to do payrolls for employees.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-14 21:34 +0000 |
| Message-ID | <87wpsgww86.fsf@bsb.me.uk> |
| In reply to | #78688 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, December 14, 2015 at 8:33:46 PM UTC, Ben Bacarisse wrote: > >> Are you seriously advocating making the source of some data be >> explicitly from something you call "a keyboard"? Explicitly in the >> program itself I mean? >> > Often you want to treat the space bar as the "fire" button. Sure. > There's more to programming computers than writing applications > to do payrolls for employees. But those are the very programs BartC is talking about. He's not taking about games, but about programs that read general data. He wants to be able to insist that some of *these* programs take data from "a keyboard". Why? I don't really know. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-14 21:45 +0000 |
| Message-ID | <n4nd59$27k$1@dont-email.me> |
| In reply to | #78678 |
On 14/12/2015 20:33, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> Well, this is one of the disadvantages of mixing up files and >> keyboards! > > Are you seriously advocating making the source of some data be > explicitly from something you call "a keyboard"? Explicitly in the > program itself I mean? Um, yes. Why, is that wrong? Just because keyboards can deliver character data, and files can also contain character data, doesn't mean you're obliged to create some composite kind of device/data/whatever that tries to do the job of both. Keyboards are very different. You have control keys as well as printable keys. There are function keys. State keys (caps lock etc). Keyboards are interactive, so you can control what or how something is going to be typed by issuing instructions, because there's a human in charge. When I create entry boxes in a GUI, the supposition is that a keyboard is used to enter or edit data within it, not a file. In short, I can't imagine something more unlike a file! Just because Unix has done it for decades, doesn't mean it's the only possible way to do something. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-14 22:00 +0000 |
| Message-ID | <874mfkwv18.fsf@bsb.me.uk> |
| In reply to | #78698 |
BartC <bc@freeuk.com> writes: > On 14/12/2015 20:33, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> Well, this is one of the disadvantages of mixing up files and >>> keyboards! >> >> Are you seriously advocating making the source of some data be >> explicitly from something you call "a keyboard"? Explicitly in the >> program itself I mean? > > Um, yes. Why, is that wrong? It goes against the way OSes and programming languages have developed over many decades. They provide high-level abstractions so the programmer need not care about where the data come from. Maybe your snipping of the context will lead you to claim that you *do* sometimes need to know -- as in Malcolm's game example. Just in case, I remind you we are talking about more general input to programs that do things like like make histograms of word lengths. > Just because keyboards can deliver character data, and files can also > contain character data, doesn't mean you're obliged to create some > composite kind of device/data/whatever that tries to do the job of > both. > > Keyboards are very different. You have control keys as well as > printable keys. There are function keys. State keys (caps lock > etc). Keyboards are interactive, so you can control what or how > something is going to be typed by issuing instructions, because > there's a human in charge. > > When I create entry boxes in a GUI, the supposition is that a keyboard > is used to enter or edit data within it, not a file. > > In short, I can't imagine something more unlike a file! Just because > Unix has done it for decades, doesn't mean it's the only possible way > to do something. Bingo! The old "slow bait and switch". You: I want to read lines into a fixed buffer to count word lengths. Me: there's no need -- it's simpler not to. You: it's OK because the tty driver has a limited buffer. Me: how do you know you are talking to a tty? You: why should I not know if I want to? GUI programs need to see the modifier keys! <Sigh> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-14 22:23 +0000 |
| Message-ID | <n4nfde$blv$1@dont-email.me> |
| In reply to | #78700 |
On 14/12/2015 22:00, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 14/12/2015 20:33, Ben Bacarisse wrote:
>>> Are you seriously advocating making the source of some data be
>>> explicitly from something you call "a keyboard"? Explicitly in the
>>> program itself I mean?
>>
>> Um, yes. Why, is that wrong?
>
> It goes against the way OSes and programming languages have developed
> over many decades. They provide high-level abstractions so the
> programmer need not care about where the data come from.
That doesn't follow. It often does matter if you want to write
/interactive/ programs.
> Maybe your snipping of the context will lead you to claim that you *do*
> sometimes need to know -- as in Malcolm's game example. Just in case, I
> remind you we are talking about more general input to programs that do
> things like like make histograms of word lengths.
This is a case in point. In a polished version, there would be nice
prompts at the start and continuing prompts at every line to keep the
user assured something is happening and the program hasn't died. Maybe
there's a problem on one of the lines and you can report that and offer
the user a chance to correct it.
It would also explain how to signal the end of any data (even with those
crude break keys if it really has to).
But there's no point if you don't know and don't care where the data is
coming from. (And most programs along these lines I've seen here really
don't care and don't give much reassurance either, it's like typing into
a black hole. If I complain that it's hard to know what to do, I get
'RTFM'.)
The technique of taking data from stdin instead of naming an actual file
is sloppy, in my opinion. Especially when the file is redirected to
stdin instead of just naming it:
program < file
instead of:
program file
(Yes, I know, another Unix-ism that is done that way because of pipes.)
When you code for the 'program' or 'program < file' model, clearly the
user interface is not going to be too polished or particularly interactive!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-12-14 14:41 -0800 |
| Message-ID | <bbd9880f-7aaa-4097-ac2e-17a247df8355@googlegroups.com> |
| In reply to | #78705 |
On Monday, December 14, 2015 at 10:24:13 PM UTC, Bart wrote: > > That doesn't follow. It often does matter if you want to write > /interactive/ programs. > > > Maybe your snipping of the context will lead you to claim that you *do* > > sometimes need to know -- as in Malcolm's game example. Just in case, I > > remind you we are talking about more general input to programs that do > > things like like make histograms of word lengths. > > This is a case in point. In a polished version, there would be nice > prompts at the start and continuing prompts at every line to keep the > user assured something is happening and the program hasn't died. Maybe > there's a problem on one of the lines and you can report that and offer > the user a chance to correct it. > A general problem in programming, which no-one seems to have tackled properly, is where do you put your levels of spoofing or indirection. A program expects input from a keyboard and to output to a screen. However another program can fake up the keypresses and put output to a file. But, say the program is ls, that can be a nuisance. if output is really going to go to file, you want a simple list with one entry per line. if it's going to a screen, you want three entries per line. So ls has a little routine which detects whether the console is spoofed. But then some people don't want ls to revert to entry per line mode, they want the literal output that the screen would get. So they defeat that spoof by pretending at a deeper level to be a human- readable screen. And so it can go on, for layer after layer. Usually the programs are trying to co-operate with each other, there's no issue of hostile code. But it's never quite clear who should have final say.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-14 23:38 +0000 |
| Message-ID | <87io40vbx4.fsf@bsb.me.uk> |
| In reply to | #78705 |
BartC <bc@freeuk.com> writes: > On 14/12/2015 22:00, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 14/12/2015 20:33, Ben Bacarisse wrote: > >>>> Are you seriously advocating making the source of some data be >>>> explicitly from something you call "a keyboard"? Explicitly in the >>>> program itself I mean? >>> >>> Um, yes. Why, is that wrong? >> >> It goes against the way OSes and programming languages have developed >> over many decades. They provide high-level abstractions so the >> programmer need not care about where the data come from. > > That doesn't follow. It often does matter if you want to write > /interactive/ programs. > >> Maybe your snipping of the context will lead you to claim that you *do* >> sometimes need to know -- as in Malcolm's game example. Just in case, I >> remind you we are talking about more general input to programs that do >> things like like make histograms of word lengths. > > This is a case in point. In a polished version, there would be nice > prompts at the start and continuing prompts at every line to keep the > user assured something is happening and the program hasn't died. Maybe > there's a problem on one of the lines and you can report that and > offer the user a chance to correct it. Who wants a histogram of words they type in? There is no realistic situation where this program is anything but a tool -- a tool to analyse text for one reason or another. It's handy to be able to type at it for a quick test or two, but it's not going to be used like that. It's like wc, head, tail, grep, cut and so on. The number of interactive program of the sort you envisage is vanishingly small. When the input is small enough to be typed in, a polished program will probably provide some form-based input, even on a text terminal. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-15 00:50 +0000 |
| Message-ID | <n4no0p$d2r$1@dont-email.me> |
| In reply to | #78711 |
On 14/12/2015 23:38, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>> This is a case in point. In a polished version, there would be nice
>> prompts at the start and continuing prompts at every line to keep the
>> user assured something is happening and the program hasn't died. Maybe
>> there's a problem on one of the lines and you can report that and
>> offer the user a chance to correct it.
>
> Who wants a histogram of words they type in? There is no realistic
> situation where this program is anything but a tool -- a tool to analyse
> text for one reason or another. It's handy to be able to type at it for
> a quick test or two, but it's not going to be used like that. It's like
> wc, head, tail, grep, cut and so on.
>
> The number of interactive program of the sort you envisage is
> vanishingly small. When the input is small enough to be typed in, a
> polished program will probably provide some form-based input, even on a
> text terminal.
Thank you, now I'm starting to understand why you favour certain
approaches and not others.
You are also making one of my points for me, in that console inputs can
be split into two:
(1) Interactive programs with many small inputs and with humans at the
other end.
(2) Programs with little interaction and few or just one large input,
where you'd normally expect a file to be redirected into stdin.
The word count program (most such that I've seen here it seems) is being
treated as (2). If it's used for 'live' input, user dialogue is minimal
to non-existent; Termination methods are crude.
Effectively, it's a program reading from a file. It has little in common
with (1). I'd write (1) as a 'keyboard' program and (2) as a 'file' program.
You however don't seem interested in such a distinction.
In the case of the histogram and many similar exercises, while they can
be written as standalone programs in the Unix style of reading stdin and
writing stdout, they can also be usefully and far more flexibly
implemented as operating on strings, which would be my preference.
(I just spent a few minutes creating such a histogram function in my
script language. It takes a string as input, and returns a list of word
counts.
I tested it with "one two three four five". That worked. Then I tested
it with 'readstrfile("bible.txt")'. That also sort of worked, but I had
to tweak it so that it printed counts rather than multiple asterisks. I
ran it again, and it told me that 3-letters words are most common in an
English bible (based on using isalpha() to define words).
One more minute, and I had a loop reading a line of text (with prompt),
and displaying the histogram of each line. Terminating with a blank line.
No EOF, ferror, redirect or pipe in sight. Although this is a little
scripting language, it shows the kinds of approaches I'd like to use in
languages like C too, if only I can keep well away Unix and its dated
ideas.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-12-14 17:00 -0800 |
| Message-ID | <5d342440-39a4-40a2-9802-4d97e5fe94a6@googlegroups.com> |
| In reply to | #78718 |
On Tuesday, December 15, 2015 at 12:51:05 AM UTC, Bart wrote: > > One more minute, and I had a loop reading a line of text (with prompt), > and displaying the histogram of each line. Terminating with a blank line. > > No EOF, ferror, redirect or pipe in sight. Although this is a little > scripting language, it shows the kinds of approaches I'd like to use in > languages like C too, if only I can keep well away Unix and its dated > ideas.) > C isn't great for text processing. It's usable, but really you want strings to be first class objects, rich pattern matching to be standard, and string concatenation and number to string conversions to be easy. That's without considering non-English text. You also want slightly higher-level file functions.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-15 01:20 +0000 |
| Message-ID | <87y4cwtsma.fsf@bsb.me.uk> |
| In reply to | #78718 |
BartC <bc@freeuk.com> writes:
> On 14/12/2015 23:38, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> This is a case in point. In a polished version, there would be nice
>>> prompts at the start and continuing prompts at every line to keep the
>>> user assured something is happening and the program hasn't died. Maybe
>>> there's a problem on one of the lines and you can report that and
>>> offer the user a chance to correct it.
>>
>> Who wants a histogram of words they type in? There is no realistic
>> situation where this program is anything but a tool -- a tool to analyse
>> text for one reason or another. It's handy to be able to type at it for
>> a quick test or two, but it's not going to be used like that. It's like
>> wc, head, tail, grep, cut and so on.
>>
>> The number of interactive program of the sort you envisage is
>> vanishingly small. When the input is small enough to be typed in, a
>> polished program will probably provide some form-based input, even on a
>> text terminal.
>
> Thank you, now I'm starting to understand why you favour certain
> approaches and not others.
I'm still mystified by your choices.
> You are also making one of my points for me, in that console inputs
> can be split into two:
>
> (1) Interactive programs with many small inputs and with humans at the
> other end.
>
> (2) Programs with little interaction and few or just one large input,
> where you'd normally expect a file to be redirected into stdin.
>
> The word count program (most such that I've seen here it seems) is
> being treated as (2). If it's used for 'live' input, user dialogue is
> minimal to non-existent; Termination methods are crude.
>
> Effectively, it's a program reading from a file. It has little in
> common with (1). I'd write (1) as a 'keyboard' program and (2) as a
> 'file' program.
>
> You however don't seem interested in such a distinction.
No, that's not a distinction I'd bother with. I'd distinguish between
interactive programs (that need to do text IO with a live human person
though they may be automated by clever technology), and those that are
not. It's much simpler -- interactive or not.
> In the case of the histogram and many similar exercises, while they
> can be written as standalone programs in the Unix style of reading
> stdin and writing stdout, they can also be usefully and far more
> flexibly implemented as operating on strings, which would be my
> preference.
I don't know what that means. If the specification is for a program
that processes input, you can't avoid the input. Anyway, you agree, I
think, that this program is *not* an interactive one in the sense you've
been pushing up to now.
> (I just spent a few minutes creating such a histogram function in my
>script language. It takes a string as input, and returns a list of word
>counts.
>
> I tested it with "one two three four five". That worked. Then I tested
> it with 'readstrfile("bible.txt")'. That also sort of worked, but I
> had to tweak it so that it printed counts rather than multiple
> asterisks. I ran it again, and it told me that 3-letters words are
> most common in an English bible (based on using isalpha() to define
> words).
>
> One more minute, and I had a loop reading a line of text (with
> prompt), and displaying the histogram of each line. Terminating with a
> blank line.
>
> No EOF, ferror, redirect or pipe in sight. Although this is a little
> scripting language, it shows the kinds of approaches I'd like to use
> in languages like C too, if only I can keep well away Unix and its
> dated ideas.)
So you have a language from the 80s that can do string IO? So what?
The interesting approaches to writing this sort of program involve
things like Haskell's lazy IO, C++'s input/output interators and Go's
reader/writer interfaces.
But this is comp.lang.c and giant strings are generally not a good
structure to use -- certainly not for a beginner starting out in C.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-15 11:41 +0000 |
| Message-ID | <n4ou58$rvt$1@dont-email.me> |
| In reply to | #78724 |
On 15/12/2015 01:20, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> (I just spent a few minutes creating such a histogram function in my >> script language. It takes a string as input, and returns a list of word >> counts. >> ... Although this is a little >> scripting language, it shows the kinds of approaches I'd like to use >> in languages like C too, if only I can keep well away Unix and its >> dated ideas.) > > So you have a language from the 80s that can do string IO? So what? So, that approach is very simple and works extremely well. What's wrong with that? > The interesting approaches to writing this sort of program involve > things like Haskell's lazy IO, C++'s input/output interators and Go's > reader/writer interfaces. OK, so you're ignoring anything that might have come out between the 1970s and 2010s, and have a penchant for 'difficult' languages that are hard to understand. Big ones too. What's the idea, to try and make me feel very small? I'm just trying to introduce an alternative point of view. > But this is comp.lang.c and giant strings are generally not a good > structure to use True. My script that loaded the Bible in one go used up a massive 0.15% of the memory in my machine. It also ran marginally faster than optimised gcc code! Which is interesting since my script uses interpreted byte-code. (However that was probably due to a rubbish getchar() implementation for gcc -O3 on Windows. On Linux, gcc -O3 is four times as fast as my script. Still not too bad.)
[toc] | [prev] | [next] | [standalone]
Page 11 of 20 — ← Prev page 1 … 9 10 [11] 12 13 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web