mod.std.c Digest V6#9

[Orlando Sotomayor-Diaz]

From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>


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 at 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 at 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 at mcvax.UUCP
	The shell is my oyster.

------------------------------

Date: 14 May 1985 23:58:02 PDT
From: Dave Decot <ihnp4!hplabs!hpdsd!hpdsq!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 at BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.