public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ross Combs <rocombs@cs.nmsu.edu>
To: gcc@gcc.gnu.org
Subject: Re: Compiler Directive to List Defined Macros?
Date: Wed, 28 Jun 2000 17:19:00 -0000	[thread overview]
Message-ID: <200006290019.SAA23796@quito.cs.nmsu.edu> (raw)

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

             reply	other threads:[~2000-06-28 17:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-06-28 17:19 Ross Combs [this message]
2000-06-28 19:40 ` Geoff Keating
2000-06-29  0:39 ` Martin v. Loewis
  -- strict thread matches above, loose matches on Subject: below --
2000-06-30 14:34 Ross Combs
2000-06-29 15:49 Ross Combs
2000-06-30  1:36 ` Neil Booth
2000-06-29  8:28 Ross Combs
2000-06-29 13:44 ` Martin v. Loewis
2000-06-29  8:18 Ross Combs
2000-06-29 11:38 ` Geoff Keating
2000-06-28  6:44 Bolan Meek
2000-06-28  7:27 ` Franz Sirl
2000-06-28  7:35   ` Bolan Meek
2000-06-28  7:56     ` Alexandre Oliva
2000-06-28  8:06       ` Bolan Meek
2000-06-28  8:14         ` Alexandre Oliva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200006290019.SAA23796@quito.cs.nmsu.edu \
    --to=rocombs@cs.nmsu.edu \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).