Re: valgrind problems

[Szabolcs Nagy <nsz@port70.net>]

* Jens Gustedt <jens.gustedt@inria.fr> [2013-06-16 17:58:52 +0200]:
> yes, I think it is gcc+platform behavior. the C standard makes no
> guarantee that this
> 
>    if (*z) *z=0;
> 
> guarantees that *z is observably 0 afterwards. And the problem is not
> that *z could be UB (if size_t had traps) but that there is no
> guarantee that an undetermined value is stable between two reads (the
> first with that "if" and the second from the application that receives
> this).

there is no undefined/implementation defined behaviour there

as rich said in freestanding mode malloc is not special
(musl gets initialized memory from the system through syscalls
and are always well defined at that point)

as far as i can see in freestanding mode you can only get
indeterminate values in
- objects with automatic storage duration
- objects modified from a signal handler
- unnamed members of a structure
none of these apply to *z in calloc

but i think you are wrong about the if (*z) *z=0; more generally:

accessing objects with indeterminate value is not undefined
in general, at least the definition of 'indeterminate value'
does not allow that, unless it may be a trap representation:
http://port70.net/~nsz/c/c11/n1570.html#3.19.2p1

if it is intended to be undefined then the normative text should
say so

the only explicitly undefined case i see is
http://port70.net/~nsz/c/c11/n1570.html#6.3.2.1p2
but that does not apply to accessing objects through a pointer