mnc@m10ux.UUCP (04/27/87)
Here is a nasty little bug I just ran into with the Sys V R2 (VAX) C
compiler and the Sun C compiler (but it does not exist on 4.3 BSD).
Consider:
extern void f(), (*fp)();
int x;
main() {
g(x ? f : fp);
g(x ? f : *fp);
}
Both of the uses of the "? :" operator produce the message "operands of
: have incompatible types". Changing "void" to any other type makes
both error messages go away. Notice that there is no attempt to use
a void value in the above expression. Since this code is likely to
occur in any C program that passes procedures (i.e. void functions) as
arguments, I don't understand how the bug could have persisted this long.
The only work-around I can think of (besides changing the declaration of
f and fp) is to use "if - else" instead of "? - :".
--
Michael Condict {ihnp4|vax135|cuae2}!m10ux!mnc
AT&T Bell Labs (201)582-5911 MH 3B-416
Murray Hill, NJknudsen@ihlpl.ATT.COM (Knudsen) (10/14/88)
YACCB == Yet Another Microware OS9/6809 'C' Compiler Bug (just what we
needed).
This one is strange, and probably occurs only when the compiler is
overloaded by a big source file.
After a *very* long main() function definition,
and a couple of static arrays,
I had several more very short function bodies.
The second one looked like
int barmice(x)
int x;
{
int i;
....couple lines of code ....
}
and the compiler tagged the "int x" as "redeclaration of x."
Or mayube "redefinition."
Now that's quite a trick, since argument variable declarations
override any other usage of that same name.
[I'd already called barmice(mx), where mx was also int;
I hear some fancy compilers will pre-infer argument types from calls,
something I've only seen LINT do.]
Changing x's name to something unique didn't help.
Swapping this function body with the following one got rid of
the error. I don't consider that much of a "fix."
My belief is that some table in the compiler got full.
Since the 6809 compiler phases don't bother to check for I/O
errors (like disk full), I suspect they didn't catch this table-full
error and either messed up a table entry or expanded one table
to tromp on some other data, so all bets were off.
Guess we'll just have to keep our function bodies less than a few pages
each, even for main(). (Flames about programming style to /NIL).
I like the Microware C compiler, but I sure wish they'd
do better error checking, at least in Level II where you can afford
the extra memory.
--
Mike Knudsen Bell Labs(AT&T) att!ihlpl!knudsen
"Lawyers are like handguns and nuclear bombs. Nobody likes them,
but the other guy's got one, so I better get one too."kim@mcrware.UUCP (Kim Kempf) (10/18/88)
In article <7201@ihlpl.ATT.COM>, knudsen@ihlpl.ATT.COM (Knudsen) writes: > YACCB == Yet Another Microware OS9/6809 'C' Compiler Bug (just what we > needed). > This one is strange, and probably occurs only when the compiler is > overloaded by a big source file. > > After a *very* long main() function definition, > and a couple of static arrays, > I had several more very short function bodies. > The second one looked like > [non interesting lines deleted] > and the compiler tagged the "int x" as "redeclaration of x." You might want to try compiling the program on Nuxi or run it through the "cb" to find the unbalanced braces you overlooked in the "very long main() function" that preceeds this. Or, mail me the source file and I'll point out the problem for you. Since moving the function elsewhere changes the problem, this is the likely problem. We understand the confusion and frustration one suffers when confronted with problems of this sort...apologies are gladly accepted :-) ---------------- Kim Kempf, Microware Systems Corporation ...!sun!mcrware!kim
knudsen@ihlpl.ATT.COM (Knudsen) (10/21/88)
In article <762@mcrware.UUCP>, kim@mcrware.UUCP (Kim Kempf) writes: > You might want to try compiling the program on Nuxi or run it through > the "cb" to find the unbalanced braces you overlooked in the "very > long main() function" that preceeds this. Or, mail me the source > file and I'll point out the problem for you. Since moving the function > elsewhere changes the problem, this is the likely problem. Sorry, a missing '}' was my first suspicion, and I checked it against my own braces checker. And since there were more little function bodies below the two discussed, swapping the top two would have just grieved one of them, at least at link time. Also a {} screwup usually breaks the syntax analyzer into spewing gobs of error messages, which didn't happen here. So I still think I just overloaded a table or stack somewhere. BTW, I moved the functions into another file (after it worked). > We understand the confusion and frustration one suffers when confronted > with problems of this sort...apologies are gladly accepted :-) Well, your error messages are better than some big-time OS's compiler's I could name. Overall I think your C is fine. But we 6809ers really do have an ongoing problem in that the 6809 C compiler is not being maintained, all of Microware's energy is going into 68K stuff. I know we can't expect Amtrak and Conrail to restore steam locomotives, but some of us are working very hard to develop some damned good applications under OS9-Level 2. Since you have the only C game in our town, we have to gripe once in a while. -- Mike Knudsen Bell Labs(AT&T) att!ihlpl!knudsen "Lawyers are like handguns and nuclear bombs. Nobody likes them, but the other guy's got one, so I better get one too."