Compilation broken
Rob Landley
rob at landley.net
Sun Jan 8 20:56:40 UTC 2006
On Sunday 08 January 2006 05:04, Tito wrote:
> Hi,
> Somehow while applying the bb_do_delay patch
> a change slipped in libbb.h that broke compilation
> (BTW i'm sure this was not in my patch!!!) :
>
> libbb.h Line 355
> extern const char bb_path_mtab_file[]; extern char bb_path_mtab_file[];
Sorry, it leaked in from my tree. (Part of the mount work I'm doing trying to
get remount to work.)
Considering that we're not feeding the compiler -fwriteable-strings, and thus
any attempt to modify the string will reliably segfault at runtime, "const"
notation for them seems actively stupid to me.
I personally find "const" pointless and annoying anyway, since it's not there
to affect the resulting binary (-fstrict-aliasing is already enabled by -Os)
but instead it's an attempt to make static typechecking do something useful,
which is sad. (Wandering back and forth between Python and C means you can't
help but view C's typechecking in an "aww, isn't that cute, give it a cookie"
sort of way. If we were running sparse against busybox that might almost be
useful, but I'd much rather put that sort of effort into a real regression
test suite than any kind of abstract theorem prover to show that we've
consistently implemented our bad assumptions rather than testing real-world
behavior.)
This means every time I hit some stupid "ha! you're mixing const and
non-const!" complaint, I lean towards ripping the "const" notation out. Note
that I don't remember this error having ever _once_ indicated a single real
bug in my code in the entire time I've been using versions of gcc that warn
about that. (Has anyone else ever found a real bug because of this? Maybe
it's that I understand what pointers _do_, and lots of people conceptually
have trouble with them. I dunno.)
Rob
--
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word.
I do not think it means what you think it means.
More information about the busybox
mailing list