aking@BFLY-VAX.BBN.COM.UUCP (12/05/87)
Has anybody seen the following bug in version 4.14 of Alcyon C?
Neil: Is there a bug list for 4.14? This bug cost me 6 hours to find,
and I've found many others. When is the next rev going to be out?
Will it fix this?
/*
* The Alcyon C compiler (Version 4.14) gets confused with the following
* fragment, thinking that "y" in the assignment to F->y (line 10) is of
* type "struct in".
*
* The fault seems to require that the same names be used in the two structs,
* and that the two seemingless senseless compound statements are present.
* (Why put them there? Well this is boiled down from a 300+ line program
* which exhibited the same funnyness).
*
* A fragment of the .s file is shown below
*/
main ()
{ register struct fl {float x, y;} *F;
register struct in {int x, y;} *I;
{
{
I += 2;
}
F->y = F->y - 3.0; /* line 10 */
}
}
------------------------------ produces: --------------------
~I=R12 | yep, they're register based
~F=R13
*line 8
add.l #8,R12
*line 10
move.l #$c00000c2,-(sp) | -3.0
move.l $4(R13),-(sp) | F->y
jsr _fpadd
addq.l #8,sp
move.l R0,-(sp)
jsr _fpftol | Floating Point to Long !
addq.l #4,sp
move R0,$2(R13) | offset looks like "struct in"
| to mesteven@cwi.nl (Steven Pemberton) (12/07/87)
For people interested, here are a couple of bugs in the Alcyon
compiler that we've been hitting our heads against for the last few
weeks:
1) The compiler doesn't seem able to cope with nested
initialisations. For instance, a struct with an array in
the middle:
static struct foo table[] = {
{ ...... {.....} ......},
...
}
The compiler complains about mismatched braces.
Cure: 'unwrap' the struct declaration, so it's all at the
same level.
2) In a construct like
bar *p = (expression1, expression2);
the result of expression2 gets coerced to int, and then
back to bar *, meaning basically that you get bombs on the
screen when you try to use p, due to a wrong address.
Cure: use
bar *p = (expression1, (bar *) expression2);
3) We believe that 'complicated' initialisations to auto
variables in functions (for instance where the
initialisation involves a call to another function) often
come out wrong. However, by this point, we despaired, and
stopped using the compiler, so we never followed up on it.
I might point out that we're trying to compile a BIG program: 30,000
lines of C, so just trying to trace bug 2 took us a LOT of time.
By the way, just for interest: to compile the lot from scratch, using
a ram disk for temporaries would take 4 hours. When we reinitialised
the disk partition, and copied the files back, a recompile only took
1.5 hours!
Steven Pemberton, CWI, Amsterdam; steven@cwi.nlroot@cca.ucsf.edu (Computer Center) (12/09/87)
In article <8712051307.AA12109@ucbvax.Berkeley.EDU>, aking@BFLY-VAX.BBN.COM (Allen King) writes: > Has anybody seen the following bug in version 4.14 of Alcyon C? > > /* > * The Alcyon C compiler (Version 4.14) gets confused with the following > * fragment, thinking that "y" in the assignment to F->y (line 10) is of > * type "struct in". > * > * The fault seems to require that the same names be used in the two structs, Please read K&R page 197 which requires that when the same member names are used in different structs the types must agree from the beginning of the struct through the member in question. Thos Sumner (thos@cca.ucsf.edu) BITNET: thos@ucsfcca (The I.G.) (...ucbvax!ucsfcgl!cca.ucsf!thos) If he says it's "user friendly" watch out; he's a con artist. #include <disclaimer.std>
tainter@ihlpg.ATT.COM (Tainter) (12/13/87)
> In article <8712051307.AA12109@ucbvax.Berkeley.EDU>, aking@BFLY-VAX.BBN.COM (Allen King) writes: > Please read K&R page 197 which requires that when the same member > names are used in different structs the types must agree from the > beginning of the struct through the member in question. >--Thos Sumner (thos@cca.ucsf.edu) BITNET: thos@ucsfcca Please go back and read the statement about this being an implementation characteristic of the now consistered to be crummy implementation of C they were documenting in that book. Even if they do have that restriction it is the obligation of the compiler to at a minimum warn you that such a conflict exists. What makes this a bug is silently accepting the code and generating bogus code. --j.a.tainter
sandra@utah-cs.UUCP (Sandra J Loosemore) (01/21/88)
In article <8712051307.AA12109@ucbvax.Berkeley.EDU>, aking@BFLY-VAX.BBN.COM (Allen King) writes: > Has anybody seen the following bug in version 4.14 of Alcyon C? > > main () > { register struct fl {float x, y;} *F; > register struct in {int x, y;} *I; > (etc.) I've run into this one before myself. If you read K&R carefully, two structures can have components with the same names *only* if the components are of the same type and at the same offset from the beginning of the structure. Many C compilers have departed from K&R and fixed this particular brain damage long ago -- I've been told that the ANSI C standard does not impose any similar restriction. It would be nice if Alcyon at least provided a warning about duplicate component names, but C has never been known as a language that provided good compiler diagnostics.... -Sandra Loosemore (sandra@cs.utah.edu)