Bug#317849: brittle recursion in limits.h

[Mike Furr <mfurr@debian.org>]

Package: libc6-dev
Version: 2.3.2.ds1-22
Severity: normal

/usr/include/limits.h tries to include limits.h from
/usr/lib/gcc/.../include, via:
#include_next <limits.h>
on line 124 which is outside of its ifdef on _LIBC_LIMITS_H_

Thus, with the preprocessor shipped with gcc-4.0, this may cause an
infinite recursion when a file in /usr/include calls:
 #include "limits.h"
like in  bug #317839.  Because of the search path order in cpp-4.0,
cpp will continually reread /usr/include/limits.h and never try the one
in /usr/lib/gcc/.../include

While, it is arguably a bug in a header which specifies "limits.h"
instead of <limits.h>, it would be nice if /usr/include/limits.h
handled this case as well.  From my limited testing, it seems that a
patch of:
122c122
< #if defined __GNUC__ && !defined _GCC_LIMITS_H_
---
> #if defined __GNUC__ && !defined _GCC_LIMITS_H_ && !defined
> _LIBC_LIMITS_H_

would make the recursion more robust.

Cheers,
-Mike

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages libc6-dev depends on:
ii  libc6                2.3.2.ds1-22        GNU C Library: Shared libraries an
ii  linux-kernel-headers 2.5.999-test7-bk-17 Linux Kernel Headers for developme

Versions of packages libc6-dev recommends:
ii  gcc [c-compiler]             4:3.3.6-1   The GNU C compiler
ii  gcc-2.95 [c-compiler]        1:2.95.4-22 The GNU C compiler
ii  gcc-3.2 [c-compiler]         1:3.2.3-9   The GNU C compiler
ii  gcc-3.3 [c-compiler]         1:3.3.6-7   The GNU C compiler
ii  gcc-3.4 [c-compiler]         3.4.4-3     The GNU C compiler
ii  gcc-4.0 [c-compiler]         4.0.1-1     The GNU C compiler

-- no debconf information