From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6765 invoked by alias); 7 Feb 2012 21:27:15 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 30189 Received: (qmail 6363 invoked from network); 7 Feb 2012 21:27:13 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_LOW, T_DKIM_INVALID,T_TO_NO_BRKTS_FREEMAIL autolearn=no version=3.3.2 Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.google.com designates 74.125.82.43 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:to:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=QoRuJi0lRssSMoqaxxgWqzkwXYO7yllZiZIwNrDPIss=; b=ACmzgVQk10nHzJgcvs4GoJJunl9IsPBWRn3ijHKWtsc4tSXaMAsUDNLC0Rdibj4Ccg H6mN2e521hoqEQC8uROZZ3mwKXcI0hg2L4idFKlatnuLBWQlaKXVjMWrjAsrVwk2XoBe iojcHpx3Yxj4TLZc/dR8RrocqLlP177xgMqI8= Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: zsh-workers@zsh.org Subject: Re: [PATCH] GNU canonicalize_file_name can return a NULL pointer References: <87r4y6e759.fsf@ft.bewatermyfriend.org> Date: Tue, 07 Feb 2012 22:26:39 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Timothy Redaelli" Message-ID: In-Reply-To: <87r4y6e759.fsf@ft.bewatermyfriend.org> User-Agent: Opera Mail/11.61 (Linux) On Tue, 07 Feb 2012 21:10:58 +0100, Frank Terbeck wrote: > Timothy Redaelli wrote: >> In Src/hist.c on line 1668 there is a NULL pointer dereference because >> GNU canonicalize_file_name returns NULL on some errors. >> >> In attachment you will find a small patch that fixes that bug. > > Thanks! > > I've looked at the code and it bails out for a couple of errors in > `errno'. I've looked at how canonicalize_file_name() is implemented by > glibc, and it's just a short hand for "realpath(foo, NULL)". So at least > on GNU systems the errors from realpath(3) apply to > canonicalize_file_name(), too. Here's the current standard: > > > > I don't know if it's worth checking all those or just go with bailing > out if `real' is NULL. > > Both HAVE_REALPATH and HAVE_CANONICALIZE_FILE_NAME use a `real' pointer, > so I think the "if (!null)" test should be in there unconditionally, > without the `#ifdef'. > > Comments? Hi, in HAVE_REALPATH branch real it's not a point, but it's defined as real[PATH_MAX] so it cannot be NULL. We can make the if unconditionally, but it's quite useless (because it's always false in the HAVE_REALPATH branch).