Here is the assert.h from OSX-- I'm assuming this is the source of the
assert definition. And, of course, the stringification would cause the
problem....
/* Allow this file to be included multiple times
with different settings of NDEBUG. */
#undef assert
#undef __assert
#ifdef NDEBUG
#define assert(ignore) ((void) 0)
#else
#ifndef __GNUC__
#define assert(expression) \
((void) ((expression) ? 0 : __assert (expression, __FILE__, __LINE__)))
#define __assert(expression, file, lineno) \
(printf ("%s:%u: failed assertion\n", file, lineno), \
abort (), 0)
#else
#if defined(__STDC__) || defined (__cplusplus)
/* Defined in libgcc.a */
#ifdef __cplusplus
extern "C" {
extern void __eprintf (const char *, const char *, unsigned, const
char *)
__attribute__ ((noreturn));
}
#else
extern void __eprintf (const char *, const char *, unsigned, const
char *)
__attribute__ ((noreturn));
#endif
#define assert(expression) \
((void) ((expression) ? 0 : __assert (#expression, __FILE__,
__LINE__)))
#define __assert(expression, file, line) \
(__eprintf ("%s:%u: failed assertion `%s'\n", \
file, line, expression), 0)
#else /* no __STDC__ and not C++; i.e. -traditional. */
extern void __eprintf () __attribute__ ((noreturn)); /* Defined in
libgcc.a */
#define assert(expression) \
((void) ((expression) ? 0 : __assert (expression, __FILE__, __LINE__)))
#define __assert(expression, file, lineno) \
(__eprintf ("%s:%u: failed assertion `%s'\n", \
file, lineno, "expression"), 0)
#endif /* no __STDC__ and not C++; i.e. -traditional. */
#endif /* no __GNU__; i.e., /bin/cc. */
#endif
On Tuesday, June 26, 2001, at 04:27 AM, Hrvoje Niksic wrote:
> Bill Bumgarner <[EMAIL PROTECTED]> writes:
>
>> Certainly:
>>
>> [localhost:/tmp] bbum% cc -v
>> Reading specs from /usr/libexec/gcc/darwin/ppc/2.95.2/specs
>> Apple Computer, Inc. version gcc-926, based on gcc version 2.95.2
>> 19991024 (release)
>
> Interestingly, Gcc 2.95.2 works perfectly for me. It's probably the
> fault of a weirdly-defined `assert' macro.
>
> Even more proof that this is the way to go:
>
>>> I think I should simply use 0x22 instead of either.
