Libgcc symbols
Russ Allbery
rra@stanford.edu
Tue Apr 17 23:11:00 GMT 2001
Joe Buck <jbuck@racerx.synopsys.com> writes:
> __eprintf is an annoyance, frequently encountered (e.g. on Solaris) by
> people who mix C code generated by gcc and by some other C compiler and
> attempt to link it, thereby getting this one as an undefined symbol.
> It would be nice to make it go away somehow, e.g. by relying on the
> vendor's assert.h header.
A couple of us were discussing this elsewhere, including the fact that C99
requires that the function name also be added to the output from assert()
and most of the vendor assert.h headers probably don't do that, and I
started wondering why this was done as a libgcc library call instead of as
a statement expression. After all, we're guaranteed that gcc's private
assert.h is always compiled by gcc.
Why not define assert as:
#define assert(expr) \
((void) ((expr) ? 0 : __assert (#expr, __FILE__, __LINE__, __func__)))
#define __assert(expression, file, line, function) \
({ \
fprintf (stderr, "%s:%u: failed assertion `%s' in function %s\n", \
expression, file, line, function); \
abort (); \
})
? I assume that statement expressions are supposed to be allowable
anywhere that function calls are permitted.
Hurm. I guess one problem is that this requires that one expose fprintf
and stderr somehow, probably by including stdio.h, and that violates the
C99 limits on what namespace pollution is allowed by including
assert.h....
--
Russ Allbery (rra@stanford.edu) < http://www.eyrie.org/~eagle/ >
More information about the Gcc
mailing list