[–] Morbo 0 points 3 points (+3|-0) ago 

As someone who had to work with Visual Basic 1.0 through 6.0 in the 90s, it's not a compiler error, except for all those times it was a compiler error. The VB (non .Net) compiler was notorious for fucking up shit inexplicably if you were pushing VB to its limits with Win32 API calls. Hell, on a good day you could compile your project and get an EXE file of a particular file size then compile it again and get an EXE with a different file size. No code changes in between yet the compiler somehow took a completely different route on optimization (I say that loosely as the VB compiler was not so good with optimization). So it's never the compiler, unless it's an old VB compiler.

[–] TheBuddha [S] 0 points 0 points (+0|-0) ago 

I remember the days of proprietary compilers, including VB!

I'm going to see if I can smoke those memories away.

[–] BlockMe 0 points 2 points (+2|-0) ago  (edited ago)

In thirty years I've found one compiler error. One. Something to do with the way the return value was handled in one register.

Something like this:

int f() { int result = a + b;

return; // instead of return result; }

It worked as the value was in the right reg anyway. Broke under recursion.

Can't remember the platform.

[–] rwbj 0 points 0 points (+0|-0) ago 

Not actually a compiler error! That's valid C code per the standard, including the weirdness. Functions with return types don't actually need to return anything. What is returned is undefined and would probably be different from platform to platform.

[–] BlockMe 0 points 0 points (+0|-0) ago 

Which standard?

I date back to the time when the production compiler was K&R 1st ed. and silly things like "void v(void) { void *vPtr;} had not been invented.

[–] AnmanIndustries 0 points 1 points (+1|-0) ago 

I have never heard anyone ever say the compiler was at fault. Or maybe because my programmers were professionals and when I program I can recognise mistakes.