From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18992 invoked by alias); 23 May 2012 15:01:53 -0000 Received: (qmail 18982 invoked by uid 22791); 23 May 2012 15:01:52 -0000 X-SWARE-Spam-Status: No, hits=-5.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-vb0-f41.google.com (HELO mail-vb0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 May 2012 15:01:23 +0000 Received: by vbbey12 with SMTP id ey12so6000816vbb.0 for ; Wed, 23 May 2012 08:01:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=wkHYe2hEksOUn/fzlb+aekCnw0ORkXzSujYhi5aGAXw=; b=KauwvzQME1TH273e29jCINMbpS/PbqSEP6EAA67VV/B9AaxVfLcKh4J/v6LFeoY4sK 2gITFWvrsemsd/xa9MxGi53creWllbXs4++3f1/xCEkE5ifJUWEpU8CDxJ8smvrtr0nQ QWOrR0AkmMuQUNaM6+0CT0bQ+EFpGdLJI9sRYR3qwBqDLBLTRCFOy9Ni3QBhL3b9DEDD X7UzBPuds+2QiommxOCYm4ux2+BD9omqVrx/ae6pAPEEdHcoDKT1bM4wUpBDe/KLBJqK uG3gd0FCg5GR9zz12hN+iAdBVUNyyakuusaBHgqhENjNCkhArBMp4teDZelOoauIzhLX 5onw== Received: by 10.52.73.132 with SMTP id l4mr12764940vdv.4.1337785283106; Wed, 23 May 2012 08:01:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.132 with SMTP id l4mr12764933vdv.4.1337785283009; Wed, 23 May 2012 08:01:23 -0700 (PDT) Received: by 10.52.172.166 with HTTP; Wed, 23 May 2012 08:01:22 -0700 (PDT) In-Reply-To: References: <20120523015503.GA25312@sourceware.org> <4fbc9d77.0853b40a.641e.ffff90dbSMTPIN_ADDED@mx.google.com> Date: Wed, 23 May 2012 15:01:00 -0000 Message-ID: Subject: Re: New ARI warning Wed May 23 01:55:03 UTC 2012 From: Doug Evans To: Pierre Muller Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlfcMoRw4Yws5Pd4o23Frz8P5F9yOZZX6H4DrtyySARQkKY9PShT7oxNBI8a9X6YReFF4H/57oePYk9P7fCBIMXW2VGxDNv8bxQCbgoXa7fLZeSySh8uInWOReFIg+nF97enGJqSHZeGHVM4Ro8UgFiNBGZZw== X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00895.txt.bz2 On Wed, May 23, 2012 at 7:46 AM, Doug Evans wrote: > On May 23, 2012 1:19 AM, "Pierre Muller" > wrote: >> >> =A0As a possible ARI maintainer I would like to clarify >> things here: >> =A0"long long" and "unsigned long long" >> are used in lots of native files, and they are >> OK in those context. >> >> =A0In fact, one of the improvements I have in mind is >> to restrain some ARI rules, like this one to >> GDB common files. >> =A0This 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. > >> >> =A0The 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. > >> =A0Another 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 ...).