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 1 of 16 [1] 2 3 … 16 Next page →
| From | G G <gdotone@gmail.com> |
|---|---|
| Date | 2015-04-13 21:19 -0700 |
| Subject | SAFEcode |
| Message-ID | <e8a2658f-49d8-4af1-a6ca-6ec7f686f0b7@googlegroups.com> |
from:
http://safecode.cs.illinois.edu/docs/UsersGuide.html
1 #include "stdio.h"
2 #include "stdlib.h"
3
4 int
5 foo (char * bar) {
6 for (unsigned index = 0; index < 10; ++index)
7 bar[index] = 'a';
8 return 0;
9 }
10
11 int
12 main (int argc, char ** argv) {
13 char * array[100];
14 int max = atoi (argv[1]);
15
16 for (int index = max; index >= 0; --index) {
17 array[index] = malloc (index+1);
18 }
19
20 for (int index = max; index >= 0; --index) {
21 foo (array[index]);
22 }
23
24 exit (0);
25 }
reformatted:
#include "stdio.h"
#include "stdlib.h"
int foo (char * bar)
{
for ( unsigned index = 0; index < 10; ++index )
bar[ index ] = 'a';
return 0;
}
int main( int argc, char **argv )
{
char * array[ 100 ];
int max = atoi( argv[ 1 ] );
for ( int index = max; index >= 0; --index )
{
array[ index ] = malloc( index + 1 );
}
for ( int index = max; index >= 0; --index )
{
foo( array[ index ] );
}
exit (0);
}
the author explains how SAFEcode alerts one the a problem of accessing
memory it should not.
uses ./test 10 so i guess they complied the program as test. then ran it.
as they explain, "Lines 16-18 allocate character arrays of decreasing size,
starting with the argument plus one specified by the user down to an array
of one character. Lines 20-22 then call the function foo() which accesses
elements 0-9 of the array."
please explain what happens when foo is called. i mean at what point is
it accessing space outside it's range?
and ah, why "stdio.h", "stdlib.h" as oppose to <stdio.h>, <stdlih.h>?
is it that they have rewritten those header files and want to use
their own, or it related to where they placed their headers?
thanks everyone,
g.
[toc] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-04-14 17:12 +1200 |
| Message-ID | <cp3ltvF6t8fU1@mid.individual.net> |
| In reply to | #60000 |
G G wrote:
> from:
>
> http://safecode.cs.illinois.edu/docs/UsersGuide.html
>
> 1 #include "stdio.h"
> 2 #include "stdlib.h"
> 3
> 4 int
> 5 foo (char * bar) {
> 6 for (unsigned index = 0; index < 10; ++index)
> 7 bar[index] = 'a';
> 8 return 0;
> 9 }
> 10
> 11 int
> 12 main (int argc, char ** argv) {
> 13 char * array[100];
> 14 int max = atoi (argv[1]);
> 15
> 16 for (int index = max; index >= 0; --index) {
> 17 array[index] = malloc (index+1);
> 18 }
> 19
> 20 for (int index = max; index >= 0; --index) {
> 21 foo (array[index]);
> 22 }
> 23
> 24 exit (0);
> 25 }
>
>
> reformatted:
<snip>
> the author explains how SAFEcode alerts one the a problem of accessing
> memory it should not.
>
> uses ./test 10 so i guess they complied the program as test. then ran it.
>
> as they explain, "Lines 16-18 allocate character arrays of decreasing size,
> starting with the argument plus one specified by the user down to an array
> of one character. Lines 20-22 then call the function foo() which accesses
> elements 0-9 of the array."
>
> please explain what happens when foo is called. i mean at what point is
> it accessing space outside it's range?
None, the behaviour is undefined.
> and ah, why "stdio.h", "stdlib.h" as oppose to <stdio.h>, <stdlih.h>?
> is it that they have rewritten those header files and want to use
> their own, or it related to where they placed their headers?
Bad practice. Same with using atoi().
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-04-14 17:19 +1200 |
| Message-ID | <cp3masF6t8fU2@mid.individual.net> |
| In reply to | #60001 |
Ian Collins wrote: > G G wrote: >> >> please explain what happens when foo is called. i mean at what point is >> it accessing space outside it's range? > > None, the behaviour is undefined. Ah, did you actually read the full page? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-14 00:24 -0500 |
| Message-ID | <mgi8ae$m95$1@speranza.aioe.org> |
| In reply to | #60000 |
On 4/13/15 11:19 PM, G G wrote: > please explain what happens when foo is called. i mean at what point is > it accessing space outside it's range? When foo() is called, it stores 'a' into ten bytes pointed to by bar. If bar points to an allocation smaller than ten bytes then foo() will still attempt to store ten bytes, and storing the final byte(s) will access memory beyond the allocation. The out of range access will happen whenever foo(array[index]) is called with index < 9. > and ah, why "stdio.h", "stdlib.h" as oppose to <stdio.h>, <stdlih.h>? > is it that they have rewritten those header files and want to use > their own, or it related to where they placed their headers? Your guess is as good as any. Ask the prof. -- Morris Dovey http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | G G <gdotone@gmail.com> |
|---|---|
| Date | 2015-04-13 23:45 -0700 |
| Message-ID | <2ab2c903-27e7-470b-a0ae-653c9b08e5d7@googlegroups.com> |
| In reply to | #60003 |
On Tuesday, April 14, 2015 at 1:24:43 AM UTC-4, Morris Dovey wrote: > On 4/13/15 11:19 PM, G G wrote: > When foo() is called, it stores 'a' into ten bytes pointed to by bar. > > If bar points to an allocation smaller than ten bytes then foo() will > still attempt to store ten bytes, and storing the final byte(s) will > access memory beyond the allocation. > > The out of range access will happen whenever foo(array[index]) is called > with index < 9. ah, ok, thanks.
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-04-13 22:30 -0700 |
| Message-ID | <03095ad5-c9a3-409c-8999-ad18ce95c744@googlegroups.com> |
| In reply to | #60000 |
For me many very ugly error would happen in the line that contain "bar[ index ] = 'a';" in the few I know <stdio.h> Search stdio.h file in its sys programming directory where there is the C compiler. Instead "stdio.h" would search the file stdio.h in the directory where there is the program to compile. Possibly they assign to "file.h" one other sys directory it is not the compiler one.
[toc] | [prev] | [next] | [standalone]
| From | Robbie Hatley <see.my.sig@for.my.address> |
|---|---|
| Date | 2015-04-14 00:14 -0700 |
| Message-ID | <c7udnYRQiqfQI7HInZ2dnUVZ572dnZ2d@giganews.com> |
| In reply to | #60000 |
On 4/13/2015 9:19 PM, G G wrote:
> from:
>
> http://safecode.cs.illinois.edu/docs/UsersGuide.html
From that site:
"The SAFECode compiler is a memory safety compiler built using the
LLVM Compiler Infrastructure and the Clang compiler driver.
A memory safety compiler is a compiler that inserts run-time checks
into a program during compilation to catch memory safety errors at
run-time. Such errors can include buffer overflows, invalid frees,
and dangling pointer dereferences."
Given the code below, I'd say such a compiler would be needed!!!
It's anything *but* "safe".
#include "stdio.h"
#include "stdlib.h"
int foo (char * bar)
{
for ( unsigned index = 0; index < 10; ++index )
bar[ index ] = 'a';
return 0;
}
int main( int argc, char **argv )
{
char * array[ 100 ];
int max = atoi( argv[ 1 ] );
for ( int index = max; index >= 0; --index )
{
array[ index ] = malloc( index + 1 );
}
for ( int index = max; index >= 0; --index )
{
foo( array[ index ] );
}
exit (0);
}
Though I dare say a good compiler, with warnings turned on,
should give some warnings at compile-time. Let's find out.
Aragorn@Ketch
/rhe/src/test
%make memory-violation-test.exe
Using pattern rule %.exe:%.c to compile memory-violation-test.c
to memory-violation-test.exe:
gcc -I /rhe/include -Wall -std=c11 -Os -s memory-violation-test.c
-L/rhe/lib -lrh -lfl -ly -lm -o /rhe/bin/test/memory-violation-test.exe
memory-violation-test.exe is up to date.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Aragorn@Ketch
/rhe/src/test
%
Huh. No errors, no warnings. Probably because the character arrays
are allocated at run-time.
OK, how about run-time errors? I'm almost afraid to run this.
Aragorn@Ketch
/rhe/src/test
%memory-violation-test 20
Aragorn@Ketch
/rhe/src/test
%
Great, I just wrote a bunch of copies of the letter 'a' to
some unknown locations on my computer, with no run-time
errors. I feel raped. I think I'll restart my OS now.
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-14 10:33 +0200 |
| Message-ID | <mgijaf$8fg$1@dont-email.me> |
| In reply to | #60006 |
On 14/04/15 09:14, Robbie Hatley wrote:
>
> On 4/13/2015 9:19 PM, G G wrote:
>
>> from:
>>
>> http://safecode.cs.illinois.edu/docs/UsersGuide.html
>
> From that site:
>
> "The SAFECode compiler is a memory safety compiler built using the
> LLVM Compiler Infrastructure and the Clang compiler driver.
> A memory safety compiler is a compiler that inserts run-time checks
> into a program during compilation to catch memory safety errors at
> run-time. Such errors can include buffer overflows, invalid frees,
> and dangling pointer dereferences."
>
> Given the code below, I'd say such a compiler would be needed!!!
> It's anything *but* "safe".
>
> #include "stdio.h"
> #include "stdlib.h"
>
> int foo (char * bar)
> {
> for ( unsigned index = 0; index < 10; ++index )
> bar[ index ] = 'a';
>
> return 0;
> }
>
> int main( int argc, char **argv )
> {
> char * array[ 100 ];
>
> int max = atoi( argv[ 1 ] );
>
> for ( int index = max; index >= 0; --index )
> {
> array[ index ] = malloc( index + 1 );
> }
>
> for ( int index = max; index >= 0; --index )
> {
> foo( array[ index ] );
> }
>
> exit (0);
> }
>
> Though I dare say a good compiler, with warnings turned on,
> should give some warnings at compile-time. Let's find out.
>
>
> Aragorn@Ketch
> /rhe/src/test
> %make memory-violation-test.exe
> Using pattern rule %.exe:%.c to compile memory-violation-test.c
> to memory-violation-test.exe:
> gcc -I /rhe/include -Wall -std=c11 -Os -s memory-violation-test.c
> -L/rhe/lib -lrh -lfl -ly -lm -o /rhe/bin/test/memory-violation-test.exe
> memory-violation-test.exe is up to date.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Aragorn@Ketch
> /rhe/src/test
> %
>
>
> Huh. No errors, no warnings. Probably because the character arrays
> are allocated at run-time.
>
>
> OK, how about run-time errors? I'm almost afraid to run this.
>
>
> Aragorn@Ketch
> /rhe/src/test
> %memory-violation-test 20
>
> Aragorn@Ketch
> /rhe/src/test
> %
>
>
> Great, I just wrote a bunch of copies of the letter 'a' to
> some unknown locations on my computer, with no run-time
> errors. I feel raped. I think I'll restart my OS now.
>
It is common practice for the library to ask the OS for large lumps of
memory, and then malloc divides it up locally (to save using a system
call for every little malloc). So when your program first asks for 20
bytes, the library is probably given a few hundred KB from the OS - your
program can stomp all over that without causing problems for anything
else. And of course you should get a seg fault rather than cause damage
when you go out of those bounds.
#include <stdio.h>
#include <stdlib.h>
int main(void) {
char * p = malloc(1);
for (int i = 0; i < 30; i++) {
int x = 1 << i;
printf("Trying index %d\r\n", x);
p[x] = 123;
}
return 0;
}
Trying index 1
Trying index 2
Trying index 4
Trying index 8
Trying index 16
Trying index 32
Trying index 64
Trying index 128
Trying index 256
Trying index 512
Trying index 1024
Trying index 2048
Trying index 4096
Trying index 8192
Trying index 16384
Trying index 32768
Trying index 65536
Trying index 131072
Trying index 262144
Segmentation fault (core dumped)
(64-bit Linux)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-14 02:01 -0700 |
| Message-ID | <726b3d86-0074-4f28-9968-c75a36870a15@googlegroups.com> |
| In reply to | #60012 |
On Tuesday, April 14, 2015 at 9:33:22 AM UTC+1, David Brown wrote:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(void) {
> char * p = malloc(1);
>
> for (int i = 0; i < 30; i++) {
> int x = 1 << i;
> printf("Trying index %d\r\n", x);
> p[x] = 123;
> }
> return 0;
> }
>
> Trying index 1
> Trying index 2
> Trying index 4
> Trying index 8
> Trying index 16
> Trying index 32
> Trying index 64
> Trying index 128
> Trying index 256
> Trying index 512
> Trying index 1024
> Trying index 2048
> Trying index 4096
> Trying index 8192
> Trying index 16384
> Trying index 32768
> Trying index 65536
> Trying index 131072
> Trying index 262144
> Segmentation fault (core dumped)
>
When doing searching, it's best to use the Golden Ratio (1.618). We know that x is greater
than our test, tx. But whilst we've got some idea of the process that generates x, we don't
know whether it is arithmetical or geometrical - x could be growing 1, 2, 3 ... or 1, 2, 4 ...
(however it's not something that's stupidly huge, such that we'll never get x in a month of
Sundays by searching logarithmically).
Phi is the compromise between exponential and arithmetical growth,
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-14 10:23 +0100 |
| Message-ID | <mgim8c$ih3$1@dont-email.me> |
| In reply to | #60015 |
On 14/04/2015 10:01, Malcolm McLean wrote: > On Tuesday, April 14, 2015 at 9:33:22 AM UTC+1, David Brown wrote: >> Trying index 1 >> Trying index 2 >> Trying index 4 >> Trying index 8 >> Trying index 16 >> Trying index 32 >> Trying index 64 >> Trying index 128 >> Trying index 256 >> Trying index 512 >> Trying index 1024 >> Trying index 2048 >> Trying index 4096 >> Trying index 8192 >> Trying index 16384 >> Trying index 32768 >> Trying index 65536 >> Trying index 131072 >> Trying index 262144 >> Segmentation fault (core dumped) >> > When doing searching, it's best to use the Golden Ratio (1.618). We know that x is greater > than our test, tx. But whilst we've got some idea of the process that generates x, we don't > know whether it is arithmetical or geometrical - x could be growing 1, 2, 3 ... or 1, 2, 4 ... > (however it's not something that's stupidly huge, such that we'll never get x in a month of > Sundays by searching logarithmically). > Phi is the compromise between exponential and arithmetical growth, In other words, you've finally found a use for a Fibonacci sequence. Instead of x = 1,2,3,4,5... or 1,2,4,8,16,..., you do (1),1,2,3,5,8,.... -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-14 11:49 +0200 |
| Message-ID | <mginqe$nri$1@dont-email.me> |
| In reply to | #60015 |
On 14/04/15 11:01, Malcolm McLean wrote:
> On Tuesday, April 14, 2015 at 9:33:22 AM UTC+1, David Brown wrote:
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main(void) {
>> char * p = malloc(1);
>>
>> for (int i = 0; i < 30; i++) {
>> int x = 1 << i;
>> printf("Trying index %d\r\n", x);
>> p[x] = 123;
>> }
>> return 0;
>> }
>>
>> Trying index 1
>> Trying index 2
>> Trying index 4
>> Trying index 8
>> Trying index 16
>> Trying index 32
>> Trying index 64
>> Trying index 128
>> Trying index 256
>> Trying index 512
>> Trying index 1024
>> Trying index 2048
>> Trying index 4096
>> Trying index 8192
>> Trying index 16384
>> Trying index 32768
>> Trying index 65536
>> Trying index 131072
>> Trying index 262144
>> Segmentation fault (core dumped)
>>
> When doing searching, it's best to use the Golden Ratio (1.618). We know that x is greater
> than our test, tx. But whilst we've got some idea of the process that generates x, we don't
> know whether it is arithmetical or geometrical - x could be growing 1, 2, 3 ... or 1, 2, 4 ...
> (however it's not something that's stupidly huge, such that we'll never get x in a month of
> Sundays by searching logarithmically).
> Phi is the compromise between exponential and arithmetical growth,
>
Using the golden ratio here is exponential growth - it is not a
"compromise between exponential and arithmetical growth".
You could argue that it is a convenient way to get an exponential growth
that is lower than powers of 2 while still being possible to calculate
with easy integer arithmetic. And while there are some algorithms that
have best amortized performance when using Fibonacci numbers (such as
the Fibonacci heap for priority queues - or perhaps when choosing the
size of lumps for malloc to request from the OS memory manager), it is a
very big stretch to generalise that to saying the Golden Ratio is /the/
best choice for searching.
In this case, powers of two is clearly the best choice for searching
since we are merely looking for an indication of the scale of the value,
using a simple and quick program.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-14 04:31 -0700 |
| Message-ID | <2a853a94-7471-48e8-ad4f-2d3e16c6421d@googlegroups.com> |
| In reply to | #60018 |
On Tuesday, April 14, 2015 at 10:50:09 AM UTC+1, David Brown wrote: > > You could argue that it is a convenient way to get an exponential growth > that is lower than powers of 2 while still being possible to calculate > with easy integer arithmetic. And while there are some algorithms that > have best amortized performance when using Fibonacci numbers (such as > the Fibonacci heap for priority queues - or perhaps when choosing the > size of lumps for malloc to request from the OS memory manager), it is a > very big stretch to generalise that to saying the Golden Ratio is /the/ > best choice for searching. > It's the accepted way of searching for a minimum along a continuous function of a continuous variable, when you can't easily characterise the function other that to say x is not so large that exponential growth will never reach it in reasonable time. > > In this case, powers of two is clearly the best choice for searching > since we are merely looking for an indication of the scale of the value, > using a simple and quick program. > Actually powers of two are about the worst choice, if you've reason to believe that the answer might be either exactly a power of two or one minus a power of two. It's also a bad choice for growing a buffer - which is a very similar problem - largely because the growth is too aggressive. You can grow by length + length/2, which isn't quite the golden ratio but close enough to stretch a point. I think the golden ratio has some deeper mathematical properties which make it a good choice, but I've got to confess that I don't know them off pat.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-14 14:54 +0200 |
| Message-ID | <mgj2kp$2he$1@dont-email.me> |
| In reply to | #60022 |
On 14/04/15 13:31, Malcolm McLean wrote: > On Tuesday, April 14, 2015 at 10:50:09 AM UTC+1, David Brown wrote: And I assume you agree that you were completely wrong about Fibonacci numbers being anything other than exponential growth. It would be nice if you didn't keep snipping your mistakes - admitting that you are wrong (or providing justification for why you are not) is common courtesy. >> >> You could argue that it is a convenient way to get an exponential growth >> that is lower than powers of 2 while still being possible to calculate >> with easy integer arithmetic. And while there are some algorithms that >> have best amortized performance when using Fibonacci numbers (such as >> the Fibonacci heap for priority queues - or perhaps when choosing the >> size of lumps for malloc to request from the OS memory manager), it is a >> very big stretch to generalise that to saying the Golden Ratio is /the/ >> best choice for searching. >> > It's the accepted way of searching for a minimum along a continuous function of > a continuous variable, when you can't easily characterise the function other > that to say x is not so large that exponential growth will never reach it in reasonable > time. It is not /the/ accepted way - merely /an/ accepted way. For some types of searching problems, it is useful (or even theoretically optimal). But that does not mean it is always the best way, no matter what your definition of "best" happens to be. >> >> In this case, powers of two is clearly the best choice for searching >> since we are merely looking for an indication of the scale of the value, >> using a simple and quick program. >> > Actually powers of two are about the worst choice, if you've reason to believe that > the answer might be either exactly a power of two or one minus a power of two. If I had been trying to find an exact value, then I agree that a power of two would have been a poor choice - at least, when used like this. But that was not the aim of the code. Re-read my paragraph above, and perhaps you will understand. (If I had wanted an exact value, I would have looked it up online in the glibc documentation.) > It's also a bad choice for growing a buffer - which is a very similar problem - > largely because the growth is too aggressive. You can grow by length + length/2, > which isn't quite the golden ratio but close enough to stretch a point. There are situations when an exponential growth factor of 2 is too aggressive - and situations when it is not aggressive enough, and a factor of 10 might be a better choice. For small values, factors of 1.5 or sqrt(2) are also popular. > I think the golden ratio has some deeper mathematical properties which make it > a good choice, but I've got to confess that I don't know them off pat. > For some types of uses, it has theoretically optimal amortized behaviour. But that is only for some uses - and its use must be balanced against additional complexity compared to choices that may be simpler to implement (such as growing by 1.5) or may have additional efficiencies (it may be more efficient to allocate memory in powers of 2 rather than powers of phi). This is why it is wrong to say powers of phi is /the/ best choice or /the/ accepted value - the best way to grow a value will depend on the circumstances and the requirements.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-14 06:39 -0700 |
| Message-ID | <4964f920-9e9b-44d1-a8c5-125462c8192e@googlegroups.com> |
| In reply to | #60027 |
On Tuesday, April 14, 2015 at 1:54:52 PM UTC+1, David Brown wrote: > > And I assume you agree that you were completely wrong about Fibonacci > numbers being anything other than exponential growth. It would be nice > if you didn't keep snipping your mistakes - admitting that you are wrong > (or providing justification for why you are not) is common courtesy. > The base exponential function is e^x. The base arithmetical function is of course x + 1. The series phi^-1, 1, phi, phi^2 is a kind of midpoint between the two series. Say we want to find x for which f(x) is zero. We know that x is N steps away from unity, and we know than N is less than, say, 100. But we don't know if the function is x - N or ln(x) - N. We can't plot it, all we can do is call f(x) and see if it is positive or negative. So what's our optimal strategy? (I'm sure sure it's a golden section search, I think it is on the basis of reading, but I haven't actually tried to prove it from first principles). > > It is not /the/ accepted way - merely /an/ accepted way. For some types > of searching problems, it is useful (or even theoretically optimal). > But that does not mean it is always the best way, no matter what your > definition of "best" happens to be. > > This is why it is wrong to say powers of phi is /the/ best choice or > /the/ accepted value - the best way to grow a value will depend on the > circumstances and the requirements. > it won't always be the best way. For example if f(x) is tetration then a golden section search won't be optimal. But we live a world of three levels of recursion.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-14 16:10 +0200 |
| Message-ID | <mgj72b$jop$1@dont-email.me> |
| In reply to | #60031 |
On 14/04/15 15:39, Malcolm McLean wrote: > On Tuesday, April 14, 2015 at 1:54:52 PM UTC+1, David Brown wrote: >> >> And I assume you agree that you were completely wrong about Fibonacci >> numbers being anything other than exponential growth. It would be nice >> if you didn't keep snipping your mistakes - admitting that you are wrong >> (or providing justification for why you are not) is common courtesy. >> > The base exponential function is e^x. The base arithmetical function is of course > x + 1. The series phi^-1, 1, phi, phi^2 is a kind of midpoint between the two > series. No. The series 1, phi, phi^2, etc., is exponential. The base (phi in this case) gives the speed of growth, but it is exponential growth regardless of the base. phi^x is just e^(ln(phi) * x) . The base is just a scale factor in the x direction. > Say we want to find x for which f(x) is zero. We know that x is N steps away > from unity, and we know than N is less than, say, 100. But we don't know if > the function is x - N or ln(x) - N. We can't plot it, all we can do is call f(x) and see > if it is positive or negative. > So what's our optimal strategy? If you know nothing about f(x), then a linear search is optimal - there is no reason for expecting to find the 0 any faster with any other method (it is like searching an unsorted list). If you know f(x) is monotone, then a binary search is optimal (like searching a sorted list). > > (I'm sure sure it's a golden section search, I think it is on the basis of reading, but > I haven't actually tried to prove it from first principles). The golden section search is something different, and can be useful for finding the extrema of certain types of function. It does not work by using powers of phi. I recommend reading the Wikipedia article, to see how it does not apply here. >> >> It is not /the/ accepted way - merely /an/ accepted way. For some types >> of searching problems, it is useful (or even theoretically optimal). >> But that does not mean it is always the best way, no matter what your >> definition of "best" happens to be. >> >> This is why it is wrong to say powers of phi is /the/ best choice or >> /the/ accepted value - the best way to grow a value will depend on the >> circumstances and the requirements. >> > it won't always be the best way. For example if f(x) is tetration then a golden section > search won't be optimal. But we live a world of three levels of recursion. >
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-14 08:11 -0700 |
| Message-ID | <1f68d75f-0f30-4084-9aa3-c439c7667306@googlegroups.com> |
| In reply to | #60032 |
On Tuesday, April 14, 2015 at 3:10:29 PM UTC+1, David Brown wrote: > > If you know f(x) is monotone, then a binary search is optimal (like > searching a sorted list). > That's only the case if you know the maximum value, and you've reason to believe that the probability distribution for the answer is uniform. Which is the case if you know the target is an entry in a sorted list. But that's information you've supplied. In my problem (I'm not sure I've set it up rigorously, but it basically reflects real situations where we know f(x) represents some biological process, but we don't really know anything else about it), we know that our answer has a probability density function which is somewhere between uniform and somewhere between an exponential decay in e^x.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-14 23:58 +0200 |
| Message-ID | <mgk2h0$2j4$1@dont-email.me> |
| In reply to | #60039 |
On 14/04/15 17:11, Malcolm McLean wrote: > On Tuesday, April 14, 2015 at 3:10:29 PM UTC+1, David Brown wrote: >> Again, I have to assume that you agree with all my other points - but I would prefer if you were explicit. >> If you know f(x) is monotone, then a binary search is optimal (like >> searching a sorted list). >> > That's only the case if you know the maximum value, and you've reason to believe > that the probability distribution for the answer is uniform. Which is the case if you > know the target is an entry in a sorted list. But that's information you've supplied. As I said, "if you know f(x) is monotone, then a binary search is optimal (like searching a sorted list)". Perhaps I should have specified that you know f(x) is monotone, but know nothing else about it? > > In my problem (I'm not sure I've set it up rigorously, but it basically reflects real > situations where we know f(x) represents some biological process, but we don't > really know anything else about it), we know that our answer has a probability > density function which is somewhere between uniform and somewhere between > an exponential decay in e^x. > Your description doesn't really make sense, but in general if you know more about a function or its distribution, then of course you can pick better ways to divide up your search (for maximum, minimum, or specific values).
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-15 01:25 -0700 |
| Message-ID | <78d03d4e-8eb2-4265-b734-0a6aee1a8b20@googlegroups.com> |
| In reply to | #60062 |
On Tuesday, April 14, 2015 at 10:59:03 PM UTC+1, David Brown wrote: > On 14/04/15 17:11, Malcolm McLean wrote: > > As I said, "if you know f(x) is monotone, then a binary search is > optimal (like searching a sorted list)". Perhaps I should have > specified that you know f(x) is monotone, but know nothing else about it? > You know that n represents the number of steps in a physical process. Almost everything, but not absolutely everything, clusters towards low values. The likely distributions are top hat (n goes from 0 to a constant, and each step adds an increment, gaussian (n is usually constant and low, but each step adds a uniform number, the entire system constrained to be above zero, log gaussian (each step creates a factor which multiplies), broken stick (you get this distribution by taking a stick, breaking it in random places, then taking a distribution of the length of the fragments). There are others, but they all have the characteristic that negative values are impossible (typical of physical processes), and as we go towards infinity the probability density function goes to zero, So if you've got two constraints, zero and a sanity test or an inherent limit (e.g. the size of a fish is limited by the volume of the ocean), then a uniform distribution between zero and your limit, whilst not impossible, is unlikely. > > Your description doesn't really make sense, but in general if you know > more about a function or its distribution, then of course you can pick > better ways to divide up your search (for maximum, minimum, or specific > values). > Exactly. We're back to our previous discussion. Data means something. You're not shuffling about random bits, at least usually. You're taking measurements or observations or simulations of something in the world outside the computer.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-15 11:11 +0200 |
| Message-ID | <mgl9u5$elt$1@dont-email.me> |
| In reply to | #60074 |
On 15/04/15 10:25, Malcolm McLean wrote: > On Tuesday, April 14, 2015 at 10:59:03 PM UTC+1, David Brown wrote: >> On 14/04/15 17:11, Malcolm McLean wrote: >> >> As I said, "if you know f(x) is monotone, then a binary search is >> optimal (like searching a sorted list)". Perhaps I should have >> specified that you know f(x) is monotone, but know nothing else about it? >> > You know that n represents the number of steps in a physical process. > Almost everything, but not absolutely everything, clusters towards > low values. The likely distributions are top hat (n goes from 0 to > a constant, and each step adds an increment, gaussian > (n is usually constant and low, but each step adds a uniform number, > the entire system constrained to be above zero, log gaussian (each > step creates a factor which multiplies), broken stick (you get this > distribution by taking a stick, breaking it in random places, then > taking a distribution of the length of the fragments). There are others, > but they all have the characteristic that negative values are > impossible (typical of physical processes), and as we go towards infinity > the probability density function goes to zero, > > So if you've got two constraints, zero and a sanity test or an > inherent limit (e.g. the size of a fish is limited by the volume > of the ocean), then a uniform distribution between zero and > your limit, whilst not impossible, is unlikely. >> >> Your description doesn't really make sense, but in general if you know >> more about a function or its distribution, then of course you can pick >> better ways to divide up your search (for maximum, minimum, or specific >> values). >> > Exactly. We're back to our previous discussion. > Data means something. You're not shuffling about random bits, at least > usually. You're taking measurements or observations or simulations > of something in the world outside the computer. > I'm sorry, but I am going to have to stop replying to you in this thread. The /world/ may not shuffle around random bits, but /you/ certainly do. You leap randomly between talking about invented meaningless functions, distributions we know /nothing/ about, and distributions that we know /something/ about (but you vary what that "something" might be). You make totally incorrect mathematical claims (like "powers of phi is something between exponential and linear"), and totally incorrect programming claims (like "golden section search" is /the/ best approach). And every time you are challenged or shown to be wrong, you ignore the comment and jump off at a new tangent. It is just getting too tedious and painful explaining the same things repeatedly to someone who is convinced that he already knows everything.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-15 02:35 -0700 |
| Message-ID | <3cc4cf1e-0a4f-49d0-be24-a07294d2f488@googlegroups.com> |
| In reply to | #60076 |
On Wednesday, April 15, 2015 at 10:11:36 AM UTC+1, David Brown wrote: > On 15/04/15 10:25, Malcolm McLean wrote: > > On Tuesday, April 14, 2015 at 10:59:03 PM UTC+1, David Brown wrote: > >> On 14/04/15 17:11, Malcolm McLean wrote: > >> > >> As I said, "if you know f(x) is monotone, then a binary search is > >> optimal (like searching a sorted list)". Perhaps I should have > >> specified that you know f(x) is monotone, but know nothing else about it? > >> > > You know that n represents the number of steps in a physical process. > > Almost everything, but not absolutely everything, clusters towards > > low values. The likely distributions are top hat (n goes from 0 to > > a constant, and each step adds an increment, gaussian > > (n is usually constant and low, but each step adds a uniform number, > > the entire system constrained to be above zero, log gaussian (each > > step creates a factor which multiplies), broken stick (you get this > > distribution by taking a stick, breaking it in random places, then > > taking a distribution of the length of the fragments). There are others, > > but they all have the characteristic that negative values are > > impossible (typical of physical processes), and as we go towards infinity > > the probability density function goes to zero, > > > > So if you've got two constraints, zero and a sanity test or an > > inherent limit (e.g. the size of a fish is limited by the volume > > of the ocean), then a uniform distribution between zero and > > your limit, whilst not impossible, is unlikely. > >> > >> Your description doesn't really make sense, but in general if you know > >> more about a function or its distribution, then of course you can pick > >> better ways to divide up your search (for maximum, minimum, or specific > >> values). > >> > > Exactly. We're back to our previous discussion. > > Data means something. You're not shuffling about random bits, at least > > usually. You're taking measurements or observations or simulations > > of something in the world outside the computer. > > > > I'm sorry, but I am going to have to stop replying to you in this > thread. The /world/ may not shuffle around random bits, but /you/ > certainly do. You leap randomly between talking about invented > meaningless functions, distributions we know /nothing/ about, and > distributions that we know /something/ about (but you vary what that > "something" might be). You make totally incorrect mathematical claims > (like "powers of phi is something between exponential and linear"), and > totally incorrect programming claims (like "golden section search" is > /the/ best approach). And every time you are challenged or shown to be > wrong, you ignore the comment and jump off at a new tangent. > > It is just getting too tedious and painful explaining the same things > repeatedly to someone who is convinced that he already knows everything. > It's really very basic. If I say "we're trying to minimise a function we know nothing about", and you interpret "nothing" in the most literal way possible, then there's an infinite number of possible functions, and you're left with some rarefied branch of set theory. But if you interpret "nothing" as meaning, "I know a few basics, such as that I can represent the values adequately using my programming language, such as that the function represents something in the real world, but essentially I'm dealing with an unknown function" then you're out of the rarefied branch of mathematical set theory, and you can make a few common sense observations that require a little bit of mathematical insight, but no special training. Fish size is limited at one extreme by zero, at another by the volume of the ocean. So that gives us two limits. But a fish is likely to be closer to the lower limit than the upper. Replace fish by tree and replace "size of the ocean" by "height of earth's atmosphere" and you've got the same issue. Replace tree by salary and "height of the earth's atmosphere" by 'total world gross GDP" and you've got the same issue. Replace salary by "star" and "total world GDP" with "so massive that light can't escape" and what? Well I'm not an astrophysicist. Maybe we've got an exception here. Maybe there are a lot of stars just on the cusp of becoming black holes. So we need to be aware that we've got to support the upper limit. It's a case of making the leap from naive literalism "you can't minimise a golf course function" "well you can, here's a program that minimises Bart's function" to a more flexible, more mature, more informed way of talking and of thinking.
[toc] | [prev] | [next] | [standalone]
Page 1 of 16 [1] 2 3 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web