From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111644 invoked by alias); 26 Sep 2017 10:30:42 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 110994 invoked by uid 89); 26 Sep 2017 10:30:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=H*r:gdb@gnu.org, concessions X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Sep 2017 10:30:41 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dwn8N-0000CT-P9 for gdb@sourceware.org; Tue, 26 Sep 2017 06:30:39 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56822) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dwn8N-0000CI-La for gdb@sourceware.org; Tue, 26 Sep 2017 06:30:35 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42731) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dwn8N-0001Kc-BY for gdb@gnu.org; Tue, 26 Sep 2017 06:30:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dwn8J-000076-9k for gdb@gnu.org; Tue, 26 Sep 2017 06:30:35 -0400 Received: from mail-wr0-f172.google.com ([209.85.128.172]:43422) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dwn8J-00006d-4A for gdb@gnu.org; Tue, 26 Sep 2017 06:30:31 -0400 Received: by mail-wr0-f172.google.com with SMTP id a43so12631149wrc.0 for ; Tue, 26 Sep 2017 03:30:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=qVye7eTYPGvG1emECr2Ywo9Zw5l2Q5VAPFM7+iEvTpc=; b=RKB0IB6896N9ZUk5eLmFoJav39O/uB+MMMM6xK2Hvv3yXr5AWn66B/7dwvOq7N3HVZ duR6fgmITUYIvXE0W28Qex3+i64sYiDyaUNDWA7Dinba0UvQ0U8UXlegK3jJ3ZD32cqP RqPZcFYrAG8+85aoJtRxpeqSaBMXaDA+JlZIXP/Hg+O7K/C9CEsL1fpy61haFJSWcdPW ogWgiHqp5BW/OSR3KLE/stHWGIYTUO1lKtv0pnJ4kw23vUErJDIuuwsq0UVRXiAhKwly 5OaL1Pd+Zoee7aVy+oXI/UpodNuHUZj+eVaYV2WgK5e35KZvxwIz9ij0xlCWnkz5O0Tx PBRg== X-Gm-Message-State: AHPjjUjaJHi4QCPkoFuJ2l+f3o3VHa6JGfh3ZnXF+UWCGjtUHsjDNieU LJacrZzxMAGVcoj4kM65KJRalg== X-Google-Smtp-Source: AOwi7QAcJuHEgpR2MrN5jHv1RVdJmQzsZ4VIu9OzxJ8K8zhj+zfatuLuPgyI5NBTfwgYXACyqx2F5A== X-Received: by 10.223.147.195 with SMTP id 61mr8572071wrp.119.1506421829135; Tue, 26 Sep 2017 03:30:29 -0700 (PDT) Received: from [192.168.0.123] (bl17-148-124.dsl.telepac.pt. [188.82.148.124]) by smtp.gmail.com with ESMTPSA id b89sm16615855wrd.42.2017.09.26.03.30.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Sep 2017 03:30:27 -0700 (PDT) Subject: Re: gdb 8.0 "lazy_string" exception "Length is larger than array size" To: Phil Muldoon , Michael Stahl , gdb@gnu.org, Doug Evans , Doug Evans References: From: Pedro Alves Message-ID: <28211a38-604b-a775-598b-677ddf46673a@redhat.com> Date: Tue, 26 Sep 2017 10:30:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-SW-Source: 2017-09/txt/msg00121.txt.bz2 On 09/26/2017 08:56 AM, Phil Muldoon wrote: > On 25/09/17 18:20, Michael Stahl wrote: > This code was added at 34b433203b5 by Doug Evans and > it was noted it was a bug. I've not sure, though, fixing this bug > may have had unintended consequences. I've CC'd Doug on the patch > and maybe he could comment further. We could perhaps decide to special case trailing arrays of lengths 0 and 1 (i.e., let the caller request more elements than declared), assuming they're being used as the trailing array idiom, similarly to how gcc also has special concessions for those. I don't know off hand whether its easy for the gdb code in question to tell whether the array is the last field of a struct, though I'd assume not. If you want to ignore the array's declared length, I think you can always decay 'buffer' to a pointer and work with that, and then GDB won't have a length to validate. Thanks, Pedro Alves