[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: Include limits.h for PATH_MAX. [PATCH]
From:       Shaun Jackman <sjackman () gmail ! com>
Date:       2005-11-22 18:13:00
Message-ID: 7f45d9390511221013y73df571bm () mail ! gmail ! com
[Download RAW message or body]

2005/11/22, Rob Landley <rob@landley.net>:
> When nobody else sees a build break, including headers that everybody else
> isn't needing is either pedantic or platform dependent.

Nobody else sees build breakage because the vast majority of other
users are using either glibc or uClibc. Since the manifest of uClibc
is, for the most part, to be a drop-in replacement for glibc, but
smaller, this means that most users are testing all of *one* libc
implementation/interface.

The current behaviour of expecting PATH_MAX to be provided by a
compiler without telling the compiler it is required, by including
limits.h, is platform dependent. Including limits.h and giving the
compiler enough information to do its job is platform independent.

glibc used to provide memcpy even if string.h wasn't included.
Eventually this bug was fixed, and everyone added string.h to their
buggy source files. One day glibc might fix this PATH_MAX bug, and
everyone will be clamoring to include limits.h. glibc mistakenly
providing a symbol when it's not explicitly requested is not a good
reason not to include the header file.

> Who said anything about creating?  busybox.h and libbb.h
> have been around for years.

I prefer to think the purpose of these headers is to provide
declarations for functions defined by busybox, not to provide
arbitrary headers that some applet ought to include itself.

> The question I haven't seen answered is why does this work for everyone else?
> By what chain did this #include already get #included when it wasn't explicit
> here, and why isn't that reliable?  I'd like to understand why it worked
> before this.  Because otherwise, I'm _going_ to check in new applets at some
> point that break for you because they compile just fine for me.  Unless we
> deal with this in a compiler.h way.

This works for everyone else because most of them are using glibc/uClibc.

It's perfectly alright that you check in an applet that breaks for me,
because you are testing a different target than me. As long as glibc
does you the disservice of providing arbitrary, unrequested symbols,
this will occur from time to time. Since it only requires a one-line
patch to fix, I would simply accept it as the nature of
cross-compiling.

Cheers,
Shaun
_______________________________________________
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox

[prev in list] [next in list] [prev in thread] [next in thread]