Jonathan de Boyne Pollard wrote in a message to Clemens Anhuth:

  > MB>      that a single file cannot be larger than 2 GB, which is
  > MB> the largest number which be represented in a 32-bit signed
  > MB> integer.

CA> but okay, maybe a linux machine provides some better resolutions...

 JdBP>   If Linux follows POSIX 1003.1, it will have implemented
 JdBP> the "offset"   paramenter of the lseek() call -- which is of
 JdBP> type off_t -- as a   signed long integer.

True.  Linux is fairly POSIX compliant, or at least that is the goal.

 JdBP>   ( In addition to the POSIX calls, which at least have the
 JdBP> decency to   have a typedef of off_t, the AT&T iostreams
 JdBP> library declares most file   positioning functions explcitly
 JdBP> as taking signed long parameters. ) 

True also.

 JdBP>   On 386/486/586 machines, a signed long integer is 32 bits
 JdBP> wide (1 of   which is the sign bit) and so restricts the
 JdBP> seekable portion of a file   to 2Gb.

True, but the conclusion is wrong.  A signed long in a C implementation has
no necessary relationship to the machine word size.  We all know this from
our experience with 16-bit machines using compilers with 32-bit longs.

 JdBP>   If it was desired to overcome this limitation, either

 JdBP>     1.  POSIX 1003.1 compliance must be sacrificed, and
 JdBP> lseek() changed,         which still won't cure the problem
 JdBP> with iostreams; or     2.  a CPU with a larger word size
 JdBP> than the Intel x86es must be used. 

I'm afraid I started this discussion...

The actual rule says nothing about machine word size, but imposes only some
very loose requirements:

1. A long must be no smaller than an int.

2. A short must be no larger than an int.

3. An int should be chosen to be most quickly manipulated on a target machine.

As a practical matter, nearly every Unix implementation of C uses 16-bit
shorts and 32-bit ints and longs, and this has been carried over to 32-bit
operating systems, such as OS/2, generally.  A lot of code has probably
been written which assumes the absolute size of short, int, or long, and
which will someday break when those sizes change.

Nothing in ANSI or POSIX prevents someone from implementing a compliant C
compiler with a 64-bit long on the 386/486 platform.  It would be uncommon,
but it would certainly be proper within the standards.
 
-- Mike


---