473,231 Members | 1,618 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,231 software developers and data experts.

Definition of __FILE__, __LINE__

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.
Nov 13 '05 #1
9 25223

"qazmlp" <qa********@rediffmail.com> wrote in message
news:db**************************@posting.google.c 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.
Nov 13 '05 #2
On 9 Aug 2003 06:50:09 -0700, qa********@rediffmail.com (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
Nov 13 '05 #3
Jack Klein <ja*******@spamcop.net> writes:
On 9 Aug 2003 06:50:09 -0700, qa********@rediffmail.com (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 -
Nov 13 '05 #4
>> 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
Nov 13 '05 #5
On 9 Aug 2003 21:17:36 GMT, in comp.lang.c ,
go***********@sneaky.lerctr.org (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 =---
Nov 13 '05 #6
On 09 Aug 2003 20:37:13 +0200, Stefano Ghirlanda
<St***************@intercult.su.se> wrote in comp.lang.c:
Jack Klein <ja*******@spamcop.net> writes:
On 9 Aug 2003 06:50:09 -0700, qa********@rediffmail.com (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
Nov 13 '05 #7
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
Nov 13 '05 #8
On 11 Aug 2003 13:23:05 GMT, Da*****@cern.ch (Dan Pop) wrote:
In <ms********************************@4ax.com> Mark McIntyre <ma**********@spamcop.net> 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
Nov 13 '05 #9
On Mon, 18 Aug 2003 05:08:39 GMT, in comp.lang.c , Dave Thompson
<da*************@worldnet.att.net> wrote:
On 11 Aug 2003 13:23:05 GMT, Da*****@cern.ch (Dan Pop) wrote:
In <ms********************************@4ax.com> Mark McIntyre <ma**********@spamcop.net> 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 =---
Nov 13 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: Spry | last post by:
Hi, I wanted to write macros for finding the number of memory allocations and deallocations also wanted to find the locations. The code I have is a pretty big one. I have a wrapper on top of...
5
by: jake1138 | last post by:
I couldn't find an example of this anywhere so I post it in the hope that someone finds it useful. I believe this is compiler specific (I'm using gcc), as C99 defines __VA_ARGS__. Comments are...
5
by: baumann.Pan | last post by:
where are these macros defined? can I use it a release ver code?
7
by: Kenneth Brody | last post by:
Am I correct that using __FILE__ and __LINE__ within a macro will expand to the filename and line in which the macro is invoked, rather than where it is defined? For example, in a header file: ...
19
by: v4vijayakumar | last post by:
why the following statement dumps the core(Segmentation fault)? printf("%s\n", __FILE__);
4
by: Joakim Hove | last post by:
Hello, i have simple function like this: def log_msg(msg , file , line): print "%s:%s %s" % (file,line,msg) the file and line arguments should be the filename and linenumber of the...
5
by: Neo | last post by:
Hie, Can I put __FILE__ and __LINE__ macros inside the class function which may not be inline. And void function() { classobject::LogInfo(...); } Internally LogInfo should log file name...
9
by: Neo | last post by:
Hi Friends, I am planning to use "__FILE__,__LINE__,__FUNCTION__ " for a logging component in my class. In debug build I gets all information. I tried with release mode also and it works. But I...
4
by: allan.mcrae | last post by:
As part of a very simple memory leak detector, I am trying to store the value of __FILE__ in a char*. Since gcc4.2 I get the following warning... warning: deprecated conversion from string...
0
by: VivesProcSPL | last post by:
Obviously, one of the original purposes of SQL is to make data query processing easy. The language uses many English-like terms and syntax in an effort to make it easy to learn, particularly for...
0
by: abbasky | last post by:
### Vandf component communication method one: data sharing ​ Vandf components can achieve data exchange through data sharing, state sharing, events, and other methods. Vandf's data exchange method...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: stefan129 | last post by:
Hey forum members, I'm exploring options for SSL certificates for multiple domains. Has anyone had experience with multi-domain SSL certificates? Any recommendations on reliable providers or specific...
0
Git
by: egorbl4 | last post by:
Скачал я git, хотел начать настройку, а там вылезло вот это Что это? Что мне с этим делать? ...
1
by: davi5007 | last post by:
Hi, Basically, I am trying to automate a field named TraceabilityNo into a web page from an access form. I've got the serial held in the variable strSearchString. How can I get this into the...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: Aftab Ahmad | last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below. Dim IE As Object Set IE =...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.