[cfe-dev] C preprocessor and __LINE__

Richard Smith via cfe-dev cfe-dev at lists.llvm.org
Wed Sep 21 22:20:14 PDT 2016

On Wed, Sep 21, 2016 at 10:06 PM, Fred J. Tydeman via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> There are some problems with the C preprocessor definition in the C
> standard.
> Following is a proposal to fix one area of those problems.
> Does this seem like a good idea?   Any suggestions on this proposal?
> Any chance that clang would implement this before it becomes part of the C
> standard (so that the C committee has feedback on how good/bad this idea
> is)?

It's not obvious to me how this differs from our current behavior, other
than the new "#line __LINE__" syntax. Can you suggest cases that would
change behavior for us with this proposal?

> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
>   <meta name="generator" content=
>   "HTML Tidy for OS/2 (vers 1 September 2005), see www.w3.org">
>   <title>N21xx C2X Proposal: Preprocessor line numbers</title>
> </head>
> <body>
>   <p><br>
>   <!-- Who are the authors... -->
>    <b>Submitter:</b>Fred J. Tydeman<br>
>   <!-- What is the date of submission. yyyy-mm-dd -->
>    <b>Submission Date:</b>2016-09-??<br>
>   <b>Document:</b> WG14 N21xx<br></p>
>   <p>Problem being solved</p>
>   <p>With respect to preprocessor behaviour of line numbers and
>   __LINE__, there are differences between implementations, and
>   between releases of the same implementations.</p>
>   <p>For most implementations, it is not clear what conventions are
>   being used for line numbering, therefore, one cannot predict what
>   line number will be associated with a given preprocessor
>   token.</p>
>   <p>This makes if very difficult to write portable code that has
>   consistent behaviour.</p>
>   <p>This has shown up in (at least) DRs 173, 464, 483.</p>
>   <p>Solution</p>
>   <p>Add the following to 6.10.4 Line control:</p>
>   <blockquote>
>     <p>The presumed line number (footnote 1) associated with a
>     preprocessor token shall be the presumed line number of the
>     first character of the preprocessor token, except for the
>     preprocessor tokens in a macro replacement-list which get the
>     presumed line number of the macro invocation (footnote 2).</p>
>     <p>(footnote 1) The presumed line number is the same as the
>     physical line number unless changed by a #line directive.</p>
>     <p>(footnote 2) Required by the assert() macro.</p>
>     <p>The presumed line number associated with a macro invocation
>     shall be the presumed line number of the macro name of the
>     invocation.</p>
>     <p>The presumed line number of a preprocessing directive shall
>     be the presumed line number of the # preceding the directive
>     name.</p>

What does this affect?

>     <p>A preprocessing directive of the form<br>
>     <code>#line __LINE__ "filename"</code><br>
>     shall change the presumed file name without changing the
>     presumed line number.</p>

Why is this useful?

>   </blockquote>
>   <p>Existing practice</p>
>   <p>Based upon my testing, each of the above requirements has been
>   implemented by at least one implementation, however, it is not
>   clear if there are any implementations that do them all.</p>
> </body>
> </html>
> ---
> Fred J. Tydeman        Tydeman Consulting
> tydeman at tybor.com      Testing, numerics, programming
> +1 (775) 287-5904      Vice-chair of PL22.11 (ANSI "C")
> Sample C99+FPCE tests: http://www.tybor.com
> Savers sleep well, investors eat well, spenders work forever.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160921/951312b5/attachment.html>

More information about the cfe-dev mailing list