Definition of __FILE__, __LINE__

Discussion in 'C Programming' started by qazmlp, Aug 9, 2003.

  1. qazmlp

    qazmlp Guest

    How exactly __FILE__ and __LINE__ macros are defined? Or, Is the
    definition of these macros implementation dependent ?
    I am wondering how easily they can get the file name and line number
    respectively.
    qazmlp, Aug 9, 2003
    #1
    1. Advertising

  2. qazmlp

    Serve La Guest

    "qazmlp" <> wrote in message
    news:...
    > How exactly __FILE__ and __LINE__ macros are defined? Or, Is the
    > definition of these macros implementation dependent ?
    > I am wondering how easily they can get the file name and line number
    > respectively.


    The compiler recognizes __FILE__ and __LINE__. When it encounters them
    during compilation it uses its internal mechanism to insert the current line
    number or file into the code.
    Serve La, Aug 9, 2003
    #2
    1. Advertising

  3. Jack Klein <> writes:

    > On 9 Aug 2003 06:50:09 -0700, (qazmlp)
    > wrote in comp.lang.c:
    >
    > > How exactly __FILE__ and __LINE__ macros are defined? Or, Is the
    > > definition of these macros implementation dependent ? I am
    > > wondering how easily they can get the file name and line number
    > > respectively.

    >
    > Both macros are completely standard, although the results of
    > __FILE__ are largely implementation-defined.
    >
    > The macro __LINE__ always expands to an integer constant of the
    > number of the current line in the current translation unit's text
    > file.


    Given what you say about __FILE__, how does the standard guarantees
    that __LINE__ is portable across systems with different end-of-line
    conventions? Or does it?

    Thanks,

    --
    Stefano -
    Stefano Ghirlanda, Aug 9, 2003
    #3
  4. qazmlp

    Jack Klein Guest

    On 9 Aug 2003 06:50:09 -0700, (qazmlp) wrote
    in comp.lang.c:

    > How exactly __FILE__ and __LINE__ macros are defined? Or, Is the
    > definition of these macros implementation dependent ?
    > I am wondering how easily they can get the file name and line number
    > respectively.


    Both macros are completely standard, although the results of __FILE__
    are largely implementation-defined.

    The macro __LINE__ always expands to an integer constant of the number
    of the current line in the current translation unit's text file.

    The macro __FILE__ expands to a string literal containing the name of
    the translation unit's file, but since file names vary widely among
    different systems, the standard does not specify at all what the
    string looks like.

    For example, on some DOS/Windows implementations, __FILE__ expands to
    a complete path name (drive:\\dir\\subdir\\filename.ext), whereas on
    other compilers for those environments and most *nix implementations
    it produces the bare file name only.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c /faq
    Jack Klein, Aug 9, 2003
    #4
  5. >> The macro __LINE__ always expands to an integer constant of the
    >> number of the current line in the current translation unit's text
    >> file.

    >
    >Given what you say about __FILE__, how does the standard guarantees
    >that __LINE__ is portable across systems with different end-of-line
    >conventions? Or does it?


    The only guarantee you get with any text file is that it works on
    the system it was created for. If you want it to work on another
    system, you'll need to translate it. For example, ASCII mode of
    FTP will translate line ending conventions of the local system to
    a net standard for transport, then to the local line ending conventions
    of the remote system, so if line ending conventions are the only
    problem, it just works. Neither system has to know the conventions
    of the OTHER system. Just be sure to use ASCII mode vs. BINARY
    mode for the appropriate files. You also need to deal with character
    set translations (ASCII vs. EBCDIC, for example, and there are
    several dialects of EBCDIC to worry about).

    In the case of __LINE__, it works for the system you COMPILED it
    on (where the source code is), regardless of what system execution
    is targetted for. Text files need not be compatible between the
    compilation and execution systems if a cross-compiler is being used.
    Translation, or multiple translation, might change the line numbering
    of the source file. Offhand I can't think of a situation where it
    really does that, though.

    Gordon L. Burditt
    Gordon Burditt, Aug 9, 2003
    #5
  6. On 9 Aug 2003 21:17:36 GMT, in comp.lang.c ,
    (Gordon Burditt) wrote:

    >In the case of __LINE__, it works for the system you COMPILED it
    >on (where the source code is), regardless of what system execution
    >is targetted for. Text files need not be compatible between the
    >compilation and execution systems if a cross-compiler is being used.
    >Translation, or multiple translation, might change the line numbering
    >of the source file. Offhand I can't think of a situation where it
    >really does that, though.


    If you crosscompile on VMS and then execute on OpenVMS, the
    linenumbers become meaningless because the #included headers have
    different numbers of lines. This causes debugging woes in general,
    including breaking into the debugger, when it shows you line 2354 as
    reported to the runtime env as the breakpoint location, while the
    breakpoint is really at line 3456....

    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


    ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
    Mark McIntyre, Aug 10, 2003
    #6
  7. qazmlp

    Jack Klein Guest

    On 09 Aug 2003 20:37:13 +0200, Stefano Ghirlanda
    <> wrote in comp.lang.c:

    > Jack Klein <> writes:
    >
    > > On 9 Aug 2003 06:50:09 -0700, (qazmlp)
    > > wrote in comp.lang.c:
    > >
    > > > How exactly __FILE__ and __LINE__ macros are defined? Or, Is the
    > > > definition of these macros implementation dependent ? I am
    > > > wondering how easily they can get the file name and line number
    > > > respectively.

    > >
    > > Both macros are completely standard, although the results of
    > > __FILE__ are largely implementation-defined.
    > >
    > > The macro __LINE__ always expands to an integer constant of the
    > > number of the current line in the current translation unit's text
    > > file.

    >
    > Given what you say about __FILE__, how does the standard guarantees
    > that __LINE__ is portable across systems with different end-of-line
    > conventions? Or does it?
    >
    > Thanks,


    It gets even trickier with tricks like continuation lines in macros,
    and the standards committee has specifically decided to leave some of
    the more obscure uses unspecified.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c /faq
    Jack Klein, Aug 10, 2003
    #7
  8. On Sat, 09 Aug 2003 06:50:09 -0700, qazmlp wrote:

    > How exactly __FILE__ and __LINE__ macros are defined? Or, Is the
    > definition of these macros implementation dependent ? I am wondering how
    > easily they can get the file name and line number respectively.


    From K&R 2nd ed

    __LINE__ A decimal containing the current source line number.
    __FILE__ A string literal containing the name of the file beeing compiled.

    I don't know if they're really macros though, more like keywords for the
    preprosessor.

    How they get the filename and line is implementation dependant. I don't
    know how __FILE__ is specified, maybe one implementation can give you the
    full path while another gives you the basename? So I wouldn't depend on
    the format of __FILE__

    Perhaps reading the standard will clarify that but I don't have the time
    now.

    hth
    NPV
    Nils Petter Vaskinn, Aug 12, 2003
    #8
  9. On 11 Aug 2003 13:23:05 GMT, (Dan Pop) wrote:

    > In <> Mark McIntyre <> writes:

    <snip>
    > >If you crosscompile on VMS and then execute on OpenVMS, the
    > >linenumbers become meaningless because the #included headers have
    > >different numbers of lines. This causes debugging woes in general,
    > >including breaking into the debugger, when it shows you line 2354 as
    > >reported to the runtime env as the breakpoint location, while the
    > >breakpoint is really at line 3456....

    >
    > You're posting bullshit, as usual. __LINE__ gives you the line number
    > in the current source file, not in the current translation unit. When
    > including a header, both __FILE__ and __LINE__ indicate the header name
    > and the current line number inside the header, once you're coming back
    > to the original source file, the #include line is counted as one line.
    >

    I think you're overeager here, Dan. What you say is true, but not in
    conflict with what Mark said, nor AFAICT what the previous poster said
    although I had trouble understanding that.

    What Mark said is that if you compile on one system, with one set of
    headers, and then run and debug on a different system with a different
    set of (system) headers, when the debugger tries to chase back symbol
    information in the object file it finds mismatching source. This
    occurs precisely *because* the symbols track #include'd filename and
    linenumbers (for code) separate from the base source file, in the same
    fashion as for __FILE__ and __LINE__ -- and perhaps by the same
    mechanism, although of course the standard says nothing about
    mechanism. This problem is not limited to VMSen, and is annoying
    everywhere it occurs. Although of course generally speaking there
    shouldn't be much code generated by system headers and what there is
    should be correct already and not need debugging -- except to the
    extent bugs in user code manifest in called system code.

    - David.Thompson1 at worldnet.att.net
    Dave Thompson, Aug 18, 2003
    #9
  10. On Mon, 18 Aug 2003 05:08:39 GMT, in comp.lang.c , Dave Thompson
    <> wrote:

    >On 11 Aug 2003 13:23:05 GMT, (Dan Pop) wrote:
    >
    >> In <> Mark McIntyre <> writes:

    ><snip>
    >> >If you crosscompile on VMS and then execute on OpenVMS, the
    >> >linenumbers become meaningless because the #included headers have
    >> >different numbers of lines. This causes debugging woes in general,
    >> >including breaking into the debugger, when it shows you line 2354 as
    >> >reported to the runtime env as the breakpoint location, while the
    >> >breakpoint is really at line 3456....

    >>
    >> You're posting bullshit, as usual. __LINE__ gives you the line number
    >> in the current source file, not in the current translation unit. When
    >> including a header, both __FILE__ and __LINE__ indicate the header name
    >> and the current line number inside the header, once you're coming back
    >> to the original source file, the #include line is counted as one line.
    >>

    >I think you're overeager here, Dan.


    Nothing new here. Move along.

    >What you say is true, but not in conflict with what Mark said, nor AFAICT what the previous poster said
    >although I had trouble understanding that.


    Possibly I didn't make my self clear enough.

    >What Mark said is that if you compile on one system, with one set of
    >headers, and then run and debug on a different system with a different
    >set of (system) headers, when the debugger tries to chase back symbol
    >information in the object file it finds mismatching source.


    Exactly. Dan can deny this all he likes, but this is quite definitely
    true. Its possible he's never crosscompiled I suppose, tho I'd be
    surprised.


    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


    ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
    Mark McIntyre, Aug 19, 2003
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Spry
    Replies:
    1
    Views:
    925
    Richard Heathfield
    Jul 26, 2003
  2. Joakim Hove
    Replies:
    4
    Views:
    8,048
    Maric Michaud
    Aug 13, 2006
  3. jake1138
    Replies:
    5
    Views:
    1,031
    Dave Thompson
    Feb 14, 2005
  4. Replies:
    5
    Views:
    318
    Keith Thompson
    Mar 12, 2005
  5. Kenneth Brody

    __FILE__ and __LINE__ within macros

    Kenneth Brody, Apr 4, 2006, in forum: C Programming
    Replies:
    7
    Views:
    784
    Keith Thompson
    Apr 5, 2006
Loading...

Share This Page