bukys@rochester.UUCP (01/24/84)
One possible outcome of this "difference of two pointers can't fit in an int or even a long int" debate is that the difference will be defined to be implementation-dependent (close to undefined, except that op sys hackers can know what's going on) if the pointers do not reference elements of the same array. Maybe any array will be limited to having at most MAXINT elements. In fact, I will go so far as to claim that this definition is already the case. Consider a compiler for a segmented-memory machine where each array is in a different segment. Subtraction of {pointers into two different segments} is meaningless. There, ANSI-C-standardizers: a clean and simple solution. Liudvikas Bukys rochester!bukys (uucp) via allegra, decvax, seismo bukys@rochester (arpa)
tll@druxu.UUCP (01/25/84)
From an article by Liudvikas Bukys: >> One possible outcome of this "difference of two pointers can't fit in >> an int or even a long int" debate is that the difference will be >> defined to be implementation-dependent (close to undefined, except that >> op sys hackers can know what's going on) if the pointers do not >> reference elements of the same array. Maybe any array will be limited >> to having at most MAXINT elements. The difference is already at least somewhat implementation-dependent. I quote from "The C Reference Manual" page 189: This conversion will in general give unexpected results unless the pointers point to objects in the same array, since pointers, even to objects of the same type, do not necessarily differ by a multiple of the object-length. So we've already been warned not to subtract pointers to objects that are not in the same array (albeit for a reason other than integer overflow). It appears that limiting the maximum number of elements in an array is all that is needed to finish clarifying things. On the other hand, this limit need not be enforced, since the programmer knows that conversion to an "int" causes truncation if the value won't fit. So what's the big problem, anyway? Tom Laidig AT&T Information Systems Laboratories, Denver ...!ihnp4!druxu!tll