From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20178 invoked by alias); 21 May 2012 17:36:29 -0000 Received: (qmail 20063 invoked by uid 22791); 21 May 2012 17:36:27 -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-vc0-f169.google.com (HELO mail-vc0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 May 2012 17:36:14 +0000 Received: by vcbfl10 with SMTP id fl10so547424vcb.0 for ; Mon, 21 May 2012 10:36:13 -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=9amGGKKMVrwsVK5gaDObEN+1nemnEUzP3g0rXhYuRqU=; b=f8We6jV7Ljzlw1JXQyQXtxEVKSg9brG1kZUSPaYk0ySf9Q0Y2DYdfTdIGKewUpspJa q5anxQezbI4D97IcqMu3LFHQeN5J5et5VMj68TUOOcnAJ070zTluX9JJkIs5qnlGbNdc sq5BMNvFWe+xIEzLaT0tK7OzzjfZMKrloaNa6KigyZTOlJgf8ldqnBZK0olYi+44+nDN 5e7Odb2Ynf+1gIzS1M7JewkmhBnGuufwkPAovQ6EtUnjoDePYn2F4UKvUvG5uF/njWJk jy6cSgbEnGG5o1iMXLJGc67Gqomv3biPuooMWyiQIsfHYCYFZ2EhZyVRAHDGZUgNXxoy c2Dw== Received: by 10.52.67.106 with SMTP id m10mr9994963vdt.6.1337621773284; Mon, 21 May 2012 10:36:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.67.106 with SMTP id m10mr9994952vdt.6.1337621773153; Mon, 21 May 2012 10:36:13 -0700 (PDT) Received: by 10.52.172.166 with HTTP; Mon, 21 May 2012 10:36:13 -0700 (PDT) In-Reply-To: References: <20120517182920.64FAE2461B2@ruffy.mtv.corp.google.com> Date: Mon, 21 May 2012 17:36:00 -0000 Message-ID: Subject: Re: [RFA] leb128.h: New file. From: Doug Evans To: Ian Lance Taylor Cc: gcc-patches@gcc.gnu.org, binutils@sourceware.org, gdb-patches@sourceware.org, Jan Kratochvil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlgyEvoh6/4+ONTYxUa4yGAlHFY1m+7EF1yjWqjOu/+5CqbjwpZwVoknvmbADk3K99FcNISV3VjSaOe9EkZQtvPb5iaBNgQHTdPRgFfMAl+zmspVvH5TNbcCJFtcyUVkxWnOoKVTvpvcRlyopic0Gr58PZfFg== 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/msg00778.txt.bz2 On Mon, May 21, 2012 at 10:08 AM, Ian Lance Taylor wrote: > dje@google.com (Doug Evans) writes: > >> 2012-05-17 =A0Doug Evans =A0 >> >> =A0 =A0 =A0 * leb128.h: New file. > > I'm not entirely sure about the use of int64_t to hold the result. =A0Do > we want to let this interface support larger types some day? =A0E.g., > should the result be long long? > > I'll approve this patch, but think about it. > > The patch is not as portable as possible, but it will probably be OK in > practice. =A0You should deal with any issues that arise. I'll change the result to size_t per Jan's request. I'm kinda worried about putting people to extra effort when they compile with -Wconversion which is why I went with int (thinking people would rather just use an int). But ok. long long (+ unsigned long long) is ok by me. I could also rename the functions to read_uleb128_to_ull (unsigned long long) to allow for a day if/when someone wants read_uleb128_to_uint64. Ok?