Public Comment Number PC-UK0260 ISO/IEC CD2 9899 (SC22N2794) Public Comment =========================================== Date: 1998-09-22 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 Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 6.2.5 and others Title: Migration from "long" to "long long" Detailed description: In the original C language and in the pcc compiler (often called Kernighan and Ritchie C) and in all pre-POSIX versions of Unix, the widest signed integer type was long. Similarly, standard C (C89) defined a signed integer type to be one of signed char, signed short, signed int or signed long, with the last being required to be the widest. In all pre-POSIX versions of Unix, the size of a file was required to be representable in an object of type long; this is reflected in C in the specification of the ftell and fseek functions. It is still actually the case for most current Unix variants, though it has never been required by POSIX. A very large number of very important, portable applications need to perform calculations on mixtures of object offsets and file offsets (e.g. for database space calculations, out-of-memory sorting and so on). The traditional type to use for this purpose has been been long (or sometimes unsigned long) and, for the reasons given above, this use has been both conforming and portable. Note that these programs typically work, source unchanged, under implementations where long may be 32, 36 or 64 bits - or, indeed, any number from 32 upwards. [ Instrumenting gcc and using it to check 24 packages from the Debian 1.3.1 distribution indicated that at least 14 use long or unsigned long for this purpose or something related, and only 2 (bison and flex) did not seem to. The others could not easily be classified one way or the other. ] C9X has rendered such programs non-conforming and potentially undefined, not least because a value of type ptrdiff_t is no longer required to be representable in an object of type long, and one of size_t may exceed unsigned long. Far worse, this is a quiet change, and C9X currently provides no assistance with converting such programs from C89. The only integer type that C9X defines that is capable of taking the place of the old (K&R and C89) long in such applications is intmax_t, if for no other reason than a value of type ptrdiff_t is not required to be representable in an object of type long long either. However, this is inadequate for several reasons, the most serious of which is that the number of bytes in a file is not necessarily storable even in a value of type uintmax_t. At the very least, C9X needs to provide the following: 1) A reliable way of detecting whether a conforming compiler is implementing the C89 or C9X language. 2) Assistance with the detection of conforming and portable C89 programs that become undefined or have different effects under C9X. 3) A signed type that can be used to hold all object and file offsets, while allowing an implementation to optimise its use, to replace long in that very important class of portable and conforming C89 programs. It is highly desirable that C9X should provide the following: 4) Sufficient functionality for the intmax_t and uintmax_t types to allow C89 programs that use long and unsigned long as the longest integer types to be converted to C9X without expression rewriting, and yet with a reasonable chance of generating efficient code. 5) Better mneumonics for the conversion specifiers, and a mnemonic for the abovementioned data manipulation type.