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 13 of 15 — ← Prev page 1 … 11 12 [13] 14 15 Next page →
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2011-09-24 20:43 +0100 |
| Message-ID | <4e7e32d1$0$16760$a729d347@news.telepac.pt> |
| In reply to | #10864 |
Kenny McCormack wrote: > Rui's problem throughout this thread is that he refuses to accept that > "unsafe" != "bad". I.e., the rest of us understand that no moral > judgement is being made; we are not saying that C is a bad language. But > Rui seems obsessed with defending C's honor against the claim of > unsafeness; no such defense is warranted or necessary. You seem to be confused. My assertion was not that C was free of any safety issue. The point which I made was that this particular example was poorly though out, as it failed to demonstrate any safety issue affecting a language. If an assertion is made but is backed up with false evidence which is promptly debunked then it simply isn't possible to insist on that assertion based on bunk evidence. Otherwise we end up carelessly contributing to a myth which grows and spreads thanks to this sort of silliness. > Another way to look at this is that if you find me & Kiki arguing the same > side of a C question/issue, you can probably be certain that that position > (the one Kiki & I are arguing for) is correct. Oh yes, because it's simply impossible for you to ever be wrong about anything, as your post demonstrated quite well. Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2011-09-24 20:26 +0100 |
| Message-ID | <4e7e2eed$0$16756$a729d347@news.telepac.pt> |
| In reply to | #10860 |
Richard Harter wrote:
> You misapprehend. The example was not about the C language in
> particular; it was about whether languages that have an address of
> operator make it possible to access an object beyond its lifetime. I
> quote:
>
> A language with an "address of" operator cannot be safe as is
> illustrated by the following example:
>
> T *x;
>
> void f(void)
> {
> T y;
>
> x = &y;
> }
>
> After calling f, x is invalid.
>
> Note the "A language". This was a general proposition about languages
> that happens to be false. The error is the assumption that all
> languages bind lexical scope to storage object lifetime.
>
> Beyond that, I opine that you do not understand what it means to say
> something is safe. Just because a language (or any tool for that
> matter) is unsafe doesn't mean that it cannot be used safely by a
> skilled and careful programmer. It means that the language permits
> uncaught errors. Even "competent" programmers make mistakes - no one
> says that competent programmers intend to do things like returning out
> of scope pointers. C is unsafe in this regard because it can happen.
>
> There is nothing wrong with that - most people understand that C was
> never meant to be a safe language.
I don't believe you understood what has been said, which would explain your
unintentional strawman. The example which has been provided to try to
demonstrate how C's "address of" operator is supposed to be unsafe
represents, by definition, an erroneous program construct. Even the C
standard indicates that an expected outcome for this sort of problem is
"terminating a translation or execution (with the issuance of a diagnostic
mesage)". This is something which at least some compilers, such as gcc and
clang, actually do. They perform some diagnostics on this type of error
and, if detected, throw a warning or an error. So, if a piece of broken
code, as suggested by the standard, leads the compiler to thrown a warning
or even an error on how this piece of code is broken, why would anyone still
consider this piece of broken code as an example of a programming language
being unsafe? I mean, what else should a compiler do? Slap the programmer
in the head with a rolled up newspaper?
And regarding the "a language" Vs "C programming language" thing, this is
comp.lang.c, the code example was written in C and it was used as an example
of how C code was supposed to be unsafe. I believe we can agree that we
weren't talking about safety issues affecting lisp or visual basic.
Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <news.x.richarddamon@xoxy.net> |
|---|---|
| Date | 2011-09-24 20:53 -0400 |
| Message-ID | <j5lu1t$qps$1@dont-email.me> |
| In reply to | #10860 |
On 9/24/11 9:50 AM, Richard Harter wrote: > > There is nothing wrong with that - most people understand that C was > never meant to be a safe language. > I would go a step beyond that and say that there were definite decisions to allow unsafe code to meet the design goals of the language. "Safety" in a language tends to come at the cost of expressiveness, efficiency or clerity. You lose expressiveness when the static protections in the language keep you from doing operations because they might be unsafe (but also might be safe). An example of this would be trying to prevent the returning of the address of a local variable from a function. Since it would be possible to pass the address of the variable to another function and get the address back, you almost need to prohibit taking the address of any local variable. A second way to get safety is to lose efficiency by adding automatic run time checks to detect that an error has happened. In our example, the pointer could have an additional field attached that somehow lets us detect if it is from a context that no longer exists. (or better, check for being passed outside the context). The third cost, can happen when to minimize the loss of expressiveness, warts are added to declarations to allow the language to permit operations that can now be seen to be "safe" because the programmer can add assertions that certain things won't happen, so other actions are allowed. For example, the address of a local variable could be passed to another function, if it promises that it won't return that value or set any globals with it (or maybe declare that it may return that value so its return can't be used to sneak out the address). C, from its original design, was intended to be a language as efficient as possible, and also as expressive as possible. This leads to the language being "unsafe". Some major pitfalls might be blocked, but only if it really doesn't make sense, or there is a work around to do so if need be. One example of this is casting pointers to change their type.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-09-25 02:30 +0100 |
| Message-ID | <0.ec64120448ba2424fac2.20110925023054BST.87vcshqugh.fsf@bsb.me.uk> |
| In reply to | #10894 |
Richard Damon <news.x.richarddamon@xoxy.net> writes:
> On 9/24/11 9:50 AM, Richard Harter wrote:
>>
>> There is nothing wrong with that - most people understand that C was
>> never meant to be a safe language.
>
> I would go a step beyond that and say that there were definite
> decisions to allow unsafe code to meet the design goals of the
> language.
>
> "Safety" in a language tends to come at the cost of expressiveness,
> efficiency or clerity. You lose expressiveness when the static
> protections in the language keep you from doing operations because
> they might be unsafe (but also might be safe). An example of this
> would be trying to prevent the returning of the address of a local
> variable from a function. Since it would be possible to pass the
> address of the variable to another function and get the address back,
> you almost need to prohibit taking the address of any local variable.
I disagree about expressiveness. Yes, small local changes in the
"design space" produce less expressive languages, but if you look at the
bigger picture there is far more expressiveness to be had elsewhere.
For example, I keep writing the same sort of loops over and over again:
for (i = 0; i < n_ints; i++)
if (v[i] < t)
break;
for (i = 0; i < n_strings; i++)
if (strcmp(s[i], "abc") == 0)
break;
and so on because I can't express the idea of finding "the first i such
that X". That's rather trivial, but more complex patterns are also hard
to express.
At the very simple end of the spectrum, almost anything to do with
strings is messy to the extent that what you are trying to express can
be quite well hidden in the details.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <news.x.richarddamon@xoxy.net> |
|---|---|
| Date | 2011-09-24 22:24 -0400 |
| Message-ID | <j5m3cf$jch$1@dont-email.me> |
| In reply to | #10896 |
On 9/24/11 9:30 PM, Ben Bacarisse wrote: > Richard Damon<news.x.richarddamon@xoxy.net> writes: > >> On 9/24/11 9:50 AM, Richard Harter wrote: >>> >>> There is nothing wrong with that - most people understand that C was >>> never meant to be a safe language. >> >> I would go a step beyond that and say that there were definite >> decisions to allow unsafe code to meet the design goals of the >> language. >> >> "Safety" in a language tends to come at the cost of expressiveness, >> efficiency or clerity. You lose expressiveness when the static >> protections in the language keep you from doing operations because >> they might be unsafe (but also might be safe). An example of this >> would be trying to prevent the returning of the address of a local >> variable from a function. Since it would be possible to pass the >> address of the variable to another function and get the address back, >> you almost need to prohibit taking the address of any local variable. > > I disagree about expressiveness. Yes, small local changes in the > "design space" produce less expressive languages, but if you look at the > bigger picture there is far more expressiveness to be had elsewhere. > For example, I keep writing the same sort of loops over and over again: > > for (i = 0; i< n_ints; i++) > if (v[i]< t) > break; > > for (i = 0; i< n_strings; i++) > if (strcmp(s[i], "abc") == 0) > break; > > and so on because I can't express the idea of finding "the first i such > that X". That's rather trivial, but more complex patterns are also hard > to express. > > At the very simple end of the spectrum, almost anything to do with > strings is messy to the extent that what you are trying to express can > be quite well hidden in the details. > > <snip> Actually, to express your "find first" just requires define an appropriate macro is C, so this isn't directly an expressiveness issue. (or maybe you are using a different idea of expressiveness than me). C does run into limits of expressing more abstract ideas.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-09-25 12:36 +0100 |
| Message-ID | <0.4db8b0928c1ccdabe5d7.20110925123649BST.87hb40rgz2.fsf@bsb.me.uk> |
| In reply to | #10898 |
Richard Damon <news.x.richarddamon@xoxy.net> writes: > On 9/24/11 9:30 PM, Ben Bacarisse wrote: >> Richard Damon<news.x.richarddamon@xoxy.net> writes: >> >>> On 9/24/11 9:50 AM, Richard Harter wrote: >>>> >>>> There is nothing wrong with that - most people understand that C was >>>> never meant to be a safe language. >>> >>> I would go a step beyond that and say that there were definite >>> decisions to allow unsafe code to meet the design goals of the >>> language. >>> >>> "Safety" in a language tends to come at the cost of expressiveness, >>> efficiency or clerity. You lose expressiveness when the static >>> protections in the language keep you from doing operations because >>> they might be unsafe (but also might be safe). An example of this >>> would be trying to prevent the returning of the address of a local >>> variable from a function. Since it would be possible to pass the >>> address of the variable to another function and get the address back, >>> you almost need to prohibit taking the address of any local variable. >> >> I disagree about expressiveness. Yes, small local changes in the >> "design space" produce less expressive languages, but if you look at the >> bigger picture there is far more expressiveness to be had elsewhere. >> For example, I keep writing the same sort of loops over and over again: >> >> for (i = 0; i< n_ints; i++) >> if (v[i]< t) >> break; >> >> for (i = 0; i< n_strings; i++) >> if (strcmp(s[i], "abc") == 0) >> break; >> >> and so on because I can't express the idea of finding "the first i such >> that X". That's rather trivial, but more complex patterns are also hard >> to express. >> >> At the very simple end of the spectrum, almost anything to do with >> strings is messy to the extent that what you are trying to express can >> be quite well hidden in the details. >> >> <snip> > > Actually, to express your "find first" just requires define an > appropriate macro is C, so this isn't directly an expressiveness > issue. (or maybe you are using a different idea of expressiveness than > me). C does run into limits of expressing more abstract ideas. I don't think a macro can really express this idea because it's an expression (sorry about the two meanings of "expression" here -- I don't know how to avoid them). I wrote the loops because that's all C provides me with, but find_first_idx_such_that(condition) is something that should be usable in, say, an initialisation or a function call. Some languages have block expressions so a macro in such a language would be a start, but C does not (well, gcc does but that's besides the point). I say "start" because C macros are an entirely separate kind of thing, so once you've had to wrap an idea in a macro you can't pass it to another function, put it in a data structure, and so on. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-09-21 13:56 -0700 |
| Message-ID | <lnhb454nsf.fsf@nuthaus.mib.org> |
| In reply to | #10676 |
Rui Maciel <rui.maciel@gmail.com> writes:
> August Karlstrom wrote:
>> To me dangling pointers represent the very definition of unsafeness.
>> What is an unsafe language to you?
>
> The example you provided represented poorly written code where
> a pointer refers to an object after it's lifetime as ended.
> Understanding an object's storage duration is very basic stuff.
> Therefore, this code goes against extremely basic concepts
> which are clearly defined and therefore can only be written by
> incompetent programmers. A programming language cannot be deemed
> safe or unsafe due to mistakes made by incompetent programmers.
> If that was the case then even the most basic scripting language
> could be accused of being unsafe if a fool could inadvertently
> write a script which runs any acceptable but obviously unwanted
> command, such as rm -rf /*, and this isn't true.
You almost seem to be implying that only incompetent programmers
make mistakes. I think what you really mean is that only incompetent
programmes make *certain kinds* of mistakes -- but I think that's
unrealistic.
There are real advantages to languages that make even stupid mistakes
(like using a pointer outside its lifetime) either easy to detect,
or impossible to make in the first place. (And yes, there are also
real advantages to languages like C that give you enough rope to
shoot yourself in the foot, and depend on the programmer to get
things right.)
One example: pre-ANSI C didn't have prototypes, and so compilers
weren't able to diagnose function calls that pass the wrong number
of parameters. I remember running into that when I was first
learning C (coming from a Pascal background), and being horrified.
You could argue (with some justification) that I was incompetent for
writing an incorrect call, but the language design was also partly at
fault for not providing a mechanism to catch such errors. (And the
C committee apparently agreed, and added prototypes to the language.)
The safety of a language is not a simple binary attribute. But a
language (like ANSI C) that diagnoses function calls with the wrong
number of arguments is *safer* than a language (like pre-ANSI C)
that doesn't.
--
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 | "Rosario Pulvirenti" <NoInUseno1Spam@non.usare.invalid> |
|---|---|
| Date | 2011-09-22 07:38 +0200 |
| Message-ID | <4e7ac973$0$15668$4fafbaef@reader2.news.tin.it> |
| In reply to | #10681 |
"Keith Thompson" <kst-u@mib.org> ha scritto nel messaggio news:lnhb454nsf.fsf@nuthaus.mib.org... > Rui Maciel <rui.maciel@gmail.com> writes: > The safety of a language is not a simple binary attribute. But a > language (like ANSI C) that diagnoses function calls with the wrong > number of arguments is *safer* than a language (like pre-ANSI C) > that doesn't. yes that is the theory but the pratice is i never find any such error in assembly until now for example: function: ret 12 if i have 3 arg for function 4*3=12 ret 12 clear the stack and return to the point afther the call if the number of args are != 3 this goes to seg fault and in the rare case i make wrong, this detect the error run time + each function check each arg is in the range expected so arg errors here are null or it seem that to me i think programmers has to fear more errors that corrupt malloc arena eg write on malloc area memory that corruct pointers to free i would chek if each free() is right in the free the pointer
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-09-22 02:06 -0700 |
| Message-ID | <ln8vph3pzi.fsf@nuthaus.mib.org> |
| In reply to | #10689 |
"Rosario Pulvirenti" <NoInUseno1Spam@non.usare.invalid> writes:
> "Keith Thompson" <kst-u@mib.org> ha scritto nel messaggio
> news:lnhb454nsf.fsf@nuthaus.mib.org...
>> Rui Maciel <rui.maciel@gmail.com> writes:
>> The safety of a language is not a simple binary attribute. But a
>> language (like ANSI C) that diagnoses function calls with the wrong
>> number of arguments is *safer* than a language (like pre-ANSI C)
>> that doesn't.
>
> yes that is the theory
> but the pratice is i never find any such error in assembly until now
I was talking about C, not assembly.
[snip]
--
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 | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2011-09-22 15:24 +0100 |
| Message-ID | <4e7b4527$0$16761$a729d347@news.telepac.pt> |
| In reply to | #10681 |
Keith Thompson wrote: > You almost seem to be implying that only incompetent programmers > make mistakes. I think what you really mean is that only incompetent > programmes make *certain kinds* of mistakes -- but I think that's > unrealistic. I was referring to the example which was provided to attempt to demonstrate how unsafe the C programming language was by assigning to a pointer the reference of a temporary object and expecting to access that object after is lifetime. I don't believe it is reasonable to claim that a programming language suffers from a serious problem by presenting code which is clearly broken and, by definition, represents an erroneous program construct. The type of error presented in the example code can only appear in a program if the programmer who wrote it failed to understand where in a program a specific object is guaranteed to be accessible. This sort of stuff is so basic that it's taught right at the start of any C course. As a consequence, trying to depict such a basic mistake, which is the sole responsible of the programmer who wrote it, as a major problem affecting a programming language is simply wrong. At best, complaints may be directed at a compiler for failing to warn about this issue, but even then this would boil down to a compiler failing to catch a problem caused by a programmer having written bad code, and not a issue affecting the programming language. > There are real advantages to languages that make even stupid mistakes > (like using a pointer outside its lifetime) either easy to detect, > or impossible to make in the first place. (And yes, there are also > real advantages to languages like C that give you enough rope to > shoot yourself in the foot, and depend on the programmer to get > things right.) > > One example: pre-ANSI C didn't have prototypes, and so compilers > weren't able to diagnose function calls that pass the wrong number > of parameters. I remember running into that when I was first > learning C (coming from a Pascal background), and being horrified. > You could argue (with some justification) that I was incompetent for > writing an incorrect call, but the language design was also partly at > fault for not providing a mechanism to catch such errors. (And the > C committee apparently agreed, and added prototypes to the language.) > > The safety of a language is not a simple binary attribute. But a > language (like ANSI C) that diagnoses function calls with the wrong > number of arguments is *safer* than a language (like pre-ANSI C) > that doesn't. I see what you mean, and you have a point. Nonetheless, some C use cases tend to be left undefined in order to make it possible for compiler developers to provide features which otherwise would be in violation of the C standard. In this specific case, the C standard only defines the portions of a program where the storage of a specific object is guaranteed to be reserved. As a consequence, it is up to the compiler developers to specify how objects are stored in their platform. This means that they are free to implement anything between eliminating the memory storage right after it is no longer guaranteed by the C standard and implementing some form of garbage collection, where malloc/free could effectively be replaced by assigning the reference of local objects to pointers (which probably would be welcomed by some embedded developers). By explicitly defining the limits where a specific behaviour must be expected then the C standard clearly defines what represents valid C code, which every competent C programmer is expected to understand. By not defining what can be expected when programmers intentionally go beyond them, the C standard grants compiler writers the ability to provide non-portable features which may be extremely useful in some applications. These non- portable features, thanks to the way the C standard was defined, are still considered valid C code, and taking advantage of these platform-specific features, if they are clearly specified and understood, doesn't force the code to become broken; only platform-specific. Another thing which must be taken under consideration is that just because some behaviour is intentionally left undefined in the C standard it doesn't mean it must be left undefined in a compiler implementation. This includes what diagnostics to run and how to react when stumbling on a program construct which is deemed either erroneous or non-portable by an implementation. A compiler may throw errors or warnings under these circumstances if deemed appropriate by the compiler writers, and it is also possible that the absence of any diagnostic represents a compiler bug. Yet, the existence/absence of these diagnostics doesn't mean that the language is suddenly safe/unsafe. This is one of those cases. Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-09-22 11:35 -0700 |
| Message-ID | <ln4o044e90.fsf@nuthaus.mib.org> |
| In reply to | #10706 |
Rui Maciel <rui.maciel@gmail.com> writes:
> Keith Thompson wrote:
[...]
>> The safety of a language is not a simple binary attribute. But a
>> language (like ANSI C) that diagnoses function calls with the wrong
>> number of arguments is *safer* than a language (like pre-ANSI C)
>> that doesn't.
>
> I see what you mean, and you have a point. Nonetheless, some C use cases
> tend to be left undefined in order to make it possible for compiler
> developers to provide features which otherwise would be in violation of the
> C standard. In this specific case, the C standard only defines the portions
> of a program where the storage of a specific object is guaranteed to be
> reserved. As a consequence, it is up to the compiler developers to specify
> how objects are stored in their platform. This means that they are free to
> implement anything between eliminating the memory storage right after it is
> no longer guaranteed by the C standard and implementing some form of garbage
> collection, where malloc/free could effectively be replaced by assigning the
> reference of local objects to pointers (which probably would be welcomed by
> some embedded developers).
Certainly if I write something simple like:
void func(void) {
int local = 42;
return &local;
}
then I've made a beginner's mistake, and it's probably my own fault,
even though the compiler isn't required to diagnose it.
But I think you're ignoring the fact that many errors are *subtle*. Toy
examples, don't quite illustrate the point, but more realistic examples
are difficult to read.
Bugs are inevitable even in code written by highly skilled and
experienced programmers. Some languages do a better job than others of
helping to diagnose those errors. (C isn't one of those languages, but
there are valid reasons for the tradeoffs C makes.)
> By explicitly defining the limits where a specific behaviour must be
> expected then the C standard clearly defines what represents valid C code,
> which every competent C programmer is expected to understand.
[...]
Understanding the limits is one thing. Consistently avoiding them while
writing or maintaining complex software is quite another.
--
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 | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2011-09-24 13:25 +0100 |
| Message-ID | <4e7dcc3e$0$16753$a729d347@news.telepac.pt> |
| In reply to | #10716 |
Keith Thompson wrote:
> Certainly if I write something simple like:
>
> void func(void) {
> int local = 42;
> return &local;
> }
>
> then I've made a beginner's mistake, and it's probably my own fault,
> even though the compiler isn't required to diagnose it.
>
> But I think you're ignoring the fact that many errors are *subtle*. Toy
> examples, don't quite illustrate the point, but more realistic examples
> are difficult to read.
>
> Bugs are inevitable even in code written by highly skilled and
> experienced programmers. Some languages do a better job than others of
> helping to diagnose those errors. (C isn't one of those languages, but
> there are valid reasons for the tradeoffs C makes.)
Yes, that is true; many errors are very subtle, and they are extremely hard
to pinpoint, even when employing specialized tools to weed them out.
Nonetheless, there is nothing subtle about assigning a global pointer to the
reference of a local object, and then expecting to access it beyond the
object's lifetime. A programmer must expressly write code for this effect,
and a programmer only does this if he doesn't know what he is doing.
Regarding how some languages do a better job than others of helping to
diagnose those errors, this is debatable. In this case, the C standard
leaves this behavior undefined to open the door for compiler developers to
implement any memory management policy they see fit. For this purpose, it
wouldn't be reasonable to mandate strict rules that interpreted this form of
memory access as being an error, as it would negate the motivation behind
leaving this behavior undefined. Yet, just because the standard doesn't
enforce any sanity check in this circumstance, this doesn't mean compiler
developers are barred from implementing them. In fact, some compilers do
test for this sort of error. For example, consider the following code:
<code>
int* test(void)
{
int test = 1;
return &test;
}
int main(void)
{
int *foo = test();
return 0;
}
</code>
When compiling this code with gcc, and without passing any flags, the
following warning is shown:
<message>
rui@Kubuntu:tmp$ gcc main.c
main.c: In function ‘test’:
main.c:5:2: warning: function returns address of local variable
</message>
When compiling this code with clang, the following warning is shown:
<message>
rui@Kubuntu:tmp$ clang main.c
main.c:5:10: warning: address of stack memory associated with local variable
'test' returned
return &test;
~^~~~
1 warning generated.
</message>
This diagnostic isn't mandated by the C standard, but at least two compilers
have implemented it. This doesn't mean that the C programming language
suddenly became safer with these platform-specific diagnostics, or that it
was less safe in the past. The language is still the same, the code is
still broken and the sole cause is still the programmer's incompetence.
>> By explicitly defining the limits where a specific behaviour must be
>> expected then the C standard clearly defines what represents valid C
>> code, which every competent C programmer is expected to understand.
> [...]
>
> Understanding the limits is one thing. Consistently avoiding them while
> writing or maintaining complex software is quite another.
Some limits are pretty obvious and pretty hard to miss, unless a programmer
is incompetent. This example would fit into this category.
It's also important to mention that this doesn't mean that C is free from
any safety issue. Yet, some of these accusations are baseless and absurd,
and only contribute to grow a myth about a problem which is far greater, far
more widespread and far more serious than what it really is, and this while
absolving any incompetence which caused it, no matter how profound it might
have been. This safety myth has grown so much that nowadays, by the
comments some people make, it almost sounds like even the smallest hello
world program written in C represents a potential security breach which no
other programming language is capable of causing. And this doesn't benefit
anyone.
Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-09-26 22:59 +0000 |
| Message-ID | <slrnj820t9.msp.usenet-nospam@guild.seebs.net> |
| In reply to | #10681 |
On 2011-09-21, Keith Thompson <kst-u@mib.org> wrote: > You almost seem to be implying that only incompetent programmers > make mistakes. I think what you really mean is that only incompetent > programmes make *certain kinds* of mistakes -- but I think that's > unrealistic. For better or worse, I make a LOT of the kinds of mistakes that "only" incompetent programmers make. I have fairly extreme ADHD, and the functional upshot is that I can do a lot of things that are too hard for most people to even attempt, but I can't do a lot of things that they take for granted, because my brain simply *won't stay focused long enough* if a task isn't Really Hard. If something isn't compelling enough to draw my whole attention to it, I'm off thinking about unrelated things within a second or two. This can be really useful, but it can also be very disruptive. Net result, I can write something interesting and nontrivial in which the only errors are mismatched ()s, missing semicolons, and format strings without their corresponding arguments -- the logic is fine on the first try. :) -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2012-01-24 13:30 -0800 |
| Message-ID | <kfnfwf4g54v.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #10976 |
Seebs <usenet-nospam@seebs.net> writes: > On 2011-09-21, Keith Thompson <kst-u@mib.org> wrote: >> You almost seem to be implying that only incompetent programmers >> make mistakes. I think what you really mean is that only incompetent >> programmes make *certain kinds* of mistakes -- but I think that's >> unrealistic. > > For better or worse, I make a LOT of the kinds of mistakes that "only" > incompetent programmers make. I have fairly extreme ADHD, and the functional > upshot is that I can do a lot of things that are too hard for most people to > even attempt, but I can't do a lot of things that they take for granted, > because my brain simply *won't stay focused long enough* if a task isn't > Really Hard. If something isn't compelling enough to draw my whole attention > to it, I'm off thinking about unrelated things within a second or two. I was going to post a really funny response to this, but then I started thinking about something else...
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.com> |
|---|---|
| Date | 2011-09-22 18:23 +0100 |
| Message-ID | <pan.2011.09.22.17.23.52.269000@nowhere.com> |
| In reply to | #10676 |
On Wed, 21 Sep 2011 20:44:05 +0100, Rui Maciel wrote: >> To me dangling pointers represent the very definition of unsafeness. >> What is an unsafe language to you? > > The example you provided represented poorly written code where a pointer > refers to an object after it's lifetime as ended. Understanding an object's > storage duration is very basic stuff. Therefore, this code goes against > extremely basic concepts which are clearly defined and therefore can only be > written by incompetent programmers. Wrong. Anyone can make mistakes, particularly when working on poorly-designed and under-documented code with a tight schedule and limited manpower. Moreso if large sections have incorrect documentation and no source code. > A programming language cannot be deemed > safe or unsafe due to mistakes made by incompetent programmers. Actually, this is pretty much the definition of "safe". You can write correct code in even the most unsafe language. Safety is a question of how difficult the language makes it to write incorrect code. Statically-typed languages make it harder to make incorrect assumptions about the type of a value. Languages with only "managed" pointers make dangling references impossible. Languages which lack mutable state make entire classes of bugs impossible.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2011-09-21 15:40 +0000 |
| Message-ID | <j5d0hv$5kr$1@news.xmission.com> |
| In reply to | #10595 |
In article <4e78f388$0$24712$a729d347@news.telepac.pt>,
Rui Maciel <rui.maciel@gmail.com> wrote:
...
>If the language specification clearly states that y's lifetime ends when f()
>finishes executing then referring to that object before or after f() is
>executed represents bad code which is a sign of incompetence, not an
>indication that the language is unsafe.
You seem to be equating "unsafe" with bad. In fact, no such moral judgement
is being made.
I think most (sensible) people would agree that C is unsafe. So is
dynamite. Both are quite useful. Neither should be used by ordinary
citizens.
In this day and age, C is not a consumer product (neither is dynamite). C
once was (dynamite never was).
--
Faced with the choice between changing one's mind and proving that there is
no need to do so, almost everyone gets busy on the proof.
- John Kenneth Galbraith -
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2011-09-21 20:20 +0100 |
| Message-ID | <4e7a38ff$0$24696$a729d347@news.telepac.pt> |
| In reply to | #10643 |
Kenny McCormack wrote: > You seem to be equating "unsafe" with bad. In fact, no such moral > judgement is being made. In this specific case I'm equating bad as being bad. If someone fails to consider an object's lifetime when designing code which assigns a pointer to a reference of that object, and then proceeds to rely on that pointer to refer to that object even when the object is no longer guaranteed to exist then this is bad code. If this case is being used to attempt to demonstrate how C is unsafe but it only manages to present code which is buggy and fundamentally broken then it isn't possible to even consider if the code can be seen as unsafe. This example is, by definition, an "erroneous program". It isn't possible to debate the perceived safety of a programming language by trying to pin on the programming language a set of problems which are a consequence of failing to write valid code in it. Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | Kleuskes & Moos <kleuske@somewhere.else.net> |
|---|---|
| Date | 2011-09-19 06:39 +0000 |
| Message-ID | <j56o2o$gct$1@dont-email.me> |
| In reply to | #10468 |
On Sun, 18 Sep 2011 23:10:54 -0400, Joe Wright wrote:
> On 9/18/2011 20:32, Keith Thompson wrote:
>> cri@tiac.net (Richard Harter) writes: [...]
>>> Any language in which it is possible for a pointer to be invalid but
>>> which provides no way to test for validity is fundamentally flawed.
>>
>> What existing language has pointers and is not "fundamentally flawed"?
>>
> Indeed. Testing a pointer by simple inspection can tell you whether it
> is null or not. If it is null it is not valid. If not you simply can't
> tell.
I actually consider NULL a valid value for a pointer, and of course
checking for NULL pointers, if called for, is not what i had in mind.
--
-------------------------------------------------------------------------------
_______________________________________
/ If I had a Q-TIP, I could prevent th' \
\ collapse of NEGOTIATIONS!! /
---------------------------------------
\
\
___
{~._.~}
( Y )
()~*~()
(_)-(_)
-------------------------------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-09-19 10:06 -0700 |
| Message-ID | <lnr53c5uo4.fsf@nuthaus.mib.org> |
| In reply to | #10479 |
Kleuskes & Moos <kleuske@somewhere.else.net> writes:
> On Sun, 18 Sep 2011 23:10:54 -0400, Joe Wright wrote:
>> On 9/18/2011 20:32, Keith Thompson wrote:
>>> cri@tiac.net (Richard Harter) writes: [...]
>>>> Any language in which it is possible for a pointer to be invalid but
>>>> which provides no way to test for validity is fundamentally flawed.
>>>
>>> What existing language has pointers and is not "fundamentally flawed"?
>>>
>> Indeed. Testing a pointer by simple inspection can tell you whether it
>> is null or not. If it is null it is not valid. If not you simply can't
>> tell.
>
> I actually consider NULL a valid value for a pointer, and of course
> checking for NULL pointers, if called for, is not what i had in mind.
The phrase "valid pointer" is context-dependent. NULL is not valid
as the operand of the unary "*" operator; it's perfectly valid as
the argument of free().
--
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 | Kleuskes & Moos <kleuske@somewhere.else.net> |
|---|---|
| Date | 2011-09-20 07:03 +0000 |
| Message-ID | <j59dr5$g5v$1@dont-email.me> |
| In reply to | #10505 |
On Mon, 19 Sep 2011 10:06:03 -0700, Keith Thompson wrote:
> Kleuskes & Moos <kleuske@somewhere.else.net> writes:
>> On Sun, 18 Sep 2011 23:10:54 -0400, Joe Wright wrote:
>>> On 9/18/2011 20:32, Keith Thompson wrote:
>>>> cri@tiac.net (Richard Harter) writes: [...]
>>>>> Any language in which it is possible for a pointer to be invalid but
>>>>> which provides no way to test for validity is fundamentally flawed.
>>>>
>>>> What existing language has pointers and is not "fundamentally
>>>> flawed"?
>>>>
>>> Indeed. Testing a pointer by simple inspection can tell you whether it
>>> is null or not. If it is null it is not valid. If not you simply can't
>>> tell.
>>
>> I actually consider NULL a valid value for a pointer, and of course
>> checking for NULL pointers, if called for, is not what i had in mind.
>
> The phrase "valid pointer" is context-dependent.
Aye. But "valid value for a pointer" is not.
> NULL is not valid as
> the operand of the unary "*" operator; it's perfectly valid as the
> argument of free().
True, but that's not what i said. 0 is a valid value for an integer, while
it's an invalid (rhs) operand for '/' and '%'.
-------------------------------------------------------------------------------
______________________________________
/ over in west Philadelphia a puppy is \
\ vomiting ... /
--------------------------------------
\
\
___
{~._.~}
( Y )
()~*~()
(_)-(_)
-------------------------------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
Page 13 of 15 — ← Prev page 1 … 11 12 [13] 14 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web