Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 15 Dec 2019 06:47:46 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: max_align_t mess on i386

On Sat, Dec 14, 2019 at 10:19:32AM -0500, Rich Felker wrote:
> The disadvantage of leaving max_align_t alone is that we have to
> (continue to) consider _Float128 an unsupported extension type whose
> use would be outside the scope of any guarantees we make, and that
> would need memalign to use. This is largely viable at present because
> it's a fringe thing, but we don't know if that will continue to be
> true far in the future.
>

It wouldn't just be that. Any application making use of SSE vector types
would have to use *memalign(). Apparently, there are libraries out there
that expect to get a 16byte alignment out of malloc(), or at least
that's what the author of dietlibc is alleging here:

https://blog.fefe.de/?ts=bac7bb06

Yes, it's German, but Google Translate exists. More importantly though,
it is from 2006, and he says he's "hacking about with" a bignum library,
and I don't know if he means his own or a public one. In any case,
though, the mere existance of SSE was cause enough for that man to
change the allocator to return a higher alignment on x86. Maybe one more
factor leaning towards the ABI change, right?

> Rich

Ciao,
Markus

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.