It is supposed to work, that's why generate_disposal_code and free_temps are seperate calls. The former can be called multiple times in generate_..._code, the latter must be called exactly once. The temporary variable will be held on to until the end of the C branch, which is optimized away by gcc.
You'll find examples somewhere of this, but I can't remember where at the moment. Dag Sverre Seljebotn -----Original Message----- From: Robert Bradshaw <[email protected]> Date: Saturday, Jan 17, 2009 11:37 pm Subject: Re: [Cython] Temp allocation bug To: [email protected]: [email protected] On Jan 17, 2009, at 2:20 PM, Dag Sverre Seljebotn wrote: > >> Robert wrote: >> Is this going to be a general problem with any inside a >> NewTempExprNode (plain) ExprNode? That could be bad. On that note, is >> there any reason that temp freeing is done as a separate step now >> instead of as part of the disposal code? (Someone more familiar with >> the new code probably has a trivial answer to this.) > >> Some code is generated like this: > >> /*allocate node*/ > if (something) { > block A > /* deallocate node */ > } else { > block B > /* deallocate node */ > } > >> If temp releasing is tied up with disposal, the temp can be > reallocated > and reused in block B, leading to disaster. Also it would be released > twice. Etc. > >> If the C control flow matched the node tree, this wouldn't be a > problem, > but it doesn't. > >> Pyrex didn't have this problem, but that meant that deallocation (i.e. > decrefs) is done later than necesarry. > >Ah, I see. > >Well, I'd rather deallocate too late than deallocate incorrectly. >Does this mean that it's all or nothing with the NewTempExprNodes, or >is a mix and match supposed to work? > >- Robert > >_______________________________________________ >Cython-dev mailing list >[email protected] >http://codespeak.net/mailman/listinfo/cython-dev > _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
