[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 11 Jun 2014 08:59:12 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Re: thoughts on reallocarray, explicit_bzero?
On Wed, Jun 11, 2014 at 09:59:56AM +0000, Thorsten Glaser wrote:
> Szabolcs Nagy <nsz <at> port70.net> writes:
>
> > static size_t sizemul(size_t a, size_t b)
> > {
> > return b>1 && a>1 && a>-1/b ? -1 : a*b;
> > }
>
> There is no -1 in size_t. (And *you* complain about OpenBSD checks…)
The standard way (especially for generic programming, but it's usable
anywhere) to get the max value for an unsigned type is to convert -1.
b and a*b both have type size_t, so...
> > i don't see how the openbsd explicit_bzero stops the
> > compiler to do optimizations..
>
> On OpenBSD: by being in libc which is not built with LTO.
> I’ve wondered about how to do this either. Maybe:
Yeah, that's a poor hack. We still probably have some places where
"extern" is used as a compiler barrier, but it's wrong, and I'm
working to identify and remove them all.
> void
> explicit_bzero(void *s, size_t n)
> {
> bzero(s, n);
> __lto_boundary
> }
>
> Then you #define __lto_boundary to something like
> __asm__ volatile ("" : : : "memory");
> or
> __sync_synchronize();
> or some C11 barrier function.
These are not sufficient. It would probably need to be:
__asm__ volatile ("" : : "r"(s) : "memory");
or similar. This is because volatility and memory-clobber only
provide a barrier with respect to objects which exist in memory, and
at the point of the asm (after transformations which do not disturb
the observable behavior of the program), the pointed-to object with
automatic storage does not exist.
Rich
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.
