httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: cvs commit: httpd-2.0/server/mpm/threaded threaded.c
Date Fri, 04 May 2001 12:54:45 GMT
Jeff Trawick wrote:
> 
> Maybe my point wasn't taken.  Rephrased more simply.
> 
> INT_MAX still has to be the largest value that can be stored in a
> signed int, so
> 
> on a 16-bit machine, INT_MAX will be 32767
> on a 32-bit machine, INT_MAX will be 2billion or so
> 
> Therefore, bringing "32767" into the discussion means bringing
> Apache-on-16-bit into the discussion.
> 
> I seriously doubt we would want to hack up Apache *and* APR *and*
> expat *and* PCRE *and* whatever else to work on a 16-bit machine.  I
> seriously doubt that any publically released version of Apache has
> ever worked on a 16-bit machine.
> 
> So let's put the "32767" part of the discussion to rest.
> 

A machine can be ANSI compliant and have INT_MAX == 32767 and
have as many bits as it wants. All ANSI does is set a lower
limit to INT_MAX. ANSI doesn't define the number of bits per any
type, except setting that char must be at least 8 bits. At that
point, ANSI does not bring "number of bits" into any discussions
at all (IIRC).

ANSI only guarantees that signed ints will go up to 32767. If you
need them to be higher, then ANSI doesn't do that for you, and
we need to make sure that we have a large enough range. It ain't
bits at all, but scale.

Of course, in the real world, INT_MAX of 32767 implies 16bit, but
it's just these kinds of assumptions that create problems in the
64bit world.

-- 
===========================================================================
   Jim Jagielski   [|]   jim@jaguNET.com   [|]   http://www.jaguNET.com/
          "Hell is hot, that's never been disputed by anybody."

Mime
View raw message