Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Typecasting Pointers on a 64 bit System |
| Date | 2011-11-18 14:24 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <87fwhlaaaf.fsf@bazspaz.fatphil.org> (permalink) |
| References | (6 earlier) <4EC18C2D.2010001@verizon.net> <9idh7dFhikU4@mid.individual.net> <4EC192F0.3000908@verizon.net> <87k470bhma.fsf@bazspaz.fatphil.org> <ja087s$oq6$1@dont-email.me> |
James Kuyper <jameskuyper@verizon.net> writes: > On 11/16/2011 03:23 AM, Phil Carmody wrote: > > James Kuyper <jameskuyper@verizon.net> writes: > >> On 11/14/2011 04:58 PM, Ian Collins wrote: > ... > >>> In the same vein as "as long as you hold the knife by the handle, what's > >>> the problem?". > >> > >> I would interpret a question such as that as one which dismisses the > >> importance of having to hold the knife by the handle, because it's easy > >> to arrange to do so. I had assumed you were doing the same: implicitly > >> asserting that it's trivial to arrange that the address remains valid; > > > > By default, addresses remain valid unless you explicitly do something > > that makes them invalid. > > Off-hand I can think of three ways by which previously valid addresses > can be come invalid, and three of them are quite explicit: free(), > realloc(), and fclose(). > However, the addresses of variables with automatic storage duration > become invalid as soon as execution of the block in which they are > defined ends; that seems pretty implicit to me. YMMV I was considering the ending of a scope to be quite explicit. > I hope you're not suggesting that the fact that free(), realloc() and > fclose() can only occur explicitly somehow makes it trivial to ensure > that they have not yet been called for a given pointer? If that were the > case, garbage collection wouldn't be as popular an extension as it is. > Even in single-threaded code it takes a certain amount of discipline to > ensure that a pointer is not used after the memory it points to has been > free()d. That's the fallacy of the hasty generalisation. Whilst /in general/ it's hard to ensure all pointers are treated safely, that doesn't mean for every single pointer it's hard. > When possible, I try to make sure that pointers into dynamically > allocated memory are stored only in automatic objects whose lifetime > ends immediately after the call to free(), rendering it impossible for > such problems to occur. However, it's not always possible to impose such > restrictions. When I can't do that, I insert code setting the pointer to > NULL immediately after the free(). However, to be helpful, that requires > that I protect all problematic uses of such a pointer with tests to > determine whether it's null. That started off sounding like good defensive programming, but as the issue in question was having multiple pointers to the same block of memory, resetting and checking the pointer is not a solution. > When the expressions p=malloc(), *p=3, x=*p, and free(p) occur in two or > more different threads executing asynchronously, it seems to me that it > would be all that much harder to ensure that they occur only in the > proper order. I'm not saying it's impossible - just that it's harder. > Though Ian has assured me that this is not the case, I don't quite see > how that could be. If the creator is tasked with freeing the memory, then clearly some synchronisation is required. However, it the thread is tasked with the free, then none is required (and the creator may defensively NULL the pointer it no longer may assume is valid). Phil -- Unix is simple. It just takes a genius to understand its simplicity -- Dennis Ritchie (1941-2011), Unix Co-Creator
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Typecasting Pointers on a 64 bit System Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2011-11-10 20:21 +0000
Re: Typecasting Pointers on a 64 bit System Lauri Alanko <la@iki.fi> - 2011-11-10 20:29 +0000
Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 20:51 +0000
Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 20:58 +0000
Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-10 16:08 -0500
Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 21:35 +0000
Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-10 17:18 -0500
Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 23:14 +0000
Re: Typecasting Pointers on a 64 bit System Richard Damon <news.x.richarddamon@xoxy.net> - 2011-11-10 19:36 -0500
Re: Typecasting Pointers on a 64 bit System Ben Pfaff <blp@cs.stanford.edu> - 2011-11-10 12:32 -0800
Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-10 15:44 -0500
Re: Typecasting Pointers on a 64 bit System Keith Thompson <kst-u@mib.org> - 2011-11-10 12:58 -0800
Re: Typecasting Pointers on a 64 bit System blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-11-17 15:53 +0000
Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 20:45 +0000
Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 21:00 +0000
Re: Typecasting Pointers on a 64 bit System Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-11-10 15:14 -0700
Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-11 11:22 +1300
Re: Typecasting Pointers on a 64 bit System William Ahern <william@wilbur.25thandClement.com> - 2011-11-14 11:10 -0800
Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-15 08:28 +1300
Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-14 14:48 -0500
Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-15 10:15 +1300
Re: Typecasting Pointers on a 64 bit System jacob navia <jacob@spamsink.net> - 2011-11-14 22:18 +0100
Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-15 10:26 +1300
Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-14 16:46 -0500
Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-15 10:58 +1300
Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-14 17:15 -0500
Re: Typecasting Pointers on a 64 bit System blp@cs.stanford.edu (Ben Pfaff) - 2011-11-14 14:18 -0800
Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-15 11:29 +1300
Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-14 18:14 -0500
Re: Typecasting Pointers on a 64 bit System Seebs <usenet-nospam@seebs.net> - 2011-11-14 23:01 +0000
Re: Typecasting Pointers on a 64 bit System Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-16 10:39 +0200
Re: Typecasting Pointers on a 64 bit System Seebs <usenet-nospam@seebs.net> - 2011-11-16 20:18 +0000
Re: Typecasting Pointers on a 64 bit System Fritz Wuehler <fritz@spamexpire-201111.rodent.frell.theremailer.net> - 2011-11-17 02:54 +0100
Re: Typecasting Pointers on a 64 bit System pete <pfiland@mindspring.com> - 2011-11-16 21:29 -0500
Re: Typecasting Pointers on a 64 bit System Seebs <usenet-nospam@seebs.net> - 2011-11-17 02:31 +0000
Re: Typecasting Pointers on a 64 bit System Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-18 14:31 +0200
Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-17 02:44 +0000
Re: Typecasting Pointers on a 64 bit System Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-11-16 21:33 -0700
Re: Typecasting Pointers on a 64 bit System "io_x" <a@b.c.invalid> - 2011-11-17 04:01 +0100
Re: Typecasting Pointers on a 64 bit System blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-11-17 15:46 +0000
Re: Typecasting Pointers on a 64 bit System Seebs <usenet-nospam@seebs.net> - 2011-11-17 18:48 +0000
Re: Typecasting Pointers on a 64 bit System blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-11-18 14:48 +0000
Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-15 14:37 +1300
Re: Typecasting Pointers on a 64 bit System Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-16 10:23 +0200
Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-16 06:53 -0500
Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-16 11:15 -0500
Re: Typecasting Pointers on a 64 bit System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-16 17:08 +0000
Re: Typecasting Pointers on a 64 bit System Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-18 15:09 +0200
Re: Typecasting Pointers on a 64 bit System Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-18 14:24 +0200
Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-18 10:08 -0500
Re: Typecasting Pointers on a 64 bit System Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-18 17:52 +0200
Re: Typecasting Pointers on a 64 bit System Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-11-14 15:45 -0700
Re: Typecasting Pointers on a 64 bit System "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2011-11-10 15:19 -0800
Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 23:41 +0000
Re: Typecasting Pointers on a 64 bit System Keith Thompson <kst-u@mib.org> - 2011-11-10 20:48 -0800
Re: Typecasting Pointers on a 64 bit System "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2011-11-14 03:39 -0800
Re: Typecasting Pointers on a 64 bit System Lauri Alanko <la@iki.fi> - 2011-11-14 13:08 +0000
Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-14 09:21 -0500
Re: Typecasting Pointers on a 64 bit System Keith Thompson <kst-u@mib.org> - 2011-11-14 12:54 -0800
csiph-web