hokey@plus5.UUCP (02/20/87)
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