On Wednesday 28 October 2009 08:08:40 Peter Kjellerstedt wrote: > > From: Mike Frysinger [mailto:[email protected]] > > On Wednesday 28 October 2009 04:57:01 Peter Kjellerstedt wrote: > > > From: Mike Frysinger > > > > our friend goto solves the leak. stick it in the middle of the file > > > > to maximize short forward/backward jumps and we only get a small > > > > increase: > > > > > > > > @@ -114,6 +114,8 @@ char got_path[]; > > > > while (*path != '\0' && *path != '/') { > > > > if (new_path > max_path) { > > > > __set_errno(ENAMETOOLONG); > > > > + err: > > > > + free(allocated_path); > > > > return NULL; > > > > > > Fore readability, wouldn't it be better to put the three lines > > > above at the end of the function, and just put another goto err > > > here? Or is there some other reason to have the error exit path > > > in the middle of the function? > > So, in effect it is an architecture specific optimization.
if it's an optimization that most arches can utilize, and there is no difference to arches that lack short forward/backward jumps, then it's certainly a valid one to utilize imo. sad that gcc itself didnt do it, but handling of jumps is pretty hard to do. > With that kind of optimization, isn't it a sign that the > function is too long and should be split? feel free to tackle that pig, but considering it's all going to be done with static functions that are used once so gcc's going to inline anyways, i dont see much point here. unless doing so allows gcc to do some crazy magic and get smaller code ... > In any case, there should be a comment explaining why the exit path > is in the middle of the function, or someone is bound to rearrange > the code for readability at a later stage. certainly -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
