This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ Darwin Port BUG in source code



On 2005-02-07, at 01:25, Dale Johannesen wrote:



On Feb 6, 2005, at 4:01 PM, Gabriel Dos Reis wrote:


Andrew Pinski <pinskia@physics.uc.edu> writes:

| Then we only change one thing and it is easier to make sure that we
| got this right
| and that the names stay constantly used.

and we get two functions supposed to have same or similar semantics
and wonder which to call ;-)

To prevent this sort of thing from happening again, I'd like to suggest an agreement
that functions in the language-specific areas of the code have language-specific
names. The ones specific to C++ should begin with cp_, for example. Sound OK?

Sure. The actual code already does c_ respective cp_ prefixing. The enum tree_class
id's do it too. (They actually do too much of it if you ask me...) However the
problem here at hand actually is that the function in question is NOT language specific.
It's just an id lookup - kind of class method overload alike.


If you want to prevent this kind of things to turn up again - do as I did to actually
discover the bug - make the whole thing compilable by C++ as the host compiler.
There really isn't that much preventing it: mostly use of "class" and "template" as object
names in C code. Rest is piece of cake. However I'm seriously considering to add C++ like
name mangling based on type signature to the C front end as an alternative option. This
would help to extend type safety from the compilation to the linkage stage in C code. Great
thing for preventing subtile bugs in big projects...


Anyway my patch is ready and I will send it to gcc-patches in one minute...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]