Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!sri-spam!ames!amdcad!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.lang.c,comp.unix.wizards
Subject: Re: pointer alignment when int != char *
Message-ID: <27276@sun.uucp>
Date: Fri, 4-Sep-87 15:13:06 EDT
Article-I.D.: sun.27276
Posted: Fri Sep  4 15:13:06 1987
Date-Received: Sat, 5-Sep-87 20:38:47 EDT
References: <493@its63b.ed.ac.uk> <6061@brl-smoke.ARPA> <3812@spool.WISC.EDU> <286@halley.UUCP>
Sender: news@sun.uucp
Lines: 51
Xref: mnetor comp.lang.c:4175 comp.unix.wizards:4090

> Let's say a function is to take two pointer arguments, a pointer to a
> string and a pointer into the string.  What you say seems to indicate
> that arithmetic expressions involving both pointers, such as their
> difference, will produce unpredictable results at execution time, because
> the called function has no way of knowing whether the pointers are actually
> to the same "string" or not.

It indicates no such thing.  The called function doesn't *have to* know whether
the pointers point to elements of the same array; it is free to subtract them
*as if* they were, since if they are a correct result will be produced if the
program is compiled by a conforming compiler.  As such, if the called function
is called correctly, so that the two pointers *do* point to members of the same
array, there will be no problem.

If they do not point to members of the same array, the generated code that
subtracts them can produce the "expected" result, produce a garbage result, or
trigger global thermonuclear war; it is not obliged to worry about this.  The
Standard "imposes no requirements" on the behavior of an implementation in a
particular situation if the Standard indicates that behavior in that situation
is "undefined".  "Permissible behavior ranges from ignoring the situation
completely with unpredictable results, to behaving during translation or
program exution in a documented manner characteristic of the environment
(with or without the issuance of a diagnostic message), to terminating a
translation or execution (with the issuance of a diagnostic message)."

People seem to be having trouble with this point, so I'll give some concrete
examples.

In a system with a flat address space, and where pointer subtraction is done by
treating the bit patterns in the pointers as integral quantities, subtracting
them, and dividing the result by the size of the object type to which both
pointers point, subtraction of two "char *"s that do not point to members of
the same array will produce the "expected" result, namely the distance between
the two addresses in "char"-sized units.

In a system with a segmented address space, where pointer subtraction is done
by subtracting the offsets of the pointers, an entire array must fit into a
segment in order to produce a conforming implementation.  (You may even have to
ensure that the last element doesn't end on the last address of the segment, in
order that you can also subtract a pointer from "pointer_to_last_element"+1.)
If both pointers point to objects in the same array, the segment number is
irrelevant; subtracting the offsets gives the correct result.  If both pointers
point to objects in different segments (which are obviously not members of the
same array), you will get a meaningless result.  This is not a problem for e.g.
"strlen"; "strlen" *will* give the correct length if handed a real string (such
that all characters, including the null character, are members of the same
array, and thus in the same segment).  What it does when handed something that
isn't a real string is irrelevant.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com