Re: Re: thoughts on reallocarray, explicit_bzero?

[Rich Felker <dalias@libc.org>]

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