[BusyBox] Re: newlib's libbb/printf.c [PATCH]

[Rob Landley]

On Wednesday 27 July 2005 02:23, Shaun Jackman wrote:
> On 7/27/05, Rob Landley <rob at landley.net> wrote:
> > B) If newlib is lying and claiming to be glibc, yet doesn't work like
> > glibc for something that we care about, why isn't it newlib that's
> > broken?
>
> It's not that newlib is lying, but that newlib doesn't provide the
> Linux specific headers needed by busybox. To be able to compile
> busybox using newlib, you need a few glibc headers for the Linux
> specific features. Including any header from glibc defines __GLIBC__
> though. I know using headers from two different libc is scary, but
> it's the only way to make it work for now.

Huh.  That sucks deeply.  Have you tried Maszur's cleaned up 2.6 headers?  
(Which kernel are you using?)

What features, specifically, does busybox need these glibc headers for?

> > C) Half this patch is whitespace noise adding spaces between the # and
> > the preprocessor directive (which I personally consider a regression, and
> > would have applied a patch to _undo_.  But that's just me...)
>
> Eh? No it's not. It move nine lines totally verbatim (cut and paste)
> from one place to another. Six of thoses lines are comments. Are we
> looking at the same patch?

svn diff -r 10921:10922 | less

@@ -81,7 +90,7 @@
  * #define _IO_feof_unlocked(__fp) (((__fp)->_flags & _IO_EOF_SEEN) != 0)
  * #define _IO_ferror_unlocked(__fp) (((__fp)->_flags & _IO_ERR_SEEN) != 0)
  */
-#define SET_FERROR_UNLOCKED(S)    ((S)->_flags |= _IO_ERR_SEEN)
+#  define SET_FERROR_UNLOCKED(S)    ((S)->_flags |= _IO_ERR_SEEN)

 # else
 /* Assume the older version of glibc which used a bitfield entry
@@ -90,19 +99,10 @@
  * #define feof_unlocked(stream)         ((stream)->__eof != 0)
  * #define ferror_unlocked(stream)       ((stream)->__error != 0)
  */
-#define SET_FERROR_UNLOCKED(S)    ((S)->__error = 1)
+#  define SET_FERROR_UNLOCKED(S)    ((S)->__error = 1)

And so on...

(Sorry, this hits two pet peeves of mine.  Mixing unrelated whitespace changes 
and functional changes in the same patch, and doing cruel things to 
preprocessor directives.  The first gives me hives, and the second... If a 
cluster of preprocessor directives are so complicated there's a burning 
_need_ to indent them, that's a pretty good sign the preprocessor is being 
abused anyway.  Again, personal pet peeve...)

> Cheers,
> Shaun

Rob