Ada, treelang needs to be converted to --enable-mapped-location
Laurent GUERBY
laurent@guerby.net
Wed Oct 6 21:58:00 GMT 2004
On Wed, 2004-10-06 at 19:38, Zack Weinberg wrote:
> This is news to me; I had thought that hashtab.c was required. I'm
> sure I don't have to explain to you why duplicated code is bad; and I
> don't see why Ada's packaging requirements prevent you from picking up
> C modules which have, after all, been carefully coded to be
> independent of the rest of GCC. Such as hashtab.c and line-map.c.
A general point, C is an unsafe language (at least for most
implementations of C out there), carefully coded C
will have X % less buffer overflows or similar errors than "not
carefully coded" C but that still leaves some of them with all their
potential nastiness see the stream of security community news on the
topic, and unfortunately major, old, stable, ironed out C libraries are
not immune to this problem. Recoding in a safe language
C libraries is not without value in some contexts but of course
you can introduce new bugs as always :).
In the context of GNAT, most Ada checks are suppressed in the
default build configuration and we link with code using libiberty so
this does not directly applies, but since the Ada front-end has a
potential to be (re)used without GCC and in an environment where
libiberty won't be available like managed virtual machines
(there's some work to do).
More to the point, in a multi language environment you loose inlining
which can be big performance-wise for class of code. If the source is C
you probably have to recode anyway all the C access macros which are
available only for the C family of languages. And of course on the other
side you gain some flexibility to tailor the data structure to your
specific usage pattern.
All in all, I think the situation is not really unconditionnally black
and white.
Laurent
More information about the Gcc
mailing list