From dev-return-24649-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Sun Jan 29 19:24:04 2012 Return-Path: X-Original-To: apmail-apr-dev-archive@www.apache.org Delivered-To: apmail-apr-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 078139CF7 for ; Sun, 29 Jan 2012 19:24:03 +0000 (UTC) Received: (qmail 31038 invoked by uid 500); 29 Jan 2012 19:24:03 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 30912 invoked by uid 500); 29 Jan 2012 19:24:02 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 30904 invoked by uid 99); 29 Jan 2012 19:24:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 29 Jan 2012 19:24:01 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [74.125.83.50] (HELO mail-ee0-f50.google.com) (74.125.83.50) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 29 Jan 2012 19:23:53 +0000 Received: by eekb57 with SMTP id b57so1216719eek.37 for ; Sun, 29 Jan 2012 11:23:31 -0800 (PST) Received: by 10.14.11.144 with SMTP id 16mr4553187eex.45.1327865011454; Sun, 29 Jan 2012 11:23:31 -0800 (PST) Received: from zulu.local (cpe-46-164-12-254.dynamic.amis.net. [46.164.12.254]) by mx.google.com with ESMTPS id t11sm35416338eea.10.2012.01.29.11.23.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Jan 2012 11:23:30 -0800 (PST) Message-ID: <4F259CB0.1000204@apache.org> Date: Sun, 29 Jan 2012 20:23:28 +0100 From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dev@apr.apache.org Subject: Re: svn commit: r1237078 - /apr/apr/trunk/tables/apr_hash.c References: <20120128155422.BCF80238890B@eris.apache.org> <4F253CEB.5020002@apache.org> <4F2545DC.80708@apache.org> <1157242535.1012357368@rexursive.com> <1327851294.16813.0.camel@shrek.rexursive.com> In-Reply-To: <1327851294.16813.0.camel@shrek.rexursive.com> X-Enigmail-Version: 1.3.4 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAADBQTFRF IhsbCy0qZjoVOVRoeFxSAIKBzXQiAKaibYiewnk7nn9z0qCTgL3i87Ep6Kx/+tHBsrE+zgAAAjZJ REFUOMvF0jFoE1EYB/CzjWlqIzaTjqVIBifRRWyG0t5iUqlLyFpCeXBgKg5yq6A4degUDJjoUDpc 1Qt4Ux94B11SOLB0KGS4discpbkORTCn9/m9d3fvLhXnvuHu3f+Xx/veyyfZfLSdZHzgicSfeyw4 JISwdz8FT6M8lM8Ceg385Dlhs+cC9sQCDn0B78QCogzwN+sxfHGOIXBbRGkNAM4cZymGtgNsDPgz cByxon3EEm1TLmvAlghoHOO3CZSa+IQ/vF6JV8tgKOMow78gRgL2/+EIvATOUtB3SSdMg4GXgrbn uk0uLiGdoCHKbX4E+t1FUTqn1AtIdPJebssDQ64YANSQyyaQNyUOFs0ijMsMFnOPTahPLXKYowtY 08MfCP7vR7hRnc5zmPK7CDYYbHcbC7tHuyFA94U/1LYZaJpu/sxACHMwvwZljTLY0TbNk4x+zuEt yC3MfCM6uSIvfwur0itFL4FA2Yal8BzLfnYV4EIGwEPAk7o5zIcnvzHMEjwJrrhAKK7on6IrsfRJ 7A53BhaK+CL7fj6+q/sPeOvcDTtoZTxpUYsFeIknrOXep3p3l7Ua+8sZ5FPQKyKwWi+DfROTU7ny C1/9UhpeY7K287WJCzbsNPQm2S6Yk4PSCNhWM2r3nD0K9liYb6yPgCRJhSzPrxUK0yUBVk1VX0lj s7MzGZyp0wImMK/e8rHbz2soL+O+2r1dxfGsAmBcx0lNjS/RUhlUC7gRn1wGMdQ7Vw1/AReW/RN3 xFWdAAAAAElFTkSuQmCC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On 29.01.2012 16:34, Bojan Smojver wrote: > On Mon, 2012-01-30 at 02:22 +1100, Bojan Smojver wrote: >> we could run the hash value produced by hashing the strings through >> the hash function twice This is overkill. If the current hash function isn't good enough, running stuff through it twice isn't going to help. I posit that the results are good enough now, since the default implementation isn't meant to be cryptographically secure, let alone unattackable. Spending more time grinding on the same set of bits isn't going to make a badly designed application any more robust. -- Brane