Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Why not realloc(&ptr, ...) and free(&ptr)?

Reply
Thread Tools

Why not realloc(&ptr, ...) and free(&ptr)?

 
 
James Kuyper
Guest
Posts: n/a
 
      08-07-2013
On 08/07/2013 06:01 AM, James Harris wrote:
> "James Kuyper" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> On 08/06/2013 03:01 PM, Scott Fluhrer wrote:
>>> "Shao Miller" <(E-Mail Removed)> wrote in message
>>> news:ktocmj$u9$(E-Mail Removed)...

>> ...
>>>> void func(void) {
>>>> long * lp;
>>>>
>>>> lp = malloc(sizeof *lp);
>>>> /* ... */
>>>> free(lp);
>>>> lp = NULL;
>>>> }
>>>>
>>>> There's not really a need to set 'lp' to a null pointer value, here, as
>>>> its lifetime is about to expire. You might want to for security
>>>> reasons,
>>>> perhaps, but then it does cost time.
>>>
>>> Actually, it doesn't likely cost anything. If the compiler is even
>>> slightly
>>> aggressive about optimization, it will realize that lp is a dead variable
>>> here (no further reads), and hence will optimize the assignment out.

>>
>> True. The program isn't going to waste any time executing that line of
>> code, because the compiler is going to spend a completely negligible
>> amount of time figuring that it can be dropped. On the other hand, the
>> author wasted his time writing that line of code, and others will waste
>> time reading it and puzzling over why it's there. I think the waste of
>> their time is far more important than the time the compiler will waste.

>
> In a tiny program that's true but consider that in a large program where the
> pointer is reused as an rval as
>
> *p


I was talking very specifically about the case given in Shao Miller's
example above, where the variable's lifetime ends immediately after it
is set to NULL. I strongly recommend nulling any pointer variable that
points into a block of allocated memory immediately after free(), if it
will continue to be used after being nulled. On the other hand, I
strongly recommend avoiding the creation of such variables. Whenever
possible (which, in my experience, is fairly frequently), I arrange to
make sure that pointer objects containing pointers into a piece of
allocated memory have lifetimes that end immediately after the call to
free().
--
James Kuyper
 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      08-08-2013
Keith Thompson <(E-Mail Removed)> writes:

> Shao Miller <(E-Mail Removed)> writes:
>> On 8/5/2013 14:39, Keith Thompson wrote:

> [...]
>>> I think there's a DR (which I can't find at the moment) that says that
>>> free(p) can actually change the representation of p -- which implies
>>> that the unsigned char objects that make up its representation can have
>>> their values change. If I'm remembering it correctly, I'm not at all
>>> convinced that that can be derived from the normative wording of the
>>> standard. (Can someone else find a reference to it?)
>>>

>>
>> DR #260?:
>>
>> http://www.open-std.org/jtc1/sc22/wg...ocs/dr_260.htm

>
> Yeah, that's the one.
>
> The committee response says, in effect, that the representation of a
> pointer p can change after free(p):
>
> Values may have any bit-pattern that validly represents them
> and the implementation is free to move between alternate
> representations (for example, it may normalize pointers,
> floating-point representations etc.). In the case of an
> indeterminate value all bit-patterns are valid representations
> and the actual bit-pattern may change without direct action of
> the program.
>
> The DR mentions the issue that the bytes making up the
> representation are themselves objects, and that the requirement
> that "An object [...] retains its last-stored value throughout
> its lifetime." implies that those bytes cannot change. The
> response seems to ignore that argument.
>
> On the other hand, I actually like the conclusion.


It's a horrendous ruling. I have great respect for people
on the committee, but the decision in this case shows
very muddy thinking.

> As the DR discusses, it permits certain optimizations.


That's a bogus argument, because it's comparing apples and
oranges. A code transformation is rightly called an optimization
only when it preserves program semantics; the examples given
work only by taking advantage of more relaxed semantics, and
hence should not be called optimizations. Furthermore there is
no reason to think the gain of such "optimizations" would
amount to much - they don't happen very often, and don't
provide much relative value when they do. The potential
benefits are way not worth the cost in consistency.

> I think I would have preferred to have an explicit normative
> statement added to the standard, saying that objects with
> indeterminate values can have their representations change behind
> the scenes.
>
> Note that the response applies to more than just objects with
> indeterminate values. If a type has multiple representations for
> the same value, an object's representation can switch between
> those representations -- which changes the values of the unsigned
> char objects that make up its representation. This has
> implications for the use of memcmp() to compare things other than
> byte arrays.


More muddy thinking. The rule in such cases should be the same
as for regular representations - the program must behave
according to the semantics of the abstract machine, with
optimizations allowed only under the as-if rule. The idea that
object representations (when stored in an object accessible to
the program) may sensibly spontaneously change is lunacy.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
difference between *ptr++ and ++*ptr ? Jason C Programming 19 05-19-2005 04:50 PM
is (!ptr) or (ptr) valid way to check for NULL or NOT NULL? G Fernandes C Programming 9 02-27-2005 03:07 AM
what's the difference between delete ptr and ptr=0 -dont they accomplish the same Sid C++ 5 07-29-2004 03:42 AM
Re: realloc, need to free old ptr? Christopher Benson-Manica C Programming 4 09-01-2003 09:26 PM



Advertisments