jeff@warwick.UUCP (Jeff Smith) (04/10/86)
The adventures started when 3 control characters were discovered
lurking at the end of an identifier in the middle of cfront's output.
Taking anything out of the input (even comments!) made the bug vanish.
On other machines (sun, gould ..) this problem didn't arise. Maybe because
there was sufficient slack after the storage hunks had been rounded, or maybe
because the corruption was an adjoining 32-bit pointer with the `top'
byte zero, in which case you would expect either zero or three characters of
garbage depending on the direction of storage.
I've found this batch of malloc-style problems by ripping out
the C++ alloc.c storage handling routines and replacing them
with calls to the standard malloc and free. Then I recompiled
the standard malloc and free with stringent arena checking, and
initialisation to zero of the store returned (but not of any slosh
bytes at the end of the newly allocated store).
Does anyone know why C++ has its own storage management routines?
Actually, the arena tests turn out to be a bit of an overkill for
this particular problem: all of these problems could have
been found by cacheing the last couple of values returned by malloc
and checking their consistency. Probably the overhead would
be sufficiently small that I could leave such code in the
default version.
The following fix to expr.c corrects a bug in the way in which strings are
saved in the release 1 c++ compiler. While c_strlen does count
the NUL at the end of the string, it also counts backslash
escape sequences as a single character. This is not right
when the string is being stashed literally using strcpy.
*** original/src/expr.c Mon Nov 25 15:53:36 1985
--- /usr/src/cmd/c++/src/expr.c Wed Apr 9 19:57:07 1986
***************
*** 431,436
save:
/*error('d',"%s const_save %d",string,const_save);*/
if (const_save) {
int ll = c_strlen(string);
char* p = new char[ll];
strcpy(p,string);
--- 431,439 -----
save:
/*error('d',"%s const_save %d",string,const_save);*/
if (const_save) {
+ #ifdef STRLENFIXES
+ char* p = new char[strlen(string)+1];
+ #else !STRLENFIXES
int ll = c_strlen(string);
char* p = new char[ll];
+ #endif STRLENFIXES
Interestingly, all the problems I've encountered in this area are where
an array is being allocated and the size is calculated by some other
lump of code. Most calls to new are fine, because they're of the
form
Pexpr = new expr(A,B,c);
or similar - all of the calculation is done by the C++ system itself.
Surely there are systems round the world that have had this fixed already?
I must be wasting a massive amount of time trying to debug C++ problems
with inferior tools (Wot! No c++ source debugger??) and so must lots of
other people. Why can't the labs post fixes? Do we all have to work
in parallel to get the same bugs fixed, only on posting to get a
comment from Bjarne that it's been fixed in his version? (And no,
you can't have it!).
The problem, of course, is that there isn't time to reinvent
all these fixes ourselves out here in net-land, and if there
isn't any local support, the system doesn't get used - people
find it too difficult to cope with deficiencies and bugs in the
translator while they're still trying to learn the language.
Froth, foam at the mouth, fall over backwards
jeff
+44 203 523485
..mcvax!warwick!jeff (uucp)
jeff%warwick.uucp%daisy.warwick.ac.uk@ucl-cs.arpa (arpa)