> And for perfectly good reason; strtoq.c includes integer constants
> that are too large (for obvious reasons), and as such, won't build
> with 2.7.2.
> 
> I assume we have a patch for this, which was applied to 2.4.5.  Can
> anyone point me at it?

It's been reported that strtoq.c compiles fine on some architectures,
while it reports warnings on others.  I suspect this is caused by the
fact that different definitions for QUAD_MIN and QUAD_MAX.

The architectures where strtoq.c has been reported to compile
(like the m68k) use gcc's "long long" constants.

m68k/include/limits.h:#define   UQUAD_MAX       0xffffffffffffffffULL          /* max unsigned quad */
m68k/include/limits.h:#define   QUAD_MAX        0x7fffffffffffffffLL           /* max signed quad */
m68k/include/limits.h:#define   QUAD_MIN        (-0x7fffffffffffffffLL-1)      /* min signed quad */

While (at least some of) the architectures where strtoq.c has been reported
to fail to compile (like the pmax) use arithmetic expressions and casts:

pmax/include/limits.h:#define   UQUAD_MAX       ((u_quad_t)0-1) /* max value for a uquad_t */
pmax/include/limits.h:#define   QUAD_MAX        ((quad_t)(UQUAD_MAX >> 1))
pmax/include/limits.h:#define   QUAD_MIN        (-QUAD_MAX-1)   /* min value for a quad_t */

I haven't done the math to see if these expressions do overflow or
not, so I can't be certain if this is a gcc bug.  But it does seem like
the easiest fix might be to change the macro definitions to use the gcc
long long constants.

	--jtc