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).

What is your function prototype for create()? Does it have void listed as the parameter?

Well what if you just change your function to:

Code:

---

Table* create()
{
    return NULL;
}

---

I would keep the void in there if you can because there is a different between the two in C. I can't remember the particular difference between C89 and C99, if there is one. I need to look that up, but I think C99 is a little more strict on void vs empty parameters.

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...

Bah, I can't believe I missed that. LOL. Nice spot, brewbuck.

Quote:

---

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 ;)

Quote:

---

Originally Posted by TalonStriker

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

---

If I make a compiler, I think I need to invent really interesting error and warnings messages. :D

Quote:

---

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.

Quote:

---

Originally Posted by cpjust

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.

---

How can the compiler know that the original error wasn't that clear() should have been defined to return something other than "void?"

As I said, the compiler interpreted this as a semantic error, not a syntactic one. How far must the compiler go? How many billion ways can the compiler inject small syntactic changes to correct a semantic error? This is not the compiler's job.

Also, adding a comma would work just as well as a semicolon. Again, how does the compiler know what you want?

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).

Quote:

---

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.

Quote:

---

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. :)

If you compile once and you do not get many errors and then suddenly you alter something and get tons....it's usually a semicolon, parentheses, bracket, brace, something spelled wrong, etc.

Also, if you use an auto-indenting editor, the line with a missing semicolon will be shown by the fact that the NEXT line is indented differently than you'd expect.

I'm with brewbuck on "how can the compiler know which variation of many different possible mistakes you made"? It can see that clear is of void type, so shouldn't be used as math. [And it may also realize that a pointer is not a good target for multiplication, but it may also take more effort to do that, and it will ONLY fix the particular case where semicolon is missing after a function followed by a dereference to a pointer - not one of the most common mistakes, I wouldn think].

--
Mats