Forward Referencing in C | Hacker News Reader

Forward Referencing in C

twitter.com

50 pointsazhenley34 comments

I wish folks would be wary of saying "such and such is legal in C _because an implementation accepts it_".

I'm well aware that the practice is for compilers to accept this; it was a standard "feature" of K&R C. However, per Wikipedia, this feature was removed in C99 <https://en.wikipedia.org/wiki/ANSI_C#C99> a fact that I verified by reading the forward to the C99 draft standard ISO/IEC 9899:TC3. So I'm a little surprised that the construct is only treated with a warning in `gcc -std=c99 -ansi -pedantic -Wall`.

There must be other context to the tweet because I’m sure that Walter Bright knows all of that..

To be fair, the linked Tweet does not claim it is legal behaviour. Just that it ought to be possible, in principle, in at least some situations.

Just declare fwd() with a prototype, and everything's good.

First they need to learn to distinguish what is ISO C and whateve their compiler accepts, the large majority doesn't.

Hence why so many just try to use GCC everywhere (nowadays clang as well).

> So I'm a little surprised that the construct is only treated with a warning

GCC does that for everything short of actual things it can't compile, you have to use -Werror[=…] to make it error out.

-ansi translates to -std=c90, so you're effectively cancelling the -std=c99.

Recently GCC moved to make this an hard error by default in >=C99 mode. There was huge push back form some very vocal members of the community against such exoteric, bleeding edge type system non-sense like function prototypes; according to them having to add -pedantic to the gcc command-line to build legacy code is an unreasonable breaking change. The burden should be on beginners to find the correct GCC arguments to enable all the "useless" warning.

Thankfully GCC is going ahead with the change anyway.

Yeah, perhaps even more when they wrote said implementation. :) Nothing against WalterBright, I just thought it was funny to use your own compiler as a referene like that.

I don't quite understand the point, is forward references to undeclared things something to strive after?

It prevents you from having to topologically sort your definitions, or otherwise declare everything at the top. Since idiomatic C uses header files, though, it doesn't matter too much. Main benefit is that non-public implementation details (e.g. static functions) needn't be declared at the top of the source file.

There’s no such language as C anyway, strictly speaking. There’s the C standard which defines a family of languages, then there’s the (C compiler version, OS, misc factors) tuples that define actual C-like languages.

What is ANSI C or C99 then?

According to the parent post, two families of languages. I disagree, though. Each standard _is_ a language. But which one does your compiler implement?

Exactly, it's "a language" but what you say will be interpreted differently depending on which specific version of which specific compiler you happen to be using today.

I not think you know who Walter Bright is :)

In my opinion he wrote wrote of the best c/c++ compilers for DOS. If he says something compiler (c) related, I usually pay attention.

Isn't it common knowledge that c89 has implicit function declarations?

Here the the relevant standard quote:

     If the expression that precedes the parenthesized argument list in a function call consists solely of an identifier, and if no declaration is visible for this identifier, the identifier is implicitly declared exactly as if, in the innermost block containing the function call, the declaration
    
             extern int  identifier();
    
    appeared

Right. And in the example, the function definition does not match the implicit definition, so it is undefined behaviour. (The calling conventions may differ.)

"Proof that C can do forward referencing", as long as you compile it with the D compiler. This is a trait of an implementation, not of the language itself.

I assume his point was that there's no technical reason for C to not support it.

"There is no point in not supporting it" is not "it is supported" though. The former is an opinion, the latter is simply false.

And the former is the meaning of TFA, the latter is a fictional alternative intention of TFA where it fails to meet the standards of truth.

The technical reason is that it makes the compiler a lot more complicated.

I've implemented this for calls in a single-pass compiler and it is really simple. You just treat the yet-undeclared call as if it was used correctly and add it to a list of calls to check later.

Compared to everything else a compiler needs to do this is trivial.

Doing it for types is harder though as far as single-pass compilers are concerned. Both are much easier if the compiler builds a syntax tree (or at least a list of all declarations even if the function bodies are handled at a later pass) ahead of time though.

It hinders single-pass in just the same fashion as types do. Consider:

    f() { g(1); }
    g(x) double x; { printf("%lf\n", x); }

You have to know the type of g's parameter before you can generate code for f.

(that function definition would be "void g(double x) { ... }" in non-obsolete C)

As another commenter pointed out, this is obsolete C, however: this is just not how modern compilers work. at all. Compilation is performed in phases, you have syntax analysis, semantic analysis, and then optimization and codegen. It’s trivial for a compiler to handle this code, heck C++ compilers (which your C compiler is under the hood) already do this for struct/classes (allowing member functions to be called before being declared). Pretty much every other language supports this too, but universally and not just in classes. We’ve come a long way since the 60’s.

> Compilation is performed in phases

In this context, it isn’t. The comment you replied to was a response to the statement:

> I've implemented this for calls in a single-pass compiler and it is really simple. You just treat the yet-undeclared call as if it was used correctly and add it to a list of calls to check later.

Looks like you missed the point.

The k&r-style function definitions apparently amused only me, but are beside the point regardless.

Single-pass compilation is very pertinent. One tenet of c's design is that it should be compilable in a single pass (which is why it is compilable in a single pass, unlike many other programming languages). This is relevant to us because it allows us to make predictions about the language; in particular, if the addition of some feature would cause c to not be compilable in a single pass, we can predict that the feature will not be added to the language. Notice that I have not made any value judgments. You may disagree about the importance of supporting single-pass compilers, but I am not the person you need to convince of that.

That doesn't work if definition is part of a different compilation unit. 99% of functions in C will be (libc, other system libraries you may be using, etc.).

It's the checking later bit that can cause issues.

You need to be able to (ideally) treat compilation as a dynamic schedule rather than a static list of passes.

D needs to do that because it's weird. I don't see why c would, in order to have forward references. It doesn't do inference or have any fancy compile time features.

I guess but allow me to nudge towards the more interesting problem rather than just writing 1 more ISO C compiler with a slight modification.

Complicated for the single-pass PDP-11 compiler.

Everything else that can fit AST in RAM can do it relatively easily. Modern C compilers have millions of lines and hundreds of person-years of work in them, so two passes and a lookup table is not a big deal.

It's just not done because the C standard doesn't say it should. Perhaps there is some preprocessor crime that this isn't compatible with, or they just don't want to break that PDP-11 compatibility.

Reply on news.ycombinator.com