On Dec 8, 2009, at 1:27 PM, Henning Thielemann wrote:
On Tue, 8 Dec 2009, Richard O'Keefe wrote:
On Dec 8, 2009, at 12:28 PM, Henning Thielemann wrote:
It is the responsibility of the programmer to choose number types that are appropriate for the application. If I address pixels on a todays screen I will have to choose at least Word16. On 8-bit computers bytes were enough. Thus, this sounds like an error.
That kind of attitude might have done very well in the 1960s.
I don't quite understand. If it is not the responsibility of the programmer to choose numbers of the right size, who else?
It is the responsibility of the computer to support the numbers that the programmer needs. It is the responsibility of the computer to compute CORRECTLY with the numbers that it claims to support. I repeat: the programmer might not KNOW what the integer sizes are. In Classic C and C89, the size of an 'int' was whatever the compiler chose to give you. In c89, limits.h means that the program can find out at run time what range it got, but that's too late.
If the operating system uses Int32 for describing files sizes and Int16 for screen coordinates, I'm safe to do so as well.
In a very trivial sense, this is true. In any less trivial sense, not hardly. Suppose I am calculating screen coordinates using / x \ / a11 a12 a13 \ / u \ | y | = | a21 a22 a23 | | v | \ 1 / \ 0 0 1 / \ 1 / which is a fairly standard kind of transformation, it is not in general sufficient that u, v, x, and y should all fit into Int16. The intermediate results must _also_ fit. (Assume for the moment that overflow is checked.) If I need to represent *differences* of Int32 pairs, I know perfectly well what type I need: Int33. But there is no such type.
The interface to the operating system could use type synonyms FileSize and ScreenCoordinate that scale with future sizes. But the programmer remains responsible for using ScreenCoordinate actually for coordinates and not for file sizes.
Consider this problem: We are given a whole bunch of files, and want to determine the total space used by all of them. Smalltalk: fileNames detectSum: [:each | (FileStatus fromFile: each) size] The answer is correct, however many file names there are in the collection. But if we're using C, or Pascal, or something like that, we want to do FileCollectionSize fcs = 0; for (i = 0; i < n; i++) { fcs += OS_File_System_Size(filename[i]); } and how on earth do we compute the type FileCollectionSize? Remember, it has to be big enough to hold the sum of the sizes of an *unknown* and quite possibly large number of quite possibly extremely large files, not necessarily confined to a single disc, so the total could well exceed what will fit in FileSize. This is especially so when you realise that there might be many repetitions of the same file names. I can _easily_ set this up to overflow 64 bits on a modern machine. In Haskell, you'd want to switch straight over to Integer and stay there.
In an age when Intel have demonstrated 48 full x86 cores on a single chip, when it's possible to get a single-chip "DSP" with >240 cores that's fast enough to *calculate* MHz radio signals in real time, typical machine-oriented integer sizes run out _really_ fast. For example, a simple counting loop runs out in well under a second using 32-bit integers.
The programmer doesn't always have the information necessary to choose machine-oriented integer sizes. Or it might not offer a choice. Or the choice the programmer needs might not be available: if I want to compute sums of products of 64-bit integers, where are the 128-bit integers I need?
And the consequence is to ship a program that raises an exception about problems with the size of integers?
Yes. Just because the programmer has TRIED to ensure that all the numbers will fit into the computer's arbitrary and application- irrelevant limits doesn't mean s/he succeeded. For that matter, it doesn't mean that the compiler won't use an optimisation that breaks the program. (Yes, I have known this happen, with integer arithmetic, and recently.)
I'm afraid I don't understand what you are arguing for.
I'm arguing for three things. (1) If you look at the CERT web site, you'll discover that there have been enough security breaches due to integer overflow that they recommend working very hard to prevent it, and there's an "As If Ranged" project to enable writing C _as if_ it could be trusted to raise exceptions about problems with the size of integers. It is better to raise an exception than to let organised crime take over your computer. (2) In a language like Ada where the programmer can *say* exactly what range they need, and the bounds can be computed at compile time, and the compiler either does it right or admits right away that it can't, it's the programmer's fault if it's wrong. Otherwise it isn't. (3) Be very worried any time you multiply or divide integers. (INT_MIN / (-1) is an overflow, C is allowed to treat INT_MIN % (-1) as undefined even though it is mathematically 0.) No, make that "be terrified". If you cannot formally verify that results will be in range, use Haskell's Integer type.