From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6932 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Daniel_Cegie=C5=82ka?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: thoughts on reallocarray, explicit_bzero? Date: Thu, 29 Jan 2015 11:54:48 +0100 Message-ID: References: <20140519153130.GA519@muslin> <20140519161654.GO507@brightrain.aerifal.cx> <20150129021919.GM4574@brightrain.aerifal.cx> <20150129041509.GN4574@brightrain.aerifal.cx> <20150129100431.GJ32318@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1422528924 5301 80.91.229.3 (29 Jan 2015 10:55:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Jan 2015 10:55:24 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6945-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 29 11:55:23 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YGmks-00086T-Ks for gllmg-musl@m.gmane.org; Thu, 29 Jan 2015 11:55:22 +0100 Original-Received: (qmail 5518 invoked by uid 550); 29 Jan 2015 10:55:21 -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 5510 invoked from network); 29 Jan 2015 10:55:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=5UyYfOwRLuEQ64ozNlwizXuVFxtiu+rHDM/1e95RNsA=; b=0WQjmSRBHgriLGTc6lWfJTB4r5qSN8LlXUoOswSfk/2WrUtOObGIeCgKrcLzceqGht mTnAfHn1zlFyvXaRLMyr+7nPV2GHzxFa3zEtBVVrRzcEeYClFKR4lS1cUNfkjBCXbnie Ay/L27ZtFdWQD62faG3eHqjdEHTg6Bd0Ca0LyODTfvZI4FNE66J/EHT8v/oLV2pPXZBi qf6T1Z2bkxJLnjZryO107M+TvdL0TplRmyi0B23nkLON/TgI+A2G8INmbyU7UDk9NYrS 6nf5NI+2w2LnsY5ClvR8SXDFZ9BafuWp6JM0vE/R2FgbEwa1fgchQSMSHnnukRTzJ8M5 914A== X-Received: by 10.182.71.73 with SMTP id s9mr5259444obu.15.1422528909098; Thu, 29 Jan 2015 02:55:09 -0800 (PST) In-Reply-To: <20150129100431.GJ32318@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:6932 Archived-At: 2015-01-29 11:04 GMT+01:00 Szabolcs Nagy : > * Daniel Cegie??ka [2015-01-29 10:30:40 +0100]: >> yet another secure_memzero(). A better solution would be to promote a >> single standard (eg. memset_s()) and the expectation that the compiler >> will respect it. >> > > i think you don't know the semantics of memset_s > (it uses nonsense types, has superflous arguments, handles > constraint violations through global state etc) btw. memset_s() is an attempt to solve the same problem. However, this version will not work with LTO: ftp://ftp.netbsd.org/pub/NetBSD/misc/apb/memset_s.20120224.diff #include __RCSID("$NetBSD$"); #define __STDC_WANT_LIB_EXT1__ 1 #include #include #include /* * __memset_vp is a volatile pointer to a function. * It is initialised to point to memset, and should never be changed. */ static void * (* const volatile __memset_vp)(void *, int, size_t) = (memset); #undef memset_s /* in case it was defined as a macro */ errno_t memset_s(void *s, rsize_t smax, int c, rsize_t n) { errno_t err = 0; if (s == NULL) { err = EINVAL; goto out; } if (smax > RSIZE_MAX) { err = E2BIG; goto out; } if (n > RSIZE_MAX) { err = E2BIG; n = smax; } if (n > smax) { err = EOVERFLOW; n = smax; } /* Calling through a volatile pointer should never be optimised away. */ (*__memset_vp)(s, c, n); out: if (err == 0) return 0; else { errno = err; /* XXX call runtime-constraint handler */ return err; } }