sean@garfield.UUCP (Sean Byrne) (12/04/83)
I have noticed this bug in 2.8 (in might be in 2.9 although WE
HAVEN'T GOT IT YET). It is this:
struct abcdef {
int a;
char name[256];
}
struct ghijkl {
int a;
char name[256];
}
to which the compiler promptly replies:
a.c: name redeclared
Integers are not redeclared, only arrays. This problem is fixed in 4.1
and greater.
Anybody fix/encounter this problem yet?
--
Sean Byrne Memorial University of NF St. John's, Nfld
UUCP: {allegra, ihnp4, utcsrgv}!garfield!seandave@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