steve@warwick.UUCP (Steve Rumsby) (03/11/86)
This is one of a series of reports of bugs found in the C++ compiler here at
warwick. We have release 1.0 of the software.
DESCRIPTION
Implicit type conversion doesn't work.
Nore that the below example is a cut down version of the "tiny"
example on page 175 of the book. That also doesn't work.
EXAMPLE
class big {
int b;
public:
big() { b = 0;}
operator int();
};
big::operator int() { return(b);}
main()
{
big b;
int i;
i = b + 1; // Oops, doesn't work (line 15)
i = (int)b + 1; // But this does
}
OUTPUT
CC /tmp/x.c:
"/tmp/x.c", line 15: error: call of b; b is a big
1 error
--
Steve Rumsby.
...!ukc!warwick!steve.steve@warwick.UUCP (Steve Rumsby) (03/11/86)
This is one of a series of reports of bugs found in the C++ compiler here at
warwick. We have release 1.0 of the software.
DESCRIPTION:
Mishandling of constant pointers.
Assignment of a constant pointer to a non-constant pointer
not allowed.
EXAMPLE:
char *const foo = "hello world";
main()
{
char *cp = foo;
}
OUTPUT:
CC const_ptr.c:
"const_ptr.c", line 6: error: bad initializer type char * const for cp ( char * expected)
1 error
--
Steve Rumsby.
...!ukc!warwick!steve.steve@warwick.UUCP (Steve Rumsby) (03/11/86)
This is one of a series of reports of bugs found in the C++ compiler here at
warwick. We have release 1.0 of the software.
DESCRIPTION
A C++ file is run through cpp before cfront, right?
Cpp Doesn't recognise // style comments and tries to process them
as normal. Any words in such comments which also happen to be
macro names will cause cpp to throw up.
EXAMPLE
#define foo(x) (x)
main()
{
int i = 1;
int j = 2;
i = foo(j); // That use of foo is fine, but the two
// occurrances of foo in this comment
// aren't
}
OUTPUT
CC /tmp/x.c:
/tmp/x.c: 8: foo: argument mismatch
/tmp/x.c: 9: foo: argument mismatch
/tmp/x.c: 8: foo: unterminated macro call
1 error
--
Steve Rumsby.
...!ukc!warwick!steve.steve@warwick.UUCP (Steve Rumsby) (03/11/86)
This is one of a series of reports of bugs found in the C++ compiler here at
warwick. We have release 1.0 of the software.
DESCRIPTION:
Mishandling of dynamic creation of an array of structs which have
a constructor.
Type cast missing for return value of _vec_new.
EXAMPLE:
struct foo {
foo() {}
};
main()
{
foo *bp = new foo[42]; // Oops...
}
OUTPUT:
CC buggy.c:
cc buggy.i -lC
"buggy.c", line 14: warning: illegal pointer combination
--
Steve Rumsby.
...!ukc!warwick!steve.dave@inset.UUCP (Dave Lukes) (03/18/86)
In article <261@euclid.warwick.UUCP> steve@warwick.UUCP (Steve Rumsby) writes: > > .... > > char *const foo = "hello world"; > > main() > { > char *cp = foo; > } > >OUTPUT: > CC const_ptr.c: > "const_ptr.c", line 6: error: bad initializer type char * const for cp ( char * expected) > 1 error Surely you would expect that: the erroneous line SHOULD read: > char *cp = (char *)foo; -- Dave Lukes. (...!inset!dave) All opinions, philosophies, dogmas and idiosyncrasies expressed in this article INCLUDING THIS DISCLAIMER, are solely those of the author.
steve@warwick.UUCP (Steve Rumsby) (03/20/86)
In article <869@inset.UUCP> dave@inset.UUCP (Dave Lukes) writes: >In article <261@euclid.warwick.UUCP> steve@warwick.UUCP (Steve Rumsby) writes: >> >> .... >> >> char *const foo = "hello world"; >> >> main() >> { >> char *cp = foo; >> } >> > >Surely you would expect that: the erroneous line SHOULD read: >> char *cp = (char *)foo; No, why? foo already *is* a (char *) - it just happens to be a constant one. Are you suggesting the we all should start writing int i = (int)42; After all, 42 isn't an "int", it's a "const int" isn't it :-) Seriously tho', why should I have to cast the value of foo from "char *const" to "char *" before I can use its value? Steve. -- Steve Rumsby. ...!ukc!warwick!steve.
guy@sun.uucp (Guy Harris) (03/24/86)
> >> char *const foo = "hello world"; > >> > >> main() > >> { > >> char *cp = foo; > >> } > >> > > > >Surely you would expect that: the erroneous line SHOULD read: > >> char *cp = (char *)foo; > > No, why? foo already *is* a (char *) - it just happens to be a constant one. > ...Seriously tho', why should I have to cast the value of foo from > "char *const" to "char *" before I can use its value? You can use its value perfectly well with the following: /*ARGSUSED*/ int main(argc, argv) int argc; /* OK, so call me a pedant... */ char **argv; { const char *cp = foo; ... /* one presumes there's more to "main()" than was shown */ } A "const char *" will do just as well as a "char *" in this case; the only thing you can't do with the "const char *" that you can do with a "char *" is modify what it refers to - and if "foo" points to a "const char" array, you can't modify it anyway (be warned - when ANSI C comes out, or when a C++ compiler that produces assembler or machine code instead of C comes out, there is an excellent chance that the string in question might be put into a read-only portion of your process' address space). In short, why are you trying to evade the type mechanism of C++? If you intend to modify what "foo" points to, declare "foo" to be a "char *" instead of a "const char *"; if you *don't* intend to modify what it points to, declare "cp" to be a "const char *" instead of a "char *". Type checking in general, and "const" type checking in particular, is there for your own good; use it. (BTW, why is it 'const char *foo = "string";' and not 'const char foo[] = "string";'? People seem to have the tendency to declare pointers unnecessarily in C and C++.) -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.arpa (yes, really)