Resolving the licensing issues.

[Rob Landley]

On Thursday 02 March 2006 3:41 am, Vladimir N. Oleynik wrote:
> Yann E. MORIN wrote:
> > For all these reasons, being a maintainer is a hard work, and I'm glad
> > someone like Rob Landley is maintaining busybox. I would not like for
> > anything in the world to be in his place.
> >
> > To me, Rob does a good job at maintaining busybox.
>
> Last some hours ago example:
>
> http://www.busybox.net/lists/busybox/2006-March/018852.html
>
> without comment the 5 years busybox's dispute: if(p) free(p) vs free(p)

I also checked the free() man page, which says:

       free() frees the memory space pointed to by ptr, which must  have  been
       returned by a previous call to malloc(), calloc() or realloc().  Other‐
       wise, or  if  free(ptr)  has  already  been  called  before,  undefined
       behaviour occurs.  If ptr is NULL, no operation is performed.

The oldest system I have lying around is Red Hat 7, which also said "if ptr is 
NULL, no operation is performed" as well.

The Open Group Base Specifications, Version 6 say "If ptr is a null pointer, 
no action shall occur.", which you can check for yourself here:
       http://www.opengroup.org/onlinepubs/009695399/functions/free.html

So free(NULL) doing nothing is explicitly documented behavior, and it's 
smaller.  Relying on this is not exactly a huge gamble.

You recently messed with bb_strlen() which exists to save one byte per 
instance, and yet you're happy leaving if(x) free(x) littering the tree?  How 
does that make sense?

> http://www.google.com/search?q=free+NULL+site:www.busybox.net&num=1000

The top two hits of that were both Glenn, and the second hit he voted for 
free(p) without the if().  Then some unrelated cvs comments...  Then a 
message from Axel Kittenberger (whoever that is) saying free(NULL) doesn't 
hurt...  More random hits in code, a discussion of free inodes...

Eventually a hit says "Electric Fence" might care, which is about the same as 
valgrind caring that we don't free all the data on the way out.  (which we 
still don't: last I checked CONFIG_FEATURE_CLEAN_UP just reduces the noise a 
bit.)

"Controversy" is not a reason to make or not make a technical decision.  Do 
you have specific arguments against relying on behavior that the man page and 
standards explicitly document as reliable?

Rob
-- 
Never bet against the cheap plastic solution.