gdykes@batcomputer.tn.cornell.edu (Gene Dykes) (05/07/87)
I have uncovered lots of bugs in C++, V1.2, and these are documented here
and in four accompanying postings. My apologies if any of them are "features".
Following are some miscellaneous bugs that are brief enough to discuss here.
* * * * * * * *
V1.0 form() only accepted 8 arguments.
V1.2 form() only accepts 10 arguments.
These limits have never been documented.
When more arguments are attempted, it returns garbage for the excess arguments.
Let's hope V1.3 gets it right and lets people know what the limits are.
The source (lib/stream/out.c) can be easily hacked if you need more arguments.
* * * * * * * *
Also in form() (lib/stream/out.c) is an exit()! No fprintf or anything.
We just got finished tracking down a bug that caused termination of the process
with no error message and this was it. I haven't yet looked to see if there
are more of the same lurking in C++ to make debugging a headache.
* * * * * * * *
In "CC/curses.h",
The printw,scanw family of declarations are bad.
They all end with ", int" when they should end with " ..."
I haven't looked farther than that, so there could well be lots of
other bad declarations in curses.h
* * * * * * * * *
If CC is given the following command, where one.c has errors,
it tries to continue after failing to compile one.c:
CC one.c two.o -o three
CC one.c:
"one.c", line 2: error: syntax error
1 error
cc -o three two.o -lC
ld: Undefined external -
_main
ld: output file still contains undefined symbols
ld: (Warning) did not generate an output file
Whereas "cc" handles this properly:
cc one.c two.o -o three
"one.c", line 2: syntax error
* * * * * * * *
At least on HPUX, the following fails:
CC x.c -o x
Loading and compiling must be done in two steps when there is only a
single file involved:
CC -c x.c
CC x.o -o x
* * * * * * * *
// This isn't a bug, but...
class cb ;
class
ca {
friend cb::funcb() ;
funca() ;
} ;
class
cb
{
friend ca::funca() ;
funcb() ;
} ;
In the example above, two classes each want to have a friend that is a
member of the other class. This would be very useful, but it doesn't
compile because a class has to be defined in order to declare a friend
of one of its functions. Clearly, they can't both be defined first.
Every time this happens to me, then I must resort to moving a data item
into the public part of the class so that I can access it just from the
single function that I need it for. But then it is accessible by
everybody and his dog, which is what this data hiding was supposed to
prevent.
Can anything be done about this in future versions of the language?
I run into this problem all the time...
* * * * * * * * *
My guess is that the following is a feature of C++ that is loved by many,
but here's my dissenting vote: if I declare a function "void func(float)"
and then call it with an integer I want an error reported - I don't want
C++ to coerce the int into a float for me. Wouldn't it be a good idea
to have something like "#define CC_STRICT" that would optionally turn off
this kind of type conversion?
* * * * * * * * *
The installation makefiles and release notes are still woefully inadequate,
at least for HPUX sites, so the following should help those people along.
1) Don't even THINK about trying to do an update. Start from the beginning
and bootstrap a version of C++. But first attend to the following:
2) Fix CC, line 79, which won't work. (It won't work on GOULD Unix
either) If you don't patch it, compiling "x.c" will give you "x.c.o"
A quick and dirty fix is to replace "[cC]" with "c". I haven't yet tried
to fix it so that x.C will be recognized. It's probably trivial.
3) Remove the line with "ranlib" in it from "lib/mk/makefile". The test
won't work.
4) In the top-level "makefile" replace the single line that makes "munch"
with the following two lines... (see bug reported above)
$(CC) $(CCFLAGS) -c lib/static/munch.c
$(CC) $(CCFLAGS) -o munch lib/static/munch.o
5) The following is a useful "hp.sed" to run in the scratch directory.
echo "Fixing _iobuf structures:"
for f in */*..c
do
echo $f
sed -e '/char __iobuf__flag/s//short __iobuf__flag/' \
-e '/char \*__iobuf__ptr/s//unsigned char \*__iobuf__ptr/g' \
-e '/char \*__iobuf__base/s//unsigned char \*__iobuf__base/g' \
$f > temp$$
mv temp$$ $f
done
* * * * * * *
Fortunately, C++ is well worth any troubles encountered in bringing it up,
and still worth it after putting up with the bugs which are described in
the accompanying articles.
--
Gene Dykes, 120 Rand Hall, Cornell U., Ithaca, NY 14853 (607)255-6713
UUCP: {uw-beaver,ihnp4,decvax,allegra,vax135}!cornell!batcomputer!gdykes
ARPA: gdykes@tcgould.tn.cornell.edu
BITNET: gdykes@CRNLTHRYgdykes@batcomputer.tn.cornell.edu (Gene Dykes) (05/07/87)
void
f (int dummy1, struct { int flag; } *x, int dummy2)
{
x->flag = 0 ;
}
/*
The above code fails to compile, with the following message:
"bug.c", line 4: error: x is undefined
The following three ways all "fix" the bug:
1) remove "dummy1" from the function call
2) remove "dummy2" from the function call
3) declare the structure ahead of time with a tag,
and use the tag to declare x
*/
--
Gene Dykes, 120 Rand Hall, Cornell U., Ithaca, NY 14853 (607)255-6713
UUCP: {uw-beaver,ihnp4,decvax,allegra,vax135}!cornell!batcomputer!gdykes
ARPA: gdykes@tcgould.tn.cornell.edu
BITNET: gdykes@CRNLTHRYgdykes@batcomputer.tn.cornell.edu (Gene Dykes) (05/07/87)
/*
* In this example, the code compiles correctly.
* If the two lines that are commented out are de-commented,
* the compiler states that I am passing a bad argument to my_func -
* "example.c", line 17: error: bad argument list for overloaded my_func()
*/
// overload my_func ;
// int my_func (int) ;
int my_func (char *[]) ;
main()
{
char *a[3] ;
my_func (a) ;
}
/*
* This certainly doesn't seem reasonable to me...
* If it was a good argument list to a non-overloaded function,
* why is it a bad argument list to an overloaded one?
*
* The following is an additional example using implicit overloading
*/
// This example compiles okay...
class
c_wm
{
// c_wm () ;
c_wm(char *[]) ;
} ;
class
c_select
{
void member() ;
char *arg[2] ;
c_wm *w_manager ;
} ;
void
c_select::member ()
{
w_manager = new c_wm(arg) ;
}
/**
But if the additional constructor is not commented out, it won't compile
because it claims the original constructor was called with bad arguments.
**/
--
Gene Dykes, 120 Rand Hall, Cornell U., Ithaca, NY 14853 (607)255-6713
UUCP: {uw-beaver,ihnp4,decvax,allegra,vax135}!cornell!batcomputer!gdykes
ARPA: gdykes@tcgould.tn.cornell.edu
BITNET: gdykes@CRNLTHRYgdykes@batcomputer.tn.cornell.edu (Gene Dykes) (05/07/87)
// It appears that a pointer to a function cannot be the first argument
// in a function...
void a (int, void (*)()) ; // no problem here
void b (void (*)()) ; // syntax error !!!
// So, whenever I want to do something like that, I have to pass along
// a dummy argument to keep CC happy.
--
Gene Dykes, 120 Rand Hall, Cornell U., Ithaca, NY 14853 (607)255-6713
UUCP: {uw-beaver,ihnp4,decvax,allegra,vax135}!cornell!batcomputer!gdykes
ARPA: gdykes@tcgould.tn.cornell.edu
BITNET: gdykes@CRNLTHRYgdykes@batcomputer.tn.cornell.edu (Gene Dykes) (05/07/87)
// The "duplicate line" problem...
void function (int arg1)
{
int var1 ; // eliminate this line and the next one...
var1 = arg1 ; // and the bug goes away.
// otherwise...
// both of these lines are tagged as the same line by cfront with "#line"
int var2 = arg1 + 10 ;
int var3 = arg1 - 10 ; // this is quite annoying when using debuggers
}
--
Gene Dykes, 120 Rand Hall, Cornell U., Ithaca, NY 14853 (607)255-6713
UUCP: {uw-beaver,ihnp4,decvax,allegra,vax135}!cornell!batcomputer!gdykes
ARPA: gdykes@tcgould.tn.cornell.edu
BITNET: gdykes@CRNLTHRYmikem@otc.OZ (Mike Mowbray) (05/09/87)
in article <909@batcomputer.tn.cornell.edu>, gdykes@batcomputer.tn.cornell.edu (Gene Dykes) says: > [ ... ] if I declare a function "void func(float)" and then call it > with an integer I want an error reported - I don't want C++ to coerce > the int into a float for me. Wouldn't it be a good idea to have > something like "#define CC_STRICT" that would optionally turn off this > kind of type conversion? I too would like to have the option to turn on such warnings, especially in the case of user-defined types. Sometimes the coercion will NOT be what you want. My preference, though, would be for a command-line option to CC, rather than a #define. Mike Mowbray Systems Development Overseas Telecommunications Commission (Australia) UUCP: {seismo,mcvax}!otc.oz!mikem ACSnet: mikem@otc.oz
news@rlvd.UUCP (05/19/87)
In article <909@batcomputer.tn.cornell.edu> gdykes@tcgould.tn.cornell.edu.UUCP (Gene Dykes) writes: > >I have uncovered lots of bugs in C++, V1.2, and these are documented here >... >2) Fix CC, line 79, which won't work. (It won't work on GOULD Unix >either) If you don't patch it, compiling "x.c" will give you "x.c.o" >A quick and dirty fix is to replace "[cC]" with "c". I haven't yet tried >to fix it so that x.C will be recognized. It's probably trivial. > This problem is that the System V basename(1) (or at least the one we have in the att universe on our Pyramid) allows invocations of the form: basename filename .[cC] which has the expected (to sh(1) users) effect. The fix I came up with for the older basename(1) was to use: case $A in *.c) B=`basename $A .c` ;; *.C) B=`basename $A .C` ;; esac The only other change I had to make, apart from coping with odd flavours of UNIX and sh(1), was to add a -DBSD to the CC script when appropriate so that stdio.h comes out of cpp correctly. This may be mentioned in the documentation somewhere and I have just missed it. >... >Fortunately, C++ is well worth any troubles encountered in bringing it up, I agree. Also, over the last few years I have ported five or so versions of C++ to several different and tricky machines and I really appreciate the effort that Bjarne and his assistants have put into making this version so much more portable. Chris. ======================================================================= Chris M Crampton UK JANET: cmc@uk.ac.rl.vd Rutherford Appleton Labs, ARPA: @ucl-cs.arpa:cmc@vd.rl.ac.uk Didcot, OXON, U.K. UUCP: ..!mcvax!ukc!rlvd!cmc +44 235 21900 ext. 6756
seindal@diku.UUCP (Rene Seindal) (05/25/87)
In article <369@rlvd.UUCP> news@rlvd.UUCP (News) writes: >This problem is that the System V basename(1) (or at least the one we >have in the att universe on our Pyramid) allows invocations of the form: > basename filename .[cC] > >which has the expected (to sh(1) users) effect. The fix I came up with for >the older basename(1) was to use: > case $A in > *.c) B=`basename $A .c` > ;; > *.C) B=`basename $A .C` > ;; > esac This is actually one of the nastiest bugs in CC under Berkeley UNIX, since one can't bring up the system before it is fixed. I think Bjarne should be aware of such sysV dependencies for the next release. As far as I could see, the distribution (of 1.2) could not run on anything but sysV. This is not acceptable for a commercially distributed system. Rene' Seindal (seindal@diku.UUCP). The Computer Department, Institute of Datalogy, U. of Copenhagen.
jon@oddhack.UUCP (05/26/87)
In article <3237@diku.UUCP> seindal@diku.UUCP (Rene Seindal) writes: >This is actually one of the nastiest bugs in CC under Berkeley UNIX, since >one can't bring up the system before it is fixed. I think Bjarne should be >aware of such sysV dependencies for the next release. As far as I could >see, the distribution (of 1.2) could not run on anything but sysV. This is >not acceptable for a commercially distributed system. I don't know about 1.2, but my 1.1 manual says prominently on the front cover: UNIX System V AT&T C++ Translator Release Notes and also comments that it is intended for System V in the Introduction. This is hardly surprising given AT&T's position with respect to Sys V! If you want support for BSD, buy it from one of the outfits that repackages it. Otherwise, you takes what you can get. Having some experience with keeping a program portable across many types of unix and other operating systems (a complex screen editor in my case), I have a great deal of sympathy for Bjarne. Give him a break. -- Jon Leech (jon@csvax.caltech.edu || ...seismo!cit-vax!jon) Caltech Computer Science Graphics Group __@/
seindal@diku.UUCP (Rene Seindal) (05/27/87)
In article <2816@cit-vax.Caltech.Edu> jon@oddhack.caltech.edu (Jon Leech) writes: >In article <3237@diku.UUCP> seindal@diku.UUCP (Rene Seindal) writes: >>This is actually one of the nastiest bugs in CC under Berkeley UNIX, since >>one can't bring up the system before it is fixed. I think Bjarne should be >>aware of such sysV dependencies for the next release. As far as I could >>see, the distribution (of 1.2) could not run on anything but sysV. This is >>not acceptable for a commercially distributed system. > I don't know about 1.2, but my 1.1 manual says prominently on the >front cover: > UNIX System V > AT&T C++ Translator > Release Notes >and also comments that it is intended for System V in the Introduction. >This is hardly surprising given AT&T's position with respect to Sys V! I don't have any release notes for 1.2.1, but the label on my distribution tape says UNIX* System C++ Translator Release 1.2.1 I have a C++ Translator Porting Guide, and it contains a lot of useful hints about how to port C++ to BSD. But all these information concerns cfront, munch and the system header files. Nothing is said about the CC script (except about putting a "#!/bin/sh" in top of it, which is trivial) >If you want support for BSD, buy it from one of the outfits that repackages >it. Otherwise, you takes what you can get. Having some experience with >keeping a program portable across many types of unix and other operating >systems (a complex screen editor in my case), I have a great deal of >sympathy for Bjarne. Give him a break. If is wasn't for the basename bug, C++ would have been extremely easy to port, and I could have done it in an hour. Because of this bug, it took me more than a day. When it was it was fixed everything was fine. About all the problems I have encountered with C++, concerns the CC script. It seems as if it was forgotten when working through the portablity issues. Rene' Seindal (seindal@diku.UUCP). The Computer Department, Institute of Datalogy, U. of Copenhagen.