Definition of __FILE__, __LINE__

[qazmlp]

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.

 

[Serve La]

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.

 

[Stefano Ghirlanda]

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,

 

[Jack Klein]

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

 

[Gordon Burditt]

The macro __LINE__ always expands to an integer constant of the

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

 

[Mark McIntyre]

On 9 Aug 2003 21:17:36 GMT, in comp.lang.c ,

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....

 

[Jack Klein]

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

 

[Nils Petter Vaskinn]

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

 

[Dave Thompson]

In <[email protected]> Mark McIntyre <[email protected]> writes:

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

 

[Mark McIntyre]

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.