Guess I grew up with old-school C. Looking at the question with example code made me think: "Am I missing something? Looks like pretty ordinary C to me. Why wouldn't it compile?"
https://en.wikipedia.org/wiki/C_%28programming_language%29#K...
But it's way easier to consult the lazyweb than to do your own research.
"C99 standard doc" let's you find http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf but searching for "function declaration" does not take you anywhere useful.
That's not to say reading the whole thing is a waste of time, just beyond the scope of most new programmers.
You may be able to solve the question by a simple search, but it still fits in on StackOverflow. The fact that it was upvoted a lot is irrelevant to me, it just means a few people bothered to press a button.
Perhaps for people who don't really know C, that's interesting information, but anyone who calls themselves a "C programmer" should not be surprised by that bit of code (well, you should be surprised if anyone still writes code like that, but not surprised that it's valid).
It's not even just an "exposed to legacy code" thing: C is a fairly simple language in both syntax and concepts (esp. when compared to most other languages people are using today), and I don't believe you can call yourself fluent in C without this kind of knowledge.
(I could also argue from the other angle: if you haven't been exposed to that sort of legacy C code, you probably haven't done it enough to call yourself fluent.)
I think it's an interesting question from the perspective of "what are some cool language gotchas that people not familiar with the language would find neat?"... or from the perspective of someone who is new to C, came across some code like that, and is trying to learn what's going on (and is apparently too lazy to google the C specification and spend 2 minutes reading it).
I think it's useful to know how C compilers, the C specification and C coding styles have evolved over the years. For one, it helps put some of the arguments for/against certain styles and syntax in perspective.
In short, make an effort to learn from history before you make the minimal effort required to learn from a contemporary forum like stackexchange.
Or, I guess, the people having problems learning to code are the people who happen to be on ancient compilers. Maybe it's not so surprising after all.
Many C programmers cannot make valid judgments as to the severity of a warning ('warning: bla bla may ...' => does it or doesn't it? I wouldn't know)
Also, those programmers typically would not know how to change their code to get rid of warnings. If they do, or if their compiler shoves a solution in their face (for example, a compiler might suggest to do "if((y=f(x)))") to get rid of an 'assignment inside if' warning), they do not see the advantage of the extra work.
The end result is code that produces hundreds of warnings. If a code change brings in a new one, people don't notice and/or don't care.
Some IDEs make things worse by allowing you to filter out warnings and messages from their output, so that you can focus on compiler errors. That is good for good programmers (they will fix errors, compile again, and then study every single warning), but bad for those who are happy to have code that compiles at all, as they will run into 'do not show me warnings' mode.
Really, if a programmer can't fix warnings (and that includes taking the time to learn why they are there), what are you paying them for? My policy on projects I work on is to enable all warnings, treat them as errors, then only disable warnings after trying to fix them, researching them, and finally discussing them, and usually then only on a case by case basis (only occasionally do I eschew certain warnings altogether (such as -Waggregate-return for g++), and I leave them commented out with the reason they are disbled).
(Edit: a quick tip for gcc, BTW: use -fdiagnostic-show-option for easier search of a warning, and the name of it in case you have to pragma it out).
If the default settings of gcc included throuwing out warnings for every time a function is declared without parameters and missing the void, lots of people would complain, and loud. It's a very common construct.
Interestingly, adding -std=c99 oddly removes the warning about the missing return statement in main().
I can't find a way to warn about the empty param list in the prototype, but it's possible that it's just not considered "bad enough style" to warrant one.
C++ is, of course, more strict. Try to compile that with g++, and you get several errors. The compiler needs to know how to mangle the symbol when it first encounters it, so you can't have "unspecified" parameter lists anywhere.
(And I'm not even that old! I've only been writing C for 12 years or so!)