«

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" <> wrote in message
news: om...
> 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.

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 -

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

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

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

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

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

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

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