Re: Pointers in C

From article <1262@ima.ISC.COM>, by pfeiffer@herve.cs.wisc.edu (Phil Pfeiffer):
> ...my posting about C's semantics was not totally accurate...
>
>>K&R 1, page 98:
>>"But all bets are off if you do arithmetic or comparisons with pointers
>>pointing to different arrays. If you're lucky, you'll get obvious
>>nonsense on all machines. If you're unlucky, your code will work on one
>>machine but collapse mysteriously on another."


To combine this with what was said before: An optimizer can assume
that once a pointer, 'p', is assigned to an address within an array, 'a',
'p' will stay within the bounds of 'a' until assigned to an address
within some other array or in the heap space.


While this assumption is valid (according to the book,) it is also true
that the optimized code may behave differently than unoptimized code,
but only for programs that are not in the domain of valid K&R C programs.


Nevertheless, I can think of a rather large set of programs that
aren't "valid K&R C programs": All those programs that use varargs.
(At least by the definitions of varargs that I've seen.)


> Also, on page 90 of K&R (version 1):
> "You should also note the implications in the declaration that a pointer is
> constrained to point to a particular kind of object."


I think a C compiler would be very hard pressed to guarantee this sort
of thing, with the cast operation lurking about. The only way to absolutely
guarantee this is to do some unpleasantly complicated typechecking on
every object in memory.


Insofar as mainstream C compilers go, I think you have to accept Phil's
original assertion about pointer operations -- at least within the heap
space. If you can circumvent the varargs problem, you might be able to
get by with the K&R definition in the stack space.


- Steve Benz
[From ]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.