mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Szabolcs Nagy <nsz@port70.net>
To: Vicente Bergas <vicencb@gmail.com>
Cc: musl@lists.openwall.com
Subject: Re: calloc question about clearing allocated memory
Date: Tue, 27 Jun 2017 15:13:27 +0200	[thread overview]
Message-ID: <20170627131327.GD2032@port70.net> (raw)
In-Reply-To: <CAAMcf8Bvw9Dwd177+WaQ+poArKfWuODPNC8DWsz55DYx3NdKQw@mail.gmail.com>

* Vicente Bergas <vicencb@gmail.com> [2017-06-26 23:30:53 +0200]:
> Hello,
> when compiling a program against the musl libc and running it under
> valgrind, then it reports lots of uninitialized value errors.
> I have tracked them down to only two sources:
> http://git.musl-libc.org/cgit/musl/tree/src/string/strlen.c?id=e6def544#n15
> http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc.c?id=e6def544#n375
> 
> The first one about strlen is clearly an optimization everybody would
> like to have, but the second one in __malloc0 is not that obvious.
> Please, could that be explained: why is *z read just before being
> cleared?
> In fact it is counter-intuitive and looks like an overhead.
> In case there is a reason for it, it would be nice to put an
> explanatory comment there. Otherwise, that extra read could be
> removed to make valgrind happy.

this should be the faq of the month..

a zero page does not take up resources, however when
it is written (even if that's just 0) the page gets
dirty and it does take up resources (and the write
operation would cause a page fault introducing
significant delays)

so if(*z) *z=0; should be an obvious optimization.
that said the current code is not optimal and an
improvement was just posted:
http://www.openwall.com/lists/musl/2017/06/26/1
but that won't fix the valgrind issue: to fix that
valgrind just needs to be taught not to report
uninitialized error for calloced memory.

> 
> Regards,
>   Vicenç.
> 
> P.S.: Please, CC me as I am not subscribed to the list.


  reply	other threads:[~2017-06-27 13:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-26 21:30 Vicente Bergas
2017-06-27 13:13 ` Szabolcs Nagy [this message]
2017-06-27 18:24   ` Vicente Bergas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170627131327.GD2032@port70.net \
    --to=nsz@port70.net \
    --cc=musl@lists.openwall.com \
    --cc=vicencb@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).