[antlr-interest] Updates for release 3.2 of the C Target

[Jim Idle]

On 09/24/2009 11:04 AM, David-Sarah Hopwood wrote:
> Gavin Lambert wrote:
>    
>> At 13:05 24/09/2009, Jim Idle wrote:
>>      
>>> Some platforms define this to be undefined though. Remember there
>>> are lots if embedded systems that use this. Hence the qualification.
>>> I think it would have been better to define free(NULL) as safe
>>> myself but early Lib C would crash if you did this and I think it
>>> was C++ that first took a stand?
>>>        
>> I haven't looked at the standards recently, but from what I recall
>> "delete NULL;" is guaranteed safe but "free(NULL);" wasn't.
>>      
> C89 clause 4.10.3.2:
>
> # The free function causes the space pointed to by ptr to be
> # deallocated, that is, made available for further allocation.
> # If ptr is a null pointer, no action occurs. [...]
>
> (This is the same in C89 and C99; in the latter it is clause 7.20.3.2.)
>    
However, some of us had been C programmers for quite some time before 
'89 and of course the standards don't kick in automagicaly and 
retroactively on the day of their publication - I wish they did!
>> I definitely recall seeing some static testers and malloc replacements
>> (some for performance, some for allocation debugging) that reacted badly
>> to use of "free(NULL);" (sometimes just a failed assertion, sometimes
>> worse).
>>      
> That would be a bug. C89 is 20 years old; there's really no excuse for
> writers of testers and malloc replacements not to have read the sections
> of it that directly apply to them.
>
>    

Yeah - you are correct of  course, but even now I find implementations 
that will segv if you try this, so realistically, as the gate is going 
to cost you nothing at all, then belt and braces always seems like a 
good idea :-) But regardless, one should always set the pointer to NULL 
/after/ ;-) freeing it.

Jim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20090924/9d8a7d45/attachment.html