🚀 go-pugleaf

In article <2330@eagle.ukc.ac.uk> pc@ukc.ac.uk (R.P.A.Collinson) writes:
>Whilst on the subject of complaining about people who sell duff C
>compilers - here's a reason you might want to worry about the ST
>Lattice C compiler.
>
>The following C bits will generate incorrect code:
>
>	char	buffer[BUFSIZ];
>
>	register char *pt;
>	register n;
>
>	/* How many bytes left in the buffer please ? */
>	n = &buffer[BUFSIZ] - pt;
>
>When I found this bug - I ditched the compiler so I cannot tell you the
>answer - I think that it is always zero.

   Yes, it results in a zero answer.  I played with it a bit, and the following
will work, but there is definitely something bizarre going on.  I mentioned the
problem in the BIX Lattice conference, so the Lattice people should become aware
of the problem.  Meanwhile, be careful about doing pointer arithmetic (which
is something I try not to do anyway).  Anyway, the following code produced
correct results for *both* the pointer and non-pointer cases (please forgive
any unintended syntax errors, as I'm typing this in quickly from memory):

# define BUFSIZ 1000

main () {

   char buffer[BUFSIZ];
   char *pt;
   int  n1, n2, pint, bint;

   pt = &buffer[499];

   bint = (int) &buffer[BUFSIZ];
   pint = (int) pt;

   n1 = &buffer[BUFSIZ] - pt;
   n2 = bint - pint;

   printf( "pt: %u; bint: %u; n1: %u; n2: %u.\n", pt, bint, n1, n2 );
}

   Like I said, both n1 and n2 came out with identical, correct results
when I tried this, so it's not merely as simple a problem as incorrect
pointer aritmetic.  If I don't get a response from Lattice on BIX, I intend
to write them a letter about it.  I'm not dissatisfied with the product so
far, since I haven't encountered any of the bugs in my week-to-week use
of the compiler, but something like this could affect me sooner or later.
Incidentally, it may help if somebody who has a CompuServe account and owns
Lattice C would let them know about this there, also.  If they think people
are running into this problem right and left, they may be more prone to do
something about it.
--

 - Joel Plutchak
   uucp: {allegra,ihnp4,seismo}!uwvax!uwmacc!oyster
   ARPA: oyster@unix.macc.wisc.edu
   BITNET: plutchak@wiscmacc