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.
9  25262 
"qazmlp" <qa********@red iffmail.com> wrote in message
news:db******** *************** ***@posting.goo gle.com... 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.
On 9 Aug 2003 06:50:09 -0700, qa********@redi ffmail.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\\s ubdir\\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.l earn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
Jack Klein <ja*******@spam cop.net> writes: On 9 Aug 2003 06:50:09 -0700, qa********@redi ffmail.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 -
>> 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 , go***********@s neaky.lerctr.or g (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.c om/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
<St************ ***@intercult.s u.se> wrote in comp.lang.c: Jack Klein <ja*******@spam cop.net> writes:
On 9 Aug 2003 06:50:09 -0700, qa********@redi ffmail.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.l earn.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, Da*****@cern.ch (Dan Pop) wrote: In <ms************ *************** *****@4ax.com> Mark McIntyre <ma**********@s pamcop.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.ne t
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**********@s pamcop.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.c om/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 =--- This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
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 malloc(int
x) as Xmalloc(int x)
Now I want to write a macro for Xmalloc which can log the location of the
file and the line and the number of bytes allocated.
|
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 welcome.
This will print the file name and line number followed by a format
string and a variable number of arguments. The key here is that you
MUST have a space between __LINE__ and the last comma, otherwise
__LINE__ gets eaten by the ## if...
|
by: baumann.Pan |
last post by:
where are these macros defined? can I use it a release ver code?
|
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:
#ifdef DEBUG
#define LOGIT(note) DoLogging(__FILE__,__LINE__,note)
#else
#define LOGIT(note)
|
by: v4vijayakumar |
last post by:
why the following statement dumps the core(Segmentation fault)?
printf("%s\n", __FILE__);
| | |
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 source file where the function is called. If this were C I would
have used the __FILE__ and __LINE__ macros as:
|
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 and line number. Here I dont
|
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 want to verify that will I able to get this
information at any kind of build with all possible optimizations?
Regards
Vikram S
|
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 constant to 'char*'
object. The macro of delete assigns this to a global char* which is
used to track where deletions were made. Something like:
#define delete delete_FILE_ = __FILE__, \
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
| | |
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| | |
