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

["Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>]

  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.

  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.

 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.

Pierre Muller


> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Doug Evans
> Envoyé : mercredi 23 mai 2012 09:28
> À : gdb-patches
> Cc : Sergio Durigan Junior
> Objet : Re: New ARI warning Wed May 23 01:55:03 UTC 2012
> 
> Hmmm, there's more than a few uses of long long in gdb (not all
> conditioned on CC_HAS_LONG_LONG, though most are in target files) and
> gdbserver (I was pretty sure I checked at the time).
> 
> So is this ARI check outdated?
> 
> I'm happy to change the code as necessary.
> If we can't use C++ can we at least use a modern C?  1/2 :-)
> 
> On Wed, May 23, 2012 at 12:10 AM, Doug Evans <dje@google.com> wrote:
> > Well, blech.
> > src/include/leb128.h uses long long per request, so that's what I used
> here.
> > src/include/anything obviously cannot use LONGEST/ULONGEST.
> >
> > Are long long's really verboten?
> >
> > I suppose I could create a gdb-leb128.h that used LONGEST/ULONGEST,
> > but blech.
> >
> >
> > On Tue, May 22, 2012 at 9:17 PM, Sergio Durigan Junior
> > <sergiodj@redhat.com> wrote:
> >> WDYT about the following patch?  I would like you to take a look at the
> >> gdb/dwarf2expr.h's castings that I had to make in order to get the
> >> compilation right.