INT_MAX undeclared / limits.h

[Jakub Jelinek]

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.html#tag_02_02_02

so the removal of limits.h include in bits/socket.h was a bug fix.

	Jakub