[Buildroot] Buildroot fails on powerpc with busybox login.c

Rob Landley rob at landley.net
Mon Sep 18 14:00:20 UTC 2006


On Monday 18 September 2006 1:44 am, Denis Vlasenko wrote:
> 	fgets(bb_common_bufsiz1, sizeof(bb_common_bufsiz1), stdin);
> 	if (strcmp(bb_common_bufsiz1,"diediedie")) exit(1);
> 
> Here it is obviously safe unless applet has a function which
> uses bb_common_bufsiz1 as a non-temporary buffer which must
> retain contents across calls (not very sane code).

I'm not awake yet.  (Monday morning meeting in 5 minutes...)  Why 
is "obviously safe" something to recommend against using?  I'm confused...

> In this particular case buffer is used for reading lines 
from /etc/securetty.
> I think it can be reduced to 128 bytes. If someone got bigger line there,
> they'll get what they asked for.

As long as we trucate rather than corrupting the stack.

> > > > login.02_of_03.diff
> > > > shrink by perusing bb_getopt_ulflags()
> > > 
> > > +#define LOGIN_OPT_f (1<<0)
> > > +#define LOGIN_OPT_h (1<<1)
> > > +#define LOGIN_OPT_p (1<<2)
> > > 
> > > Defining constants using enum {...}; is saner.
> > 
> > Why?  (I've never understood this one.  O_RDWR and O_BINARY were #defines 
back 
> > in the 1970's, what exactly's wrong with it?)
> 
> In 1970's there were no enums in C, iirc. I think this is the sole reason.

> [cut-n-pasting...]
> 
> #defines just look more familiar than enum {}. But #define has serious
> flaws: it knows nothing about scope rules, and when you accidentally
> #define name which is already used for something before or after
> #define site, possibly inside another macro/#define
> (for example: errno is a #define in glibc!), you get really obscure
> compile errors. If you are lucky, that is. If you are not,
> you get the most obscure bugs.
> 
> "enum { a = 1, b = 10 };" looks a bit ugly AT FIRST, while one
> is not yet accustomized to parse them visually,
> but has none of those "bug generator" properties.

I've been seeing them for years.  They still look ugly.

> "const a = 1;" is even better, but currently gcc+ld is not clever enough
> to optimize it out completely.

Then someday it will be.  Why not wait until then instead of doing a 
half-assed cleanup now?

I'm going to wait an hour to wake up and get less grumpy before reading more 
email...

> --
> vda

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list