From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16759 invoked by alias); 7 Mar 2011 00:51:41 -0000 Received: (qmail 16750 invoked by uid 22791); 7 Mar 2011 00:51:40 -0000 X-SWARE-Spam-Status: No, hits=-5.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,TW_XF,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Mar 2011 00:51:36 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 3658A1D004; Sun, 6 Mar 2011 16:51:35 -0800 (PST) Received: from msnyder-server.eng.vmware.com (promd-2s-dhcp138.eng.vmware.com [10.20.124.138]) by mailhost2.vmware.com (Postfix) with ESMTP id 2F4E88EE68; Sun, 6 Mar 2011 16:51:35 -0800 (PST) Message-ID: <4D742C16.3060100@vmware.com> Date: Mon, 07 Mar 2011 02:59:00 -0000 From: Michael Snyder User-Agent: Thunderbird 2.0.0.24 (X11/20101201) MIME-Version: 1.0 To: DJ Delorie CC: "gcc-patches@gcc.gnu.org" , "gdb-patches@sourceware.org" Subject: Re: [RFA] libiberty/hashtab.c, higher_prime_index: avoid array overrun References: <4D701056.1080208@vmware.com> <201103032211.p23MB9Ed003261@greed.delorie.com> <4D70158A.5080209@vmware.com> <201103032259.p23Mx6R0014467@greed.delorie.com> In-Reply-To: <201103032259.p23Mx6R0014467@greed.delorie.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-03/txt/msg00412.txt.bz2 DJ Delorie wrote: > Bizzare, the problem isn't the hash loop, it's the error handler at > the end! It never uses [30] for the main loop, only if you give it a > number between 0xfffffffb and 0xffffffff - and in the case where it > would use [30], it's supposed to abort anyway. > > I couldn't figure out why your patch worked until I realized that the > main loop still fails! It works because the error handler just > doesn't abort, returning the last array entry, which happens to be the > right one. > > I think a suitable comment explaining what's actually going on, and > why it still works, is warranted... but your patch is OK with me > otherwise :-) Please give me the comment, and I'll check it in.