https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #33 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> --- The way it is currently implemented by GCC makes #line __LINE__ a useless construct. The form where subsequent line numbers remain unchanged is very useful. From the literature, that was the way it was expected to work. In THAT sense it is more portable. I have had occasion to write C like pre-processors more than once. When coded to collect the entire directive and then dispatch on the directive keyword, the natural outcome for #line __LINE__ was to leave the subsequent line numbers unchanged. That falls out naturally if you code the specifiction for identifying directives following the standards as a separate step. It is only when you merge the directive collection, tokenization and interpretation steps that you get an interpretation of #line __LINE__ that changes subsequent line numbers. On 10/25/17, joseph at codesourcery dot com <gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687 > > --- Comment #32 from joseph at codesourcery dot com <joseph at codesourcery > dot com> --- > The evidence from the DR discussion is that it's the *less* portable > interpretation - that none of the implementations tested behaved as you > suggest. > > -- > You are receiving this mail because: > You reported the bug.
