From patchwork Fri Jan 24 07:53:05 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dodji Seketeli X-Patchwork-Id: 313821 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id AE6402C00B5 for ; Fri, 24 Jan 2014 18:53:20 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type; q=dns; s=default; b=bKCtv7uXC4MIRL+i DizBWpt0yO/ystO8zqfXL7w8WUZgy/ilWKGvJZOXU6CH1am13pxtwcqrB1Hcq/Nt 3tDJjIFmAvKgjDSQxpx9JgWXquARb6WG3g1wBPlnTQMGOdkaAAieVawqj48hMwoR 0lYMFikzYmJcm7ER4JeYdp5NcPE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type; s=default; bh=+4e/cl39WdP8/pjSeyMef1 R1HtE=; b=C5j0KsOU7HLpEAEqS3VFHDTigyQJQBQtbjTHEdUugcsb9ZB39XkbUy K7bVSm0NpCjmsxKOeVh4EUkujSkLJxWkp0NxpvKhMBwBNCYrWozG+7HNuAQloZIr sOdKlUBsmahj3+a8eVWYE9SmqHc1R9fbVXi822Sky2g5+IbMH+ttk= Received: (qmail 30997 invoked by alias); 24 Jan 2014 07:53:12 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 30985 invoked by uid 89); 24 Jan 2014 07:53:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Jan 2014 07:53:09 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s0O7r7q5021799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Jan 2014 02:53:08 -0500 Received: from localhost (ovpn-116-92.ams2.redhat.com [10.36.116.92]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s0O7r6Qj013220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jan 2014 02:53:07 -0500 Received: by localhost (Postfix, from userid 1000) id 514EB1632F2; Fri, 24 Jan 2014 08:53:05 +0100 (CET) From: Dodji Seketeli To: Jakub Jelinek Cc: Bernd Edlinger , GCC Patches , Tom Tromey , Manuel =?utf-8?B?TMOzcGV6LUliw6HDsWV6?= Subject: Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals References: <87y559xz7y.fsf@redhat.com> <20131031173649.GW27813@tucnak.zalov.cz> <87zjpbb5qu.fsf@redhat.com> <20131111142159.GZ27813@tucnak.zalov.cz> <878uwuap4f.fsf@redhat.com> <878uwt63e2.fsf@redhat.com> <20131113081610.GH27813@tucnak.zalov.cz> <87zjp7t73c.fsf@redhat.com> <87vbxcig8t.fsf@redhat.com> <20140123171245.GK892@tucnak.redhat.com> X-URL: http://www.redhat.com Date: Fri, 24 Jan 2014 08:53:05 +0100 In-Reply-To: <20140123171245.GK892@tucnak.redhat.com> (Jakub Jelinek's message of "Thu, 23 Jan 2014 18:12:45 +0100") Message-ID: <87ha8t24v2.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Jakub Jelinek writes: > On Wed, Jan 22, 2014 at 09:16:02AM +0100, Dodji Seketeli wrote: >> +static fcache* >> +add_file_to_cache_tab (const char *file_path) >> +{ >> + >> + FILE *fp = fopen (file_path, "r"); >> + if (ferror (fp)) >> + { >> + fclose (fp); >> + return NULL; >> + } > > I've seen various segfaults here when playing with preprocessed sources > from PRs (obviously don't have the original source files). > When fopen fails, it just returns NULL, so I don't see why you just don't > do > if (fp == NULL) > return fp; Right, I am testing the patch below. * input.c (add_file_to_cache_tab): Handle the case where fopen returns NULL. diff --git a/gcc/input.c b/gcc/input.c index 290680c..547c177 100644 --- a/gcc/input.c +++ b/gcc/input.c @@ -293,11 +293,8 @@ add_file_to_cache_tab (const char *file_path) { FILE *fp = fopen (file_path, "r"); - if (ferror (fp)) - { - fclose (fp); - return NULL; - } + if (fp == NULL) + return NULL; unsigned highest_use_count = 0; fcache *r = evicted_cache_tab_entry (&highest_use_count);