Thread: This is the stupiest compiler error I've ever seen

Code:

list.c:35: error: void value not ignored as it ought to be

This is the code:

Code:

Table *create(void)
{
	return NULL;
}

void init(Table **table)
{
	clear(table)
	*table = create(); // line 35
}

As you can see I'm not passing anything into create(). Tried changing it to create(void)...no luck.

I tried googling it, but most of the results don't pertain to what I'm attempting to do.

I'm using gcc compiler (there is a bug report on it @ http://gcc.gnu.org/ml/gcc-bugs/2003-08/msg01200.html... but the workaround doesn't do any good).

Well what if you just change your function to:

Code:

Table* create()
{
    return NULL;
}

Yeah, blame the "stupid" compiler.

Code:

void init(Table **table)
{
	clear(table) <-- missing semicolon.
	*table = create(); // line 35
}

That parses as clear(table) * table = create(). clear() probably returns void. You can't multiply a void by a "table." The compiler spits this error.

Blaming the compiler just blinds you to reality...

Originally Posted by brewbuck

Yeah, blame the "stupid" compiler.

Code:

void init(Table **table)
{
	clear(table) <-- missing semicolon.
	*table = create(); // line 35
}

That parses as clear(table) * table = create(). clear() probably returns void. You can't multiply a void by a "table." The compiler spits this error.

Blaming the compiler just blinds you to reality...

LOL. I blame the compiler anyway for giving me the wrong error message

Originally Posted by TalonStriker

LOL. I blame the compiler anyway for giving me the wrong error message

It gave precisely the right error message. Your code was trying to multiply something by a void value. Just because you didn't THINK that was what your code was doing doesn't change that fact. The compiler is not going to start guessing, "Hey, maybe there should have been a semicolon here... or here... or maybe here?"

Sometimes a parse error is unambiguous and leads to a very clear error message. But in this case, it wasn't even a parse error, but a semantic error. How on earth would you expect the compiler to know that you "meant" to put a semicolon there?

Maybe the compiler could check to see if the line causing the error spans 2 or more lines and then dynamically add semicolons to the end of the lines to see if that fixes it. If it does, print an error telling the user to add semicolons, otherwise print the original error.

I would think that putting "lines 34--35" in the error message would be enough of a hint without the compiler having to try a bunch of things. I don't know of any compiler that does that, though (admittedly I don't have a very complete collection).

Originally Posted by tabstop

I would think that putting "lines 34--35" in the error message would be enough of a hint without the compiler having to try a bunch of things. I don't know of any compiler that does that, though (admittedly I don't have a very complete collection).

Or the programmer could just learn the basic rule that, if an error message doesn't make sense on the line it was reported on, look at previous lines until you find it.

Sometimes it isn't always easy to see why the compiler is complaining.
The more information the compiler can give, the better.

Originally Posted by tabstop

I would think that putting "lines 34--35" in the error message would be enough of a hint without the compiler having to try a bunch of things. I don't know of any compiler that does that, though (admittedly I don't have a very complete collection).

That's a good idea actually.