stringizing a hex value in the preprocessor

[Henry Townsend]

Consider the little program below. It simply attempts to determine what
version of what compiler it was built with via documented preprocessor
macros and print out the result. When the compiler is gcc it works fine,
because __VERSION__ is supplied as a string. But identifying the Sun
compiler is harder because it provides __SUNPRO_C as a numerical value
(equal in my case to 0x580). My attempt to stringify it produces an error:

% cc -g -o foo foo.c
"foo.c", line 13: invalid source character: '#'
"foo.c", line 13: syntax error before or at: 0x580
cc: acomp failed for foo.c

Is there a way to do this?

Thanks,
HT

--------------------------------------------------------------
#include <stdio.h>

#if defined(__GNUC_ _)
#define COMPILER_STRING "gcc " __VERSION__
#elif defined(__SUNPR O_C)
#define COMPILER_STRING "SunStudio " #__SUNPRO_C
#else
#define COMPILER_STRING "unknown compiler/version"
#endif

int main(void)
{
printf("Compile d with %s\n", COMPILER_STRING );
return 0;
}

[Jordan Abel]

On 2005-12-02, Suman <sk*****@gmail. com> wrote:

#ifdef __STDC__

#define str(x) #x
#define paste(x, y) x ## y #else
#define str(x) "x"
#define paste(x) x/**/y
#endif #define xstr(x) str(x)

--
hey, if you're going to hide them in their own macros, you might as well...

[pete]

pete wrote:

Hubble wrote:

Suman writes:

#define str(x) #x
#define xstr(x) str(x)
#define paste(x, y) x ## y

I would not use small letters for macros. Or did I miss
something? These macros is good but hard to read for me.

The first two of those macros are copied from the C standard.
That makes it easy to look them up in the standard
if you want to see what the standard has to say about them.
Otherwise, neither would I write them that way.

I suppose they wouldn't be that difficult to look up
if they were in caps and you knew they were in the standard.
There's a couple of things
that I copy from the C standard in my code.

For example

int main(int argc, char *argv[])

even though

int main(int argc, char **argv)

is really my prefered style.

--
pete

[Keith Thompson]

"Hubble" <re****@huober. de> writes:

Keith Thompson writes:

What solution

Please read <http://cfaj.freeshell. org/google/>.

Sorry for using google:

[snip]

No need to apologize; using google is perfectly acceptable as long as
you use it correctly. (Some people have killfiled everything posted
through groups.google.c om, but that's their decision.)

--
Keith Thompson (The_Other_Keit h) 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.

[Suman]

pete wrote:

Hubble wrote:

Suman writes:

#define str(x) #x
#define xstr(x) str(x)
#define paste(x, y) x ## y

I would not use small letters for macros. Or did I miss
something? These macros is good but hard to read for me.

The first two of those macros are copied from the C standard.
That makes it easy to look them up in the standard
if you want to see what the standard has to say about them.
Otherwise, neither would I write them that way.

Addendum:
The third, is a modified form of what you find in K&R 2:
#define paste(front, back) front ## back

[pete]

Suman wrote:

pete wrote:

Hubble wrote:

Suman writes:

>#define str(x) #x
>#define xstr(x) str(x)
>#define paste(x, y) x ## y

I would not use small letters for macros. Or did I miss
something? These macros is good but hard to read for me.

The first two of those macros are copied from the C standard.
That makes it easy to look them up in the standard
if you want to see what the standard has to say about them.
Otherwise, neither would I write them that way.

Addendum:
The third, is a modified form of what you find in K&R 2:
#define paste(front, back) front ## back

That's good enough for me.

It might be worth keeping in mind
that there's a few deviations here and there in standard C,
from what's generally considered good style.
FILE is a typedef, stdout is a macro.

--
pete