Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #60000 > unrolled thread
| Started by | G G <gdotone@gmail.com> |
|---|---|
| First post | 2015-04-13 21:19 -0700 |
| Last post | 2015-04-14 13:03 +0100 |
| Articles | 20 on this page of 303 — 23 participants |
Back to article view | Back to comp.lang.c
SAFEcode G G <gdotone@gmail.com> - 2015-04-13 21:19 -0700
Re: SAFEcode Ian Collins <ian-news@hotmail.com> - 2015-04-14 17:12 +1200
Re: SAFEcode Ian Collins <ian-news@hotmail.com> - 2015-04-14 17:19 +1200
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-14 00:24 -0500
Re: SAFEcode G G <gdotone@gmail.com> - 2015-04-13 23:45 -0700
SAFEcode asetofsymbols@gmail.com - 2015-04-13 22:30 -0700
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 16 — ← Prev page 1 … 5 6 [7] 8 9 … 16 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-21 01:00 -0700 |
| Message-ID | <1544b4ee-95d6-4138-b05c-4862f40d6619@googlegroups.com> |
| In reply to | #60610 |
On Tuesday, April 21, 2015 at 8:21:16 AM UTC+1, David Brown wrote: > On 21/04/15 06:56, Malcolm McLean wrote: > > You've got to think that you're applying a function to areal problem > > If this were a /real/ problem, the /real/ solutions proposed by several > people long ago would be appropriate (like streaming the data to a file, > or making a linked list of malloc'ed blocks), taking into account /real/ > cost functions (rather than your imaginary ones). > > If it were a /real/ problem, you wouldn't be using the number of atoms > in the universe when figuring out the maximum size of an input. > You're right, it's not a real problem. It's an invented problem that bears some relationship to real problems. In reality the linked list option is the way to go if the constraint genuinely is on memory take, and the input genuinely is text of unknown size. > > It is a totally /artificial/ problem. There's nothing wrong with > artificial problems - that's how much of the theory of algorithms gets > figured out, and then it can be applied to real problems. But > artificial problems have artificial answers. I have shown, clearly (I > hope) and mathematically answers to several of the variants of your > artificial problems while you change the rules and details in every > other post. In no case have the answers matched your imagined and > desired result - and in no case have they been useful answers that could > be applied in real problems. > Those answers are smart Alec answers - store the data on the stack, or the "optimal strategy" is to know the size beforehand. (I told you that the enemy might send lots of attacks of one byte, but then I said "he won't do that", because then he costs you N * first allocation bytes) (or N/2 if you want to nitpick). So that rules out guessing N if N is high. He'll send you the biggest message he can, which is one over the last allocation you make that brings you over his maximum size. There's no point him sending you any more bytes. Then he conserves ammunition. So he sends you another attack with his remaining data. Which again will be the biggest message he can send, which is one byte larger than your highest allocation. So if we assume the enemy has N bytes, which he can distribute as he wishes, he doesn't have a better strategy than that, and it's a problem we can solve. We can then ask whether it's actually helped us.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-21 10:37 +0200 |
| Message-ID | <mh525q$mi2$1@dont-email.me> |
| In reply to | #60612 |
On 21/04/15 10:00, Malcolm McLean wrote: > On Tuesday, April 21, 2015 at 8:21:16 AM UTC+1, David Brown wrote: >> On 21/04/15 06:56, Malcolm McLean wrote: >>> You've got to think that you're applying a function to areal problem >> >> If this were a /real/ problem, the /real/ solutions proposed by several >> people long ago would be appropriate (like streaming the data to a file, >> or making a linked list of malloc'ed blocks), taking into account /real/ >> cost functions (rather than your imaginary ones). >> >> If it were a /real/ problem, you wouldn't be using the number of atoms >> in the universe when figuring out the maximum size of an input. >> > You're right, it's not a real problem. It's an invented problem > that bears some relationship to real problems. In reality the linked > list option is the way to go if the constraint genuinely is on > memory take, and the input genuinely is text of unknown size. It bears very little relationship to real problems. In reality, you rarely have such completely unconstrained data sizes (or where the constraint is the size of the universe, if you prefer), with no idea about the distributions. You rarely have an artificial cost model. You rarely have an "enemy". You rarely have artificial constraints (such as your restraints on the allocations and reallocations). This is why, in reality, there is no problem. The obvious solution of allocating in a fixed-size lump that matches input buffer size and/or memory page sizes, and keeping a linked list, is going to be a solid basis for the code. You might want different solutions depending on what you are going to do with the data afterwards, but that would be a different problem. >> >> It is a totally /artificial/ problem. There's nothing wrong with >> artificial problems - that's how much of the theory of algorithms gets >> figured out, and then it can be applied to real problems. But >> artificial problems have artificial answers. I have shown, clearly (I >> hope) and mathematically answers to several of the variants of your >> artificial problems while you change the rules and details in every >> other post. In no case have the answers matched your imagined and >> desired result - and in no case have they been useful answers that could >> be applied in real problems. >> > 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. For the underlying "real" problem, the answer I gave was a linked list. But I think other answers, including stacking the data and writing out to a file, have their merits too. > (I told you that the enemy might send lots of attacks of one byte, > but then I said "he won't do that", because then he costs you > N * first allocation bytes) (or N/2 if you want to nitpick). > So that rules out guessing N if N is high. You change the problem ever other post. If you were a customer, my company would have dropped you long ago. And with the cost functions you have defined, and the global cost function for optimisation (minimum worst case cost), and the possibility that the enemy /does/ send N bytes at the start, then allocating N straight away is optimal. That's the mathematics. It is /fact/. It is /provable/. No amount of hand-waving or weasel-words about N being "high" will change that. If you don't like the answer, find another problem (and specify it this time!) - or find yourself a different universe with different mathematics. It also makes no sense to talk about "if N is high" - "high" in relation to what? If this were a /real/ problem, you could relate "high" to the size of a memory page, network buffer or program stack size. But this is a theoretical problem. A number can't be "high" or "big", it can only be "higher than" or "bigger than". > > He'll send you the biggest message he can, which is one over the > last allocation you make that brings you over his maximum size. > There's no point him sending you any more bytes. > > Then he conserves ammunition. So he sends you another attack with > his remaining data. Which again will be the biggest message he > can send, which is one byte larger than your highest allocation. > > So if we assume the enemy has N bytes, which he can distribute > as he wishes, he doesn't have a better strategy than that, and > it's a problem we can solve. > > We can then ask whether it's actually helped us. > The only thing this has helped is the hole in my wall where I beat my head in frustration at the absurdity of some of the things you write.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-21 01:59 -0700 |
| Message-ID | <7b6b8a7d-328e-41d8-b609-7abbd2363cea@googlegroups.com> |
| In reply to | #60615 |
On Tuesday, April 21, 2015 at 9:37:18 AM UTC+1, David Brown wrote: > On 21/04/15 10:00, Malcolm McLean wrote: > > It bears very little relationship to real problems. In reality, you > rarely have such completely unconstrained data sizes (or where the > constraint is the size of the universe, if you prefer), with no idea > about the distributions. You rarely have an artificial cost model. You > rarely have an "enemy". You rarely have artificial constraints (such as > your restraints on the allocations and reallocations). > > This is why, in reality, there is no problem. The obvious solution of > allocating in a fixed-size lump that matches input buffer size and/or > memory page sizes, and keeping a linked list, is going to be a solid > basis for the code. You might want different solutions depending on > what you are going to do with the data afterwards, but that would be a > different problem. > So we're implementing realloc() ? Isn't that essentially the same problem, admittedly with additional complications due to overhead, fragmentation, memory chunk size and so on? > 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. > No, because your answer was "allocate N bytes, that's the minimum". Fair enough, then the enemy sends you one byte, because he always sends exactly one over the last allocation. But I'd already said "he won't do that" (adopt a strategy of sending his data one byte at a time). You're not really solving the problem. However you can legitimately think "what if we start large?" and so on. But let's start by considering when we start at 1, and grow by a small factor relative to data size. > > It also makes no sense to talk about "if N is high" - "high" in relation > to what? If this were a /real/ problem, you could relate "high" to the > size of a memory page, network buffer or program stack size. But this > is a theoretical problem. A number can't be "high" or "big", it can > only be "higher than" or "bigger than". > N is "the amount of data the enemy can get his hands on". We know he can get a least a million words, because we know that books are readily available of that length. And we know he can't send us more than the concatenation of all English text that exists. But we can't establish how much English text exists. We can establish the order of magnitude of the logarithm of the amount of English language text that exists. So our low estimate of about million words could be more or less right, or it could be wildly wrong, but it can't be totally, out of this world, impossibly wrong. > > The only thing this has helped is the hole in my wall where I beat my > head in frustration at the absurdity of some of the things you write. > It's absurdity. It's a case of flexibility of thought.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-21 12:21 +0200 |
| Message-ID | <mh588i$b74$1@dont-email.me> |
| In reply to | #60616 |
On 21/04/15 10:59, Malcolm McLean wrote: > On Tuesday, April 21, 2015 at 9:37:18 AM UTC+1, David Brown wrote: >> On 21/04/15 10:00, Malcolm McLean wrote: >> >> It bears very little relationship to real problems. In reality, you >> rarely have such completely unconstrained data sizes (or where the >> constraint is the size of the universe, if you prefer), with no idea >> about the distributions. You rarely have an artificial cost model. You >> rarely have an "enemy". You rarely have artificial constraints (such as >> your restraints on the allocations and reallocations). >> >> This is why, in reality, there is no problem. The obvious solution of >> allocating in a fixed-size lump that matches input buffer size and/or >> memory page sizes, and keeping a linked list, is going to be a solid >> basis for the code. You might want different solutions depending on >> what you are going to do with the data afterwards, but that would be a >> different problem. >> > So we're implementing realloc() ? No. > > Isn't that essentially the same problem, admittedly with additional complications > due to overhead, fragmentation, memory chunk size and so on? No. > > >> 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. >> > No, because your answer was "allocate N bytes, that's the minimum". > Fair enough, then the enemy sends you one byte, because he always > sends exactly one over the last allocation. But I'd already said "he won't > do that" (adopt a strategy of sending his data one byte at a time). > You're not really solving the problem. I was solving the problem given. If you want a different answer, give a different problem. > > However you can legitimately think "what if we start large?" and so on. > But let's start by considering when we start at 1, and grow by a small factor > relative to data size. You can think that way if you want. It will give a suboptimal result, as I have proven. Your challenge, if you choose to accept it, is to produce a properly specified optimisation problem for which the optimal answer is an exponential growth with a small factor (ideally phi, but certainly no more than 2). >> >> It also makes no sense to talk about "if N is high" - "high" in relation >> to what? If this were a /real/ problem, you could relate "high" to the >> size of a memory page, network buffer or program stack size. But this >> is a theoretical problem. A number can't be "high" or "big", it can >> only be "higher than" or "bigger than". >> > N is "the amount of data the enemy can get his hands on". We know he can > get a least a million words, because we know that books are readily available > of that length. And we know he can't send us more than the concatenation of > all English text that exists. But we can't establish how much English text > exists. We can establish the order of magnitude of the logarithm of the amount > of English language text that exists. > So our low estimate of about million words could be more or less right, or it could > be wildly wrong, but it can't be totally, out of this world, impossibly wrong. Okay, lets just throw all maths out of the window. When he starts sending text, we allocate 6 MB - enough for about a million words. If that's too little, we abort and claim he cheated and used computer-generated words. Since he can't realistically prove that all the words were written by humans, we win. >> >> The only thing this has helped is the hole in my wall where I beat my >> head in frustration at the absurdity of some of the things you write. >> > It's absurdity. It's a case of flexibility of thought. >
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-21 03:45 -0700 |
| Message-ID | <850b5177-1e4c-40c0-be92-1c2f63f4a7da@googlegroups.com> |
| In reply to | #60625 |
On Tuesday, April 21, 2015 at 11:21:10 AM UTC+1, David Brown wrote: > On 21/04/15 10:59, Malcolm McLean wrote: > > > No, because your answer was "allocate N bytes, that's the minimum". > > Fair enough, then the enemy sends you one byte, because he always > > sends exactly one over the last allocation. But I'd already said "he won't > > do that" (adopt a strategy of sending his data one byte at a time). > > You're not really solving the problem. > > I was solving the problem given. If you want a different answer, give a > different problem. > No, because I specified he always sends 1 byte above your last allocation over N, where N is the number of bytes he has at his disposal. I also specified that if you allocate x bytes, he can break up his message into streams of 1 byte, and charge you N * x, but "that won't be his strategy". So that rules out allocating N. Anyway, you're not doing it properly, because you need to fix the strategy and vary N. So yes, there's an optimum at x = N, but it disappears when N goes to N-1. It's a case of not really understanding. I was trying to lead you to the answer. But I'll give you it. > > > However you can legitimately think "what if we start large?" and so on. > > But let's start by considering when we start at 1, and grow by a small factor > > relative to data size. > > You can think that way if you want. It will give a suboptimal result, > as I have proven. > > Your challenge, if you choose to accept it, is to produce a properly > specified optimisation problem for which the optimal answer is an > exponential growth with a small factor (ideally phi, but certainly no > more than 2). > We know that enemy has a certain number of bytes at his disposal, which he's going to allocate in the way calculated to make us allocate the most memory (summing reallocs). We don't know what it is, but we're expecting at least a million words, because that's the length of the longest book we've seen. But our estimate of N could be way out, by orders of magnitude. But not so far out that its log is out by orders of magnitude. He might have concatenated all English language texts he can lay his hands on and claimed, cheekily, that that's message. However we're expecting he'll play fair, but we can't be sure of that, and we can't exactly quantify it - how can we, how can we put an exact figure on "the probability that the enemy will play fair and not try to make out that a concatenation is a "human-composed English language message"? So we need to test for a massive attack, the biggest physically possible, the expected attack, which is a million words or so, a smaller than expected attack (we've grossly overestimated his determination, or "human-composed messages" means "composed by a human there an then, sitting at his keyboard"), and everything in between.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-21 10:05 +0100 |
| Message-ID | <mh53q7$s0i$1@dont-email.me> |
| In reply to | #60615 |
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! -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| 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]
Page 7 of 16 — ← Prev page 1 … 5 6 [7] 8 9 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web