X3J11: Why do we need ptrdiff_t and size_t?

[hokey at plus5.UUCP]

We have recently begun porting our software to environments which supply
us with C compilers and libraries which are (or claim to be) compliant with
the proposed Standard.

One of the initial nits we are discovering is the use of ptrdiff_t and size_t.

Questions:

	What major advantage do we gain by having these typedefs?

	Is it worth the trouble?

First, regarding ptrdiff_t:  The only benefit I can see to having a ptrdiff_t
is to allow *strictly conforming* programs to effect compile-time allocation
of arrays with more than 32k elements.  Of course, if the *alloc() routines
use ptrdiff_t as the size field, one can create large arrays at run-time with
strictly conforming programs.  Is this capability so useful that it should be
incorporated to the level of strict conformance?

Granted, if one uses function prototypes old software will work.  However,
I have not seen a clean and simple mechanism which I can incorporate into my
software which will permit me to enable or disable function prototypes with
a macro definition.  If such a mechanism exists, I'd like to see it, and I
believe it should be published along with the Standard.

It is not sufficient to say "One can make old software work with the new
compiler by using <blah>".  We must have reasonable facilities to enable
our software to be compiled on both new *and* old compilers with a minimum
of effort.

Next, on to size_t.  Seems to me a #define would be better than a typedef.
Again, much old software declares functions like strlen() without using
a header file.  These declarations cannot coexist with the declarations
brought in by the proposed standard <string.h>.

Furthermore, I *think* one would need/want to cast objects of type size_t to
an integral type when performing, say, string array operations.  A cast is
commonly used to say "Compiler, I know what I am doing here."  My concern is
that a programmer will use the cast to turn a size_t into a smaller "regular"
object in order to perform arithmetic, and such a truncation may not be
reported simply because it was an explicit cast.

Basically, I believe identical functionality could have been provided by
making size_t a #define instead of a typedef, and the (perceived) cast
problem would then disappear.
-- 
Hokey