Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #60006 > unrolled thread
| Started by | Robbie Hatley <see.my.sig@for.my.address> |
|---|---|
| First post | 2015-04-14 00:14 -0700 |
| Last post | 2015-04-14 13:03 +0100 |
| Articles | 20 on this page of 297 — 22 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: SAFEcode Robbie Hatley <see.my.sig@for.my.address> - 2015-04-14 00:14 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-14 10:33 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-14 02:01 -0700
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-14 10:23 +0100
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-14 11:49 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-14 04:31 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-14 14:54 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-14 06:39 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-14 16:10 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-14 08:11 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-14 23:58 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 01:25 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-15 11:11 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 02:35 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-15 13:52 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 06:04 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-15 08:08 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 08:57 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-15 18:24 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 09:45 -0700
Re: SAFEcode Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-04-15 19:09 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 22:29 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-16 08:23 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-16 10:44 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-16 11:22 -0700
Re: SAFEcode raltbos@xs4all.nl (Richard Bos) - 2015-04-19 15:33 +0000
Re: SAFEcode Steve Thompson <stevet810@gmail.com> - 2015-04-16 04:38 +0000
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-16 14:12 -0500
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-17 09:28 +0200
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-17 09:33 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-17 02:08 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-17 09:43 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-17 08:04 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-17 17:08 -0500
Re: SAFEcode Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-17 08:07 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-15 12:29 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 22:56 -0700
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-16 10:29 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-16 04:46 -0700
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-16 13:08 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-16 08:42 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-16 16:47 +0100
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-16 16:53 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-16 10:52 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-16 22:11 +0100
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-17 10:22 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-17 02:17 -0700
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-17 05:56 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-17 04:37 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-17 10:04 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-17 08:38 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-17 20:52 +0100
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-18 13:16 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-18 04:22 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-18 14:08 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-18 06:00 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-18 21:42 +0200
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-18 17:47 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 00:11 -0700
Re: SAFEcode raltbos@xs4all.nl (Richard Bos) - 2015-04-19 12:52 +0000
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-19 09:10 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 07:21 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-19 12:54 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 11:18 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-20 09:58 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 08:09 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-20 13:06 -0500
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-19 07:32 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 09:03 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-19 16:30 +0100
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-19 12:58 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 05:37 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-18 08:00 -0500
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-18 19:28 +0100
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-18 09:37 -0500
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-19 11:37 +0100
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-19 09:56 -0500
Re: SAFEcode Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-22 15:49 -0700
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-22 18:13 -0500
Re: SAFEcode Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-28 12:46 -0700
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-20 16:50 -0500
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-17 10:31 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-17 21:09 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-17 19:01 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-18 15:18 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-18 09:00 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-18 21:52 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 00:02 -0700
Re: SAFEcode asetofsymbols@gmail.com - 2015-04-19 00:40 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 03:52 -0700
Re: SAFEcode asetofsymbols@gmail.com - 2015-04-21 09:02 -0700
Re: SAFEcode raltbos@xs4all.nl (Richard Bos) - 2015-04-19 12:58 +0000
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 07:25 -0700
Re: SAFEcode raltbos@xs4all.nl (Richard Bos) - 2015-04-19 15:51 +0000
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-19 23:22 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 16:26 -0700
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-20 00:48 +0100
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 09:15 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 00:39 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 10:33 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 01:55 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 11:28 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 02:39 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 12:35 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 03:58 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 13:37 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 06:04 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 15:37 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 06:52 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 16:23 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 07:32 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 22:42 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 21:56 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-21 09:21 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-21 01:00 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-21 10:37 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-21 01:59 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-21 12:21 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-21 03:45 -0700
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-21 10:05 +0100
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-21 12:14 +0200
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-21 08:18 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-21 08:51 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-22 09:44 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 01:38 -0700
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-22 03:45 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 02:13 -0700
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-22 04:29 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 03:29 -0700
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-22 10:30 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 09:13 -0700
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-22 13:03 -0500
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-22 11:38 -0700
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-22 15:25 -0500
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-22 21:49 +0100
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-22 16:17 -0500
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-22 22:33 +0100
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-22 16:56 -0500
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-23 09:24 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-23 02:25 -0700
Re: SAFEcode Richard Damon <Richard@Damon-Family.org> - 2015-04-23 08:24 -0400
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-23 06:18 -0700
Re: SAFEcode Ben Bacarisse <ben.lists@bsb.me.uk> - 2015-04-23 14:47 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-23 07:16 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-23 17:20 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-23 08:44 -0700
Re: SAFEcode raltbos@xs4all.nl (Richard Bos) - 2015-04-25 10:14 +0000
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-25 04:04 -0700
Re: SAFEcode raltbos@xs4all.nl (Richard Bos) - 2015-04-25 12:22 +0000
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-25 10:53 -0700
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-23 16:48 +0100
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-24 12:49 +0200
Re: SAFEcode Ben Bacarisse <ben.lists@bsb.me.uk> - 2015-04-23 20:40 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-23 13:03 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-23 23:49 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-24 01:07 -0700
Re: SAFEcode Ben Bacarisse <ben.lists@bsb.me.uk> - 2015-04-24 11:51 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-24 04:29 -0700
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-24 13:20 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-24 06:48 -0700
Re: SAFEcode raltbos@xs4all.nl (Richard Bos) - 2015-04-25 10:16 +0000
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-24 15:48 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-24 10:05 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-24 22:59 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-26 00:16 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-24 04:39 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-24 22:59 +0100
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-23 08:17 -0500
Re: SAFEcode Robert Wessel <robertwessel2@yahoo.com> - 2015-04-22 16:49 -0500
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-22 17:01 -0500
Re: SAFEcode James Kuyper <jameskuyper@verizon.net> - 2015-04-22 17:51 -0400
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-22 17:35 -0500
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-22 17:45 -0700
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-23 09:29 +0100
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-23 08:29 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-23 08:55 -0700
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-23 21:11 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 06:23 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-22 13:08 -0500
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-22 20:17 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 12:43 -0700
Re: SAFEcode raltbos@xs4all.nl (Richard Bos) - 2015-04-23 11:52 +0000
Re: SAFEcode Robert Wessel <robertwessel2@yahoo.com> - 2015-04-23 13:53 -0500
Re: SAFEcode raltbos@xs4all.nl (Richard Bos) - 2015-04-25 10:18 +0000
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-25 21:37 -0500
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-20 12:05 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 04:28 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 04:38 -0700
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-20 12:40 +0100
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 14:11 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 06:31 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 16:31 +0200
Re: SAFEcode jadill33@gmail.com - 2015-04-20 09:38 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 22:52 +0200
Re: SAFEcode asetofsymbols@gmail.com - 2015-04-20 11:10 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-20 22:43 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 22:59 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-21 09:27 +0200
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-21 15:12 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-21 07:31 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-21 16:43 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-21 08:01 -0700
Re: SAFEcode raltbos@xs4all.nl (Richard Bos) - 2015-04-21 22:29 +0000
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-21 11:09 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-21 10:13 -0700
Re: SAFEcode gwowen <gwowen@gmail.com> - 2015-04-21 10:22 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-21 16:51 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-22 02:52 +0100
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-21 14:44 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-21 16:58 -0700
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-22 01:11 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-21 17:31 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-22 10:09 +0200
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-22 10:50 +0100
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-22 11:12 +0100
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-22 11:37 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 05:54 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-22 15:31 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 06:48 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-22 16:29 +0200
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-22 16:13 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 08:22 -0700
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-22 16:25 +0100
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-22 10:35 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-22 13:24 -0500
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-23 01:18 +0200
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-23 06:11 +0100
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-23 09:36 +0200
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-22 08:38 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-22 13:04 +0200
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-22 09:52 -0500
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-22 16:23 +0100
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-22 10:28 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 08:16 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-22 13:53 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 12:45 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-22 16:44 -0500
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-21 22:58 +0100
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-22 09:53 +0200
Re: SAFEcode gwowen <gwowen@gmail.com> - 2015-04-21 10:15 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-21 13:57 -0500
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-21 23:01 +0100
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-21 23:46 +0100
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-22 01:49 +0100
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-22 08:32 +0100
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-22 10:02 +0100
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-21 12:06 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-21 20:18 +0100
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-21 12:30 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-21 21:30 +0100
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-21 13:39 -0700
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-21 20:21 +0100
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-22 10:24 +0200
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-22 09:46 +0100
Re: SAFEcode gwowen <gwowen@gmail.com> - 2015-04-22 02:57 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-22 08:42 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-19 16:19 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 09:08 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-16 08:55 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-16 11:03 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-16 11:35 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-17 10:28 +0200
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-17 09:51 +0100
Re: SAFEcode Phil Carmody <pc+usenet@asdf.org> - 2015-04-20 11:28 +0300
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-17 10:32 +0200
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-14 15:24 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-14 08:03 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-14 18:48 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-14 12:43 -0700
Re: SAFEcode Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-04-14 21:52 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-14 13:16 -0700
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-14 21:39 +0100
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-15 01:20 +0100
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-15 01:29 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 01:32 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-15 08:17 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 09:13 -0700
Re: SAFEcode Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-04-15 18:33 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 10:02 -0700
Re: SAFEcode Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-04-15 20:55 +0200
Re: SAFEcode Robert Wessel <robertwessel2@yahoo.com> - 2015-04-15 19:27 -0500
Re: SAFEcode Phil Carmody <pc+usenet@asdf.org> - 2015-04-20 11:53 +0300
Re: SAFEcode Ian Collins <ian-news@hotmail.com> - 2015-04-16 14:51 +1200
Re: SAFEcode Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-17 02:13 -0700
Re: SAFEcode Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-04-15 08:14 +0200
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-14 21:02 +0100
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-14 08:33 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-14 08:54 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-14 11:43 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-14 12:41 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-14 13:08 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-14 14:02 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-14 15:29 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-15 10:03 +0200
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-15 10:02 +0200
Re: SAFEcode Phil Carmody <pc+usenet@asdf.org> - 2015-04-20 11:13 +0300
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-14 13:03 +0100
Page 9 of 15 — ← Prev page 1 … 7 8 [9] 10 11 … 15 Next page →
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-04-25 10:16 +0000 |
| Message-ID | <553b692d.9455562@news.xs4all.nl> |
| In reply to | #60996 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Friday, April 24, 2015 at 1:20:39 PM UTC+1, Bart wrote: > > What enemy? It's quite possible that someone will simply give the wrong > > kind of input, for example, a 4GB video file, or an executable > > containing resources, when what is expected is a shopping list. > > > The idea is that the enemy gives valid input, but always contrived to be one > byte above our last allocation. No, that's _your_ idea. The rest of us are talking about the problem in the real world, where you have to deal with _all_ circumstances, not just the ones that happen to appear in your textbook. Richard
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-24 15:48 +0100 |
| Message-ID | <mhdl28$tg9$1@dont-email.me> |
| In reply to | #60990 |
On 24/04/2015 15:00, Stefan Ram wrote:
> Bartc <bc@freeuk.com> writes:
>> This is similar to my requirement that 'line-oriented' text input must
>> consist of lines no longer than some reasonable length (eg 1K or 2K
>> characters). Otherwise it's invalid input and there's no point trying to
>> accommodate it. However, you do have to check for that.
>
> That's an advantage of C++. One writes:
>
> #include <iostream>
> #include <string>
> ... { ::std::string line; ::std::cin >> line; ... } ...
>
> and one just does not worry anymore about such stuff.
It can also be a disadvantage. And you still do have to worry about it.
I tried this:
#include <iostream>
#include <string>
int main(void){
std::string line;
std::cin >> line;
std::cout << line;
}
And gave it a file consisting of 3.7 billion "A"s.
To be fair, it dealt with it a lot better than I expected**: only taking
8 minutes and only using 1.2GB of RAM, as I was expecting an
out-of-memory condition, or my machine becoming unresponsive for a long
time.
Still, given erroneous input and with no signs of what it's up to, it
can be worrying for the user who may well have to abort the program.
But giving the same input to one of my programs expecting a line of
text, the result (be it a truncated line, error message, or whatever is
wanted) is instant, without hundreds of MB of RAM used either.
(**I did another test and found out why! By printing the length of the
line instead, the length was truncated to 2147483591 characters.
So, basically, the C++ code doesn't work either! It just silently
truncates to about 2 billion characters instead of the 16KB I used.
Although I'm not still now sure how it manages to fit 2GB of data into
1.2GB of memory, unless there was a memory peak I missed, or it was
swapped out.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-24 10:05 -0700 |
| Message-ID | <a60b985f-30fa-42c1-9d1d-cfedab03a5f0@googlegroups.com> |
| In reply to | #60990 |
On Friday, April 24, 2015 at 3:00:32 PM UTC+1, Stefan Ram wrote:
> Bartc <bc@freeuk.com> writes:
>
> That's an advantage of C++. One writes:
>
> #include <iostream>
> #include <string>
> ... { ::std::string line; ::std::cin >> line; ... } ...
>
> and one just does not worry anymore about such stuff.
.
How long is a piece of string?
The question is how the implementation determines that. It's
reasonable to shunt your problems off to someone else, but that
doesn't make them go away.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-24 22:59 +0100 |
| Message-ID | <87egn73kea.fsf@bsb.me.uk> |
| In reply to | #60986 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, April 24, 2015 at 11:52:04 AM UTC+1, Ben Bacarisse wrote: <snip> >> [...] I'll just >> ask this: what effect on your solution does this essential stipulation >> have? If I pose the same question but remove it, and say that the N >> bytes of data are read from /dev/random, in what way does the solution >> change? >> > The model is a sub-problem. > We need to know that N can be many orders of magnitude larger than the > "expected message size" or David Brown chimes in and says "your optimal > strategy is to allocate N bytes, there is no other answer ...". So we've got to > start small (say with one byte), and x has got to be small in relation to N. > Human-composed English language text fulfils those conditions - we can't > sensibly put a maximum on what someone will send us and claim it's > "human-composed English language text", and the only minimum we have is > one byte. It's not the only set of criteria that would fulfil those > conditions. I never said otherwise. The problem with the stipulation is that it specifies three unnecessary things (being human-generated, being in English and being text) whilst failing to specify the things you need. Using three unnecessary conditions to imply what you want is simply absurd. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-26 00:16 -0700 |
| Message-ID | <ad47f914-eff9-4908-bfcc-bf4040500037@googlegroups.com> |
| In reply to | #61109 |
On Saturday, April 25, 2015 at 11:36:55 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > Human-composed English language text fulfils those conditions - we can't > > sensibly put a maximum on what someone will send us and claim it's > > "human-composed English language text", and the only minimum we have is > > one byte. It's not the only set of criteria that would fulfil those > > conditions. > > I never said otherwise. The problem with the stipulation is that it > specifies three unnecessary things (being human-generated, being in > English and being text) whilst failing to specify the things you need. > Using three unnecessary conditions to imply what you want is simply > absurd. > Firstly, we didn't know a priori what the answer would be. Secondly, we haven't come up with an equation and solved it, we've only done a simulation. So whilst we can show that x = 2 as N becomes very large, we haven't actually shown that if N is vastly over FLT_MAX, x remains 2. Thirdly, whilst it appears to be a result, the enemy with N bytes hypothesis is a bit silly, and actually can't be carried out exactly fulfilling the criteria - you can't take Clarissa, take the last 100,001 bytes, and have an "English language message", you've got to cut a bit more intelligently than that. So that leads us on the the next question, how can we get a more relevant answer to the original question? Any offers, or just assertions that no answer is possible?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-24 04:39 -0700 |
| Message-ID | <d1f0e7c9-7c2d-4cea-8b07-ed82b5904f45@googlegroups.com> |
| In reply to | #60985 |
On Friday, April 24, 2015 at 11:52:04 AM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > Say we have the series > > 1, 2*2, 3^3^3, 4^^4^^4^^4, 5^^^5^^^5^^^5^^^5, 6^^^^6^^^^6^^^^6^^^^6^^^^6 > > ... where ^ is exponentiation, ^^ is tetration, ^^^ quintation or > > whatever the next operation is called, and so on, and we generate > > the allocation requests by throwing a 1 sided die and applying the > > series. > > Is exponential growth still a viable strategy? I'd say not, you're > > not significantly chipping away at that last number by taking its > > logarithm. > > But it's so large that it couldn't possibly represent characters > > of human composed text. Maybe it does represent the number of allowed > > states for some particle in physics. The "human-composed English > > language text" stipulation is essential. > > I'm not prepared to try work out what you mean by these words. That > will take hours and you won't answer any questions about it so I'll just > ask this: what effect on your solution does this essential stipulation > have? If I pose the same question but remove it, and say that the N > bytes of data are read from /dev/random, in what way does the solution > change? > We've shown by computer simulation that when N is 1000, the answer is a bit less then 2, when it's a million it's as close to 2 as we can measure, when it's FLT_MAX, it's also as close to 2 as we can measure. That does not prove that the answer is 2 as N approaches infinity. Maybe the answer is generated by an unbounded series which grows extremely slowly. However it's not a practical issue, because we know that N can never go anything like as big as FLT_MAX.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-24 22:59 +0100 |
| Message-ID | <87lhhf3kec.fsf@bsb.me.uk> |
| In reply to | #60987 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: <snip> > We've shown by computer simulation To whom (other than you) does that "we" refer? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-23 08:17 -0500 |
| Message-ID | <mhardd$h6a$1@speranza.aioe.org> |
| In reply to | #60847 |
On 4/23/15 3:24 AM, Bartc wrote: > On 22/04/2015 22:56, Morris Dovey wrote: >> On 4/22/15 4:33 PM, Bartc wrote: >>> Use the stack via recursion? >> >> Yes. > > OK, but I think that will have its own problems that might end up being > worse than the traditional buffer solutions: > > * If the stack is fixed-size, it will overflow and probably crash on > large inputs. > > * If the stack grows, that is little different from growing a buffer. > > * If the stack can grow, but only up to a certain limit, then it > crashes, that combines the worst features! > > * If the stack can grow, then you don't have any control over the steps > it uses (however, it can only grow once to a certain size). > > * If the stack can grow, then usually this will be permanent. If it gets > to a very large size on one particular input, then there is no way of > deallocating that, and the machine might stay crippled. > > * With recursion, a stack can grow and (permanently) eat up memory at at > least a magnitude faster rate than with a simple character buffer. > > * With your scheme, especially if the stack has to be extended, you will > need twice the memory to read large buffers. So for a 1 billion > character buffer, you will need 2 billion characters of storage, and can > only recover half of that. Time to get our feet back on the ground. If you need a spooler, then use a spooler - these routines weren’t intended for slurping up massive amounts of data disguised as a "line" in one go. I trust that you're capable of making sensible choices in the building-blocks you use. :-) Compiled with gcc's -O3 option, getsmx.c generated 65 instructions - which seemed like a reasonable cost for the capability and convenience provided. -- Morris Dovey http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-04-22 16:49 -0500 |
| Message-ID | <oi5gjapkln2deekgd5nl4v28gs6miafj5t@4ax.com> |
| In reply to | #60796 |
On Wed, 22 Apr 2015 16:17:40 -0500, Morris Dovey <mrdovey@iedu.com> wrote: >On 4/22/15 3:49 PM, Bartc wrote: >> On 22/04/2015 21:25, Morris Dovey wrote: > >>> The approach I took has been sufficient to my needs. >> >> Which approach is that, to just allocate N bytes of storage according to >> need? But as Keith said, you won't know what N is in advance. You would >> need to over-allocate (as with my fixed-length buffer), or read the >> input twice if possible, or you will have to grow a buffer. (Or, as >> people here like doing, manage without a line-buffer at all. But that >> doesn't solve the problem for when it /is/ needed.) > >That's exactly the approach taken. The line is read once (but not into a >buffer) and the value of N is determined as it's read. At end-of-line >that N value is used to allocate an exact-size buffer into which all the >chars in the line are stored. > >There is no need to over-allocate, read twice, or "grow" (which may >require behind-the-scenes copying) a too-small buffer. All of those >things are "features" of the primitive paradigm which says chars must be >placed into a buffer as they are read. > >I'm simply applying a different paradigm. Even if you can assume that someone else is magically going to have all the storage needed to read and hold a line for you, what about the case where you can have C-like* line continuations? You've got exactly the same problem building the logical line out of the physical lines. *Only as an example, many similar things exist.
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-22 17:01 -0500 |
| Message-ID | <mh95ns$m6e$1@speranza.aioe.org> |
| In reply to | #60804 |
On 4/22/15 4:49 PM, Robert Wessel wrote: > Even if you can assume that someone else is magically going to have > all the storage needed to read and hold a line for you, what about > the case where you can have C-like* line continuations? You've got > exactly the same problem building the logical line out of the > physical lines. Of course. It's a line input function, not an application. :-) > *Only as an example, many similar things exist. They do, and dealing with such issues is what programmers are paid to do. This simply makes the programming task easier. -- Morris Dovey http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-04-22 17:51 -0400 |
| Message-ID | <553817F1.4060701@verizon.net> |
| In reply to | #60796 |
On 04/22/2015 05:17 PM, Morris Dovey wrote: > That's exactly the approach taken. The line is read once (but not into a > buffer) and the value of N is determined as it's read. At end-of-line > that N value is used to allocate an exact-size buffer into which all the > chars in the line are stored. > > There is no need to over-allocate, read twice, or "grow" (which may > require behind-the-scenes copying) a too-small buffer. All of those > things are "features" of the primitive paradigm which says chars must be > placed into a buffer as they are read. > > I'm simply applying a different paradigm. I found that description very confusing, so I tracked back to previous messages your wrote, and found your code for getsml.c, which seems to be what you're talking about (let me know if it's not). I wasn't sufficiently interested the first time you mentioned it to bother reading that code. It seems to me that your code uses recursion to essentially treat the stack itself as a buffer, and automatically assumes (untestably) that the stack is large enough to hold all of the characters. On some implementations of C that I've used, each level of recursion would waste at least 11 bytes of space (to store the return address and to ensure correct alignment) in order to store one byte of data on the stack. I don't think your "different" paradigm is a better paradigm. I think I like just about any of the other "primitive" alternatives mentioned above better than that one.
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-22 17:35 -0500 |
| Message-ID | <mh97oc$qn5$1@speranza.aioe.org> |
| In reply to | #60805 |
On 4/22/15 4:51 PM, James Kuyper wrote: > On 04/22/2015 05:17 PM, Morris Dovey wrote: > >> That's exactly the approach taken. The line is read once (but not >> into a buffer) and the value of N is determined as it's read. At >> end-of-line that N value is used to allocate an exact-size buffer >> into which all the chars in the line are stored. >> >> There is no need to over-allocate, read twice, or "grow" (which >> may require behind-the-scenes copying) a too-small buffer. All of >> those things are "features" of the primitive paradigm which says >> chars must be placed into a buffer as they are read. >> >> I'm simply applying a different paradigm. > > I found that description very confusing, so I tracked back to > previous messages your wrote, and found your code for getsml.c, which > seems to be what you're talking about (let me know if it's not). I > wasn't sufficiently interested the first time you mentioned it to > bother reading that code. Okay. I'm not a salesman. :-) > It seems to me that your code uses recursion to essentially treat > the stack itself as a buffer, and automatically assumes (untestably) > that the stack is large enough to hold all of the characters. On > some implementations of C that I've used, each level of recursion > would waste at least 11 bytes of space (to store the return address > and to ensure correct alignment) in order to store one byte of data > on the stack. I don't think your "different" paradigm is a better > paradigm. I think I like just about any of the other "primitive" > alternatives mentioned above better than that one. True. I didn't (and won't) address environment/virtualization and implementation issues - but, having said that, I will say that I haven't gone out of my way to ignore the effects of Moore's Law... -- Morris Dovey http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-22 17:45 -0700 |
| Message-ID | <878udjk6yr.fsf@kst-u.example.com> |
| In reply to | #60794 |
Bartc <bc@freeuk.com> writes:
[...]
> I managed for a decade or two with a fixed line-buffer limits of some
> 132 characters. It's grown over the years and I think now it's up to
> 1K or 2K characters. This is for line-oriented input; anything above
> that is not really line-oriented (no-one has a display that wide).
>
> Of course there's plenty of text input that could be longer for
> various reasons (machine-generated database records for example, with
> one record per line), but you just don't class that as simple
> line-oriented data, and you use a different approach.
If you happen to have a set of tools that are already designed to work
with text files with arbitrarily long lines, it can be very handy to use
those same tools with text-like files with *very* long lines. Why
reinvent the wheel? (The GNU coreutils package is an example.)
--
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-04-23 09:29 +0100 |
| Message-ID | <mhaafm$etb$1@dont-email.me> |
| In reply to | #60833 |
On 23/04/2015 01:45, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: > [...] >> I managed for a decade or two with a fixed line-buffer limits of some >> 132 characters. It's grown over the years and I think now it's up to >> 1K or 2K characters. This is for line-oriented input; anything above >> that is not really line-oriented (no-one has a display that wide). >> >> Of course there's plenty of text input that could be longer for >> various reasons (machine-generated database records for example, with >> one record per line), but you just don't class that as simple >> line-oriented data, and you use a different approach. > > If you happen to have a set of tools that are already designed to work > with text files with arbitrarily long lines, it can be very handy to use > those same tools with text-like files with *very* long lines. Why > reinvent the wheel? (The GNU coreutils package is an example.) But I haven't got such a tool. And I strongly disagree with tolerating text files with very long lines without complaining. If I /expect/ such files, then I don't class them as line-oriented, and might use a file-oriented approach or whatever is more appropriate. I don't really want to bring down the system just because I like to be tolerant. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-23 08:29 -0700 |
| Message-ID | <87wq12j217.fsf@kst-u.example.com> |
| In reply to | #60848 |
Bartc <bc@freeuk.com> writes:
> On 23/04/2015 01:45, Keith Thompson wrote:
[...]
>> If you happen to have a set of tools that are already designed to work
>> with text files with arbitrarily long lines, it can be very handy to use
>> those same tools with text-like files with *very* long lines. Why
>> reinvent the wheel? (The GNU coreutils package is an example.)
>
> But I haven't got such a tool.
You can have it if you want it.
> And I strongly disagree with tolerating
> text files with very long lines without complaining.
What exactly do you gain by complaining?
> If I /expect/ such files, then I don't class them as line-oriented,
> and might use a file-oriented approach or whatever is more
> appropriate.
With my approach, I can treat them as line-oriented files.
With yours, you have to go hunting for (or implement) another set
of tools to process them, just because the lines are longer than
you're willing to tolerate.
A simple example: Say I have a file representing a sequence of
records, where each record is represented as a line of text.
How many records are in the file? `wc -l filename` gives me the
answer, no matter how long the lines are. How many records contain
the word "FOO"? `grep -c FOO filename`.
> I don't really want to bring down the system just because I like to be
> tolerant.
Who said anything about bringing down the system? Suppose I have
a file that's formatted like plain text, but with lines up to,
say, a few thousand characters. I can process such a file using
the same tools I use for ordinary text files. (If I'm displaying
lines, I have to decide whether I want them wrapped or truncated;
that's not hard to handle.)
If the lines are, say, a gigabyte each, I might have some problems,
but the existing line-oriented tools might still work just as
well as a specialized tool. Sure, sometimes you're going to need
specialized tools, but the existing tools are a good starting point.
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-23 08:55 -0700 |
| Message-ID | <9d31a00d-5467-4f5b-abfe-ce83e46b5747@googlegroups.com> |
| In reply to | #60907 |
On Thursday, April 23, 2015 at 4:30:04 PM UTC+1, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: > > If the lines are, say, a gigabyte each, I might have some problems, > but the existing line-oriented tools might still work just as > well as a specialized tool. Sure, sometimes you're going to need > specialized tools, but the existing tools are a good starting point. > You need a system that won't crash out if line are a gigabyte in length and there's a gigabyte of contiguous memory available, and won't lock up the computer for too long either. But you want it to be optimal for lines of about 80 characters, with a distribution that tails off and gets very thin towards 1024 characters or so. You might also want to be able to handle the case of huge numbers of extremely short lines very efficiently. Or you might reasonably say that this is unlikely, and allocating 80 bytes or as a first guess will adequately cover that. But you just want to plug and go, you can't model every situation. You can't sensibly get the probability density function.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-23 21:11 +0100 |
| Message-ID | <mhbjjn$hhs$1@dont-email.me> |
| In reply to | #60907 |
On 23/04/2015 16:29, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: >> On 23/04/2015 01:45, Keith Thompson wrote: > [...] >>> If you happen to have a set of tools that are already designed to work >>> with text files with arbitrarily long lines, it can be very handy to use >>> those same tools with text-like files with *very* long lines. Why >>> reinvent the wheel? (The GNU coreutils package is an example.) >> >> But I haven't got such a tool. > > You can have it if you want it. > >> And I strongly disagree with tolerating >> text files with very long lines without complaining. > > What exactly do you gain by complaining? I help enforce the distinction between truly line-oriented input of short lines, and everything else. Because as soon as you lose that distinction, then it is necessary to deal with massively large lines, or no lines at all, just one big file. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-22 06:23 -0700 |
| Message-ID | <0a3af622-c154-4ebe-8810-bc6c0c9443d9@googlegroups.com> |
| In reply to | #60714 |
On Wednesday, April 22, 2015 at 10:29:19 AM UTC+1, Morris Dovey wrote:
> On 4/22/15 4:13 AM, Malcolm McLean wrote:
> > On Wednesday, April 22, 2015 at 9:45:24 AM UTC+1, Morris Dovey wrote:
> >> On 4/22/15 2:44 AM, David Brown wrote:
> >>
> >> When the discussion turned to "unfriendly" data sources, I wrote a
> >> second version http://www.iedu.com/tmp/getsml.c with an additional
> >> parameter for specification of a maximum number of bytes allowed in a
> >> "friendly" message. Unfriendly messages are reported, but without
> >> wasting time or allocating memory.
> >>
> > So we need that parameter.
> >
> > Progress at last. What's the longest human-composed English language message someone
> > could send you?
>
> On this machine? My largest test input was a gigabyte.
>
> In real life applications that I write, I'd use the one of the limiting
> versions and reject lines longer than 1K. :-)
>
Here's my test for "unfriendly input".
We've got assume that the enemy has N bytes, which he's going to distribute as to
cause us maximum distress. So he could send one byte at a time, or all N at once,
or anything in between, but he can only send N.
So he sends as much as he can, until our allocation goes over N. So he
ends the message, and attacks again, and so on, until his ammunition is
exhausted.
I couldn't get an equation to work because of the ceiling factors. So I'm just
simulating it.
double cost3(double x, double N)
{
double answer = 0;
double take = 1;
double last = 0;
if(N <= 0)
return 0;
while(take <= N)
{
last = take;
take *= x;
if(ceil(take) != last)
answer += ceil(take);
}
return answer + cost3(x, N - last -1);
}
Assuming enemy has FLT_MAX bytes to send us, and testing all values of the growth
factor for 1.1 to 10.
1.100 4.11742e+39
1.200 2.45003e+39
1.300 1.91692e+39
1.400 1.66738e+39
1.500 1.53127e+39
1.600 1.45187e+39
1.700 1.40488e+39
1.800 1.37814e+39
1.900 1.36491e+39
2.000 1.36113e+39
2.100 1.36422e+39
2.200 1.37247e+39
2.300 1.38469e+39
2.400 1.40002e+39
2.500 1.41784e+39
2.600 1.43769e+39
2.700 1.45921e+39
2.800 1.48212e+39
2.900 1.5062e+39
3.000 1.53127e+39
3.100 1.5572e+39
3.200 1.58386e+39
3.300 1.61116e+39
3.400 1.63903e+39
3.500 1.66738e+39
3.600 1.69618e+39
3.700 1.72536e+39
3.800 1.75488e+39
3.900 1.78472e+39
4.000 1.81484e+39
4.100 1.84521e+39
4.200 1.87581e+39
4.300 1.90661e+39
4.400 1.93761e+39
4.500 1.96878e+39
4.600 2.0001e+39
4.700 2.03158e+39
4.800 2.06319e+39
4.900 2.09492e+39
5.000 2.12676e+39
5.100 2.15872e+39
5.200 2.19077e+39
5.300 2.22291e+39
5.400 2.25514e+39
5.500 2.28745e+39
5.600 2.31984e+39
5.700 2.35229e+39
5.800 2.38481e+39
5.900 2.41739e+39
6.000 2.45003e+39
6.100 2.48273e+39
6.200 2.51547e+39
6.300 2.54827e+39
6.400 2.5811e+39
6.500 2.61399e+39
6.600 2.64691e+39
6.700 2.67987e+39
6.800 2.71287e+39
6.900 2.74591e+39
7.000 2.77897e+39
7.100 2.81207e+39
7.200 2.8452e+39
7.300 2.87836e+39
7.400 2.91154e+39
7.500 2.94475e+39
7.600 2.97799e+39
7.700 3.01124e+39
7.800 3.04453e+39
7.900 3.07783e+39
8.000 3.11115e+39
8.100 3.1445e+39
8.200 3.17786e+39
8.300 3.21124e+39
8.400 3.24464e+39
8.500 3.27805e+39
8.600 3.31148e+39
8.700 3.34493e+39
8.800 3.37839e+39
8.900 3.41187e+39
9.000 3.44536e+39
9.100 3.47886e+39
9.200 3.51238e+39
9.300 3.54591e+39
9.400 3.57945e+39
9.500 3.613e+39
9.600 3.64656e+39
9.700 3.68013e+39
9.800 3.71372e+39
9.900 3.74731e+39
10.000 3.78091e+39
There's a clear minimum at 2. Try other large numbers, and 2 always pops out as the answer.
However when the enemy has only a few bytes to send us relative to the initial allocation,
things change a bit.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-04-22 13:08 -0500 |
| Message-ID | <mh8o0p$b93$1@dont-email.me> |
| In reply to | #60730 |
On 4/22/2015 8:23 AM, Malcolm McLean wrote:
> On Wednesday, April 22, 2015 at 10:29:19 AM UTC+1, Morris Dovey wrote:
>> On 4/22/15 4:13 AM, Malcolm McLean wrote:
>>> On Wednesday, April 22, 2015 at 9:45:24 AM UTC+1, Morris Dovey wrote:
>>>> On 4/22/15 2:44 AM, David Brown wrote:
>>>>
>>>> When the discussion turned to "unfriendly" data sources, I wrote a
>>>> second version http://www.iedu.com/tmp/getsml.c with an additional
>>>> parameter for specification of a maximum number of bytes allowed in a
>>>> "friendly" message. Unfriendly messages are reported, but without
>>>> wasting time or allocating memory.
>>>>
>>> So we need that parameter.
>>>
>>> Progress at last. What's the longest human-composed English language message someone
>>> could send you?
>>
>> On this machine? My largest test input was a gigabyte.
>>
>> In real life applications that I write, I'd use the one of the limiting
>> versions and reject lines longer than 1K. :-)
>>
> Here's my test for "unfriendly input".
> We've got assume that the enemy has N bytes, which he's going to distribute as to
> cause us maximum distress. So he could send one byte at a time, or all N at once,
> or anything in between, but he can only send N.
>
> So he sends as much as he can, until our allocation goes over N. So he
> ends the message, and attacks again, and so on, until his ammunition is
> exhausted.
>
> I couldn't get an equation to work because of the ceiling factors. So I'm just
> simulating it.
>
> double cost3(double x, double N)
> {
> double answer = 0;
> double take = 1;
> double last = 0;
>
> if(N <= 0)
> return 0;
> while(take <= N)
> {
> last = take;
> take *= x;
> if(ceil(take) != last)
> answer += ceil(take);
> }
>
> return answer + cost3(x, N - last -1);
> }
I doubt this does what you think it does. For example, with x = 1.1 and
N = 2.0, This returns 17.0. Given your description of the attackers
strategy and our strategy, it should return 3.0.
[snip irrelevant numbers]
Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-22 20:17 +0100 |
| Message-ID | <87k2x49dmb.fsf@bsb.me.uk> |
| In reply to | #60730 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
<snip>
> Here's my test for "unfriendly input".
> We've got assume that the enemy has N bytes, which he's going to distribute as to
> cause us maximum distress. So he could send one byte at a time, or all N at once,
> or anything in between, but he can only send N.
>
> So he sends as much as he can, until our allocation goes over N. So he
> ends the message, and attacks again, and so on, until his ammunition is
> exhausted.
>
> I couldn't get an equation to work because of the ceiling factors. So I'm just
> simulating it.
>
> double cost3(double x, double N)
> {
> double answer = 0;
> double take = 1;
> double last = 0;
>
> if(N <= 0)
> return 0;
> while(take <= N)
> {
> last = take;
> take *= x;
> if(ceil(take) != last)
> answer += ceil(take);
> }
>
> return answer + cost3(x, N - last -1);
> }
Can you explain what's going on here? I can't tie this to your previous
remarks about cost functions. Naturally I know what the code says, I
just can't see what cost you are measuring.
The preceding text is no help. Can you work a small example? Take an
unrealistically low value for whatever parameters are involved and show
the messages, allocations and costs at each step.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 9 of 15 — ← Prev page 1 … 7 8 [9] 10 11 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web