[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