mailing list of musl libc
 help / color / mirror / code / Atom feed
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


      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).