battle@alphard.cs.utk.edu (David Battle) (01/03/90)
I seem to have discovered a bug in DEC's Ultrix C compilers. The bug
exhibits itself on both vax and mips architectures. The problem is that
it seems to ignore objects declared as "void *". Here is an example,
straight out of K&R2 (page 121):
First, on a DECStation 3100:
mips> head -1 /etc/motd
Ultrix Worksystem V2.1 (Rev. 14) System #2: Mon Nov 6 11:22:25 EST 1989
mips> cat tmp.c
void
swap(void *v[], int i, int j)
{
void *temp;
temp = v[i];
v[i] = v[j];
v[j] = temp;
}
mips> cc -c tmp.c
ccom: Error: tmp.c, line 6: temp undefined
temp = v[i];
---------^
ccom: Warning: tmp.c, line 6: illegal combination of pointer and integer, op =
temp = v[i];
---------------^
ccom: Warning: tmp.c, line 8: illegal combination of pointer and integer, op =
v[j] = temp;
---------------^
(ccom): tmp.c, line 8: cannot recover from earlier errors: goodbye!
}
^
And on the MicroVax (doesn't handle prototypes yet):
vax> head -1 /etc/motd
Ultrix-32 V3.0 (Rev 64) UWS V2.0 System #2: Fri Aug 4 00:02:44 EDT 1989
vax> more foo.c
void
swap(v,i,j)
void *v[];
int i, j;
{
void *temp;
temp = v[i];
v[i] = v[j];
v[j] = temp;
}
vax> cc -c foo.c
"foo.c", line 8: temp undefined
"foo.c", line 8: warning: illegal combination of pointer and integer, op =
"foo.c", line 10: warning: illegal combination of pointer and integer, op =
The unprotoized version works fine on a sun:
sun> cat > foo.c
swap(v,i,j)
void *v[];
int i, j;
{
void *temp;
temp = v[i];
v[i] = v[j];
v[j] = temp;
}
sun> cc -c foo.c
sun>
Am I missing something here, or is this a real bug?
-David L. Battle
battle@battle.esd.ornl.gov
battle@utkux1.utk.edukyriazis@herodotus.rdrc.rpi.edu (George Kyriazis) (01/03/90)
In article <1528@utkcs2.cs.utk.edu> battle@alphard.cs.utk.edu (David Battle) writes: >I seem to have discovered a bug in DEC's Ultrix C compilers. The bug >exhibits itself on both vax and mips architectures. The problem is that >it seems to ignore objects declared as "void *". Here is an example, >straight out of K&R2 (page 121): > [ lots of interesting bechmarks ] > >Am I missing something here, or is this a real bug? > Last year I had the same problem with a uVAX II C compiler and I think it is a bug. The program compiled fine on suns. I got around it with a useless: '#define void char' and now it works in both architectures. Since char *'s have the smaller stride size (1 byte) everything should work fine. I wonder what DEC people have to say about that though.. > > -David L. Battle > battle@battle.esd.ornl.gov > battle@utkux1.utk.edu George Kyriazis kyriazis@turing.cs.rpi.edu kyriazis@rdrc.rpi.edu ------------------------------
henry@utzoo.uucp (Henry Spencer) (01/04/90)
In article <1528@utkcs2.cs.utk.edu> battle@alphard.cs.utk.edu (David Battle) writes: >I seem to have discovered a bug in DEC's Ultrix C compilers. The bug >exhibits itself on both vax and mips architectures. The problem is that >it seems to ignore objects declared as "void *"... >Am I missing something here, or is this a real bug? Yes. :-) What you've missed is that K&R2 describes ANSI C, and many C compilers have not yet been updated to fully conform to the (draft) standard. However, this is arguably a bug -- they've had plenty of warning about what they ought to be implementing. -- 1972: Saturn V #15 flight-ready| Henry Spencer at U of Toronto Zoology 1990: birds nesting in engines | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
hoyt@bessie.alf.dec.com (Kurt Hoyt) (01/04/90)
In article <6-HQ+=@rpi.edu> kyriazis@herodotus.rdrc.rpi.edu.UUCP (George Kyriazis) writes: >Last year I had the same problem with a uVAX II C compiler and I >think it is a bug. The program compiled fine on suns. I got > >I wonder what DEC people have to say about that though.. > Speaking unofficially... It's not a bug. The current pcc-based compilers on Ultrix are K&R1, not K&R2. I don't know when this will change. The VAX C for Ultrix compiler is ANSI-like and will accept pointers to void (for those of you who don't mind using vcc). I'm not privy to what the Ultrix compiler folks are up to, so I don't know the when and/or ifs on ANSIfication. Kurt Hoyt Digital Equipment Corporation hoyt@decatl.alf.dec.com "Daddy, you not people, you a GUY! Mommy a girl." -- Faith Hoyt
scjones@sdrc.UUCP (Larry Jones) (01/04/90)
In article <1528@utkcs2.cs.utk.edu>, battle@alphard.cs.utk.edu (David Battle) writes: > I seem to have discovered a bug in DEC's Ultrix C compilers. The bug > exhibits itself on both vax and mips architectures. The problem is that > it seems to ignore objects declared as "void *". No, it's not a bug, it's just an old compiler. When the void type was originally added to C, the only valid use was as the return type of a function (no void variables, no arrays of void, no pointers to void). The bit pattern corresponding to the "nonsensical" void * type just happened to be what was used for undeclared variables, hence the somewhat confusing diagnostic. ---- Larry Jones UUCP: uunet!sdrc!scjones SDRC scjones@SDRC.UU.NET 2000 Eastman Dr. BIX: ltl Milford, OH 45150-2789 AT&T: (513) 576-2070 "You know how Einstein got bad grades as a kid? Well MINE are even WORSE!" -Calvin
randall@uvaarpa.virginia.edu (Randall Atkinson) (01/07/90)
In article <1528@utkcs2.cs.utk.edu> battle@alphard.cs.utk.edu (David Battle) writes: >I seem to have discovered a bug in DEC's Ultrix C compilers. The bug >exhibits itself on both vax and mips architectures. The problem is that >it seems to ignore objects declared as "void *"... >Am I missing something here, or is this a real bug? Henry was correct that DEC doesn't yet claim to have an ANSI C compiler. Indications are that the only C Compiler from DEC getting significant maintenance is the "Vax C" compiler which the periodically ported from VMS back to Ultrix. DEC indicates that they plan to make it both X3J11 and POSIX.1 compatible eventually. If that is the only problem that people are having with "cc" on Ultrix 3, they can't be using it very much. For reasons beyond my understanding, DEC broke the "cc" compiler from BSD and it won't compile many of the sources from UC Berkeley. I find this very odd in a system which is mostly 4.2 BSD. Needless to say, I wish my workplace hadn't "upgraded" [ sic ] from 4 BSD to Ultrix last summer. We did it to get better support and haven't had much support so far. Needless to say, I don't speak for the corporation which is The University of Virginia. This machine runs 4.3.tahoe and has none of the problems that the Ultrix VAX at work does. I've digressed a bit, so I've pointed followups to alt.religion.computers.