Re: New ARI warning Wed May 23 01:55:03 UTC 2012

[Doug Evans <dje@google.com>]

On Wed, May 23, 2012 at 7:46 AM, Doug Evans <dje@google.com> wrote:
> On May 23, 2012 1:19 AM, "Pierre Muller"
> <pierre.muller@ics-cnrs.unistra.fr> wrote:
>>
>>  As a possible ARI maintainer I would like to clarify
>> things here:
>>  "long long" and "unsigned long long"
>> are used in lots of native files, and they are
>> OK in those context.
>>
>>  In fact, one of the improvements I have in mind is
>> to restrain some ARI rules, like this one to
>> GDB common files.
>>  This would mean that files that are
>> only used for specific native targets would be allowed to use
>> "long long" without generating a warning.
>
> I'm not comfortable with such rules, fwiw.
> It's just more arcane baggage to have to remember and follow.
>
>>
>>  The use of "long long" and "unsigned long long"
>> is discouraged as it is not available in all C compilers
>> if I understood the definitions in defs.h around line 112.
>
> I wonder how old that is.
>
>>  Another possible use of LONGEST and ULONGEST
>> is also to be able to cope with 128-bit integers if these
>> are used in GDB later.
>
> Think bigger.
> LONGEST,ULONGEST are gdb-specific, and there is nothing in reading
> leb128 values that is gdb-specific.
>
> Plus a lot of code uses them with the assumption that they're 64 bits,
> having them be 128 bits is probably not workable.
>
> We've been debating whether to move to C++, and yet we can't even move
> to C99. :-(

For reference sake,
An alternative is to use {,u}int64_t, does ARI have any rule on them?
It's been in use in at least findcmd.c since gdb 7.0 [IIUC]
(perhaps errantly, but nevertheless ...).