Re: INT_MAX undeclared / limits.h
On Wed, Feb 13, 2008 at 06:24:48PM +0100, Ralf Corsepius wrote:
On Wed, 2008-02-13 at 18:09 +0100, Till Maas wrote:
> On Wed February 13 2008, Till Maas wrote:
> In Fedora 7 and 8, INT_MAX is already declared when arpa/inet.h is included,
> i.e. this compiles:
>
> #include <arpa/inet.h>
> #include <stdio.h>
>
> main() {
> printf("%i", INT_MAX);
> }
>
> But I guess it won't compile in Rawhide. arpa/inet.h comes from glibc-headers
> which is a subpackage of glibc, so is this a bug in glibc?
Nope. What you describe above simply is unreliable, undocumented
behavior - It might work somewhere, but it also might not work somewhere
else.
POSIX mandates code to include <limits.h> to reliably get INT_MAX.
In this case even POSIX mandates that limits.h is not included by
arpa/inet.h nor stdio.h (that strict requirement is just when using
POSIX feature test macros, but programs assuming anything else are broken
anyway). POSIX lists which headers may be included inside of each header
(precisely symbols from which headers it can make visible),
and in arpa/inet.h case that's just netinet/in.h and inttypes.h.
See http://www.opengroup.org/onlinepubs/009695399/basedefs/arpa/inet.h.html
and
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_02.htm...
so the removal of limits.h include in bits/socket.h was a bug fix.
Jakub