Public Comment Number PC-UK0117 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-02-25 Author: N.M Maclaren Author Affiliation: Self Postal Address: University of Cambridge, Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB3 3QG, United Kingdom E-mail Address: Telephone Number: +44 1223 334761 Fax Number: +44 1223 334679 Number of individual comments: 1 Comment 1. Category: Inconsistency Committee Draft subsection: 6.1.2.5 Title: Major incompatibility with C89 Detailed description: Paragraph 3 introduces a fifth integer type, longer than long. The current partial draft of the rationale explains why, but conveniently ignores the major incompatibilities with C9X. There are a large number of very important, portable, conforming programs that rely on the fact that long is the longest integer type, and they will all be badly broken by this change. For example, any C89 program that needs to calculate space requirements using a mixture of size_t and off_t (with the XPG4 or Single Unix definitions) has little option but to convert both to unsigned long. This is highly portable, conforming and (as far as the actual calculations go) even strictly conforming. As this class of programs includes an immense number of commercially important applications, from sorting utilities to databases, it cannot be ignored. The best solution would be to abandon 'long long' entirely. Several vendors (such as HP) have already converted to 64-bit long on 64-bit systems, which shows that the extra type is not actually needed. If this approach is rejected, then it is imperative to prevent this change being a quiet change that will break clean, portable and conforming programs. The only solution that has been proposed is a mandatory diagnostic for any narrowing cast to either long or unsigned long. This clearly must include both explicit casts and implicit ones (e.g. when used as arguments). However, even that does not solve all of the problems. The only way for a portable or conforming C89 program to print a size_t value is to convert it to unsigned long, and print it using "%lu" or "%lx". This construction is so common that it is unreasonable to break such code without comment, and the C standard should mandate a diagnostic in at least the cases where a format string is fixed at compilation time. Frankly, I think that this is a horrible way to proceed, but I regard it as completely unreasonable for C9X to break clean, portable and conforming C89 programs without comment in the way that is being proposed.