Short form of __FILE__

[Lukas Ruf]

Dear all,

for debugging purposes, I like the pre-compiler macros

__FILE__, __FUNCTION__, __LINE__

I have been wondering if there is a short form of __FILE__ that
provides only the filename without path.

I am using gcc as available in Debian unstable:

gcc (GCC) 4.0.3 20060128 (prerelease) (Debian 4.0.2-8)
Reading the info pages on gcc has not revealed what I am looking
for. Hence my question....

wbr,
Lukas
--
Lukas Ruf <http://www.lpr.ch> | Ad Personam
rbacs <http://wiki.lpr.ch> | Restaurants, Bars and Clubs
Raw IP <http://www.rawip.org> | Low Level Network Programming
Style <http://email.rawip.org> | How to write emails

[pemo]

"Lukas Ruf" <ru*@rawip.org> wrote in message
news:sl****************@pc-4082.ethz.ch...

Dear all,

for debugging purposes, I like the pre-compiler macros

__FILE__, __FUNCTION__, __LINE__

I have been wondering if there is a short form of __FILE__ that
provides only the filename without path.

I am using gcc as available in Debian unstable:

gcc (GCC) 4.0.3 20060128 (prerelease) (Debian 4.0.2-8)
Reading the info pages on gcc has not revealed what I am looking
for. Hence my question....

__FILE__ contains whatever path is given to the compiler.

consider a simple 'test.c' ...

#include <stdio.h>
int main(void){puts(__FILE__); return 0;}

If you compile test.c like this: gcc -E test.c

You will see __FILE__ is "test.c".

If you compile it like this gcc -E ./test.c

You will see __FILE__ is "./test.c".

--
==============
*Not a pedant*
==============

[Lukas Ruf]

> pemo [Mon, 6 Feb 2006 15:44:42 -0000]:

thanks for the info!

"Lukas Ruf" <ru*@rawip.org> wrote in message
news:sl****************@pc-4082.ethz.ch...

Dear all,

for debugging purposes, I like the pre-compiler macros

__FILE__, __FUNCTION__, __LINE__

I have been wondering if there is a short form of __FILE__ that
provides only the filename without path.

I am using gcc as available in Debian unstable:

gcc (GCC) 4.0.3 20060128 (prerelease) (Debian 4.0.2-8)
Reading the info pages on gcc has not revealed what I am looking
for. Hence my question....

__FILE__ contains whatever path is given to the compiler.

consider a simple 'test.c' ...

#include <stdio.h>
int main(void){puts(__FILE__); return 0;}

If you compile test.c like this: gcc -E test.c

You will see __FILE__ is "test.c".

If you compile it like this gcc -E ./test.c

You will see __FILE__ is "./test.c".

wbr,
Lukas
--
Lukas Ruf <http://www.lpr.ch> | Ad Personam
rbacs <http://wiki.lpr.ch> | Restaurants, Bars and Clubs
Raw IP <http://www.rawip.org> | Low Level Network Programming
Style <http://email.rawip.org> | How to write emails

[Clark S. Cox III]

On 2006-02-06 10:29:14 -0500, Lukas Ruf <ru*@rawip.org> said:

Dear all,

for debugging purposes, I like the pre-compiler macros

__FILE__, __FUNCTION__, __LINE__

I have been wondering if there is a short form of __FILE__ that
provides only the filename without path.
No. Whatever __FILE__ expands to is really up to your compiler. Some
compilers may provide options to change this, or may provide other
macros as an extension. Depending on your need for this information,
you could just parse the string given you by __FILE__ at runtime.


I am using gcc as available in Debian unstable:

gcc (GCC) 4.0.3 20060128 (prerelease) (Debian 4.0.2-8)

<OT>
With GCC, it expands to whatever was passed to the compiler on the
command line, so given the following file:
/* begin test.c */
#include <stdio.h>

int main()
{
printf("\"__FILE__\" expands to \"%s\"\n", __FILE__);
return 0;
}
/* end test.c */
On my machine:
[littleclark2:~] clarkcox% gcc test.c && ./a.out
"__FILE__" expands to "test.c"
[littleclark2:~] clarkcox% gcc ./test.c && ./a.out
"__FILE__" expands to "./test.c"
[littleclark2:~] clarkcox% gcc ~/test.c && ./a.out
"__FILE__" expands to "/Users/clarkcox/test.c"
[littleclark2:~] clarkcox% gcc ../clarkcox/test.c && ./a.out
"__FILE__" expands to "../clarkcox/test.c"
</OT>
--
Clark S. Cox, III
cl*******@gmail.com

[pemo]

"Clark S. Cox III" <cl*******@gmail.com> wrote in message
news:2006020611333516807-clarkcox3@gmailcom...

On 2006-02-06 10:29:14 -0500, Lukas Ruf <ru*@rawip.org> said:
<snip>
No. Whatever __FILE__ expands to is really up to your compiler. Some
compilers may provide options to change this, or may provide other macros
as an extension. Depending on your need for this information, you could
just parse the string given you by __FILE__ at runtime.

--
==============
*Not a pedant*
==============

[pemo]

"Lukas Ruf" <ru*@rawip.org> wrote in message
news:sl****************@pc-4082.ethz.ch...

pemo [Mon, 6 Feb 2006 15:44:42 -0000]:

>
> for debugging purposes, I like the pre-compiler macros
>
> __FILE__, __FUNCTION__, __LINE__
>
> I have been wondering if there is a short form of __FILE__ that
> provides only the filename without path.
>
> I am using gcc as available in Debian unstable:
>
> gcc (GCC) 4.0.3 20060128 (prerelease) (Debian 4.0.2-8)
>
>
> Reading the info pages on gcc has not revealed what I am looking
> for. Hence my question....

__FILE__ contains whatever path is given to the compiler.

consider a simple 'test.c' ...

#include <stdio.h>
int main(void){puts(__FILE__); return 0;}

If you compile test.c like this: gcc -E test.c

You will see __FILE__ is "test.c".

If you compile it like this gcc -E ./test.c

You will see __FILE__ is "./test.c".

You could also use something like this

#define FLE strrchr(__FILE__, '/') ? strrchr(__FILE__, '/') + 1 : __FILE__

[SM Ryan]

Lukas Ruf <ru*@rawip.org> wrote:
# Dear all,
#
# for debugging purposes, I like the pre-compiler macros
#
# __FILE__, __FUNCTION__, __LINE__
#
# I have been wondering if there is a short form of __FILE__ that
# provides only the filename without path.

#define __SHORT_FORM_OF_FILE__ \
(strrchr(__FILE__,'/') \
? strrchr(__FILE__,'/')+1 \
: __FILE__ \
)

int main(int N,char **P) {
printf("%s\n",__FILE__);
printf("%s\n",__SHORT_FORM_OF_FILE__);
return 0;
}

--
SM Ryan http://www.rawbw.com/~wyrmwif/
I have no idea what you just said.
I get that alot.

[Keith Thompson]

Lukas Ruf <ru*@rawip.org> writes:

for debugging purposes, I like the pre-compiler macros

__FILE__, __FUNCTION__, __LINE__

I have been wondering if there is a short form of __FILE__ that
provides only the filename without path.
As far as the C language is concerned, a file name is an uninterpreted
string. Since C has no concept of directories, there's no standard
way to extract a file name from a full pathname.
I am using gcc as available in Debian unstable:

gcc (GCC) 4.0.3 20060128 (prerelease) (Debian 4.0.2-8)

You can scan for the last '/' character, if any (be sure to allow for
the case where there are no '/' characters). This isn't strictly
portable, since not all systems use '/' as a directory delimiter, but
it's a good approach if you don't mind limiting yourself to Unix-like
systems.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Dag-Erling Smørgrav]

Lukas Ruf <ru*@rawip.org> writes:

for debugging purposes, I like the pre-compiler macros

__FILE__, __FUNCTION__, __LINE__

There is no __FUNCTION__ in C (though perhaps your compiler implements
it as an extension)

DES
--
Dag-Erling Smørgrav - de*@des.no

[John Devereux]

de*@des.no (Dag-Erling Smørgrav) writes:

Lukas Ruf <ru*@rawip.org> writes:

for debugging purposes, I like the pre-compiler macros

__FILE__, __FUNCTION__, __LINE__

There is no __FUNCTION__ in C (though perhaps your compiler implements
it as an extension)

I gather C99 has __func__, according to gcc:
GCC provides three magic variables which hold the name of the current
function, as a string. The first of these is __func__, which is part
of the C99 standard:

The identifier __func__ is implicitly declared by the translator
as if, immediately following the opening brace of each function
definition, the declaration
static const char __func__[] = "function-name";

appeared, where function-name is the name of the
lexically-enclosing function. This name is the unadorned name of
the function.
--

John Devereux

[Dag-Erling Smørgrav]

John Devereux <jd******@THISdevereux.me.uk> writes:

de*@des.no (Dag-Erling Smørgrav) writes:

Lukas Ruf <ru*@rawip.org> writes:

for debugging purposes, I like the pre-compiler macros
__FILE__, __FUNCTION__, __LINE__

There is no __FUNCTION__ in C (though perhaps your compiler implements
it as an extension)

I gather C99 has __func__, according to gcc:

yes, but it is not a "pre-compiler macro" (which I assume is intended
to mean "preprocessor macro").

DES
--
Dag-Erling Smørgrav - de*@des.no

[Jordan Abel]

On 2006-02-07, John Devereux <jd******@THISdevereux.me.uk> wrote:

de*@des.no (Dag-Erling Smørgrav) writes:

Lukas Ruf <ru*@rawip.org> writes:

for debugging purposes, I like the pre-compiler macros

__FILE__, __FUNCTION__, __LINE__

There is no __FUNCTION__ in C (though perhaps your compiler implements
it as an extension)

I gather C99 has __func__, according to gcc:
GCC provides three magic variables which hold the name of the current
function, as a string. The first of these is __func__, which is part
of the C99 standard:

The identifier __func__ is implicitly declared by the translator
as if, immediately following the opening brace of each function
definition, the declaration
static const char __func__[] = "function-name";

appeared, where function-name is the name of the
lexically-enclosing function. This name is the unadorned name of
the function.

Why didn't they make a macro instead of a "magic identifier"?

say, 'The macro __FUNC__ is implicitly defined by the translator as if,
immediately following the opening brace of each function definition, the
lines
#undef __FUNC__
#define __FUNC__ "function-name"
appeared, ...'

[John Devereux]

Jordan Abel <ra*******@gmail.com> writes:

On 2006-02-07, John Devereux <jd******@THISdevereux.me.uk> wrote:

GCC provides three magic variables which hold the name of the current
function, as a string. The first of these is __func__, which is part
of the C99 standard:

The identifier __func__ is implicitly declared by the translator
as if, immediately following the opening brace of each function
definition, the declaration
static const char __func__[] = "function-name";

appeared, where function-name is the name of the
lexically-enclosing function. This name is the unadorned name of
the function.

Why didn't they make a macro instead of a "magic identifier"?

say, 'The macro __FUNC__ is implicitly defined by the translator as if,
immediately following the opening brace of each function definition, the
lines
#undef __FUNC__
#define __FUNC__ "function-name"
appeared, ...'

It might be something to do with separating the functions of the
preprocessor and the compiler. The preprocessor part does not know
what functions are, so it cannot implement your suggestion. While the
compiler part *does* know what functions are, by the time it gets to
work it would be too late if the preprocessor relied on __FUNC__ being
defined as you suggest.

--

John Devereux

[Martin Ambuhl]

Dag-Erling Smørgrav wrote:

Lukas Ruf <ru*@rawip.org> writes:

for debugging purposes, I like the pre-compiler macros

__FILE__, __FUNCTION__, __LINE__

There is no __FUNCTION__ in C (though perhaps your compiler implements
it as an extension)

But, in the current standard, we have __func__, which should do as well.
The relevant part of the standard (6.4.2.2) include the following text:

The identifier __func__ shall be implicitly declared by the translator
as if, immediately following the opening brace of each function
definition, the declaration

static const char __func__[] = "function-name";

appeared, where function-name is the name of the lexically-enclosing
function.
[Footnote:Note that since the name __func__ is reserved for any use by
the implementation (7.1.3), if any other identifier is explicitly
declared using the name __func__, the behavior is undefined.]

This name is encoded as if the implicit declaration had been written in
the source character set and then translated into the execution
character set as indicated in translation phase 5.

EXAMPLE Consider the code fragment:
#include <stdio.h>
void myfunc(void)
{
printf("%s\n", __func__);
/* ... */
}

Each time the function is called, it will print to the standard output
stream:
myfunc

[Emmanuel Delahaye]

Lukas Ruf a écrit :

Dear all,

for debugging purposes, I like the pre-compiler macros

__FILE__, __FUNCTION__, __LINE__
[C99] ITYM __func__
I have been wondering if there is a short form of __FILE__ that
provides only the filename without path.

Nope, it's implementation dependent. There is nothing that prevents you
to use strrchr() to find the last '/' or '\\' in the __FILE__ string...

--
A+

Emmanuel Delahaye

[Eric Sosman]

Emmanuel Delahaye wrote On 02/07/06 13:47,:

Lukas Ruf a écrit :

Dear all,

for debugging purposes, I like the pre-compiler macros

__FILE__, __FUNCTION__, __LINE__

[C99] ITYM __func__

I have been wondering if there is a short form of __FILE__ that
provides only the filename without path.

Nope, it's implementation dependent. There is nothing that prevents you
to use strrchr() to find the last '/' or '\\' in the __FILE__ string...

... or ']' or '>' or '(' membername ')' or ...

--
Er*********@sun.com

[Rod Pemberton]

"Dag-Erling Smørgrav" <de*@des.no> wrote in message
news:86************@xps.des.no...

Lukas Ruf <ru*@rawip.org> writes:

for debugging purposes, I like the pre-compiler macros

__FILE__, __FUNCTION__, __LINE__

There is no __FUNCTION__ in C (though perhaps your compiler implements
it as an extension)

FYI,

__FUNCTION__ is an WATCOM/OpenWATCOM extension.

Rod Pemberton

[Keith Thompson]

"Rod Pemberton" <do*******@bitbucket.cmm> writes:

"Dag-Erling Smørgrav" <de*@des.no> wrote in message
news:86************@xps.des.no...

Lukas Ruf <ru*@rawip.org> writes:

> for debugging purposes, I like the pre-compiler macros
>
> __FILE__, __FUNCTION__, __LINE__

There is no __FUNCTION__ in C (though perhaps your compiler implements
it as an extension)

FYI,

__FUNCTION__ is an WATCOM/OpenWATCOM extension.

<OT>
It's also a gcc extension.
</OT>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Dag-Erling Smørgrav]

"Rod Pemberton" <do*******@bitbucket.cmm> writes:

"Dag-Erling Smørgrav" <de*@des.no> writes:

There is no __FUNCTION__ in C (though perhaps your compiler implements
it as an extension)

__FUNCTION__ is an WATCOM/OpenWATCOM extension.

While true, this is completely irrelevant.

DES
--
Dag-Erling Smørgrav - de*@des.no