From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62134 invoked by alias); 14 May 2015 19:15:48 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 62121 invoked by uid 89); 14 May 2015 19:15:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qg0-f44.google.com Received: from mail-qg0-f44.google.com (HELO mail-qg0-f44.google.com) (209.85.192.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 14 May 2015 19:15:44 +0000 Received: by qgg76 with SMTP id 76so16386975qgg.3 for ; Thu, 14 May 2015 12:15:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.21.221 with SMTP id 90mr12279823qkv.44.1431630942750; Thu, 14 May 2015 12:15:42 -0700 (PDT) Received: by 10.229.215.4 with HTTP; Thu, 14 May 2015 12:15:42 -0700 (PDT) In-Reply-To: <5554B68A.1020900@redhat.com> References: <55549C0B.5010400@redhat.com> <5554B68A.1020900@redhat.com> Date: Thu, 14 May 2015 19:25:00 -0000 Message-ID: Subject: Re: [PATCH 2/7] [D] libiberty: Fail if reached end of symbol string From: Iain Buclaw To: Jeff Law Cc: gcc-patches , Ian Lance Taylor Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg01356.txt.bz2 On 14 May 2015 at 16:51, Jeff Law wrote: > On 05/14/2015 07:36 AM, Iain Buclaw wrote: >> >> On 14 May 2015 at 14:58, Jeff Law wrote: >>> >>> On 05/13/2015 02:51 AM, Iain Buclaw wrote: >>>> >>>> >>>> If a symbol that has so far been valid abruptly ends then we will want >>>> to fail the process rather than silently succeed. >>>> >>>> --- >>>> libiberty/ChangeLog >>>> >>>> 2015-05-13 Iain Buclaw >>>> >>>> * d-demangle.c (dlang_call_convention): Return NULL if have >>>> reached >>>> the >>>> end of the symbol, but expected more. >>>> (dlang_attributes): Likewise. >>>> (dlang_function_type): Likewise. >>>> (dlang_type): Likewise. >>>> (dlang_identifier): Likewise. >>>> (dlang_value): Likewise. >>> >>> >>> I spot checked various callers of these functions that not return NULL >>> and >>> they looked reasonable. Though I was a bit concerned about the callers of >>> dlang_type, dlang_value and dlang_identifier. >>> >>> In those cases we'll often still do the string_append, string_setlength >>> and >>> other calls in the caller of dlang_{value,type,identifier}. I'm assuming >>> that's safe (the error still appears to be bubbling up properly). >>> >> >> The string routines should be safe for that (appending a string with a >> zero length does nothing, for instance). >> >>> If you can confirm that we're OK in those cases, then this is OK for the >>> trunk. >>> >> >> I can start fuzzing mangle strings to test that failures actually fail >> gracefully. There's already a fuzzer that exists for C++, I think the >> only change that would be required for D is exchanging "_Z" for "_D" >> and calling cplus_demangle with DMGL_DLANG. > > Your call whether to fuzz before or after committing the changes. > > jeff Iant commited in the changes first time around. I don't have write after approval access in GCC just yet, probably should go about getting that sorted out if this is to become a regular thing. I dealt with copyright assignments back in September. Iain.