Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83 based; site homxa.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!homxa!osd7 From: osd7@homxa.UUCP (Orlando Sotomayor-Diaz) Newsgroups: mod.std.c Subject: mod.std.c Digest V6#9 Message-ID: <932@homxa.UUCP> Date: Sat, 18-May-85 18:01:56 EDT Article-I.D.: homxa.932 Posted: Sat May 18 18:01:56 1985 Date-Received: Sun, 19-May-85 00:17:30 EDT Organization: AT&T Bell Labs, Holmdel NJ Lines: 154 Approved: osd7@homxa.UUCP From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Sat, 18 May 85 Volume 6 : Issue 9 Today's Topics: Pointer math and ints pointers to functions Pointers which do not fit into an int sizeof(*main) ---------------------------------------------------------------------- Date: 17 May 85 20:10:13 CDT (Fri) From: plus5!hokey (Hokey) Subject: Pointer math and ints To: std-c@cbosgd "When two pointers to members of the same array object are substracted, the result is converted (by division by the size of the member) to >> a signed integer (the size of which is implementation defined) << representing the difference of the subscripts of the two array members. As with any other arithmetic overflow, if the result does not fit in the space provided, the behavior is undefined. If two pointers that do not point to members of the same array object are substracted, this conversion is undefined, because such pointers do not necessarily differ by an integral multiple of the size of the object." From C.3.6 Additive Operators (semantics), p. 21, draft 85-008. -- Mod -- ] K&R (p 189, last paragraph of 7.4) states "If two pointers to objects of the same type are subtracted, the result is converted (by division by the length of the object) to an _int_ representing the number of objects separating the pointed-to objects." Changing the result from "an _int_" to "a signed integer (the size of which is implementation defined)" breaks existing code. [ Someone can prove the above statement? For your information, signed ints in ANSI C must cover the following value range: from -32767 to 32767. Implementations can cover beyond that range (e.g., signed ints in 32 bits instead of 16), but the implementation must have it documented. In K&R a "signed" int can have 16 bits on a PDP11, 36 on a Honeywell 6000, etc. (See page 34.) The point is, already in K&R int size is implementation defined. -- Mod -- ] The next question is: Why did the Committee choose to implement pointer subtraction in this fashion? It is one thing to break existing code in a manner which is easily flagged by the compiler. It is another matter entirely to break existing code in a manner which is difficult to detect. I suspect this was an editorial oversight by the Committee. The string length example I posted earlier does not break because the value of "return(p-s)" is cast to an int automatically. I apologize for using a bad example. A better example of this problem (pointer==long, int==short) occurs when one passes the (previously guaranteed to be an int) "p-s" as an actual parameter to a subroutine, which is expecting an int. Under the current definition, the "p-s" expression pushes a long on the stack, but the subroutine expects a short. Not only does this mess up the binding for this parameter, but it offsets any remaining parameters as well. Aside from the "breaks existing code" problem, I don't see why the result of pointer subtraction is of implementation-defined integral size. The quantity is always divided by the member size, and the memory allocators in common use take either an int to specify how much space to allocate, or the number of elements and the element size. Assuming space is allocated in this fashion, it is impossible for the result of (proper) pointer subtraction to result in more bits than can fit in an int. Hokey ..ihnp4!plus5!hokey 314-725-9492 ------------------------------ Date: Thu, 16 May 85 21:38:33 edt From: sfbc!lr Subject: pointers to functions To: std-c@cbosgd Additive arithmetic is permitted only on pointers to arrays, which are assemblages of objects of the same type. Functions are not objects, therefore ... Larry Rosler ------------------------------ Date: Mon, 13 May 85 10:11:40 -0200 From: ihnp4!seismo!mcvax!jack (Jack Jansen) Subject: Pointers which do not fit into an int To: homxa!osd7 Plus5!hokey said that pointers which do not fit into an int (I assume 'long' is OK too, otherwise *lots* of machines are in trouble) would break a lot of programs, but I have the impression that this is not the case. For instance, on a prime pointers are 48 bits, and integers 32. Since the upper 16 bits are used for all kinds of funny things, like segment numbers, etc. this isn't a problem. It is quite useless to determine the difference between two pointers that lie in two different segments. Moreover, it is usually even *wrong* to do so. I think that architectures where the difference between two 'comparable' pointers can not be expressed in any int are probably very rare, and in any case very weird. The 8086 is the only machine I know of that might be in trouble. The solution is simple (though not nice): Don't use big arrays. Just pretend that you're still on a PDP-11 with 64Kb data space. Jack Jansen, jack@mcvax.UUCP The shell is my oyster. ------------------------------ Date: 14 May 1985 23:58:02 PDT From: Dave Decot Subject: sizeof(*main) To: hpdsd!hplabs!ihnp4!cbosgd!std-c Is it permitted to ask for the size of a function object, since various people have pointed out that it should not be permitted to perform arithmetic on function pointers? The draft standard I have is silent in its definition of sizeof as to what the value of sizeof is when applied to a function object. I suggest that it *should be possible*, and that the value should be the size of the type returned by the function, or 0 if the function explicitly does not return a value (i.e., returns type void). Dave Decot / Hewlett-Packard Company, Data Systems Division / hpda!decot [ If you look at L. Rosler's observations above, the is no such thing as a function object. There are functions and objects... -- Mod -- ] ------------------------------ End of mod.std.c Digest - Sat, 18 May 85 09:42:51 EDT ****************************** USENET -> posting only through cbosgd!std-c. ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C) In all cases, you may also reply to the author(s) above.