Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!think!ames!rutgers!uwvax!uwmacc!uwmcsd1!marque!ddsw1!gryphon!greg
From: greg@gryphon.CTS.COM (Greg Laskin)
Newsgroups: comp.lang.c
Subject: Re: char (*a)[]  (was: Style [++i vs i++])
Message-ID: <1631@gryphon.CTS.COM>
Date: Sun, 20-Sep-87 19:03:48 EDT
Article-I.D.: gryphon.1631
Posted: Sun Sep 20 19:03:48 1987
Date-Received: Tue, 22-Sep-87 00:54:37 EDT
References: <8298@brl-adm.ARPA> <587@cblpe.ATT.COM>
Reply-To: greg@gryphon.CTS.COM (Greg Laskin)
Organization: Trailing Edge Technology, Redondo Beach, CA
Lines: 35
Keywords: brain dead architectures versus X3J11
Summary: all architectures are braindead when the code is broke.

In article <2474@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes:
>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 ...
>>	for( p = &foo[9]; p >= foo; --p ){	/* loops forever */
>
>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.
>

Given:
	extern struct FOO foo[];

Assume:
	sizeof struct FOO == n+1
	foo == (struct FOO *) n;

where n is any address in any linear address space.

Does the example code loop forever?
If so, does this mean that linear address spaces are brain-dead or that
the code is broken?

&
-- 
Greg Laskin   
"When everybody's talking and nobody's listening, how can we decide?"
INTERNET:     greg@gryphon.CTS.COM
UUCP:         {hplabs!hp-sdd, sdcsvax, ihnp4}!crash!gryphon!greg
UUCP:         {philabs, scgvaxd}!cadovax!gryphon!greg