Re: Compiler Directive to List Defined Macros?

Re: Compiler Directive to List Defined Macros?

[Ross Combs]

I was going to ask a similar question today.  I tried the -E -dD options as
suggested and they do print out many of the predefined symbols.

A few things seem to be missing though.  It doesn't show __FILE__, __LINE__,
__func__, or __PRETTY_FUNCTION__.  I understand these are a little different
since they are "dynamic", but it would be helpful to know which ones are
avaliable.

The reason I wanted to know was that I had some code like this:
 #ifdef __func__
   /* code using __func__ */
 #else
 # ifdef __PRETTY_FUNCTION__
   /* code using __PRETTY_FUNCTION__ */
 # else
   /* code that doewsn't use function names */
 # endif
 #endif

It kept acting like neither one was avaliable.  So I tried forcing it to use
__func__, and I got compile errors.  I though that was strange, so I tried
forcing it to use __PRETTY_FUNCTION__ and finally it worked.

So I thought "maybe dynamic macros aren't detected by #ifdef".  I tried:
 #ifdef __LINE__
 # error __LINE__ is defined
 #endif

And it did indeed print the error message.

So a few things are going on:
 1) This version of gcc (egcs-2.91.66 from Red Hat 6.1) doesn't support
    __func__, but another version I used did.
 2) This version of gcc doesn't allow detection of __PRETTY_FUNCTION__ with
    #ifdef or #defined.

I know that #1 was "fixed" by version 2.95.1, because it works on another
machine using that version of gcc.

But is #2 "fixed" yet?  I tried it in version 2 with 2.95.1 and it still
didn't work.  The test for __LINE__ did work with 2.95.1 also.

I would suggest this should be made consistant.  It is nice to be able to
support these extensions when they are avaliable, and detection through
ifdef seems like the logical way to do so.

(Also, I never got a response to my last email to this list about detecting
multiple side effects and issuing a warning... does anyone care?  Is it such
a horrible idea?)

Thanks for your time,
-Ross

Re: Compiler Directive to List Defined Macros?

[Geoff Keating]

Ross Combs <rocombs@cs.nmsu.edu> writes:

> The reason I wanted to know was that I had some code like this:
>  #ifdef __func__
>    /* code using __func__ */
>  #else
>  # ifdef __PRETTY_FUNCTION__
>    /* code using __PRETTY_FUNCTION__ */
>  # else
>    /* code that doewsn't use function names */
>  # endif
>  #endif
> 
> It kept acting like neither one was avaliable.  So I tried forcing it to use
> __func__, and I got compile errors.  I though that was strange, so I tried
> forcing it to use __PRETTY_FUNCTION__ and finally it worked.
...

I don't think you can reliably use #ifdef on __func__ or
__PRETTY_FUNCTION__.  This is because they're not macros.  They're
predefined static variables in every function's scope.

> I would suggest this should be made consistant.  It is nice to be able to
> support these extensions when they are avaliable, and detection through
> ifdef seems like the logical way to do so.

I believe that the new C standard specifies a standard way to do this,
and that GCC now does it in the standard way.  I forget what the exact
name is, perhaps __function__.

> (Also, I never got a response to my last email to this list about detecting
> multiple side effects and issuing a warning... does anyone care?  Is it such
> a horrible idea?)

It's not a bad idea.  Perhaps you could submit a patch?

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: Compiler Directive to List Defined Macros?

[Martin v. Loewis]

> A few things seem to be missing though.  It doesn't show __FILE__, __LINE__,
> __func__, or __PRETTY_FUNCTION__.  I understand these are a little different
> since they are "dynamic", but it would be helpful to know which ones are
> avaliable.

The complete list can be found be combining those required by the
standard with those documented in the GCC documentation, in particular
in the section "Function Names".

> The reason I wanted to know was that I had some code like this:
>  #ifdef __func__
>    /* code using __func__ */
>  #else

As Geoff explains, __func__ is not a preprocessor macro. Instead, it
is an identifier. The proper way of testing for it is to write

#if __STDC_VERSION__+0 >= 199901L

since __func__ is defined by C99.

>  # ifdef __PRETTY_FUNCTION__
>    /* code using __PRETTY_FUNCTION__ */
>  # else
>    /* code that doewsn't use function names */
>  # endif
>  #endif

The proper way of testing for these is to write

#ifdef __GNUC__

in which case you can use either one.

>  1) This version of gcc (egcs-2.91.66 from Red Hat 6.1) doesn't support
>     __func__, but another version I used did.

Yes, I believe it was added in 2.95.

>  2) This version of gcc doesn't allow detection of __PRETTY_FUNCTION__ with
>     #ifdef or #defined.

No, that is not possible - the preprocessor has no way of knowing what
the current function is. That's why they are identifiers, or string
literals.

> But is #2 "fixed" yet?

It's not broken. It can't possibly work the way you expect it to
work. Instead, you must use other tests in portable code.

Regards,
Martin

Re: Compiler Directive to List Defined Macros?

[Ross Combs]

Yep. The double xstr() level is the trick I was missing.  It works
just fine.

Thanks!

-Ross

Re: Compiler Directive to List Defined Macros?

[Ross Combs]

> > So __PRETTY_FUNCTION__ has existed for a long time in gcc?  I can trust
> > that even old copies will support this?
>
> Yes. I could check when it was first introduced - but so could you.
> Then you could define a reliable test based on the values of __GNUC__
> and __GNUC_MINOR__

Look like 2.7 introduced this feature from looking at the release notes.
In 2.8 __FUNCTION__ and __PRETTY_FUNCTION__ became functions instead of
strings.  I'll add in the tst like this:

 #if defined(__GNUC__) && \
     (__GNUC__ == 2 && __GNUC_MINOR__ >= 7) || \
     __GNUC__ > 2)

> (*) It still is, and some people claim that __func__ should have been
> one of these, also, to allow concatenation as in
>
>   __FILE__ ":" __FUNCTION__

Hmm.  That is how I originally tried to use it.  It is also annoying that
I couldn't find a way to stringize __LINE__ and then concatenate it to
__FILE__.  But such things can be worked around.

-Ross

Re: Compiler Directive to List Defined Macros?

[Neil Booth]

Ross Combs wrote:-

> Hmm.  That is how I originally tried to use it.  It is also annoying that
> I couldn't find a way to stringize __LINE__ and then concatenate it to
> __FILE__.  But such things can be worked around.

You mean to get output like "\"myfile.c\": 200"?  If so, the following
should work:

#define str(x) #x
#define xstr(x) str(x)
xstr(__FILE__: __LINE__)

Or if you want "myfile.c: 200", i.e. without the inner quotes, try

__FILE__ ": " xstr(__LINE__)

If you don't understand why this works, info cpp should help.  If it
doesn't, please help us to improve the docs!

Neil.

Re: Compiler Directive to List Defined Macros?

[Ross Combs]

> > A few things seem to be missing though.  It doesn't show __FILE__, __LINE__,
> > __func__, or __PRETTY_FUNCTION__.  I understand these are a little different
> > since they are "dynamic", but it would be helpful to know which ones are
> > avaliable.
>
> The complete list can be found be combining those required by the
> standard with those documented in the GCC documentation, in particular
> in the section "Function Names".

Ok.  I admit to being guilty of not reading the info documents.  I really
prefer the man format, but I know it has limitations and is considered to
be historical baggage.  I'm still curious as to why they aren't listed.
(Except for __func__ and __PRETTY_FUNCTION__.)

> As Geoff explains, __func__ is not a preprocessor macro. Instead, it
> is an identifier. The proper way of testing for it is to write
>
> #if __STDC_VERSION__+0 >= 199901L
>
> since __func__ is defined by C99.

Ah.  But I'm getting version 199409 even though __func__ is defined...
Was there a C94 standard?  Was C9X released as a standard or is it still
in development?

> >  # ifdef __PRETTY_FUNCTION__
> >    /* code using __PRETTY_FUNCTION__ */
> > ...
>
> The proper way of testing for these is to write
>
> #ifdef __GNUC__
>
> in which case you can use either one.

So __PRETTY_FUNCTION__ has existed for a long time in gcc?  I can trust
that even old copies will support this?

> No, that is not possible - the preprocessor has no way of knowing what
> the current function is. That's why they are identifiers, or string
> literals.

I understand that now.  I'm sorry for not figuring that out before.  It
still seems like __PRETTY_FUNCTION__ looks like a macro to me.

> > But is #2 "fixed" yet?
>
> It's not broken. It can't possibly work the way you expect it to
> work. Instead, you must use other tests in portable code.

In my reply to Geoff I noted one way to make it work.  It isn't needed
as you point out there are other ways to detect these things.  Is it
standard to make function names all uppercase though?

Thanks for showing me how to fix this.

-Ross

Re: Compiler Directive to List Defined Macros?

[Martin v. Loewis]

> Ah.  But I'm getting version 199409 even though __func__ is defined...
> Was there a C94 standard?  Was C9X released as a standard or is it still
> in development?

No, there was an Amendment 1 to ISO 9899:1989, which was issued in
1994. That said implementations conforming to that ammendment should
define this value. Your implementation probably does not define the
1999 value, as it probably can't claim full conformance, yet. As a
result, you either need to specifically check for the version of the
compiler (as opposed to the version of the language), or just not use
__func__.

Please note that the implementation can rightfully define __func__ and
still claim conformance to C89+Amd1, as that name is in the
implementation-reserved namespace.

> > The proper way of testing for these is to write
> >
> > #ifdef __GNUC__
> >
> > in which case you can use either one.
> 
> So __PRETTY_FUNCTION__ has existed for a long time in gcc?  I can trust
> that even old copies will support this?

Yes. I could check when it was first introduced - but so could you.
Then you could define a reliable test based on the values of __GNUC__
and __GNUC_MINOR__

> In my reply to Geoff I noted one way to make it work.  It isn't needed
> as you point out there are other ways to detect these things.  Is it
> standard to make function names all uppercase though?

Well, these aren't function names, either. __func__ is a variable
name, so C99 followed the typical style for such names. When
__FUNCTION__ was first introduced, it was "magic" - a named string
literal (*). It was the only one of its kind, so it did not have to follow
any convention. Since it was anticipated that it is used together with
__FILE__ and __LINE__, it was given the same appearance.

Regards,
Martin

(*) It still is, and some people claim that __func__ should have been
one of these, also, to allow concatenation as in

  __FILE__ ":" __FUNCTION__

Re: Compiler Directive to List Defined Macros?

[Ross Combs]

First, thanks for taking the time to explain this.

> > It kept acting like neither one was avaliable.  So I tried forcing it to use
> > __func__, and I got compile errors.  I though that was strange, so I tried
> > forcing it to use __PRETTY_FUNCTION__ and finally it worked.
> ...
>
> I don't think you can reliably use #ifdef on __func__ or
> __PRETTY_FUNCTION__.  This is because they're not macros.  They're
> predefined static variables in every function's scope.

I see.  I guess the capitalization of __PRETTY_FUNCTION__ and the similarity
to __LINE__ threw me off.  Obviously the preprocessor doesn't know about
functions.  But why not make it something like an implicit:

 #define __PRETTY_FUNCTION__ __pretty_function__

and then I could test for it, but more importantly it would follow traditional
capitalization rules.

> I believe that the new C standard specifies a standard way to do this,
> and that GCC now does it in the standard way.  I forget what the exact
> name is, perhaps __function__.

Hmm... I thought it was __func__.  That is why I tried using it in preference
to __PRETTY_FUNCTION__.  Do you know how you are suppossed to test for it?

> > (Also, I never got a response to my last email to this list about detecting
> > multiple side effects and issuing a warning... does anyone care?  Is it such
> > a horrible idea?)
>
> It's not a bad idea.  Perhaps you could submit a patch?

I wouldn't mind working on one but there is no patch yet.  I haven't signed
a copyright release form and that might be a problem.  I also want to discuss
which cases should be warned about but that is a subject for another email...

-Ross

Re: Compiler Directive to List Defined Macros?

[Geoff Keating]

> Date: Thu, 29 Jun 2000 09:18:38 -0600
> From: Ross Combs <rocombs@cs.nmsu.edu>

> Hmm... I thought it was __func__.  That is why I tried using it in preference
> to __PRETTY_FUNCTION__.  Do you know how you are suppossed to test for it?

Yes, it's __func__.

You can test for the availability of C99 features by seeing if the
macro __STDC_VERSION__ is 199901L or greater.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Compiler Directive to List Defined Macros?

[Bolan Meek]

Greetings:  God bless you.

I've searched `info gcc` and the mailing list archives,
but have found nothing on this:

Is there any compiler directive that will cause a listing
of defined macros to be printed to stdout or stderr?
A #pragma something, perhaps?

Re: Compiler Directive to List Defined Macros?

[Franz Sirl]

At 15:42 28.06.00, Bolan Meek wrote:
>Greetings:  God bless you.
>
>I've searched `info gcc` and the mailing list archives,
>but have found nothing on this:
>
>Is there any compiler directive that will cause a listing
>of defined macros to be printed to stdout or stderr?
>A #pragma something, perhaps?

Try

gcc -E -ansi -dM - </dev/null

Franz.

Re: Compiler Directive to List Defined Macros?

[Bolan Meek]

Franz Sirl wrote:
> 
> At 15:42 28.06.00, Bolan Meek wrote:
> >Greetings:  God bless you.
> >
> >I've searched `info gcc` and the mailing list archives,
> >but have found nothing on this:
> >
> >Is there any compiler directive that will cause a listing
> >of defined macros to be printed to stdout or stderr?
> >A #pragma something, perhaps?
> 
> Try
> 
> gcc -E -ansi -dM - </dev/null
> 
> Franz.

Thanks;  I tried it.  It looks like it supplies pre-defined
macros;  I was hoping for a compiler directive that would
also spit out the macros that have been defined in the
source code, during compilation.

Maybe I should send this in as a 'wishlist' item.

Re: Compiler Directive to List Defined Macros?

[Alexandre Oliva]

On Jun 28, 2000, Bolan Meek <Bolan.Meek@wcom.com> wrote:

> Thanks;  I tried it.  It looks like it supplies pre-defined
> macros;  I was hoping for a compiler directive that would
> also spit out the macros that have been defined in the
> source code, during compilation.

Check the manual (info gcc).  Such an option exists.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Compiler Directive to List Defined Macros?

[Bolan Meek]

Alexandre Oliva wrote:
> 
> On Jun 28, 2000, Bolan Meek <Bolan.Meek@wcom.com> wrote:
> 
> > Thanks;  I tried it.  It looks like it supplies pre-defined
> > macros;  I was hoping for a compiler directive that would
> > also spit out the macros that have been defined in the
> > source code, during compilation.
> 
> Check the manual (info gcc).  Such an option exists.

OK!  Search number two coming up!

Re: Compiler Directive to List Defined Macros?

[Alexandre Oliva]

On Jun 28, 2000, Bolan Meek <Bolan.Meek@wcom.com> wrote:

> Alexandre Oliva wrote:
>> 
>> On Jun 28, 2000, Bolan Meek <Bolan.Meek@wcom.com> wrote:
>> 
>> > Thanks;  I tried it.  It looks like it supplies pre-defined
>> > macros;  I was hoping for a compiler directive that would
>> > also spit out the macros that have been defined in the
>> > source code, during compilation.
>> 
>> Check the manual (info gcc).  Such an option exists.

> OK!  Search number two coming up!

Actually, Franz had already given you the option name (-dM), but I had
failed to notice it.  He just didn't mention that you could feed gcc
-E your source file, instead of telling it to read from `- < /dev/null'.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me