draves@harvard.ARPA (Richard Draves) (01/20/85)
I just started reading this group, so please excuse me
if this bug is well-known.
Our 4.2bsd cc accepts the following program as correct:
/* note nested declaration of struct a */
struct a
{
struct a
{
int b;
} *c;
} d;
I have no idea what the fix would be.
Rich
--
"If I am conceited, it is the conceit of an amazing man
who has never found any surpassing himself."
Al-Mutanabbiolson@lasspvax.UUCP (Todd Olson) (09/01/85)
[]
In the process of writing a human interface for a graphics program I
stumbled across what I think is a bug in the 4.2bsd cc. I've removed
the extra code and simplified the data structures to isolate the error.
I'd like to know if the rest of you out there suffer from this
'bug' and to who's attention the problem should be brought for fixing
(Is it to late for 4.3 to catch, (if it hasn't already)??)
SYSTEM:
4.2bsd on a VAX 11/750
COMMAND:
cc
DESCRIPTION:
Consider a 2-dim array of pointers to a structure. X
Consider a function that is passed a structure. f
Now, get the structure that is passed to the function by
dereferencing an element of the array selected by constant
subscripts. f(*X[0][0]);
Now, do the same but let the SECOND array subscript be
an integer variable. f(*X[0][n]);
Now, do the same but let the FIRST array subscript be
the integer variable. f(*X[n][0]);
The first two forms compile and run fine. The third form
gives the error message:
"ccbug.c", line 15: compiler error: stuck starg
Further, doing the dereferencing and then the function call
works just fine. y = *X[n][0];
f(y);
or
f(y=*X[n][0]);
REPEAT BY:
compile this program
----------------------------------------------------------------------
struct S {
int a;
int b;
} *X[2][2],
IS = { 1, 2 };
main()
{
int f();
int n;
n = 0;
X[0][0] = &IS;
f( *X[n][0] ); /* cc complains on this line */
}
int f(m)
struct S m;
{
printf("%d %d\n", m.a, m.b);
}
----------------------------------------------------------------------
BTW: 'lint -ph' produces no messages
--
Todd Olson
ARPA: olson@lasspvax -- or -- olson%lasspvax@cu-arpa.cs.cornell.edu
UUCP: {ihnp4,allegra,...}!cornell!lasspvax!olson
US Mail: Dept Physics, Clark Hall, Cornell University, Ithaca, New York 14853tps@sdchema.UUCP (Tom Stockfisch) (09/04/85)
[]
Todd Olson writes that the 4.2 C compiler can't handle
int n;
struct foo
I think there are many bugs in the way 4.2 handles passing whole structures.
Consider the following bug which prevents one from treating complex numbers
as primitives. The gyst is that you can't immediately access a member of
a structure returned by a function. Very frustrating.
Now, do the same but let the FIRST array subscript be
the integer variable. f(*X[n][0]);
The first two forms compile and run fine. The third form
gives the error message:
"ccbug.c", line 15: compiler error: stuck starg
Further, doing the dereferencing and then the function call
works just fine. y = *X[n][0];
f(y);
or
f(y=*X[n][0]);
REPEAT BY:
compile this program
----------------------------------------------------------------------
struct S {
int a;
int b;
} *X[2][2],
IS = { 1, 2 };
main()
{
int f();
int n;
n = 0;
X[0][0] = &IS;
f( *X[n][0] ); /* cc complains on this line */
}
int f(m)
struct S m;
{
printf("%d %d\n", m.a, m.b);
}
----------------------------------------------------------------------
BTW: 'lint -ph' produces no messages
--
Todd Olson
ARPA: olson@lasspvax -- or -- olson%lasspvax@cu-arpa.cs.cornell.edu
UUCP: {ihnp4,allegra,...}!cornell!lasspvax!olson
US Mail: Dept Physics, Clark Hall, Cornell University, Ithaca, New York 14853tps@sdchema.UUCP (Tom Stockfisch) (09/05/85)
[]
[Repost-- previous submission got mangled]
Todd Olson writes that the 4.2 C compiler can't handle
int n;
struct S {
int a;
int b;
} *X[2][2],
.
.
.
f( *X[n][0] ); /* cc complains on this line */
I think there are _many_ bugs in the way 4.2 handles passing whole structures.
Consider the following bug bite I received which prevents me from treating
complex numbers as primitives. The gyst is that you can't immediately
access a member of a structure returned by a function. Very frustrating.
/* C stuff trying to deal with complex numbers as primitives */
typedef struct {
double re;
double im;
} complex;
main()
{
complex topolar();
double mag;
complex c2;
static complex c1 = { 1.0, 2.0 };
/*###18 [cc] structure reference must be addressable%%%*/
mag = topolar(c1).re; /* sure would be nice if I
* could do this
*/
/*###21 [cc] structure reference must be addressable%%%*/
mag = ( c2 = topolar(c1) ).re; /* even this doesn't work */
/* you have to break it into two separate statements--this works */
c2 = topolar(c1);
mag = c2.re;
}
complex
topolar( z ) /* convert z to polar form */
complex z;
{
complex polar;
double hypot(), atan2();
/* details not related to bug */
polar.re = hypot( z.re, z.im );
polar.im = atan2( z.im, z.re );
return polar;
}
/* end of program */
I sure hope 4.3 fixes this.
--Tom Stockfisch
UCSD Chemistrywolfe@winston.UUCP (Peter Wolfe) (12/05/85)
Description:
cc(1) will generate incorrect code if you declare a forward reference
and inadvertantly have an argument inside the (). No complaints
or warnings just wrong code.
Lint does not really catch it etiher.
Repeat-By:
extern int pw(ptr); <<<<<<<<---------------- admittly illegal
int pw(d, l)
char *d;
short l;
{
pw(d, l);
}
Produces:
LL0:
.data
.text
.align 1
.globl _pw
_pw:
.word L12
jbr L14
L15:
cvtwl 12(ap),-(sp) <<<<<<<--------------- should be 8
pushl 8(ap) <<<<<<<--------------- should be 4
calls $2,_pw
ret
.set L12,0x0
L14:
jbr L15
.data
Lint (lint test.c) says the following:
test.c:
test.c(6): warning: argument ptr unused in function pw
pw: variable # of args. test.c(6) :: test.c(7)
pw, arg. 1 used inconsistently test.c(6) :: test.c(7)
pw, arg. 2 used inconsistently test.c(6) :: test.c(7)
Fix:
Here I am out of my depth. Probably this will all be fixed when
pcc gets its ANSI standard upgrade?
--
Peter Wolfe
New Media Technologies
..decvax!microsoft!ubc-vision!winston!wolfe
..ihnp4!alberta!ubc-vision!winston!wolfedonn@utah-gr.UUCP (Donn Seeley) (12/09/85)
From: wolfe@winston.UUCP (Peter Wolfe) cc(1) will generate incorrect code if you declare a forward reference and inadvertantly have an argument inside the (). ... When I compile your example, the 4.3 BSD compiler says: ------------------------------------------------------------------------ foo.c, line 1: illegal argument ------------------------------------------------------------------------ ... Probably this will all be fixed when pcc gets its ANSI standard upgrade? What 'ANSI standard upgrade'? It's news to me. In fact I hadn't heard that there was an ANSI standard yet. (And will it be an 'upgrade' or a 'downgrade' if it arrives? :-) Donn Seeley University of Utah CS Dept donn@utah-cs.arpa 40 46' 6"N 111 50' 34"W (801) 581-5668 decvax!utah-cs!donn