SEO
vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
02-18-2008, 07:17 AM
| ||||
| ||||
 Re: Anatomy of a bug : bgpd.c 1.105 : part 2 * Erblichs <erblichs@earthlink.net> [2004-09-14 01:20]: > Fine group, > > Here are a few questions after a few minutes > just scanning the code. > > Mitchell Erblich > Sr Software Engineer > --------------------- > > parse.y : 1.139 > > parse_config() > > There are three calloc's in a row. > After the 2nd and third calloc's failed > attempts their should be frees of > the conf and the conf/mrtconf structs. > > Else, it looks like a memory leak. so, with all your years long experience in commercial software development you are not able to follow the code path so far to realize that fatal() terminates bgpd? And sure you know what happens with a process' allocations when it exits under unix... > new_peer() > Calls alloc_peer() but doesn't check if > p is NULL and return with a NULL if so. > > Why not? so, with all your years long experience in commercial software development you are not able to spot that alloc_peer() cannot return NULL? > bgpd.c > > sighdlr() > Should have a default case. of course it should not. > main() > getuid() returns the effective user id. > Shouldn't you print the value when you print > "need root privileges". no, why. "need root" is pretty clear... sure shows that commercial software development is superiour to our little free software toys...      |
Linear Mode
