https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

--- Comment #29 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
While #line is indeed most commonly used by code generators, it can be used in
other contexts.  The most common other use is to remove sensitive and useless
file name components from the file specification.  Since there are bad actors
who might be able to abuse that sensitive information, that use is becoming
more critical.  While it is possible to hide that information without using
#line __LINE__, doing so introduces potential code maintenance issues. 

If you look at the old programming literature, you can find places where the
use of #line __LINE__ is assumed to not change subsequent line numbers.  I
think allowing #line __LINE__ to change subsequent line numbers makes this
construction unusable for normal purposes.  If #line __LINE__ preserves
subsequent line numbering, I find it is much easier to write safe portable
code.  If you look at the question from a portability point of view, the
natural choice is to have #line __LINE__ leave subsequent line numbers
unchanged.

When I said 'not robust' I meant that it was fairly easy to frustrate the check
as implemented.  This might be considered a good thing if you want the
alternate behavior; you can still get the alternate behavior by hiding the use
of __LINE__ behind another macro, but then you would be back in the unspecified
behavior realm.  While it is possible to change the implementation to detect
hidden __LINE__ references, I found that that requires adding a communication
path between the macro.c module and the directives.c module.  I played around
and found that to be unnecessarily complicated.  It is almost always better to
leave the coder a choice of behaviors, so being able to hide the use of
__LINE__ if the user wants to should be considered a 'good thing'.

Joseph: Do you know of any existing cases where this change would cause user's
problems?  The existing behavior has caused me enough trouble that I now use a
patched version of GCC in place of any of the usual binary distributions.

Reply via email to