Messages in this thread | | | Date | Tue, 2 Nov 2004 16:12:09 -0500 (EST) | From | linux-os <> | Subject | Re: question on common error-handling idiom |
| |
On Tue, 2 Nov 2004, Jan Engelhardt wrote:
>> There's something I've been wondering about for a while. There is a lot of code >> in linux that looks something like this: >> >> err = -ERRORCODE >> if (error condition) >> goto out; > > That's because there might something as: > > err = -EPERM; > if(error) { goto out; } > do something; > if(error2) { goto out; } > do something more; > if(error3) { goto out; } > > Is shorter than: > > if(error) { err = -EPERM; goto out; } > do something; > if(error2) { err = -EPERM; goto out; } > do something more; > if(error3) { err = -EPERM; goto out; } > > >> Is there any particular reason why the former is preferred? Is the compiler > > To keep it short. Because it might have been worse than just err =xxx: > > if(error) { > do this and that; > and more; > even more; > more more; > goto out; > } > > Repeating that over and over is not that good. So we wrap it a little bit to do > a "staircase" deinitialization: > > err = -EPERM; > if(error) { goto this_didnot_work; } > ... > err = -ENOSPC; > if(error) { goto that_didnot_work; } > > > this_didnot_work: > all uninitializations needed > > that_didnot_work: > all other uninit's > > return err; > > > So to summarize, it's done to reduce code whilst keeping the error code around > until we actually leave the function. > > > My ÿÿ 0.02! > > > Jan Engelhardt > -- > Gesellschaft fÿÿr Wissenschaftliche Datenverarbeitung > Am Fassberg, 37077 Gÿÿttingen, www.gwdg.de
I think it's just to get around the "uninitialized variable" warning when the 'C' compiler doesn't know that it will always be initialized.
Cheers, Dick Johnson Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by John Ashcroft. 98.36% of all statistics are fiction. | |