This is to propose an improvement to the #line directive of the C preprocessor, or to ask for a workaround.

Currently, it seems that the #line directive is "ignored" if it lies between a #if and a #endif directives !
I believe that in most practical cases, this behavior is undesired.

Example:

#if 0
.....
#line 10
.....
#endif

Hence, if a special purpose program adds a few lines to a C source file that happen to be enclosed by #if and #endif directives, the correction to the line numbering in the file will not take effect. Unless that special purpose program also detects the presence of the #if and #endif and adds additional #line directives. Which makes the job harder.

So the correction could like

#if 0
.....
#line 10
.....
#endif
#line 20

But things could be a lot easier if the #line directive were always processed independently of the presence or absence of #if, #ifdef, #elif, #else, and #endif directives. Indeed, why should line numbering in the file be a function of #if directives that handle compilation issues rather than file layout? Except perhaps in very unusual cases.

Does anyone know of a simple workaround?

I haven't actually used #line for debugging for ages.  I find that it hinders debugging.  If you don't use it at all then
will print the line number you're on and you just go to it.
If however, you have #line 617 then you'll have to know the nearest line number less than 617, say 500 and go 117 lines down from it.  If you don't have a #line then whether or not you have #ifs.

I only find it of use in code generators like lex/yacc or the very old C++ interpreter CFront where you can find the line in the original source.

Your example uses #if 0
That basically disables all the code in that #if block.
If you use #if 1 does the #line directive still not work right?

Replacing #if 0 with #if 1: of course then it works.
My point is that line numbering should be independent of other compiler directives. Line numbering should not change if I use #if 0 or #if 1. The line number in the file does not change!!!

We could distinguish between two things:

- Regular compiler directives (macros, conditional compilation, error reporting, etc).

- File handling and line numbering: in most cases, it has nothing to do with conditional compilations.

Hence, the second point should not be connected to the first point (unless perhaps in very rare cases).

> Hence, if a special purpose program adds a few lines to a C source
You mean like automated debug / test code which you use to gather some kind of statistical information about the running program?

#line is an internal solution to the problem which the pre-processor introduces, namely that the line numbering which the compiler sees has nothing to do with the source code line numbers after all the substitutions have been made.

#line is normally in the output of the pre-processor, not the input.

If you want to instrument your code and keep meaningful source code line numbers (from the programmers perspective), then you should run the pre-processor first (say gcc -E prog.c > prog.i), then pass it through your own program, then through the compiler proper.

--

If you feel like writing your own non-standard C compiler, be my guest.    But I don't think any existing C compilers are going to make the change you're suggesting since it would undoubtedly break a lot of existing programs that assume the current method of handling pre-processor directives...

Yes, one option is to process the file after the C preprocessor. But this option has its own issues.

For example, if I insert new lines in the file, how do I inform the compiler of the new line numbering? Is there a standard method or is it compiler dependent?

Couldn't you just do this:

That way, #line 10 is there whether you have #if 0 or #if 1.

Yes cpjust, this is the solution I gave. After every #else or #endif you recalculate the line number and issue a #line.

But that makes you program more complex. Which is unfortunate. The C standard should have specified that #line is not subject to #if conditions.

> if I insert new lines in the file, how do I inform the compiler of the new line numbering?
You keep a count, and observe current #line numbers, and output a #line after everything you insert.


And you want to change it to

--

Salem, this is the solution I currently use before the C preprocessor. It has the weakness that if there is a #if/#endif enclosing the lines you added, then the scheme fails.

If I were to work using your suggestion: after the C preprocessor, then the #line directive won't work I think. I looked at the output of gcc -E ... (as well as cc -E ...)

It uses things such as

# 10 "file.c" x y z

where 10 is the line number, and x y z are more information for the compiler, which I can't understand. I need to figure out these numbers in order to work after the C preprocessor.

Nevertheless, I prefer to solve the problem before the C preprocessor (even though harder) but for other reasons.