Re: [RFC/RFA] Cleaner handling of character entities ?

[Joel Brobecker <brobecker@adacore.com>]

> > 2006-05-05  Joel Brobecker  <brobecker@adacore.com>
> > 
> >         * dwarf2read.c (read_base_type): Set code to TYPE_CODE_CHAR
> >         for char and unsigned char types.
> >         * ada-lang.c (ada_is_character_type): Always return true if
> >         the type code is TYPE_CODE_CHAR.
> >         * c-valprint.c (c_val_print): Print arrays whose element type
> >         code is TYPE_CODE_CHAR as strings.
> > 
> > Tested on x86-linux, with GCC 3.4 (dwarf2, stabs+), GCC 4.1 (dwarf2).
> > No regression.
> > 
> > What do you guys think? Wouldn't that be a step forward?
> 
> I really suspect this impacts the existing producers in some way,
> though I don't know exactly how.  You should take a look at the most
> recent Modula-2 patch, and the discussion around the previous posting
> of it, which contained very similar changes (conditionalized for M2).

Thanks for the pointer. I think I found the actual discussion, which
started in Feb. Here is the message from Jim expressing these concerns.

        http://sources.redhat.com/ml/gdb-patches/2006-02/msg00396.html

He only says that a discussion about this lead you to stick with INT
as opposed to CHAR for C at least, and the resolution was to use CHAR
only for Modula 2. It would have been nice to have a pointer to the
actual discussion so we could remember the reasons for this, but it's
not important.

It looks like the Modula-2 patch has been approved, but not applied
yet. But I can make the same modification in dwarf2read.c regarding
the type code for character types, so that Ada follows Modula-2's
lead. Then the changes in c-valprint.c become obsolete, I believe.

We would be left with:

        * dwarf2read.c (read_base_type): Set code to TYPE_CODE_CHAR
        for char and unsigned char types of Ada compilation units.
        * ada-lang.c (ada_is_character_type): Always return true if
        the type code is TYPE_CODE_CHAR.

Would that be OK?

Thanks,
-- 
Joel

PS: Testing with -gstabs+ where we do end up with the char type being
    defined as an int did not reveal any regression with both the
    official testsuite and our internal testsuite. Being a curious
    little bugger, I can't help but wondering what the problems are.
    Darn curiosity!