----Original Message----
>From: Ralf Corsepius
>Sent: 09 May 2005 09:27
> On Sun, 2005-05-08 at 22:54 -0700, Zack Weinberg wrote:
>> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>>
>>> On Sun, 2005-05-08 at 21:34 -0700, Zack Weinberg wrote:
>>>> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>>>>
>>>>> FWIW: IMO, NO_IMPLICIT_EXTERN_C actually is an OS/libc feature ("Your
>>>>> system headers are c++ aware"), therefore it is hardly possible or
>>>>> useful to ever use "#define NO_IMPLICIT_EXTERN_C" on "generic" targets
>>>>> (*-elf, *-coff etc.).
>>>>
>>>> I'm going to ask you to think again about that assessment, because
>>>> 'implicit extern C' mode is actually trouble if the headers *are* C++
>>>> aware
>>>
>>> The point is: You don't know, because you don't know which kind of
>>> headers/libc is using a user is going to build gcc against.
>>
>> This is true. The question in my mind is which failure mode is worse,
>> and honestly I don't know.
> Neither do I.
>
> My template answer to such kind of problems is
> * Try to detect it with autoconf magic (Probably difficult to implement
> for "multi-staged builds", may-be impossible for "one-tree builds")
> * In cases detection isn't possible, fall back to "reasonable
> defaults" (e.g. --with-newlib, *-rtems*, *-linux* could imply
> -DNO_IMPLICIT_EXTERN_C)
> * Additionally provide a configure option to enable users to override
> autoconf-provided results.
>
> Ralf
Perhaps we could try and detect #ifdef _cplusplus guards at compiletime,
the same way we currently detect multiple include guards? i.e. For any
system header file that would be affected by NO_IMPLICIT_EXTERN_C being
undefined, we detect a sequence of lines that is exactly (modulo stripping
comments/whitespace)
#ifdef _cplusplus
extern "C" {
#endif
and turn off the effects of (!NO_IMPLICIT_EXTERN_C) for that file?
cheers,
DaveK
--
Can't think of a witty .sigline today....
