From owner-svn-src-head@FreeBSD.ORG Mon May 5 22:00:32 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56FCB368 for ; Mon, 5 May 2014 22:00:32 +0000 (UTC) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE405ABC for ; Mon, 5 May 2014 22:00:31 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id ec20so4574045lab.0 for ; Mon, 05 May 2014 15:00:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tj2L+0iQboEK7mq9JX53GZ6uxzvbP3ixXucCBHemmsw=; b=TPOYG7TOukqfoXU1ECJaa9O5nWHN6jMa78mQYtdHa3KBY60eVoEEBu2FVCsqk+lJob iZNVv7/ux63ydwMZ0N0Dlop6+hQQiDxwk9Wi6b6sNI7Jgf1yBFOpnV5YAuuKsvVJy3dB b8cfEcOQvRnSSjMX5V6Qik3GUpzFiuTSvSD6yvpbmDCBZpU0zvTti508GAbSbM3b6Bhu FDI7NPg3rVlF3nKbBe5Q7Nanu+w0YHzW8hj4+sH7UnMy30BmlLU2b6kPKjOuX0X1VnyH Hx9leyt0vFJqKCUdAFwGdJiMJ5FyjpcKxWg4dVdvKLNsM06KHtqowyvcMmM7fN66eTRk wg5g== X-Gm-Message-State: ALoCoQlr0nkrzZq5JxpNmhSEQprrvXeXGXuEtYIgHdNbfaQzHdtXvaOHTAynOv7OAKFR44qE/ugx X-Received: by 10.152.29.8 with SMTP id f8mr14116285lah.11.1399327224068; Mon, 05 May 2014 15:00:24 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id dl4sm10938218lbc.4.2014.05.05.15.00.23 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 May 2014 15:00:23 -0700 (PDT) Message-ID: <536809F6.8000302@freebsd.org> Date: Tue, 06 May 2014 02:00:22 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: David Chisnall Subject: Re: svn commit: r265367 - head/lib/libc/regex References: <201405051641.s45GfFje086423@svn.freebsd.org> <5367CD77.40909@freebsd.org> <53680532.7050605@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, "Pedro F. Giffuni" , src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 22:00:32 -0000 On 06.05.2014 1:52, David Chisnall wrote: > This is not relying on undocumented intrinsic knowledge, this is relying on the standard library doing what is required of it. There is a reason why secure coding standards have, for over a decade, said to prefer calloc() over malloc() unless profiling shows that calloc() is a bottleneck: it means that only one person needs to get the overflow checking right in one place, rather than everyone getting it right everywhere. It was unclear what type of ckecking you mean initially and confirm my statement that such code is hard to understand. Even if it is for arithmetic overflow, it is still semantically incorrect, see my other answer. Main purpose of calloc is to zero memory, not to check its argument, so its argument checking is side effect. It should be implemented by the caller (as I already answer) and not by the price of zeroing. -- http://ache.vniz.net/