From: Rich Felker <dalias@libc.org>
To: George Kulakowski <kulakowski@google.com>, musl@lists.openwall.com
Subject: Re: ub fix in magenta
Date: Sat, 5 Nov 2016 17:14:52 -0400 [thread overview]
Message-ID: <20161105211452.GB1555@brightrain.aerifal.cx> (raw)
In-Reply-To: <20161105202558.GK5749@port70.net>
On Sat, Nov 05, 2016 at 09:25:59PM +0100, Szabolcs Nagy wrote:
> why do you think union based type punning is ub?
> are you compiling musl as c++ code?
>
> commit 224516687417d5e9dcbb0ba300c3e34bb47bb12b
> Author: George Kulakowski <kulakowski@google.com>
> Date: 2016-10-19 17:11:59 -0700
>
> [musl][malloc] Remove undefined behavior in malloc
>
> This bit of code computes an approximation to log2(x) by extracting the
> exponent from a float. Doing it via a union this way is bad, so memcpy
> instead.
>
> https://fuchsia.googlesource.com/magenta/+/224516687417d5e9dcbb0ba300c3e34bb47bb12b
It's definitely not UB (this usage is explicitly permitted by C), and
the memcpy approach is much slower (requires store/call/load) because
-ffreestanding implies -fno-builtin. I'd like to try overriding that
with -fbuiltin-memcpy or a musl-internal header that defines memcpy to
__builtin_memcpy, etc., for all files but src/string/*, but there are
various subtle issues to be concerned about.
> this makes implementation internals publicly visible, introduce
> paddings and whenever you need to add new fields you will have
> to break the abi again.
>
> note that the initializers are not valid c and thus non-conforming.
>
> commit c751172f029e96a3208b37da91fd9e020a792834
> Author: George Kulakowski <kulakowski@google.com>
> Date: 2016-10-13 21:31:24 -0700
>
> [musl] Use a single proper struct definition for pthread types
>
> There is one slight change in layout here made for simplicity's
> sake. Upstream's pthread_barrier_t overlays the _b_count and _b_inst
> fields in the 32 bit case. Since this is so rarely used (in Fuchsia
> outside of libc I pretty much only see tsan, gdb etc. test cases),
> just do the simple thing.
>
> https://fuchsia.googlesource.com/magenta/+/c751172f029e96a3208b37da91fd9e020a792834
Yes, this change looks highly problematic to ABI stability.
> (i don't plan to review all changes i just wanted to see if there
> was anything useful in the magenta repo for musl, havent found much
> yet, but some of the changes could have been discussed upstream)
Thanks.
Rich
prev parent reply other threads:[~2016-11-05 21:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-05 20:25 Szabolcs Nagy
2016-11-05 21:14 ` Rich Felker [this message]
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=20161105211452.GB1555@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=kulakowski@google.com \
--cc=musl@lists.openwall.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).