pc@ukc.ac.uk (R.P.A.Collinson) (12/31/86)
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. NB. To be fair to Metacomco in the UK - they offered to refund my money when I reported this bug and said that as far as I was concerned the `Lattice C compiler' cannot compile C.
oyster@uwmacc.UUCP (Vicarious Oyster) (01/05/87)
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
oyster@uwmacc.UUCP (Vicarious Oyster) (01/08/87)
In article <2330@eagle.ukc.ac.uk> pc@ukc.ac.uk (R.P.A.Collinson) writes: > >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; > Doesn't the declaration "register char *pt;" mean "a pointer to a register," in fact? Can you tell me what a pointer to a register is? Supposedly, that kind of (presumably) illegal declaration is ignored, but I can see where a writer of a <$100 compiler might not handle it correctly. That's no excuse, of course... -- - Joel ({allegra,ihnp4,seismo}!uwvax!uwmacc!oyster) Disclaimer: The above, unless otherwise labeled, constitutes personal opinion.
pett@socrates.ucsf.edu (Eric Pettersen%CGL) (01/09/87)
In article <864@uwmacc.UUCP> oyster@unix.macc.wisc.edu.UUCP (Vicarious Oyster) writes: >In article <2330@eagle.ukc.ac.uk> pc@ukc.ac.uk (R.P.A.Collinson) writes: >> >>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; >> > Doesn't the declaration "register char *pt;" mean "a pointer to a >register," in fact? Can you tell me what a pointer to a register is? >Supposedly, that kind of (presumably) illegal declaration is ignored, >but I can see where a writer of a <$100 compiler might not handle it >correctly. That's no excuse, of course... >-- No, it means that the pointer's value is kept in a register. Trying to use &pt (the address of a register) would then be illegal. Eric Pettersen UCSF Computer Graphics Lab
holloway@drivax.UUCP (Bruce Holloway) (01/09/87)
In article <864@uwmacc.UUCP> oyster@unix.macc.wisc.edu.UUCP (Vicarious Oyster) writes: > Doesn't the declaration "register char *pt;" mean "a pointer to a >register," in fact? Easy to see you're not a 'C' programmer. The above declaration means that 'pt' is a pointer to a character, and should be stored in a register if at all possible. The statement "char **cp = &pt;" WOULD be illegal... perhaps this is what you were thinking. -- ....!ucbvax!hplabs!amdahl!drivax!holloway "What do you mean, 'almost dead'?" "Well, when you stop breathing, and moving around, and seeing things... that kind of almost dead."