Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!rutgers!lll-lcc!pyramid!batcomputer!gdykes
From: gdykes@batcomputer.tn.cornell.edu (Gene Dykes)
Newsgroups: comp.lang.c++
Subject: Cornell V1.2 Bug Report (1/5)
Message-ID: <909@batcomputer.tn.cornell.edu>
Date: Thu, 7-May-87 10:20:39 EDT
Article-I.D.: batcompu.909
Posted: Thu May  7 10:20:39 1987
Date-Received: Sat, 9-May-87 09:37:02 EDT
Reply-To: gdykes@tcgould.tn.cornell.edu.UUCP (Gene Dykes)
Distribution: world
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 153


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@CRNLTHRY