dave@utcsrgv.UUCP (Dave Sherman) (12/06/83)
Is that a problem? I treat it as a compiler feature I take advantage of.
struct foo
{
int x,y;
char flag;
struct something *sp;
};
struct bar
{
int x,y;
char flag;
};
Both types can usefully refer to x,y, and flag, but only the
"foo" type has ->sp as well. I've never had a problem with this,
and hope new compilers aren't going to stop it.
Yes, I know you're all going to tell me I shouldn't do it,
and there are better ways of doing it, and it's dangerous,
and... But I happen to like it.
Note that the compiler will (and should) give you an error if
you try and put "x", "y" or "flag" into a different place in
the second structure than it appears in the first.
Dave Sherman
Toronto
--
{allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsrgv!daveguy@rlgvax.UUCP (12/07/83)
<please don't trash me>
struct foo
{
int x,y;
char flag;
struct something *sp;
};
struct bar
{
int x,y;
char flag;
};
.
.
.
Note that the compiler will (and should) give you an error if
you try and put "x", "y" or "flag" into a different place in
the second structure than it appears in the first.
The language was changed as of System III so that the compiler doesn't
(and shouldn't) complain if "x", "y", or "flag" either appears in a different
place or has a different type (and since 4.xBSD comes with the System III
VAX-11 PCC, it applies there also). This behavior is more sensible than
the "sugared assembler" previous behavior - structure member names are not
just symbolic names for byte offsets. There is no reason why structure
names shouldn't be local to the structure - admittedly, putting in the
unique tags that everybody did before this compiler change may make it
a bit easier to identify what kind of a structure "c_foo" is a member
of.
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guymark@cbosgd.UUCP (12/07/83)
Uh, excuse me, but 4.xBSD does NOT come with the System III VAX pcc. If it did, you would need a system III license to get 4BSD. Also, if it did, you wouldn't be able to have names longer than 8 characters that are the same in the first 8. 4.1BSD comes with a pcc from 32V, with flexnames added and supporting the same structure field language chanes you described. 4.2BSD supports the same C language but has a C compiler largely rewritten at Berkeley.
guy@rlgvax.UUCP (Guy Harris) (12/08/83)
Well, "diff" tells me that 4.1BSD comes with the System III PCC. 99% of the
output of "diff" between the sources of the 4.1BSD C compiler and the System III
C compiler refer to the flexnames stuff, so it certainly looks either like they
got some version of the compiler that also went out with System III and put
flexnames into that, or that the C compiler that comes with System III is the
32/V compiler.
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guyrick@alice.UUCP (12/09/83)
Try ``/lib/ccom'' -Xr'' and see what your ``BSD'' compiler says to you. My guess is ``Release: PCC/364r1 vax uts3.0'' Care to speculate on what that means? (Of course, long variable names were a Berkeley addition.)
rick@alice.UUCP (12/09/83)
sorry, that should read ``/lib/ccom -Xv'' To save some suspense the ``364'' was, at the time, the Laboratory number of ``USG'', ``r1'' was a release designation, and I think you can guess what the ``vax uts3.0'' means.
fair@dual.UUCP (Erik E. Fair) (12/10/83)
Guy Harris has the cart before the horse. Probably the proper way to
refer to things is that System III comes with a 4.1BSD PCC.
a 4BSD fan who is not afraid to say nasty things about USG,
Erik E. Fair {ucbvax,amd70,zehntel,unisoft,onyx,its}!dual!fair
Dual Systems Corporation, Berkeley, Californiajimjwf@mhtsa.UUCP (12/14/83)
All of the Vax PCC implementations are derived from the 32V compiler. There was significant work done on the compiler for the System III release. The independent parts were changed at Bel Labs in Indian Hill and the machine dependent (code generation) parts were changed at Bell Labs Murray Hill (USG land). The USG integrated all of the changes to produce the Sys III PCC. There was a fair exchange of the bugs in the 32V compiler between the labs (research and USG) and the bsd people and many nits were fixed. As a result the System III compiler was adopted by one and all as the new base for the VAX PCC. Since then we seem to have gone our separate ways. Jim Farrell AT&T Bell Labs mhtsa!jimjwf
olson@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 Chemistry