From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85812 invoked by alias); 14 May 2015 13:36:37 -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 85801 invoked by uid 89); 14 May 2015 13:36:36 -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-qk0-f169.google.com Received: from mail-qk0-f169.google.com (HELO mail-qk0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 14 May 2015 13:36:30 +0000 Received: by qkgw4 with SMTP id w4so8859376qkg.3 for ; Thu, 14 May 2015 06:36:28 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.25.42 with SMTP id k42mr8531815qkh.66.1431610588740; Thu, 14 May 2015 06:36:28 -0700 (PDT) Received: by 10.229.215.4 with HTTP; Thu, 14 May 2015 06:36:28 -0700 (PDT) In-Reply-To: <55549C0B.5010400@redhat.com> References: <55549C0B.5010400@redhat.com> Date: Thu, 14 May 2015 13:47: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/msg01323.txt.bz2 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. Regards Iain