Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #10412 > unrolled thread
| Started by | jacob navia <jacob@spamsink.net> |
|---|---|
| First post | 2011-09-18 00:29 +0200 |
| Last post | 2011-09-20 00:22 -0700 |
| Articles | 20 on this page of 284 — 42 participants |
Back to article view | Back to comp.lang.c
Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-18 00:29 +0200
Re: Testing if a pointer is valid Harald van Dijk <truedfx@gmail.com> - 2011-09-17 15:38 -0700
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-18 00:57 +0200
Re: Testing if a pointer is valid Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-18 16:30 +0000
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-18 19:25 +0200
Re: Testing if a pointer is valid Ian Collins <ian-news@hotmail.com> - 2011-09-19 07:53 +1200
Re: Testing if a pointer is valid Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-18 20:00 +0000
Re: Testing if a pointer is valid Ian Collins <ian-news@hotmail.com> - 2011-09-19 08:23 +1200
Re: Testing if a pointer is valid Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-18 20:32 +0000
Re: Testing if a pointer is valid cri@tiac.net (Richard Harter) - 2011-09-18 23:28 +0000
Re: Testing if a pointer is valid blp@cs.stanford.edu (Ben Pfaff) - 2011-09-18 16:38 -0700
Re: Testing if a pointer is valid cri@tiac.net (Richard Harter) - 2011-09-19 04:27 +0000
Re: Testing if a pointer is valid blp@cs.stanford.edu (Ben Pfaff) - 2011-09-18 21:48 -0700
Re: Testing if a pointer is valid cri@tiac.net (Richard Harter) - 2011-09-19 05:38 +0000
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-19 09:14 +0200
Re: Testing if a pointer is valid "BartC" <bc@freeuk.com> - 2011-09-19 10:10 +0100
Re: Testing if a pointer is valid Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-19 05:07 -0700
Re: Testing if a pointer is valid Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-19 14:24 +0100
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-19 16:10 +0200
Re: Testing if a pointer is valid "BartC" <bc@freeuk.com> - 2011-09-19 16:50 +0100
Re: Testing if a pointer is valid Ben Pfaff <blp@cs.stanford.edu> - 2011-09-19 08:11 -0700
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-19 17:21 +0200
Re: Testing if a pointer is valid "BartC" <bc@freeuk.com> - 2011-09-19 16:27 +0100
Re: Testing if a pointer is valid Keith Thompson <kst-u@mib.org> - 2011-09-19 10:14 -0700
Re: Testing if a pointer is valid "BartC" <bc@freeuk.com> - 2011-09-19 19:56 +0100
Re: Testing if a pointer is valid blp@cs.stanford.edu (Ben Pfaff) - 2011-09-19 13:20 -0700
Re: Testing if a pointer is valid Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-20 18:31 +0300
Re: Testing if a pointer is valid "BartC" <bc@freeuk.com> - 2011-09-20 17:44 +0100
Re: Testing if a pointer is valid Keith Thompson <kst-u@mib.org> - 2011-09-20 17:06 -0700
Re: Testing if a pointer is valid "BartC" <bc@freeuk.com> - 2011-09-21 01:37 +0100
Re: Testing if a pointer is valid Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-22 22:03 +0300
Re: Testing if a pointer is valid Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-28 02:33 -0700
Re: Testing if a pointer is valid ImpalerCore <jadill33@gmail.com> - 2011-09-19 13:01 -0700
Re: Testing if a pointer is valid ImpalerCore <jadill33@gmail.com> - 2011-09-19 14:42 -0700
Re: Testing if a pointer is valid Ian Collins <ian-news@hotmail.com> - 2011-09-20 10:08 +1200
Re: Testing if a pointer is valid ImpalerCore <jadill33@gmail.com> - 2011-09-20 07:55 -0700
Re: Testing if a pointer is valid cri@tiac.net (Richard Harter) - 2011-09-19 16:39 +0000
Re: Testing if a pointer is valid blp@cs.stanford.edu (Ben Pfaff) - 2011-09-19 09:48 -0700
Re: Testing if a pointer is valid ImpalerCore <jadill33@gmail.com> - 2011-09-19 12:49 -0700
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-19 22:45 +0200
Re: Testing if a pointer is valid ImpalerCore <jadill33@gmail.com> - 2011-09-19 14:02 -0700
Re: Testing if a pointer is valid Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-19 07:14 +0000
Re: Testing if a pointer is valid cri@tiac.net (Richard Harter) - 2011-09-19 16:13 +0000
Re: Testing if a pointer is valid Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-19 17:36 +0000
Re: Testing if a pointer is valid cri@tiac.net (Richard Harter) - 2011-09-19 20:09 +0000
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-19 20:36 +0200
Re: Testing if a pointer is valid Ian Collins <ian-news@hotmail.com> - 2011-09-20 08:05 +1200
Re: Testing if a pointer is valid cri@tiac.net (Richard Harter) - 2011-09-19 20:18 +0000
Re: Testing if a pointer is valid Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-19 23:37 +0000
Re: Testing if a pointer is valid Kenneth Brody <kenbrody@spamcop.net> - 2011-09-21 12:23 -0400
Re: Testing if a pointer is valid Kenneth Brody <kenbrody@spamcop.net> - 2011-09-21 12:09 -0400
Re: Testing if a pointer is valid websnarf <websnarf@gmail.com> - 2011-09-26 22:01 -0700
Re: Testing if a pointer is valid Kenneth Brody <kenbrody@spamcop.net> - 2011-09-19 13:51 -0400
Re: Testing if a pointer is valid cri@tiac.net (Richard Harter) - 2011-09-19 20:11 +0000
Re: Testing if a pointer is valid Nobody <nobody@nowhere.com> - 2011-09-19 22:21 +0100
Re: Testing if a pointer is valid cri@tiac.net (Richard Harter) - 2011-09-20 00:05 +0000
Re: Testing if a pointer is valid Nobody <nobody@nowhere.com> - 2011-09-18 23:34 +0100
Re: Testing if a pointer is valid pacman@kosh.dhis.org (Alan Curry) - 2011-09-18 22:47 +0000
Re: Testing if a pointer is valid tom st denis <tom@iahu.ca> - 2011-09-19 04:50 -0700
Re: Testing if a pointer is valid Kenneth Brody <kenbrody@spamcop.net> - 2011-09-19 13:42 -0400
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-19 20:30 +0200
Re: Testing if a pointer is valid Ian Collins <ian-news@hotmail.com> - 2011-09-20 08:09 +1200
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-19 22:38 +0200
Re: Testing if a pointer is valid Ike Naar <ike@iceland.freeshell.org> - 2011-09-19 20:50 +0000
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-19 22:53 +0200
Re: Testing if a pointer is valid Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-19 22:30 +0100
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-20 00:05 +0200
Re: Testing if a pointer is valid Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-20 00:31 +0100
Re: Testing if a pointer is valid Ike Naar <ike@iceland.freeshell.org> - 2011-09-19 22:43 +0000
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-20 00:59 +0200
Re: Testing if a pointer is valid Ian Collins <ian-news@hotmail.com> - 2011-09-20 11:50 +1200
Re: Testing if a pointer is valid blp@cs.stanford.edu (Ben Pfaff) - 2011-09-19 19:03 -0700
Re: Testing if a pointer is valid Ian Collins <ian-news@hotmail.com> - 2011-09-20 14:11 +1200
Re: Testing if a pointer is valid Keith Thompson <kst-u@mib.org> - 2011-09-19 21:49 -0700
Re: Testing if a pointer is valid Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-28 06:17 -0700
Re: Testing if a pointer is valid Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-28 07:02 -0700
Re: Testing if a pointer is valid Ike Naar <ike@sverige.freeshell.org> - 2011-09-20 07:26 +0000
Re: Testing if a pointer is valid Kenneth Brody <kenbrody@spamcop.net> - 2011-09-21 12:31 -0400
Re: Testing if a pointer is valid Kenneth Brody <kenbrody@spamcop.net> - 2011-09-21 12:26 -0400
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-21 21:20 +0200
Re: Testing if a pointer is valid Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-21 19:40 +0000
Re: Testing if a pointer is valid Ian Collins <ian-news@hotmail.com> - 2011-09-22 07:46 +1200
Re: Testing if a pointer is valid "Rosario Pulvirenti" <NoInUseno1Spam@non.usare.invalid> - 2011-09-22 07:38 +0200
Re: Testing if a pointer is valid Ian Collins <ian-news@hotmail.com> - 2011-09-20 09:05 +1200
Re: Testing if a pointer is valid Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-20 07:16 +0000
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-20 09:50 +0200
Re: Testing if a pointer is valid Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-20 10:38 +0000
Re: Testing if a pointer is valid Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-20 04:29 -0700
Re: Testing if a pointer is valid Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-20 12:04 +0000
Re: Testing if a pointer is valid Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-20 05:25 -0700
Re: Testing if a pointer is valid Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-20 16:49 +0000
Re: Testing if a pointer is valid Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-22 22:35 +0300
Re: Testing if a pointer is valid Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-23 07:59 +0000
Re: Testing if a pointer is valid Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-23 12:33 +0300
Re: Testing if a pointer is valid Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-23 12:23 +0000
Re: Testing if a pointer is valid Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-23 17:34 +0300
Re: Testing if a pointer is valid Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-23 17:08 +0000
Re: Testing if a pointer is valid James Kuyper <jameskuyper@verizon.net> - 2011-09-23 06:49 -0400
Re: Testing if a pointer is valid Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-23 12:20 +0000
Re: Testing if a pointer is valid Seebs <usenet-nospam@seebs.net> - 2011-09-26 22:59 +0000
Re: Testing if a pointer is valid Michael Press <rubrum@pacbell.net> - 2011-09-30 01:27 -0700
Re: Testing if a pointer is valid Willem <willem@toad.stack.nl> - 2011-09-30 08:38 +0000
Re: Testing if a pointer is valid Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-10-04 12:40 +0000
Re: Testing if a pointer is valid Kenneth Brody <kenbrody@spamcop.net> - 2011-09-21 12:00 -0400
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-21 21:17 +0200
Re: Testing if a pointer is valid cri@tiac.net (Richard Harter) - 2011-09-18 23:21 +0000
Re: Testing if a pointer is valid Keith Thompson <kst-u@mib.org> - 2011-09-18 17:32 -0700
Re: Testing if a pointer is valid Joe Wright <joewwright@comcast.net> - 2011-09-18 23:10 -0400
Re: Testing if a pointer is valid gazelle@shell.xmission.com (Kenny McCormack) - 2011-09-19 03:34 +0000
Re: Testing if a pointer is valid Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-09-18 22:32 -0600
Re: Testing if a pointer is valid gazelle@shell.xmission.com (Kenny McCormack) - 2011-09-20 14:18 +0000
Re: Testing if a pointer is valid August Karlstrom <fusionfile@gmail.com> - 2011-09-20 18:15 +0200
Re: Testing if a pointer is valid "BartC" <bc@freeuk.com> - 2011-09-20 17:49 +0100
Re: Testing if a pointer is valid Willem <willem@toad.stack.nl> - 2011-09-20 17:02 +0000
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-20 20:35 +0200
Re: Testing if a pointer is valid Ike Naar <ike@iceland.freeshell.org> - 2011-09-20 20:30 +0000
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-20 22:35 +0200
Re: Testing if a pointer is valid Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-22 22:07 +0300
Re: Testing if a pointer is valid James Kuyper <jameskuyper@verizon.net> - 2011-09-22 16:11 -0400
Re: Testing if a pointer is valid Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-23 12:28 +0300
Re: Testing if a pointer is valid James Kuyper <jameskuyper@verizon.net> - 2011-09-23 06:44 -0400
Re: Testing if a pointer is valid Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-23 17:33 +0300
Re: Testing if a pointer is valid James Kuyper <jameskuyper@verizon.net> - 2011-09-23 11:31 -0400
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-23 20:09 +0200
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-23 20:02 +0200
Re: Testing if a pointer is valid Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-23 13:49 -0700
Re: Testing if a pointer is valid Ian Collins <ian-news@hotmail.com> - 2011-09-24 09:01 +1200
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-23 23:08 +0200
Re: Testing if a pointer is valid Ian Collins <ian-news@hotmail.com> - 2011-09-24 09:43 +1200
Re: Testing if a pointer is valid Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-23 22:13 +0100
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-23 23:45 +0200
Re: Testing if a pointer is valid Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-24 00:01 +0100
Re: Testing if a pointer is valid Ian Collins <ian-news@hotmail.com> - 2011-09-24 09:47 +1200
Re: Testing if a pointer is valid James Kuyper <jameskuyper@verizon.net> - 2011-09-23 17:22 -0400
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-23 23:47 +0200
Re: Testing if a pointer is valid Ian Collins <ian-news@hotmail.com> - 2011-09-24 09:50 +1200
Re: Testing if a pointer is valid James Kuyper <jameskuyper@verizon.net> - 2011-09-23 18:06 -0400
Re: Testing if a pointer is valid Ian Collins <ian-news@hotmail.com> - 2011-09-24 10:25 +1200
Re: Testing if a pointer is valid James Kuyper <jameskuyper@verizon.net> - 2011-09-24 08:02 -0400
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-24 14:13 +0200
Re: Testing if a pointer is valid Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-24 14:07 +0100
Re: Testing if a pointer is valid cri@tiac.net (Richard Harter) - 2011-09-24 13:15 +0000
Re: Testing if a pointer is valid Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-24 15:20 +0100
Re: Testing if a pointer is valid James Kuyper <jameskuyper@verizon.net> - 2011-09-24 11:28 -0400
Re: Testing if a pointer is valid Willem <willem@toad.stack.nl> - 2011-09-24 15:45 +0000
Re: Testing if a pointer is valid Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-24 20:07 +0300
Re: Testing if a pointer is valid Richard Damon <news.x.richarddamon@xoxy.net> - 2011-09-24 14:31 -0400
Re: Testing if a pointer is valid Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-24 21:49 +0100
Re: Testing if a pointer is valid Keith Thompson <kst-u@mib.org> - 2011-09-24 14:40 -0700
Re: Testing if a pointer is valid Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-25 01:14 +0100
Re: Testing if a pointer is valid Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 13:44 -0800
Re: Testing if a pointer is valid Richard Damon <news.x.richarddamon@xoxy.net> - 2011-09-24 20:23 -0400
Re: Testing if a pointer is valid Willem <willem@toad.stack.nl> - 2011-09-24 18:44 +0000
Re: Testing if a pointer is valid James Kuyper <jameskuyper@verizon.net> - 2011-09-25 07:04 -0400
Re: Testing if a pointer is valid cri@tiac.net (Richard Harter) - 2011-09-24 17:30 +0000
Re: Testing if a pointer is valid Keith Thompson <kst-u@mib.org> - 2011-09-24 12:34 -0700
Re: Testing if a pointer is valid Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-25 01:00 -0700
Re: Testing if a pointer is valid Ian Collins <ian-news@hotmail.com> - 2011-09-25 21:30 +1300
Re: Testing if a pointer is valid Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-25 05:08 -0700
Re: Testing if a pointer is valid Ian Collins <ian-news@hotmail.com> - 2011-09-26 08:39 +1300
Re: Testing if a pointer is valid Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-24 20:04 +0300
Re: Testing if a pointer is valid James Kuyper <jameskuyper@verizon.net> - 2011-09-23 17:09 -0400
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-23 23:43 +0200
Re: Testing if a pointer is valid Michael Press <rubrum@pacbell.net> - 2011-09-27 20:48 -0700
Re: Testing if a pointer is valid Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-03 19:59 +0300
Re: Testing if a pointer is valid Michael Press <rubrum@pacbell.net> - 2011-10-03 17:32 -0700
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-24 13:53 +0100
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-20 21:18 +0100
Re: Testing if a pointer is valid Willem <willem@toad.stack.nl> - 2011-09-20 20:35 +0000
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-20 22:45 +0200
Re: Testing if a pointer is valid Willem <willem@toad.stack.nl> - 2011-09-21 08:09 +0000
Re: Testing if a pointer is valid Noob <root@127.0.0.1> - 2011-09-22 13:04 +0200
Re: Testing if a pointer is valid Robert Wessel <robertwessel2@yahoo.com> - 2011-09-22 11:38 -0500
Re: Testing if a pointer is valid Noob <root@127.0.0.1> - 2011-09-23 10:41 +0200
Re: Testing if a pointer is valid Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-22 22:20 +0300
Re: Testing if a pointer is valid Willem <willem@toad.stack.nl> - 2011-09-22 22:15 +0000
Re: Testing if a pointer is valid Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-23 12:30 +0300
Re: Testing if a pointer is valid Seebs <usenet-nospam@seebs.net> - 2011-09-26 22:59 +0000
Re: Testing if a pointer is valid Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-27 02:06 +0100
Re: Testing if a pointer is valid cri@tiac.net (Richard Harter) - 2011-09-27 03:39 +0000
Re: Testing if a pointer is valid "Rosario Pulvirenti" <NoInUseno1Spam@non.usare.invalid> - 2011-10-03 19:51 +0200
Re: Testing if a pointer is valid Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-03 19:11 +0100
Re: Testing if a pointer is valid "Rosario Pulvirenti" <NoInUseno1Spam@non.usare.invalid> - 2011-10-04 16:20 +0200
Re: Testing if a pointer is valid China Blue Corn Chips <chine.bleu@yahoo.com> - 2011-10-04 08:11 -0700
Re: Testing if a pointer is valid James Kuyper <jameskuyper@verizon.net> - 2011-10-04 12:19 -0400
Re: Testing if a pointer is valid Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-27 13:56 +0300
Re: Testing if a pointer is valid Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-27 13:13 +0100
Re: Testing if a pointer is valid Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-27 12:08 +0300
Re: Testing if a pointer is valid Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-29 01:00 -0700
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-20 21:59 +0100
Re: Testing if a pointer is valid Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-22 22:08 +0300
Re: Testing if a pointer is valid Willem <willem@toad.stack.nl> - 2011-09-20 17:00 +0000
Re: Testing if a pointer is valid August Karlstrom <fusionfile@gmail.com> - 2011-09-20 20:32 +0200
Re: Testing if a pointer is valid gazelle@shell.xmission.com (Kenny McCormack) - 2011-09-20 18:53 +0000
Re: Testing if a pointer is valid August Karlstrom <fusionfile@gmail.com> - 2011-09-20 22:55 +0200
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-20 21:50 +0100
Re: Testing if a pointer is valid gazelle@shell.xmission.com (Kenny McCormack) - 2011-09-21 15:48 +0000
Re: Testing if a pointer is valid Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-21 16:12 +0000
Re: Testing if a pointer is valid Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-21 09:42 -0700
Re: Testing if a pointer is valid Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-21 18:01 +0000
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-21 21:00 +0100
Re: Testing if a pointer is valid August Karlstrom <fusionfile@gmail.com> - 2011-09-21 21:32 +0200
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-22 12:40 +0100
Re: Testing if a pointer is valid gazelle@shell.xmission.com (Kenny McCormack) - 2011-09-22 13:00 +0000
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-22 14:54 +0100
Re: Testing if a pointer is valid gazelle@shell.xmission.com (Kenny McCormack) - 2011-09-22 14:03 +0000
Re: Testing if a pointer is valid Keith Thompson <kst-u@mib.org> - 2011-09-22 11:39 -0700
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-24 13:44 +0100
Re: Testing if a pointer is valid Keith Thompson <kst-u@mib.org> - 2011-09-24 12:23 -0700
Re: Testing if a pointer is valid Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-29 04:52 -0700
Re: Testing if a pointer is valid Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-29 04:51 -0700
Re: Testing if a pointer is valid Willem <willem@toad.stack.nl> - 2011-09-20 19:32 +0000
Re: Testing if a pointer is valid August Karlstrom <fusionfile@gmail.com> - 2011-09-20 22:48 +0200
Re: Testing if a pointer is valid James Kuyper <jameskuyper@verizon.net> - 2011-09-20 17:29 -0400
Re: Testing if a pointer is valid August Karlstrom <fusionfile@gmail.com> - 2011-09-20 23:45 +0200
Re: Testing if a pointer is valid James Kuyper <jameskuyper@verizon.net> - 2011-09-21 10:35 -0400
Re: Testing if a pointer is valid Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-29 05:04 -0700
Re: Testing if a pointer is valid Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-29 04:54 -0700
Re: Testing if a pointer is valid Keith Thompson <kst-u@mib.org> - 2011-09-20 17:19 -0700
Re: Testing if a pointer is valid August Karlstrom <fusionfile@gmail.com> - 2011-09-21 23:26 +0200
Re: Testing if a pointer is valid Keith Thompson <kst-u@mib.org> - 2011-09-21 14:35 -0700
Re: Testing if a pointer is valid August Karlstrom <fusionfile@gmail.com> - 2011-09-22 00:09 +0200
Re: Testing if a pointer is valid James Kuyper <jameskuyper@verizon.net> - 2011-09-21 19:08 -0400
Re: Testing if a pointer is valid cri@tiac.net (Richard Harter) - 2011-09-21 05:25 +0000
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-20 21:11 +0100
Re: Testing if a pointer is valid August Karlstrom <fusionfile@gmail.com> - 2011-09-20 23:01 +0200
Re: Testing if a pointer is valid Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-21 03:11 -0700
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-21 12:16 +0200
Re: Testing if a pointer is valid Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-21 03:23 -0700
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-21 20:44 +0100
Re: Testing if a pointer is valid August Karlstrom <fusionfile@gmail.com> - 2011-09-21 22:53 +0200
Re: Testing if a pointer is valid James Kuyper <jameskuyper@verizon.net> - 2011-09-21 23:08 -0400
Re: Testing if a pointer is valid Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-21 21:14 -0700
Re: Testing if a pointer is valid James Kuyper <jameskuyper@verizon.net> - 2011-09-22 07:17 -0400
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-22 16:37 +0100
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-22 16:25 +0100
Re: Testing if a pointer is valid Keith Thompson <kst-u@mib.org> - 2011-09-22 11:36 -0700
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-24 13:37 +0100
Re: Testing if a pointer is valid cri@tiac.net (Richard Harter) - 2011-09-24 13:50 +0000
Re: Testing if a pointer is valid gazelle@shell.xmission.com (Kenny McCormack) - 2011-09-24 14:47 +0000
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-24 20:43 +0100
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-24 20:26 +0100
Re: Testing if a pointer is valid Richard Damon <news.x.richarddamon@xoxy.net> - 2011-09-24 20:53 -0400
Re: Testing if a pointer is valid Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-25 02:30 +0100
Re: Testing if a pointer is valid Richard Damon <news.x.richarddamon@xoxy.net> - 2011-09-24 22:24 -0400
Re: Testing if a pointer is valid Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-25 12:36 +0100
Re: Testing if a pointer is valid Keith Thompson <kst-u@mib.org> - 2011-09-21 13:56 -0700
Re: Testing if a pointer is valid "Rosario Pulvirenti" <NoInUseno1Spam@non.usare.invalid> - 2011-09-22 07:38 +0200
Re: Testing if a pointer is valid Keith Thompson <kst-u@mib.org> - 2011-09-22 02:06 -0700
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-22 15:24 +0100
Re: Testing if a pointer is valid Keith Thompson <kst-u@mib.org> - 2011-09-22 11:35 -0700
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-24 13:25 +0100
Re: Testing if a pointer is valid Seebs <usenet-nospam@seebs.net> - 2011-09-26 22:59 +0000
Re: Testing if a pointer is valid Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 13:30 -0800
Re: Testing if a pointer is valid Nobody <nobody@nowhere.com> - 2011-09-22 18:23 +0100
Re: Testing if a pointer is valid gazelle@shell.xmission.com (Kenny McCormack) - 2011-09-21 15:40 +0000
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-21 20:20 +0100
Re: Testing if a pointer is valid Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-19 06:39 +0000
Re: Testing if a pointer is valid Keith Thompson <kst-u@mib.org> - 2011-09-19 10:06 -0700
Re: Testing if a pointer is valid Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-20 07:03 +0000
Re: Testing if a pointer is valid pete <pfiland@mindspring.com> - 2011-09-19 19:17 -0400
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-20 20:57 +0100
Re: Testing if a pointer is valid cri@tiac.net (Richard Harter) - 2011-09-19 05:14 +0000
Re: Testing if a pointer is valid Ian Collins <ian-news@hotmail.com> - 2011-09-19 18:02 +1200
Re: Testing if a pointer is valid cri@tiac.net (Richard Harter) - 2011-09-19 06:18 +0000
Re: Testing if a pointer is valid August Karlstrom <fusionfile@gmail.com> - 2011-09-19 17:50 +0200
Re: Testing if a pointer is valid August Karlstrom <fusionfile@gmail.com> - 2011-09-19 20:45 +0200
Re: Testing if a pointer is valid Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-28 08:05 -0700
Re: Testing if a pointer is valid Keith Thompson <kst-u@mib.org> - 2011-09-28 09:14 -0700
Re: Testing if a pointer is valid Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-18 23:52 -0700
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-20 20:45 +0100
Re: Testing if a pointer is valid August Karlstrom <fusionfile@gmail.com> - 2011-09-20 23:35 +0200
Re: Testing if a pointer is valid Rui Maciel <rui.maciel@gmail.com> - 2011-09-21 19:53 +0100
Re: Testing if a pointer is valid "BartC" <bc@freeuk.com> - 2011-09-17 23:54 +0100
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-18 00:59 +0200
Re: Testing if a pointer is valid Heikki Kallasjoki <fis+usenet@zem.fi> - 2011-09-17 23:35 +0000
Re: Testing if a pointer is valid jacob navia <jacob@spamsink.net> - 2011-09-18 01:47 +0200
Re: Testing if a pointer is valid Geoff <geoff@invalid.invalid> - 2011-09-17 17:15 -0700
Re: Testing if a pointer is valid Максим Фомин <maxim@maxim-fomin.ru> - 2011-09-18 00:43 -0700
Re: Testing if a pointer is valid "Rosario Pulvirenti" <NoInUseno1Spam@non.usare.invalid> - 2011-09-18 10:34 +0200
Re: Testing if a pointer is valid "Rosario Pulvirenti" <NoInUseno1Spam@non.usare.invalid> - 2011-09-20 09:28 +0200
Re: Testing if a pointer is valid Ike Naar <ike@iceland.freeshell.org> - 2011-09-18 12:55 +0000
Re: Testing if a pointer is valid "Joel C. Salomon" <joelcsalomon@gmail.com> - 2011-09-19 10:29 -0400
Re: Testing if a pointer is valid China Blue Corn Chips <chine.bleu@yahoo.com> - 2011-09-20 00:22 -0700
Page 8 of 15 — ← Prev page 1 … 6 7 [8] 9 10 … 15 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-09-24 14:07 +0100 |
| Message-ID | <0.727425cfb0bb6e1d5dd1.20110924140746BST.87litet7fh.fsf@bsb.me.uk> |
| In reply to | #10850 |
jacob navia <jacob@spamsink.net> writes:
> Le 24/09/11 14:02, James Kuyper a écrit :
>> On 09/23/2011 06:25 PM, Ian Collins wrote:
>>> On 09/24/11 10:06 AM, James Kuyper wrote:
>> ...
>>>> Automatic garbage collection of malloc() allocations cannot be done by a
>>>> fully conforming implementation of C. See the requirements for
>>>> scanf("%p"), and consider the implications of having the only copy of a
>>>> pointer's value stored completely outside of any memory that the garbage
>>>> collector is capable of scanning. Of course, you don't need scanf("%p")
>>>> to achieve that; fwrite()/fread() is sufficient, unless the garbage
>>>> collector also scans files.
>>>
>>> I'm sure everyone uses that ridiculous corner case.
>>
>> I'm sure that almost no-one relies upon writing pointer values to a file
>> and reading them back later while they're still valid. Nonetheless, an
>> inability to handle "that ridiculous corner case" correctly does render
>> automatic garbage collection of malloc()'d memory non-conforming.
>
> You have a misunderstanding: the collector only cares about pointers
> allocated with gc_malloc(). Pointers allocated with plain malloc()
> must be freed() as before, they are not concerned with the gc.
I think you have a misunderstanding. This sub-thread is about an
implementation that collects malloc'd memory. Look at the very first
quote. That was prompted by Ian Collins's (now snipped)
| the main advantage of using a library is the library simply
| interposes malloc and friends.
It's been about whether an implementation that collects malloc'd memory
is conforming or not -- and it can't be because of several corner cases
-- for a few messages now. I don't think anyone has suggested that
using gc_malloc (in user code) makes an implementation non-conforming.
> Implementation specific limitations to pointers are common place.
> For instance doubles must be aligned in an eight byte boundary in
> many machines. Nothing about those limitations are specified in the
> standard.
That's not true. The standard says a number of things about these
limitations. For example, that corresponding signed and unsigned types
have the same alignment.
<snip rhetorical question>
> Similarly, pointers allocated with gc_malloc should be kept visible
> to the collector, not Xored, whatever.
That's not the same as an alignment restriction. It's not something the
standard cares about at all. Code like some_allocator_i_just_wrote()
can do pretty much anything. If a GC'd pointer's pointed-to storage
goes away because the pointer was hidden, that's just a bug caused by
misuse of some API.
But its not quite as simple as this... There is an interaction between
the implementation and a GC system. For example, if the compiler
optimises away a pointer, storage may be erroneously freed. I don't
think this affects conformity, but might mean that a compiler needs to
know more about gc_malloc than it does about some_allocator_i_just_wrote
if everything is to work propoerly.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | cri@tiac.net (Richard Harter) |
|---|---|
| Date | 2011-09-24 13:15 +0000 |
| Message-ID | <4e7dd5d3.150494258@text.giganews.com> |
| In reply to | #10849 |
On Sat, 24 Sep 2011 08:02:38 -0400, James Kuyper
<jameskuyper@verizon.net> wrote:
>On 09/23/2011 06:25 PM, Ian Collins wrote:
>> On 09/24/11 10:06 AM, James Kuyper wrote:
>...
>>> Automatic garbage collection of malloc() allocations cannot be done by a
>>> fully conforming implementation of C. See the requirements for
>>> scanf("%p"), and consider the implications of having the only copy of a
>>> pointer's value stored completely outside of any memory that the garbage
>>> collector is capable of scanning. Of course, you don't need scanf("%p")
>>> to achieve that; fwrite()/fread() is sufficient, unless the garbage
>>> collector also scans files.
>>
>> I'm sure everyone uses that ridiculous corner case.
>
>I'm sure that almost no-one relies upon writing pointer values to a file
>and reading them back later while they're still valid. Nonetheless, an
>inability to handle "that ridiculous corner case" correctly does render
>automatic garbage collection of malloc()'d memory non-conforming.
I dunno, it seems to me that there is nothing that forbids an
implementation from using "smart" pointers. Given that, the pointer
can contain a tag issued at allocation time. In turn there can be a
"database" that contains currently valid pointers. When accessing a
pointer, look it up and see whether it is valid.
So it seems to me that in principle you can't rule out a fulling
comforming garbage collector. There might be performance issues, but
that's not my department. Then, too, there might be something in the
standard that forbids it. I wouldn't know about that.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-09-24 15:20 +0100 |
| Message-ID | <0.fdc334370431f37f5c3c.20110924152058BST.871uv6t41h.fsf@bsb.me.uk> |
| In reply to | #10858 |
cri@tiac.net (Richard Harter) writes:
> On Sat, 24 Sep 2011 08:02:38 -0400, James Kuyper
> <jameskuyper@verizon.net> wrote:
>
>>On 09/23/2011 06:25 PM, Ian Collins wrote:
>>> On 09/24/11 10:06 AM, James Kuyper wrote:
>>...
>>>> Automatic garbage collection of malloc() allocations cannot be done by a
>>>> fully conforming implementation of C. See the requirements for
>>>> scanf("%p"), and consider the implications of having the only copy of a
>>>> pointer's value stored completely outside of any memory that the garbage
>>>> collector is capable of scanning. Of course, you don't need scanf("%p")
>>>> to achieve that; fwrite()/fread() is sufficient, unless the garbage
>>>> collector also scans files.
>>>
>>> I'm sure everyone uses that ridiculous corner case.
>>
>>I'm sure that almost no-one relies upon writing pointer values to a file
>>and reading them back later while they're still valid. Nonetheless, an
>>inability to handle "that ridiculous corner case" correctly does render
>>automatic garbage collection of malloc()'d memory non-conforming.
>
> I dunno, it seems to me that there is nothing that forbids an
> implementation from using "smart" pointers. Given that, the pointer
> can contain a tag issued at allocation time. In turn there can be a
> "database" that contains currently valid pointers. When accessing a
> pointer, look it up and see whether it is valid.
>
> So it seems to me that in principle you can't rule out a fulling
> comforming garbage collector. There might be performance issues, but
> that's not my department. Then, too, there might be something in the
> standard that forbids it. I wouldn't know about that.
You'd need to say more. How and when is garbage collected?
I am pretty sure than some form of automatic collection can be done
without falling over the corner cases of obscured pointers (for example
freeing storage only pointed to be a pointer that goes out of scope) but
to do it in the general case seems hard. What method do you have in
mind for finding freeable storage?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-09-24 11:28 -0400 |
| Message-ID | <j5ksuf$8qr$1@dont-email.me> |
| In reply to | #10858 |
On 09/24/2011 09:15 AM, Richard Harter wrote:
> On Sat, 24 Sep 2011 08:02:38 -0400, James Kuyper
> <jameskuyper@verizon.net> wrote:
>
>> On 09/23/2011 06:25 PM, Ian Collins wrote:
>>> On 09/24/11 10:06 AM, James Kuyper wrote:
>> ...
>>>> Automatic garbage collection of malloc() allocations cannot be done by a
>>>> fully conforming implementation of C. See the requirements for
>>>> scanf("%p"), and consider the implications of having the only copy of a
>>>> pointer's value stored completely outside of any memory that the garbage
>>>> collector is capable of scanning. Of course, you don't need scanf("%p")
>>>> to achieve that; fwrite()/fread() is sufficient, unless the garbage
>>>> collector also scans files.
>>>
>>> I'm sure everyone uses that ridiculous corner case.
>>
>> I'm sure that almost no-one relies upon writing pointer values to a file
>> and reading them back later while they're still valid. Nonetheless, an
>> inability to handle "that ridiculous corner case" correctly does render
>> automatic garbage collection of malloc()'d memory non-conforming.
>
> I dunno, it seems to me that there is nothing that forbids an
> implementation from using "smart" pointers. Given that, the pointer
> can contain a tag issued at allocation time. In turn there can be a
> "database" that contains currently valid pointers. When accessing a
> pointer, look it up and see whether it is valid.
I presume that the function of the database is to ensure that no memory
pointed at by a valid pointer get collected? If so, the key issue
becomes - when does an entry get deleted from that data base? If you
wait until after free() has been called, it's a fully conforming
implementation of C; but it doesn't really qualify as a garbage
collector, in any conventional sense of the term.
If it gets deleted as soon as there are no copies of a given pointer
value stored anywhere in memory, it causes non-conforming behavior in
precisely the "ridiculous corner case" referred to above.
I can't see anyway to specify the rule for deleting the database entry
that allows such a system to be simultaneously a part of a conforming
implementation of C and a garbage collector. Could you explain the rule
you're thinking of?
In case you're not clear about the relevant issue, here's the
"ridiculous corner case", in all it's glory:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
static int func(void)
{
void *p = malloc(16);
if(p && printf("%p\n", p) > -1)
{
strcpy(p, "It worked!");
return 1;
}
return 0;
}
int main(void)
{
if(func())
{
// Insert sufficient processing here to allow:
// All copies of the value returned by malloc()
// to disappear from scannable memory.
// The garbage collector to notice that fact.
void *q;
if(scanf("%p", &q) == 1)
{
printf("%s\n", (char*)q);
free(q);
return EXIT_SUCCESS;
}
}
return EXIT_FAILURE;
}
I assume that any reasonably conventional garbage collector would
collect the memory shortly after exiting the scope of the variable 'p'.
If I'm mistaken about that, I'd appreciate an explanation.
If translated and executed with a fully conforming implementation of C,
and if the user types back exactly the same character string that was
printed out by the first printf(), the above program is required to
print out "It worked!" and to give a successful exit status (modulo
issues about whether any I/O at all is required to succeed).
If the memory is garbage-collected and put to some other use at any time
prior to the second printf() call, that won't work as it is required to
by the C standard.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Willem <willem@toad.stack.nl> |
|---|---|
| Date | 2011-09-24 15:45 +0000 |
| Message-ID | <slrnj7ruop.r5g.willem@toad.stack.nl> |
| In reply to | #10865 |
James Kuyper wrote:
) In case you're not clear about the relevant issue, here's the
) "ridiculous corner case", in all it's glory:
<snip example using %p>
Wouldn't the 'xor-ed pointer linked list' trick be a much more
real-world example ? Even if there is no way to do that in conforming C.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2011-09-24 20:07 +0300 |
| Message-ID | <874o01zx5w.fsf@bazspaz.fatphil.org> |
| In reply to | #10866 |
Willem <willem@toad.stack.nl> writes: > James Kuyper wrote: > ) In case you're not clear about the relevant issue, here's the > ) "ridiculous corner case", in all it's glory: > > <snip example using %p> > > Wouldn't the 'xor-ed pointer linked list' trick be a much more > real-world example ? Even if there is no way to do that in conforming C. You mustn't mention those, as they violate the "you can't reverse a list in O(1) time" claim, and then we'll cross threads! Are you sure you can't do them in conforming C. Is there something nonconforming of converting a pointer to an integer type and back again? You never use the xored values as pointers, so I don't see what the issue is. Phil -- "Religion is what keeps the poor from murdering the rich." -- Napoleon
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <news.x.richarddamon@xoxy.net> |
|---|---|
| Date | 2011-09-24 14:31 -0400 |
| Message-ID | <j5l7lg$gcu$1@dont-email.me> |
| In reply to | #10870 |
On 9/24/11 1:07 PM, Phil Carmody wrote: > Willem<willem@toad.stack.nl> writes: >> James Kuyper wrote: >> ) In case you're not clear about the relevant issue, here's the >> ) "ridiculous corner case", in all it's glory: >> >> <snip example using %p> >> >> Wouldn't the 'xor-ed pointer linked list' trick be a much more >> real-world example ? Even if there is no way to do that in conforming C. > > You mustn't mention those, as they violate the "you can't reverse a > list in O(1) time" claim, and then we'll cross threads! > > Are you sure you can't do them in conforming C. Is there something > nonconforming of converting a pointer to an integer type and back > again? You never use the xored values as pointers, so I don't see > what the issue is. > > Phil It isn't "strictly conforming" as the implementation isn't required to have an int type that can round trip a pointer value, but I believe that if the implementation defines that type, the xor trick is defined to work.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-09-24 21:49 +0100 |
| Message-ID | <0.0b199a951b61b3e0a357.20110924214904BST.87r535sm2n.fsf@bsb.me.uk> |
| In reply to | #10877 |
Richard Damon <news.x.richarddamon@xoxy.net> writes:
> On 9/24/11 1:07 PM, Phil Carmody wrote:
>> Willem<willem@toad.stack.nl> writes:
>>> James Kuyper wrote:
>>> ) In case you're not clear about the relevant issue, here's the
>>> ) "ridiculous corner case", in all it's glory:
>>>
>>> <snip example using %p>
>>>
>>> Wouldn't the 'xor-ed pointer linked list' trick be a much more
>>> real-world example ? Even if there is no way to do that in conforming C.
>>
>> You mustn't mention those, as they violate the "you can't reverse a
>> list in O(1) time" claim, and then we'll cross threads!
>>
>> Are you sure you can't do them in conforming C. Is there something
>> nonconforming of converting a pointer to an integer type and back
>> again? You never use the xored values as pointers, so I don't see
>> what the issue is.
>>
>> Phil
>
> It isn't "strictly conforming" as the implementation isn't required to
> have an int type that can round trip a pointer value, but I believe
> that if the implementation defines that type, the xor trick is defined
> to work.
I don't think a reversible integer conversion is needed. You are always
permitted to manipulate an object via a pointer to char (well, any of
the three char types in fact) so can mask a pointer that way. You won't
be able to access the pointer without potential UB but that does not
matter for this example. I.e.
void *space = malloc(42);
for (size_t i = 0; i < sizeof space; i++)
((unsigned char *)&space)[i] ^= 0xaa;
Any reference to 'space' now (let alone *space or anything like that) is
UB, but provided the code is repeated before any subsequent use, you're
OK.
I say "think" because I have a niggling doubt. If pointers have padding
bits I am not sure that these have to hold the last value stored in
them. The two xor's are then not guaranteed to return the pointer to
its initial state, and the result might be a trap representation. It
would be odd indeed -- the padding bits would have to change one way on
the first xor and in some other way on the second, but that might be
permitted. Of course, no padding bits and you are home and dry.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-09-24 14:40 -0700 |
| Message-ID | <lnehz539hh.fsf@nuthaus.mib.org> |
| In reply to | #10884 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> I don't think a reversible integer conversion is needed. You are always
> permitted to manipulate an object via a pointer to char (well, any of
> the three char types in fact) so can mask a pointer that way. You won't
> be able to access the pointer without potential UB but that does not
> matter for this example. I.e.
>
> void *space = malloc(42);
> for (size_t i = 0; i < sizeof space; i++)
> ((unsigned char *)&space)[i] ^= 0xaa;
>
> Any reference to 'space' now (let alone *space or anything like that) is
> UB, but provided the code is repeated before any subsequent use, you're
> OK.
>
> I say "think" because I have a niggling doubt. If pointers have padding
> bits I am not sure that these have to hold the last value stored in
> them. The two xor's are then not guaranteed to return the pointer to
> its initial state, and the result might be a trap representation. It
> would be odd indeed -- the padding bits would have to change one way on
> the first xor and in some other way on the second, but that might be
> permitted. Of course, no padding bits and you are home and dry.
The standard only uses the term "padding bit" in reference to
integer representations. It doesn't say enough about pointer
representations for the concept to be meaningful.
The two xors will return the pointer to its original
*representation*, and that has to be good enough to return it to
its original *value*. If it didn't, then memcpy(), which has no
knowledge of the type of the data it's copying, couldn't reliably
copy pointer values. (I'm not sure where the standard guarantees
this, but an implementation where it doesn't work would be perverse
if not non-conforming.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-09-25 01:14 +0100 |
| Message-ID | <0.28fc935d8c554e4cc721.20110925011444BST.878vpdscjv.fsf@bsb.me.uk> |
| In reply to | #10889 |
Keith Thompson <kst-u@mib.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > [...] >> I don't think a reversible integer conversion is needed. You are always >> permitted to manipulate an object via a pointer to char (well, any of >> the three char types in fact) so can mask a pointer that way. You won't >> be able to access the pointer without potential UB but that does not >> matter for this example. I.e. >> >> void *space = malloc(42); >> for (size_t i = 0; i < sizeof space; i++) >> ((unsigned char *)&space)[i] ^= 0xaa; >> >> Any reference to 'space' now (let alone *space or anything like that) is >> UB, but provided the code is repeated before any subsequent use, you're >> OK. >> >> I say "think" because I have a niggling doubt. If pointers have padding >> bits I am not sure that these have to hold the last value stored in >> them. The two xor's are then not guaranteed to return the pointer to >> its initial state, and the result might be a trap representation. It >> would be odd indeed -- the padding bits would have to change one way on >> the first xor and in some other way on the second, but that might be >> permitted. Of course, no padding bits and you are home and dry. > > The standard only uses the term "padding bit" in reference to > integer representations. It doesn't say enough about pointer > representations for the concept to be meaningful. That's true, but what it does say means that there can be bits that might contribute to a trap representation but not to the value. Surely that is effectively the same thing? > The two xors will return the pointer to its original > *representation*, and that has to be good enough to return it to > its original *value*. My problem was with the first part. My worry was that, since only the value is said to be retained, bits that do not contribute to the value might change between the xors. However, that clause -- about an object retaining its last stored value -- presumably applies equally to the unsigned char objects written in the loop so there are no grounds for my niggling doubt. > If it didn't, then memcpy(), which has no > knowledge of the type of the data it's copying, couldn't reliably > copy pointer values. (I'm not sure where the standard guarantees > this, but an implementation where it doesn't work would be perverse > if not non-conforming.) 6.2.6.1 p2 seems to be it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2012-01-24 13:44 -0800 |
| Message-ID | <kfnbopsg4h6.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #10892 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Keith Thompson <kst-u@mib.org> writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> [...] >>> I don't think a reversible integer conversion is needed. You are always >>> permitted to manipulate an object via a pointer to char (well, any of >>> the three char types in fact) so can mask a pointer that way. You won't >>> be able to access the pointer without potential UB but that does not >>> matter for this example. I.e. >>> >>> void *space = malloc(42); >>> for (size_t i = 0; i < sizeof space; i++) >>> ((unsigned char *)&space)[i] ^= 0xaa; >>> >>> Any reference to 'space' now (let alone *space or anything like that) is >>> UB, but provided the code is repeated before any subsequent use, you're >>> OK. >>> >>> I say "think" because I have a niggling doubt. If pointers have padding >>> bits I am not sure that these have to hold the last value stored in >>> them. The two xor's are then not guaranteed to return the pointer to >>> its initial state, and the result might be a trap representation. It >>> would be odd indeed -- the padding bits would have to change one way on >>> the first xor and in some other way on the second, but that might be >>> permitted. Of course, no padding bits and you are home and dry. >> >> The standard only uses the term "padding bit" in reference to >> integer representations. It doesn't say enough about pointer >> representations for the concept to be meaningful. > > That's true, but what it does say means that there can be bits that > might contribute to a trap representation but not to the value. Surely > that is effectively the same thing? > >> The two xors will return the pointer to its original >> *representation*, and that has to be good enough to return it to >> its original *value*. > > My problem was with the first part. My worry was that, since only the > value is said to be retained, bits that do not contribute to the value > might change between the xors. However, that clause -- about an object > retaining its last stored value -- presumably applies equally to the > unsigned char objects written in the loop so there are no grounds for my > niggling doubt. [snip incidental] The meaning of a "value stored in an object" is defined in 6.2.6.1p4 (and p3 for bit-field objects); it is exactly the N * CHAR_BIT bits of the object, where N is the size of the object being stored into. In other words, a "stored value" is just the object representation of a value. That should clear up any doubts or confusion about changing representations, flipping padding bits, etc.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <news.x.richarddamon@xoxy.net> |
|---|---|
| Date | 2011-09-24 20:23 -0400 |
| Message-ID | <j5ls9f$i8j$1@dont-email.me> |
| In reply to | #10884 |
On 9/24/11 4:49 PM, Ben Bacarisse wrote: > > I don't think a reversible integer conversion is needed. You are always > permitted to manipulate an object via a pointer to char (well, any of > the three char types in fact) so can mask a pointer that way. You won't > be able to access the pointer without potential UB but that does not > matter for this example. I.e. > > void *space = malloc(42); > for (size_t i = 0; i< sizeof space; i++) > ((unsigned char *)&space)[i] ^= 0xaa; > > Any reference to 'space' now (let alone *space or anything like that) is > UB, but provided the code is repeated before any subsequent use, you're > OK. > > I say "think" because I have a niggling doubt. If pointers have padding > bits I am not sure that these have to hold the last value stored in > them. The two xor's are then not guaranteed to return the pointer to > its initial state, and the result might be a trap representation. It > would be odd indeed -- the padding bits would have to change one way on > the first xor and in some other way on the second, but that might be > permitted. Of course, no padding bits and you are home and dry. > One thing to note is that unsigned char isn't allowed to have "padding bits" if I remember right, so I think the aliasing works and stays conforming. Now I don't think you are allowed to even touch the value of the pointer, as it very well may be a "trap value", so even void* newspace = space; would invoke undefined behavior.
[toc] | [prev] | [next] | [standalone]
| From | Willem <willem@toad.stack.nl> |
|---|---|
| Date | 2011-09-24 18:44 +0000 |
| Message-ID | <slrnj7s97u.1dod.willem@toad.stack.nl> |
| In reply to | #10870 |
Phil Carmody wrote:
) Willem <willem@toad.stack.nl> writes:
)> Wouldn't the 'xor-ed pointer linked list' trick be a much more
)> real-world example ? Even if there is no way to do that in conforming C.
)
) Are you sure you can't do them in conforming C. Is there something
) nonconforming of converting a pointer to an integer type and back
) again? You never use the xored values as pointers, so I don't see
) what the issue is.
No, I'm entirely unsure either way. I meant the 'if' as an actual if.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-09-25 07:04 -0400 |
| Message-ID | <j5n1sn$5fg$1@dont-email.me> |
| In reply to | #10866 |
On 09/24/2011 11:45 AM, Willem wrote: > James Kuyper wrote: > ) In case you're not clear about the relevant issue, here's the > ) "ridiculous corner case", in all it's glory: > > <snip example using %p> > > Wouldn't the 'xor-ed pointer linked list' trick be a much more > real-world example ? ... I wanted to make it as clear as possible that all information about the pointer's value has completely vanished from memory that the garbage collector is capable of scanning. With the xor trick, the information is still in memory, just encrypted. I don't see any plausible way for the collector to decrypt it, but removing the information completely makes the relevant issue clearer. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | cri@tiac.net (Richard Harter) |
|---|---|
| Date | 2011-09-24 17:30 +0000 |
| Message-ID | <4e7e1374.166272324@text.giganews.com> |
| In reply to | #10865 |
On Sat, 24 Sep 2011 11:28:14 -0400, James Kuyper <jameskuyper@verizon.net> wrote: >On 09/24/2011 09:15 AM, Richard Harter wrote: >> On Sat, 24 Sep 2011 08:02:38 -0400, James Kuyper >> <jameskuyper@verizon.net> wrote: [snip exposition] Upon reflection I retract. What I had in mind wouldn't work. My bad.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-09-24 12:34 -0700 |
| Message-ID | <lnipoh3fbi.fsf@nuthaus.mib.org> |
| In reply to | #10865 |
James Kuyper <jameskuyper@verizon.net> writes:
[snip]
> In case you're not clear about the relevant issue, here's the
> "ridiculous corner case", in all it's glory:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
>
> static int func(void)
> {
> void *p = malloc(16);
> if(p && printf("%p\n", p) > -1)
> {
> strcpy(p, "It worked!");
> return 1;
> }
> return 0;
> }
>
> int main(void)
> {
> if(func())
> {
> // Insert sufficient processing here to allow:
> // All copies of the value returned by malloc()
> // to disappear from scannable memory.
> // The garbage collector to notice that fact.
>
> void *q;
> if(scanf("%p", &q) == 1)
> {
> printf("%s\n", (char*)q);
> free(q);
> return EXIT_SUCCESS;
> }
> }
> return EXIT_FAILURE;
> }
>
> I assume that any reasonably conventional garbage collector would
> collect the memory shortly after exiting the scope of the variable 'p'.
> If I'm mistaken about that, I'd appreciate an explanation.
>
> If translated and executed with a fully conforming implementation of C,
> and if the user types back exactly the same character string that was
> printed out by the first printf(), the above program is required to
> print out "It worked!" and to give a successful exit status (modulo
> issues about whether any I/O at all is required to succeed).
>
> If the memory is garbage-collected and put to some other use at any time
> prior to the second printf() call, that won't work as it is required to
> by the C standard.
I can think of a hypothetical GC implementation that could handle
even that corner case.
Perl has an optional facility for checking whether values are
"tainted", i.e., come from unsafe sources. Any value read from
a file (including standard input), from the environment, etc., is
considered to be unsafe, and any value derived from a tainted value
is also considered to be unsafe. Literal values in the program,
and values derived from them, are treated as safe. If the checking
is enabled (it's off by default), then Perl imposes restrictions
on what you can do with unsafe values.
A hypothetical implementation of C with garbage collection could
track values in a similar manner, marking values for potential
recoverability rather than safety. Writing a pointer value to a file
with "%p" would mark that pointer value as potentially recoverable,
making it ineligible for garbage collection.
This would require ridiculous levels of overhead, both in storage
space and in execution time. It probably wouldn't be worth doing,
especially considering the fact that GC can be implemented in an
*almost* conforming manner as long as the programmer takes a little
care to avoid these corner cases.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
"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 | 2011-09-25 01:00 -0700 |
| Message-ID | <cc396467-a288-4d7d-a78b-7b683483a626@h34g2000yqd.googlegroups.com> |
| In reply to | #10880 |
On Sep 24, 9:34 pm, Keith Thompson <ks...@mib.org> wrote: > > This would require ridiculous levels of overhead, both in storage > space and in execution time. It probably wouldn't be worth doing, > especially considering the fact that GC can be implemented in an > *almost* conforming manner as long as the programmer takes a little > care to avoid these corner cases. > Or it would be simpler just to define gc_malloc() as allocating a pointer that remains valid as long as it is either with the scope of a function in the call stack, or reachable by a pointer in that scope. Encrypted pointers etc are invalid. The problem isn't really that garbage collection can be defeated by a sufficiently determined programmer. It's that it can't be implemented without access to the internals of the program. gc_malloc() is not any other function, and it's not a hardware-interfacting function either. The other issue is that it changes something very fundamental. -- The 10 rules of programming http://www.malcolmmclean.site11.com/www
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-09-25 21:30 +1300 |
| Message-ID | <9e875rFoe8U2@mid.individual.net> |
| In reply to | #10904 |
On 09/25/11 09:00 PM, Malcolm McLean wrote: > On Sep 24, 9:34 pm, Keith Thompson<ks...@mib.org> wrote: >> >> This would require ridiculous levels of overhead, both in storage >> space and in execution time. It probably wouldn't be worth doing, >> especially considering the fact that GC can be implemented in an >> *almost* conforming manner as long as the programmer takes a little >> care to avoid these corner cases. >> > Or it would be simpler just to define gc_malloc() as allocating a > pointer that remains valid as long as it is either with the scope of a > function in the call stack, or reachable by a pointer in that scope. > Encrypted pointers etc are invalid. > > The problem isn't really that garbage collection can be defeated by a > sufficiently determined programmer. It's that it can't be implemented > without access to the internals of the program. Eh? All you have to do is provide alternatives to malloc and friends. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-09-25 05:08 -0700 |
| Message-ID | <a3944a55-066c-4e5e-ac97-ce8ec98a7851@q25g2000vbx.googlegroups.com> |
| In reply to | #10906 |
On Sep 25, 10:30 am, Ian Collins <ian-n...@hotmail.com> wrote: > > > The problem isn't really that garbage collection can be defeated by a > > sufficiently determined programmer. It's that it can't be implemented > > without access to the internals of the program. > > Eh? All you have to do is provide alternatives to malloc and friends. > I can easily provide a "safe malloc" that aborts on allocation failure. If for some reason we don't want it to be dependent on malloc, the user can pass it a memory area from which to do allocations. I can't provide a gc_malloc. The problem is you have to do periodic sweeps of the memory managed by the program, to detect pointers to allocated blocks. You then put any orphaned blocks back on the free list. There's no way of doing that without altering the compiler itself. -- MiniBasic - how to write a script interpreter http://www.malcolmmclean.site11.com/www
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-09-26 08:39 +1300 |
| Message-ID | <9e9ebdFoe8U4@mid.individual.net> |
| In reply to | #10914 |
On 09/26/11 01:08 AM, Malcolm McLean wrote: > On Sep 25, 10:30 am, Ian Collins<ian-n...@hotmail.com> wrote: >> >>> The problem isn't really that garbage collection can be defeated by a >>> sufficiently determined programmer. It's that it can't be implemented >>> without access to the internals of the program. >> >> Eh? All you have to do is provide alternatives to malloc and friends. >> > I can easily provide a "safe malloc" that aborts on allocation > failure. If for some reason we don't want it to be dependent on > malloc, the user can pass it a memory area from which to do > allocations. > > I can't provide a gc_malloc. The problem is you have to do periodic > sweeps of the memory managed by the program, to detect pointers to > allocated blocks. You then put any orphaned blocks back on the free > list. There's no way of doing that without altering the compiler > itself. There is, it's called a library. If I compile with cc x.c The executable uses malloc from libC. If I compile with cc x.c -lgc The executable uses malloc from libgc. Loading initialises the sweeper thread. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
Page 8 of 15 — ← Prev page 1 … 6 7 [8] 9 10 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web