By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,141 Members | 1,225 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,141 IT Pros & Developers. It's quick & easy.

Can __LINE__ be stringified?

P: n/a
I have a macro

#define DIE(msg) do { fprintf(stderr, "%s (l.%d)\n", msg, __LINE__);\
exit(1); }\
while (0)

and it works :). But later I thought, that if I use it like this:

s = malloc(2000); if (!s) DIE("malloc failed!");

it is possible that the fprintf will fail too, trying to allocate memory
to build the output string (or probably not, I don't know the internals;
and also, I think in Linux mallocs never fail, but anyway).

So I thought of using a "simpler" function to display the message,
something like

fputs(msg "\n", stderr)

But how can I add __LINE__?

fputs(msg #__LINE__ "\n", stderr)

doesn't work (the compiler says that "'#' is not followed by a macro
parameter").

Changing DIE do

#define DIE(msg, line) fputs(msg #lines, stderr)

and calling it this way: 'DIE("error", __LINE__);' results in
'fputs("error" "__LINE__", stderr)'.

I want of course 'fputs("error" "145", stderr)' or something like that.

Any ideas?
Nov 15 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Carlos wrote:
I have a macro [...]
Only a small correction, please answer to the parent taking this into
account:
Changing DIE do

#define DIE(msg, line) fputs(msg #lines, stderr)

#line

Thanks.
Nov 15 '05 #2

P: n/a
Carlos wrote:
[...]
fputs(msg #__LINE__ "\n", stderr)

doesn't work (the compiler says that "'#' is not followed by a macro
parameter").

Changing DIE do

#define DIE(msg, line) fputs(msg #lines, stderr)

and calling it this way: 'DIE("error", __LINE__);' results in
'fputs("error" "__LINE__", stderr)'.

I want of course 'fputs("error" "145", stderr)' or something like that.

Any ideas?


Sorry for wasting your time :). Immediatly after posting that I found
the solution:

$ cat pre.c
#define DIE3(msg, line) fputs(msg #line, stderr)
#define DIE2(msg, line) DIE3(msg, line)
#define DIE(msg) DIE2(msg, __LINE__)

DIE("error");
DIE("error");

$ gcc -E pre.c
# 1 "pre.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "pre.c"


fputs("error" "5", stderr);
fputs("error" "6", stderr);
$

:-)
Nov 15 '05 #3

P: n/a
On Sat, 30 Jul 2005 00:18:10 +0200, Carlos wrote:
Carlos wrote:
Immediatly after posting that I found the solution:

$ cat pre.c
#define DIE3(msg, line) fputs(msg #line, stderr)
#define DIE2(msg, line) DIE3(msg, line)
#define DIE(msg) DIE2(msg, __LINE__)


Or more generally:

#define STR0(s) #s
#define STR1(s) STR0(s)
#define LINE_STRING STR1(__LINE__)

#define DIE(msg) fputs(msg LINE_STRING, stderr)

Mike

Nov 15 '05 #4

P: n/a
In article <dc**********@domitilla.aioe.org>, Carlos wrote:
I have a macro

#define DIE(msg) do { fprintf(stderr, "%s (l.%d)\n", msg, __LINE__);\
exit(1); }\
while (0)

and it works :). But later I thought, that if I use it like this:

s = malloc(2000); if (!s) DIE("malloc failed!");

Look up the assert macro in assert.h
copy what it does.
Bye.
Jasen
Nov 15 '05 #5

P: n/a

In article <dc**********@domitilla.aioe.org>, Carlos <an***@quovadis.com.ar> writes:

it is possible that the fprintf will fail too, trying to allocate memory
to build the output string
Or for any other reason. The language doesn't guarantee that output
will succeed. It's possible that there are cases where fprintf would
fail but fputs would succeed; it's even possible, though I think it
unlikely, that your program would encounter one. Personally, I
wouldn't consider it high on my list of potential problems to
address.
and also, I think in Linux mallocs never fail, but anyway).


<OT>
About that you are wrong. man setrlimit.
</OT>

--
Michael Wojcik mi************@microfocus.com

The antics which have been drawn together in this book are huddled here
for mutual protection like sheep. If they had half a wit apiece each
would bound off in many directions, to unsimplify the target. -- Walt Kelly
Nov 15 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.