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

Jim Idle jimi at temporal-wave.com
Wed Sep 23 18:05:26 PDT 2009



On Sep 23, 2009, at 5:31 PM, David-Sarah Hopwood <david-sarah at jacaranda.org 
 > wrote:

> Jim Idle wrote:
>> The following should be read carefully before upgrading to release  
>> 3.2
>> of the C target:
> [...]
>>   * finally - this code is executed whether the rule parses
>>     successfully or not. This is probably where you should free
>>     allocations, but you should guard against uninitialized elements,
>>     which may not have been created on a parse error.
>
> Are such elements (not variables that you declare yourself) guaranteed
> to be NULL?

Yes, this is one of the issues of trying to use something other than  
pointers.
>
>>   * Because you can end up executing both @after and finally code,  
>> use
>>     safe programming patterns (you should be anyway ;-, and assign
>>     NULL to anything after declaring it and immediately before  
>> freeing
>>     it.
>
> You mean immediately after freeing it :-)
> (i.e. "free(foo); foo = NULL;")

You know what I mean ;)
>
>>     Also, guard against free(NULL) unless the semantics of your
>>     system specify that free(NULL) is allowed.
>
> "free(NULL)" is defined to be a no-op by the C standard. A libc
> implementation that got this wrong would be badly broken, and AFAIK  
> all
> the commonly used platforms get it right.

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?
>
> -- 
> David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com
>
>
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address


More information about the antlr-interest mailing list