Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!rutgers!bellcore!texbell!killer!chasm
From: chasm@killer.DALLAS.TX.US (Charles Marslett)
Newsgroups: comp.lang.c
Subject: Re: Contiguous Arrays
Summary: My point failed to get across
Message-ID: <7389@killer.DALLAS.TX.US>
Date: 2 Mar 89 14:28:46 GMT
References: <2508@ssc-vax.UUCP> <8943@alice.UUCP> <1828@valhalla.ee.rochester.edu> <8966@alice.UUCP>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 51

In article <8966@alice.UUCP>, ark@alice.UUCP (Andrew Koenig) writes:
> In article <7309@killer.DALLAS.TX.US>, chasm@killer.DALLAS.TX.US (Charles Marslett) writes:
> 
> >  > There is no guarantee that there is a way to represent &space[0] - 101
> >  > at all.  Further, computing it may cause overflows such that
> >  > 
> >  > 	(&space[0] - 101) + 101 != &space[0]
> > 
> > Please explain?  What machine does this, or what architecture would allow
> > the machine or programming language to do it?
> 
> The easiest case is if I give you a strictly checking C implementation
> in which evaluating &space[0]-101 causes your program to terminate
> with an error diagnostic.

I did not disagree that it was possible to design a compiler/computer
combination that had this difficulty -- my point was that given the amount
of code it was likely to break, would anyone write such a compiler.  Or
more precisely, again, HAS ANYONE SEEN THIS PROBLEM and what computer was it
on, and what compiler.  I want a specific KLUTZY 29020 with the GCC 5.13
compiler does blah, blah, blah, ...

Otherwise, yes you can do anything you please with the architecture and the
language once you leave the standards protected area (and some do not even
keep the K&R or Ansi defined language sacred).  Some such implementations are
relatively useless though, and just never appear in practice.  I was
suguesting this limitation is one (not that it is impossible).

Charles
> . . .  A program that attempts to generate
> the address of any other `element' of A is an invalid C program
> and the implementation is permitted to do as it pleases with it.

Once again, I did not say that this behavior is covered by the standard,
I said it is useful behavior and universal (or nearly so).

Before the recent rounds of Ansi drafts, there was no requirement (oops,
someone may nail me on this, but if I err in detail, something had to be
unspecified) that sizeof(xxx) return the size of xxx in units of "char"s.
All (or almost all) C compilers do so and have since the beginning of time
(or Unix).  I am sure much code would break if they did not.
[if this is not an accurate statement of the interpretation of "sizeof",
substitute something that was undefined under K&R, often or always implemented
one way or another, and standardized under ANSI -- there is such a beast
isn't there?]

> -- 
> 				--Andrew Koenig

--
Charles Marslett