On Tue, 26 Jun 2001 10:45:42 -0400, Bill Bumgarner <[EMAIL PROTECTED]>
wrote:
>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.
>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....
[snip]
Following the rules in the C standard(s), both versions of the
expression should stringify to valid string literals (after
preprocessing) as follows:
ch == '\'' || ch == '"' ==> "ch == '\\'' || ch == '\"'"
ch == '\'' || ch == '\"' ==> "ch == '\\'' || ch == '\\\"'"
Also, both versions of the character constant '"' and '\"' are valid,
so if the compiler barfs on any of the above it must be faulty. I
suggest a bug report to the maintainers of this compiler is in order.
