From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5144 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: thoughts on reallocarray, explicit_bzero? Date: Tue, 20 May 2014 02:41:36 +0200 Message-ID: <20140520004135.GC12324@port70.net> References: <20140519153130.GA519@muslin> <20140519162556.GY12324@port70.net> <537A80CB.3040308@mit.edu> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1400572372 6765 80.91.229.3 (20 May 2014 07:52:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 May 2014 07:52:52 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5149-gllmg-musl=m.gmane.org@lists.openwall.com Tue May 20 09:52:46 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WmY7p-0001vO-NG for gllmg-musl@plane.gmane.org; Tue, 20 May 2014 02:41:49 +0200 Original-Received: (qmail 14063 invoked by uid 550); 20 May 2014 00:41:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 14055 invoked from network); 20 May 2014 00:41:48 -0000 Content-Disposition: inline In-Reply-To: <537A80CB.3040308@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:5144 Archived-At: * Andy Lutomirski [2014-05-19 15:08:11 -0700]: > On 05/19/2014 09:25 AM, Szabolcs Nagy wrote: > > i'd use a saturated multiplication, because malloc/realloc > > are not the only places where overflowing size calculations > > may cause problems and in such cases (size_t)-1 is just as > > good as a failure and it can be added to your code without > > portability issues > > > > static size_t sizemul(size_t a, size_t b) > > { > > return b>1 && a>1 && a>-1/b ? -1 : a*b; > > } > > Before going nuts trying to optimize this, it may pay to write some > good-enough helper and to use native compiler support for this, which is > already available in Clang [1] and should be coming reasonably soon in > gcc [2]. it's a shame that clang came up with this nonsese they managed to add 18 new compiler specific builtins, without actually addressing the practical issue: easy to use overflow check of size_t multiplication.. (or checking arithmetics of various other non-builtin types) (the several new multiprecision arithmetics builtins are bad too but less problematic in practice) they didn't make it easy to write backward compatible code either: historically ifdef hackery was used to "detect" builtins support using the __GNUC__ version macros, but clang has incompatible versioning and builtins now making the use of new builtins more painful (meanwhile a lot of code has idiomatic overflow checks in iso c which is not recognized by gcc or clang.. and many c parsing tools don't understand the fancy new builtins) > I suspect that, on all reasonably platforms, if doublesize_t is the > unsigned type that's twice as wide as size_t, then this isn't too bad > either: > > doublesize_t total = (doublesize_t)a * (doublesize_t)b; > if (total > SIZE_MAX) > fail; > > For quite a while, gcc has had a 128-bit integer type that works on > 64-bit platforms, and gcc should always support a 64-bit type on 32-bit > platforms. On systems with widening multiply (e.g. x86), even if the > optimizer doesn't detect the idiom, this is only a few cycles slower > than the optimal code. umm __int128 is only supported in gcc since 4.6 i think (and even after that there were some related brokenness in hacked toolchains so >=gcc-4.6 is not enough to check) otherwise yes with doublesize_t it is easy to do but the point was to do it in c for doublesize_t you would need configure time checks.. or nasty ifdef hackery.. and in the end you still need the fallback for implementations without such a type (the code i showed can be included in any source file where size_t is defined) > [1] > http://clang.llvm.org/docs/LanguageExtensions.html#checked-arithmetic-builtins > [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61129