From owner-svn-src-all@FreeBSD.ORG Mon May 5 22:00:27 2014 Return-Path: Delivered-To: svn-src-all@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 24F1B23D for ; Mon, 5 May 2014 22:00:27 +0000 (UTC) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (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 9DCCEAB4 for ; Mon, 5 May 2014 22:00:26 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id w7so1221224lbi.23 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=cRRRwmApIx7GWybAVB/V4998S28QGNdNJdRtKXyJ+sgV8o5ZTs9MTUZE5rajFfJOB/ ERk5ivEEYWzeR6SStOs8/jEphM/TqrQd55HTYLz02Vvti+Vtt+iRa2oEl9nChISYWIsd 7DTuwcDCB+pV1evUaKepk17UBH1N02lKtxSOhnxbiZL/qLD+G6GFngg4tdN4BzyeOJrr rOSmKhZXij8GDSaYM90Fne9Zb+Y8VgCPsCmBuN7eU44cGtBxPfjG5+6OtI4bF8Hq+97A kfvRJI/9qRCDJJZ+UlQ7PSMORSxJ4lfMJK7YqpIabIBYuqSVh1KIXUMj8obDbTWEIG78 1Gpg== X-Gm-Message-State: ALoCoQn6XPj6jcRrUKUvb0vKU0tjEKdxLIhaaquKmxr1GH1PZ5fTO9T46+xbJE9sxlQdDkpWtcHa 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-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 22:00:27 -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/