From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28148 invoked by alias); 20 May 2012 15:43:10 -0000 Received: (qmail 28140 invoked by uid 22791); 20 May 2012 15:43:09 -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; Sun, 20 May 2012 15:42:56 +0000 Received: by vbbey12 with SMTP id ey12so4111446vbb.0 for ; Sun, 20 May 2012 08:42:56 -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=Kkw7lxqDIlu/MhJvAGdL50yYjjhIeBwoAfpm0byR63k=; b=BsbwxEohrHOaTth9peYkeumMthObJWcmfCk9AOQDe7P+q5H1w+uAkD7tb+8KX0GShh 9ob/O3Q8JnsRq6qkCrgNupB0+8NRZ9xm4MVphN1j/4w3Dz7xlN+4Tl8+SXC+l6XwPovt sqaCMh03SvrYNd8f378YRKn2fB5Ya+EWCucTTXXGXJe5ASenmpotpodr91VZjhLswL6q F7qZFhdyzAXeUxKTps2A0gDiXaXYLLQoFywKeyLaqoIJvzyir0qkAG6A666Jx7lfXN2V Ftzwl+Qthi44qtPRz5B7s4QRQDZxJu5Tyl4xJEmenr5HI0MxtMLdushvJ5QYSecqJ7Ov xXuw== Received: by 10.52.28.244 with SMTP id e20mr8413753vdh.14.1337528576186; Sun, 20 May 2012 08:42:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.28.244 with SMTP id e20mr8413745vdh.14.1337528576101; Sun, 20 May 2012 08:42:56 -0700 (PDT) Received: by 10.52.172.166 with HTTP; Sun, 20 May 2012 08:42:56 -0700 (PDT) In-Reply-To: <20120516131151.049251cc@spoyarek> References: <20120220132724.GB4753@spoyarek.pnq.redhat.com> <20120221210235.GA26897@host2.jankratochvil.net> <20120504183858.67d416b7@spoyarek> <20120515200454.GA11338@host2.jankratochvil.net> <20120516092012.4acba735@spoyarek> <20120516071911.GA31894@host2.jankratochvil.net> <20120516131151.049251cc@spoyarek> Date: Sun, 20 May 2012 15:43:00 -0000 Message-ID: Subject: Re: [PATCH v2] Expand bitpos and type.length to LONGEST and ULONGEST From: Doug Evans To: Siddhesh Poyarekar Cc: Jan Kratochvil , gdb-patches@sourceware.org, Tom Tromey Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQmJstqb+BjP9Ytfdx84ME4t54ogCFao1h613i8JT77P2bF+x6RjBf8+/Z5dd3dfMFPMkOk8Cb/CVzBtJsGegYYOPO9NU/wKjaKgGpMBruN3UCsgCaI/YNbQRDnNywVk3rQysRNvQERhuSjXySCDa6EtjiazZA== 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/msg00746.txt.bz2 On Wed, May 16, 2012 at 12:41 AM, Siddhesh Poyarekar wrote: > On Wed, 16 May 2012 09:19:11 +0200, Jan wrote: >> On Wed, 16 May 2012 05:50:12 +0200, Siddhesh Poyarekar wrote: >> > It would be safer in this case to keep length as LONGEST because >> > while I did try to check for all cases where ULONGEST may cause a >> > regression (like above), but I cannot say for sure that it's all >> > perfect. >> >> But type->length was already unsigned before. =A0I think it is fine to >> keep type->length ULONGEST, there should be no regression due to it. >> We agree that unsigned type (ULONGEST) is right for type->length. >> >> I meant more all the local variables turned signed->unsigned or >> unsigned->signed. > > Ah ok, I misread that. I'll watch out for that. > > Thanks, > Siddhesh Since it's now ok to use int64_t,uint64_t (right?) I wonder if we should move away from LONGEST,ULONGEST. [I remember a port Cygnus once did where long long was 128 bits. 1/2 :-)]