From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11525 Path: news.gmane.org!.POSTED!not-for-mail From: Jamie Mccrae Newsgroups: gmane.linux.lib.musl.general Subject: Query regarding malloc if statement Date: Mon, 19 Jun 2017 15:16:16 +0000 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_CY4PR02MB2231DC947A389856977CFF4E82C40CY4PR02MB2231namp_" X-Trace: blaine.gmane.org 1497885394 21179 195.159.176.226 (19 Jun 2017 15:16:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Jun 2017 15:16:34 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-11538-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jun 19 17:16:30 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dMyPl-0005Fj-NI for gllmg-musl@m.gmane.org; Mon, 19 Jun 2017 17:16:30 +0200 Original-Received: (qmail 3561 invoked by uid 550); 19 Jun 2017 15:16:31 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3525 invoked from network); 19 Jun 2017 15:16:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onelaird.onmicrosoft.com; s=selector1-lairdtech-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gDFkzMq4zFs1Pa4UxSb3urI7Xthe4G1V4v13wKoG+Mo=; b=rQUFqLJYonCbhTDLnZ4Kd9CcSEtu2geMfwVQal3sAZjC16apgGum2BN3BmnJEJG4Aj2c+uZ9vG5FgvMaSGaaQUgMbjZICTm80OvYksqEASBnVpTH4gpsC5xw++nd+3nsFWe0SFwjtNfEY3rwfXwANxTDL0l3ag1LZDjgT0vbcMw= Thread-Topic: Query regarding malloc if statement Thread-Index: AQHS6Q364nRThOi3ekOr7O8ZITuALg== Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lists.openwall.com; dkim=none (message not signed) header.d=none;lists.openwall.com; dmarc=none action=none header.from=lairdtech.com; x-originating-ip: [86.161.201.80] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;CY4PR02MB2230;7:6LhPzA47qyod8La/fI8Va84lyCthXwBYHUlpaa9SmWT1T5w6r+UVTP+9JJDSJCzIns2S5PAcQmca4WRl1soGSlOKaVQp+M/NKRdfIg/GKkhhgqXawDj8loVyclFubWJeHI+HdA7AdXzkoRJB6HUOR4Nw31VcA956ofuuhvfsh5S0w9iK2GxU3NdkXlz8BbTDGMxleCs972Tch6ZfJieGhnlyQY/i0/G1rCHuBfwtZZm0Bm68EY331wtTLHjtxRBpkmFF6ZJGbkN85ICfSYD4cqlOyFzwU2+iosePxieuCamRlmGLNabPrJsteg3fUyLeVpE6vINBQC9vYtHaD1Tgfzkh80rSR+5I/EeKTxAslbmOH8AFxV6YxntQFIR2O0RnTDrap9TqfxpBdFp1wPJD8yqMrX926WYWQSzDf1q6C4+NWEDt6XRMfVUszUrxWYFUEEUDeg5gkVxyFmCcV0NZc/fYvf9JqWfWpotCdpvsvXeFM4KIp7pUAIBHrkfqkSprDWH4wW9K4QRPRnFiDVc7Qn8UFS7yGEWE907xeO9wU68KJ7NRSK3bcxe2Iys6HfEB+y/uNnBzxyPGvXuYaisfbwQWtL3aUCfFn9d7HCu0QV5QsiSnAi6Sa+i+dtqMQGekHY8NPyWBOsHMqrciRn0XZVjn8f6STN0UxKEovXu5kF2spVaF6HP1hGWxhKNTNzrSkz9ob2qoOmFgZwSE2PIcE6cKWRlcf29zTgCFm+AjcCql o6fws4uY4SjTyB9IIyVxFz3lSfmoOLRu8Q9gpi9uo1JtjSdzoK64QVlSXE7gXps= x-ms-office365-filtering-correlation-id: 88f089f3-8dea-4bb0-4ae0-08d4b7262165 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(201703131423075)(201703031133081);SRVR:CY4PR02MB2230; x-ms-traffictypediagnostic: CY4PR02MB2230: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:CY4PR02MB2230;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:CY4PR02MB2230; x-forefront-prvs: 0343AC1D30 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39840400002)(39850400002)(39450400003)(39410400002)(39400400002)(54896002)(55016002)(99286003)(6506006)(6436002)(5640700003)(3660700001)(478600001)(77096006)(3280700002)(6116002)(3846002)(102836003)(9686003)(86362001)(122556002)(19627405001)(14454004)(38730400002)(110136004)(74316002)(53936002)(189998001)(2351001)(7736002)(33656002)(54356999)(72206003)(25786009)(66066001)(6606003)(1730700003)(8676002)(81166006)(8936002)(5660300001)(6916009)(2900100001)(7696004)(50986999)(2906002);DIR:OUT;SFP:1102;SCL:1;SRVR:CY4PR02MB2230;H:CY4PR02MB2231.namprd02.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM X-OriginatorOrg: lairdtech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2017 15:16:16.1446 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c4d27a54-2db1-4088-a044-1a83c778ad1b X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR02MB2230 Xref: news.gmane.org gmane.linux.lib.musl.general:11525 Archived-At: --_000_CY4PR02MB2231DC947A389856977CFF4E82C40CY4PR02MB2231namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I'm using musl to compile a cross-distro application which I've been having= problems with and whilst discussing the problem the developer of another p= roject, was shown a musl malloc function which manually checks the contents= of each byte and changes it to 0 if the byte is non-0. This code is in src= /malloc/malloc.c as so: void *__malloc0(size_t n) { void *p =3D malloc(n); if (p && !IS_MMAPPED(MEM_TO_CHUNK(p))) { size_t *z; n =3D (n + sizeof *z - 1)/sizeof *z; for (z=3Dp; n; n--, z++) if (*z) *z=3D0; } return p; } This code causes thousands of errors when using valgrind (in excess of 800,= 000 for my application) due to checking the value of each byte before it ha= s been set and I have to agree with this other developer that I'm at a loss= as to why this is performed. If you step through the array and just set ea= ch byte to 0 then there will be no read-before-initialisation error and the= function will run much faster due to not having to retrieve the data. Why = not instead use: for (z=3Dp; n; n--, z++) *z=3D0; --_000_CY4PR02MB2231DC947A389856977CFF4E82C40CY4PR02MB2231namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

I'm using musl to compile a cross-distro application which I've been hav= ing problems with and whilst discussing the problem the developer of anothe= r project, was shown a musl malloc function which manually checks the conte= nts of each byte and changes it to 0 if the byte is non-0. This code is in src/malloc/malloc.c as so:


void *__malloc0(size_t n)
{
        void *p =3D malloc(n);
        if (p && !IS_MMAPPED(MEM= _TO_CHUNK(p))) {
            &nb= sp;   size_t *z;
            &nb= sp;   n =3D (n + sizeof *z - 1)/sizeof *z;
            &nb= sp;   for (z=3Dp; n; n--, z++) if (*z) *z=3D0;
        }
        return p;
} 


This code causes thousands of errors when using valgrind (in excess of 8= 00,000 for my application) due to checking the value of each byte before it= has been set and I have to agree with this other developer that I'm at a l= oss as to why this is performed. If you step through the array and just set each byte to 0 then there will = be no read-before-initialisation error and the function will run much faste= r due to not having to retrieve the data. Why not instead use:

           =      for (z=3Dp; n; n--, z++) *z=3D0;

--_000_CY4PR02MB2231DC947A389856977CFF4E82C40CY4PR02MB2231namp_--