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 7 of 15 — ← Prev page 1 … 5 6 [7] 8 9 … 15 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-21 12:14 +0200 |
| Message-ID | <mh57t0$9sl$1@dont-email.me> |
| In reply to | #60617 |
On 21/04/15 11:05, Richard Heathfield wrote: > On 21/04/15 09:37, David Brown wrote: >> On 21/04/15 10:00, Malcolm McLean wrote: > > <snip> > >>> Those answers are smart Alec answers - store the data on the >>> stack, or the "optimal strategy" is to know the size beforehand. >> >> No, these are perfectly good answers to the problem as stated. Note >> that the answers I gave for the artificial mathematical problem were not >> "smart Alec" answers - they were /correct/ answers. /Provably/ correct >> answers. The /only/ correct answers. > > So you don't consider "reject the attacker's data completely" to be a > correct answer? I'm mortified! > That reminds me of the Mythbuster's motto - "I reject your reality, and substitute my own!". Sometimes I think that's the world Malcolm lives in...
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-21 08:18 -0700 |
| Message-ID | <87oamhmrvo.fsf@kst-u.example.com> |
| In reply to | #60602 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> So we've got a probability distribution for N, at least sketched it
> out. It's got a peak at somewhere near 1 million words, and it
> decays to zero at infinity. The ridiculous suggestions at the
> extreme high end are the real world interpretation of an exponential
> decay process.
A peak near 1 million words? So messages of 1 million words are more
likely than messages of 100,000 or 10 million words? That's new
information.
> The point is, it's crucial to know what your equations actually
> represent, if there's the slightest amount of uncertainty in them.
>
> So we see now that we can actually get a handle on the problem.
> It's not inherently insoluble, but only if you've got flexibility
> of thought and reasoning.
If this were a real world problem, we would be able to observe actual
inputs during development and testing of the program. That would give
us at least a rough distribution of the size of the data to be expected.
We could use that to determine a good allocation strategy.
Testing would give us more useful information that you've managed to
give us in this entire thread.
--
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-21 08:51 -0700 |
| Message-ID | <09632117-2be9-44c0-9349-aec48b64fd74@googlegroups.com> |
| In reply to | #60647 |
On Tuesday, April 21, 2015 at 4:19:00 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > So we've got a probability distribution for N, at least sketched it > > out. It's got a peak at somewhere near 1 million words, and it > > decays to zero at infinity. The ridiculous suggestions at the > > extreme high end are the real world interpretation of an exponential > > decay process. > > A peak near 1 million words? So messages of 1 million words are more > likely than messages of 100,000 or 10 million words? That's new > information. > The situation is that someone (me) has been accused of planning to manipulate the data in order to cause everyone's solutions to have worst case performance. So call him the enemy. Obviously his best strategy would be just to hook up his transmitter to a little program and send us and endless stream of bytes, but he can't do that. He's got to claim to be sending us real data, this is, human-composed English language messages. The supply of such data is limited, he's only got so much "ammunition" to throw at us. But we don't know how much. But if our strategy is to start at one byte then grow exponentially, his best strategy is to send us chunks of data, always one byte in excess of our last allocation, until our total allocation is larger than the largest message he can send. But we could use several models. One of which is that he's got a maximum message size, and is sending us that. So that's the one attack model. (David Brown was claiming that the best strategy in that case is to allocate exactly N bytes, but that's clearly hopeless as we've no way of establishing N exactly, and that would leave us vulnerable to lots of one-byte messages). Another model is that he's got a huge collection of text - as much as he can lay his hands on, and he's going to send us as much as he can until our allocation goes over his limit. Then he'll send us the nul, and send the next, and then the next, and so on. But we don't know how much text he can get his hands on. We do know that to concatenate a series of books by different authors and call it a message is pretty underhand, it's arguably cheating. But whilst we can say it's improbable that he'll cheat, we can't quantify it, and we can't quantify the probability of an appeal going in our favour if he does that. And we can't establish how much English-language text there is. But we can make some estimates, he can't send us more text than is physically possible. And it's most likely that "Human composed English language message" means, "book considered to be a unitary work". And that's about a million words. So, if we're being sent the text by an enemy, our worst case scenario is a massive attack with a concatenation of all the English language text in the world, defined as generously as possible. Our most likely enemy scenario is and track with the longest text that everyone will agree is a "human composed English language book (not "message"), which is an attack of about 1 million words. So the point is, we don't know the size of the blow that will fall upon us. But we have some idea. And we're only considering the enemy hypothesis at this stage. > If this were a real world problem, we would be able to observe actual > inputs during development and testing of the program. That would give > us at least a rough distribution of the size of the data to be expected. > We could use that to determine a good allocation strategy. > > Testing would give us more useful information that you've managed to > give us in this entire thread. > That's obviously something to do, to test on real data. But if I said to you "what's average human height, can you take a random sample of 100 people, measure them, and tell me the average?" don't you see that you have a problem. You can easily go out into the street and round up 100 people, but they're all Americans, hardly representative. if you had a database with everyone in the world listed you could knock up an RNG and pull out 100 at random, but there is no such database. You can maybe travel the world, but that's expensive, and you'll bias the sample towards people willing to speak to a strange American, probably mainly adult men. Similarly, we can't take a representative sample of something like "human-composed English language texts". There's just no way of doing it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-22 09:44 +0200 |
| Message-ID | <mh7je7$o1m$1@dont-email.me> |
| In reply to | #60653 |
On 21/04/15 17:51, Malcolm McLean wrote: > (David Brown was claiming that the best strategy in that case is to > allocate exactly N bytes, but that's clearly hopeless as we've no way > of establishing N exactly, and that would leave us vulnerable to lots > of one-byte messages) There is no doubt that allocating exactly N bytes /is/ the best strategy, even if we don't know what N is. We cannot implement it in practice, but that does not mean it is not the best strategy for the problem. It is perfectly possible to know /something/ about the answer to a problem without knowing everything. In particular, knowing a bound on the best possible strategy could help us judge implementable strategies. And with the global cost function you have asked for (minimal worst case cost), the wasted effort on one-byte messages is irrelevant.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-22 01:38 -0700 |
| Message-ID | <e22e8b4b-8003-47cc-a21a-3950578c3a8a@googlegroups.com> |
| In reply to | #60702 |
On Wednesday, April 22, 2015 at 8:44:11 AM UTC+1, David Brown wrote: > On 21/04/15 17:51, Malcolm McLean wrote: > > (David Brown was claiming that the best strategy in that case is to > > allocate exactly N bytes, but that's clearly hopeless as we've no way > > of establishing N exactly, and that would leave us vulnerable to lots > > of one-byte messages) > > There is no doubt that allocating exactly N bytes /is/ the best > strategy, even if we don't know what N is. We cannot implement it in > practice, but that does not mean it is not the best strategy for the > problem. It is perfectly possible to know /something/ about the answer > to a problem without knowing everything. In particular, knowing a bound > on the best possible strategy could help us judge implementable > strategies. > > And with the global cost function you have asked for (minimal worst case > cost), the wasted effort on one-byte messages is irrelevant. > So you've got to be able to apply the equation to the situation. You can control x (the factor) by which we grow, enemy can't control N (the total amount of data he has available to him), but the enemy can see your code, and can send as much or as little as he wants. So he always sends the total amount. So if we've one enemy, limited to one attack, it's almost the same as having no enemy at all, except that the problem isn't now to estimate the PDF of the messages the problem is to estimate the PDF of the biggest possible message. See? We've recast the problem. That's all we've done. Keeping N constant and saying we need to estimate N is true in a way, but it doesn't make your problem vanish in a puff of mathematical logic. I said "he could send you lots of messages of one byte, but he won't do that". Implying, to any sensible speaker (not a clever Dick) that he can impose N * x costs on you by sending lots of one byte or two byte messages, N *x + the sum of the intermediates by sending the whole lot in one go. So anyone with any sense know that this requirement rules out making x as large as N. It's something we've considered. "He wont do that" isn't to be interpreted literally, it means "he won't do that unless (by being silly) you make it his best strategy". But the the question is, can the enemy end us the rest of his ammunition. We can consider that later. After we've agree the costs for a one- attack scenario.
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-22 03:45 -0500 |
| Message-ID | <mh7n2n$oqv$1@speranza.aioe.org> |
| In reply to | #60702 |
On 4/22/15 2:44 AM, David Brown wrote: > On 21/04/15 17:51, Malcolm McLean wrote: >> (David Brown was claiming that the best strategy in that case is >> to allocate exactly N bytes, but that's clearly hopeless as we've >> no way of establishing N exactly, and that would leave us >> vulnerable to lots of one-byte messages) > > There is no doubt that allocating exactly N bytes /is/ the best > strategy, even if we don't know what N is. We cannot implement it > in practice, but that does not mean it is not the best strategy for > the problem. Actually, we /can/ implement it in practice. The C language provides all the capabilities needed to get the data, determine N, and /then/ allocate the N+1 bytes and store the data into it. I already had http://www.iedu.com/tmp/getsm.c to do exactly that. 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. For those not constrained to strictly-conforming code, I also wrote equivalent http://www.iedu.com/tmp/getsmx.c and http://www.iedu.com/tmp/getsmlx.c functions which offer significant improvements using nested functions. So we not only can, but it's already been done. :-) -- Morris Dovey http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-22 02:13 -0700 |
| Message-ID | <00be1cc1-5fe7-4eca-8ce9-3d2da42ad61b@googlegroups.com> |
| In reply to | #60708 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-22 04:29 -0500 |
| Message-ID | <mh7pl4$v11$1@speranza.aioe.org> |
| In reply to | #60712 |
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. :-) -- Morris Dovey http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-22 03:29 -0700 |
| Message-ID | <f109d309-699e-4105-90eb-d0d823bfbe72@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: > > > 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. > The longest novels in English are about a million words. So storing on the stack is in fact feasible. But it's a cheat. > > In real life applications that I write, I'd use the one of the limiting > versions and reject lines longer than 1K. :-) > We had a huge discussion on how to implement get_line() a few years ago.
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-22 10:30 -0500 |
| Message-ID | <mh8eqt$m8l$1@speranza.aioe.org> |
| In reply to | #60720 |
On 4/22/15 5:29 AM, Malcolm McLean wrote: > So storing on the stack is in fact feasible. But it's a cheat. I don't mind "cheating" so long as it gets the job done correctly and is portable. I remember when a hardware stack was considered a cheat. :-) -- Morris Dovey http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-22 09:13 -0700 |
| Message-ID | <f847df47-8bb6-45d7-8a53-2be1ef27fa72@googlegroups.com> |
| In reply to | #60742 |
On Wednesday, April 22, 2015 at 4:30:51 PM UTC+1, Morris Dovey wrote: > On 4/22/15 5:29 AM, Malcolm McLean wrote: > > > So storing on the stack is in fact feasible. But it's a cheat. > > I don't mind "cheating" so long as it gets the job done correctly and is > portable. > Its reasonable to say, "if I've got to handle unbounded input then I'll do it by allocating sections / finding some unbounded free storage somewhere, not by growing a buffer". But the problem is to grow the buffer. > > I remember when a hardware stack was considered a cheat. :-) >
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-22 13:03 -0500 |
| Message-ID | <mh8np6$fcc$1@speranza.aioe.org> |
| In reply to | #60749 |
On 4/22/15 11:13 AM, Malcolm McLean wrote: > On Wednesday, April 22, 2015 at 4:30:51 PM UTC+1, Morris Dovey > wrote: >> On 4/22/15 5:29 AM, Malcolm McLean wrote: >> >>> So storing on the stack is in fact feasible. But it's a cheat. >> >> I don't mind "cheating" so long as it gets the job done correctly >> and is portable. >> > Its reasonable to say, "if I've got to handle unbounded input then > I'll do it by allocating sections / finding some unbounded free > storage somewhere, not by growing a buffer". But the problem is to > grow the buffer. "Growing" a buffer is an inherently wasteful process - a sub-optimal use of available resources. If/when you want a message in a buffer, just get the message, allocate a buffer of the exact size needed, put the message into it, and return a pointer. Introducing additional (unnecessary) processing to make (and recover from) unreliable guesses strikes me as amateurish and unproductive. Of course, others may see it differently. -- Morris Dovey http://www.iedu.com/Solar/
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-22 11:38 -0700 |
| Message-ID | <87lhhkj9fa.fsf@kst-u.example.com> |
| In reply to | #60769 |
Morris Dovey <mrdovey@iedu.com> writes:
> On 4/22/15 11:13 AM, Malcolm McLean wrote:
>> On Wednesday, April 22, 2015 at 4:30:51 PM UTC+1, Morris Dovey
>> wrote:
>>> On 4/22/15 5:29 AM, Malcolm McLean wrote:
>>>
>>>> So storing on the stack is in fact feasible. But it's a cheat.
>>>
>>> I don't mind "cheating" so long as it gets the job done correctly
>>> and is portable.
>>>
>> Its reasonable to say, "if I've got to handle unbounded input then
>> I'll do it by allocating sections / finding some unbounded free
>> storage somewhere, not by growing a buffer". But the problem is to
>> grow the buffer.
>
> "Growing" a buffer is an inherently wasteful process - a sub-optimal use
> of available resources. If/when you want a message in a buffer, just get
> the message, allocate a buffer of the exact size needed, put the
> message into it, and return a pointer.
That's not always possible. Consider reading lines from an text file.
If you're not able to seek (say, if the input is coming in as a
continuous stream rather than being read from a disk file), then you
have to be able to deal with arbitrarily long lines unless you can
impose a maximum line length. If you really need an entire line in
memory at once, you're going to have to do some reallocation in some
cases. Or you can use a linked list, but then you don't always have the
full line stored contiguously.
--
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 | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-22 15:25 -0500 |
| Message-ID | <mh904k$84g$1@speranza.aioe.org> |
| In reply to | #60775 |
On 4/22/15 1:38 PM, Keith Thompson wrote: > Morris Dovey <mrdovey@iedu.com> writes: >> On 4/22/15 11:13 AM, Malcolm McLean wrote: >>> On Wednesday, April 22, 2015 at 4:30:51 PM UTC+1, Morris Dovey >>> wrote: >>>> On 4/22/15 5:29 AM, Malcolm McLean wrote: >>>> >>>>> So storing on the stack is in fact feasible. But it's a >>>>> cheat. >>>> >>>> I don't mind "cheating" so long as it gets the job done >>>> correctly and is portable. >>>> >>> Its reasonable to say, "if I've got to handle unbounded input >>> then I'll do it by allocating sections / finding some unbounded >>> free storage somewhere, not by growing a buffer". But the problem >>> is to grow the buffer. >> >> "Growing" a buffer is an inherently wasteful process - a >> sub-optimal use of available resources. If/when you want a message >> in a buffer, just get the message, allocate a buffer of the exact >> size needed, put the message into it, and return a pointer. > > That's not always possible. Consider reading lines from an text > file. If you're not able to seek (say, if the input is coming in as > a continuous stream rather than being read from a disk file), then > you have to be able to deal with arbitrarily long lines unless you > can impose a maximum line length. If you really need an entire line > in memory at once, you're going to have to do some reallocation in > some cases. Or you can use a linked list, but then you don't always > have the full line stored contiguously. Why not? I did a Google search on [ number of characters in the bible ] and the first reference came up with "The number of characters in the Bible is known to a fairly good precision: I counted 4017010 characters in the Authorized version." If you encounter (or expect to encounter) LINES longer than that, you may want to adopt some other strategy - but I haven't (yet) seen a need. The approach I took has been sufficient to my needs. I suspect it will do the same for nearly everyone else's needs (99.999999999999%) as well, but it's just another tool in the toolbox - available for use when wanted/needed. -- Morris Dovey http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-22 21:49 +0100 |
| Message-ID | <mh91ff$l11$1@dont-email.me> |
| In reply to | #60791 |
On 22/04/2015 21:25, Morris Dovey wrote: > On 4/22/15 1:38 PM, Keith Thompson wrote: >> Morris Dovey <mrdovey@iedu.com> writes: >>> "Growing" a buffer is an inherently wasteful process - a >>> sub-optimal use of available resources. If/when you want a message >>> in a buffer, just get the message, allocate a buffer of the exact >>> size needed, put the message into it, and return a pointer. >> >> That's not always possible. Consider reading lines from an text >> file. If you're not able to seek (say, if the input is coming in as >> a continuous stream rather than being read from a disk file), then >> you have to be able to deal with arbitrarily long lines unless you >> can impose a maximum line length. > Why not? I did a Google search on [ number of characters in the bible ] > and the first reference came up with "The number of characters in the > Bible is known to a fairly good precision: I counted 4017010 characters > in the Authorized version." If you encounter (or expect to encounter) > LINES longer than that, you may want to adopt some other strategy - but > I haven't (yet) seen a need. 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. > 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.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-22 16:17 -0500 |
| Message-ID | <mh935i$fuf$1@speranza.aioe.org> |
| In reply to | #60794 |
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. -- Morris Dovey http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-22 22:33 +0100 |
| Message-ID | <mh9422$v66$1@dont-email.me> |
| In reply to | #60796 |
On 22/04/2015 22:17, Morris Dovey 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. OK, now I'm curious. If you don't store the characters into a buffer as they are read, and you don't read them again, where *do* you keep the (potentially) millions of characters while they await the buffer you're going to allocate when you've found an end-of-line? Use the stack via recursion? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-22 16:56 -0500 |
| Message-ID | <mh95em$kv2$1@speranza.aioe.org> |
| In reply to | #60800 |
On 4/22/15 4:33 PM, Bartc wrote: > Use the stack via recursion? Yes. -- Morris Dovey http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-23 09:24 +0100 |
| Message-ID | <mhaa6c$e1k$1@dont-email.me> |
| In reply to | #60806 |
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. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-23 02:25 -0700 |
| Message-ID | <286d0d9d-0891-4cc4-ad27-0eaf81359c4d@googlegroups.com> |
| In reply to | #60847 |
On Thursday, April 23, 2015 at 9:24:51 AM UTC+1, Bart wrote: > On 22/04/2015 22:56, Morris Dovey wrote: > > > 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. > It's quite common that dynamic memory requests could in fact be rewritten as expandable variable-length arrays, with only the last request expandable, and everything freed in reverse order. So there's a case for providing a massive stack. > > * If the stack grows, that is little different from growing a buffer. > It's exactly the same problem, except that instead of saying "the input is human-composed English language messages", we're saying, "the input is memory requests from a recursive algorithm". Whilst we can talk about "the largest possible English language text message" in at least a slightly sensible way (the longest published novel in English is Clarissa, at 984,870 words, but of course you have to specify "published by a mainstream publisher), and we can maybe make a stab at the expected message size (we can't get onto that because of messing about by certain people), it become a lot harder when we're talking about something as vague as "memory requests from a recursive algorithm of unknown purpose". > > * 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. > Yes, the stack is a cheat in a sense. But nowadays it is actually a practical solution. But another practical solution is to allocate 10 MB (a high estimate for 1 million words), and throw out anything above that. The machine I'm typing this at won't even notice a request for 10 MB of memory. However that assumes you know you have a modern machine, which wasn't information I gave.
[toc] | [prev] | [next] | [standalone]
Page 7 of 15 — ← Prev page 1 … 5 6 [7] 8 9 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web