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? > * 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;") > 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. -- 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "il-antlr-interest" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en -~----------~----~----~----~------~----~------~--~---
