Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!mcnc!xanth!kent
From: kent@xanth.UUCP (Kent Paul Dolan)
Newsgroups: comp.lang.c
Subject: Re: char (*a)[]  (was: Style [++i vs i++])
Message-ID: <2474@xanth.UUCP>
Date: Thu, 17-Sep-87 17:41:15 EDT
Article-I.D.: xanth.2474
Posted: Thu Sep 17 17:41:15 1987
Date-Received: Sun, 20-Sep-87 05:43:03 EDT
References: <8298@brl-adm.ARPA> <587@cblpe.ATT.COM>
Reply-To: kent@xanth.UUCP (Kent Paul Dolan)
Organization: Old Dominion University, Norfolk Va.
Lines: 70
Keywords: brain dead architectures versus X3J11
Summary: I love it!

In article <5391@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes:
>All this stuff gets very interesting when you consider what happens on
>an 80286 in its native 'protected' mode (as opposed to the 'fast 8086' mode
>in which most of them are warming their sockets).
>
>In this mode, a pointer is 32 bits; a 16-bit segment number, and a 16-bit
>offset. It is meaningless to do arithmetic on the segment number since
>it is just an index into a table maintained by the OS. Pointer
>arithmetic as we know it in C affects only the offset.
>The other weird bit concerns the range of these pointers. The
>compiler may assign a separate segment for every data object.
>The segment has a size, and any reference to that segment beyond this
>size causes a trap.
>Suppose I declare 'int foo[10]', then I may get a 20-byte segment for
>foo. Then &foo[10] is a pointer which is illegal to dereference.
>This is good.
>There are lots of bits of code like this:
>	for( p = foo; p < &foo[10]; ++p ){
>which cause p to be repeatedly compared to a constant invalid pointer until it
>becomes an invalid pointer itself.  I can live with that.
>
>What gets a little weird is this: pointer inequalities are done by comparing
>only the offset part, since the comparison is invalid anyway if the segment
>numbers are different. Also, offset arithmetic is done in 16 bits.  This
>means that foo[-1] is not only an invalid pointer, but it will be 'greater
>than' foo[0] since it will have an offset of 0xfffe. What this means is that
>the following won't work:
>	for( p = &foo[9]; p >= foo; --p ){	/* loops forever */
>
>The ANSI standard must have something about such pointers. Do they
>say roughly the same thing about them as I have in the preceding paragraph?
>

I love it!

OK, X3J11, the ball's in your court.  Do we teach every C programmer
on every architecture in the world that decrementing pointer loops are
a no-no, and break half the code in existance, or do we finally bite
the bullet and decide that compiler writers for brain dead
architectures, and not the whole C community, pay the penalty for bad
hardware designs?  Especially since these folks are often the
perpetrators of the bad hardware design.

Obviously, at a cost in execution speed, several system trap calls and
whatever, the pointer can be converted to an integer, the arithmetic
done, and the result converted back to a (possibly now illegal)
pointer; if the code, as above, doesn't need the pointer, just the
arithmetic result for a comparision, then the programmer can go on
writing high level language code instead of worrying about boobosities
in the hardware.

If people who chose such obscenities to build their systems around
were made responsible for making them work like normal computers,
instead of having the whole rest of the world "fill the C compiler
with 'if' kludges" (from another posting), the forces of evolution
would consign these duds to the recycling heap in a heartbeat.  It is
only by continuing to cater to the inanities of some hardware (and
software, I suppose) designers that we are forced to continue to
suffer their stupidities in the systems we use.

Yes, I suffer fools.  But I _do_ suffer, and so do you.

Kent, the man from xanth.

"His expression lit up.  'Hey, you wouldn't be a dope smuggler, would you?'

Rail looked confused.  'Why would anyone wish to smuggle stupidity when
there is so much of it readily available?'"

		-- Alan Dean Foster, GLORY LANE