This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Converting to ISO C89
- From: <tm_gccmail at mail dot kloo dot net>
- To: Raja R Harinath <harinath at cs dot umn dot edu>
- Cc: Zack Weinberg <zack at codesourcery dot com>,"Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>, mark at codesourcery dot com,gcc at gcc dot gnu dot org, gdr at integrable-solutions dot net
- Date: Tue, 25 Mar 2003 15:03:39 -0800 (PST)
- Subject: Re: Converting to ISO C89
On Tue, 25 Mar 2003, Raja R Harinath wrote:
> Hi,
>
> Zack Weinberg <zack at codesourcery dot com> writes:
>
> > Raja R Harinath <harinath at cs dot umn dot edu> writes:
> >
> >> Hopefully the ISO C89 changes also make the source C++-safe.
> >
> > It will not. There is extensive use of identifiers which are C++
> > keywords, such as 'class' and 'delete'. I do not think your
> > suggestion is useful enough to warrant changing all of these
> > identifiers.
>
> Fair enough.
>
> > What might be useful is an optional mode for the C compiler in which
> > function names get mangled as they would be in C++. That would have
> > the effect of type-checking procedure calls across translation units
> > at link time. To avoid mangling calls into libc it would have to be
> > switchable within each translation unit -- one plausible approach is
> > to recognize extern "C" and extern "C++" in C, another is #pragma.
>
> I was thinking more about optimization: ensure that there's no
> abstraction penalty for using a C++ compiler on C code, and that both
> the C and C++ compilers exploit the same optimization opportunities.
>
> - Hari
IIRC, C code compiled as C++ needs to carry around stack unwinding
information whereas C code compiled as C does not.
Therefore, the abstraction penalty cannot be zero in terms of code size.
Toshi