Date: Sun, 16 Jun 2013 19:40:08 +0200 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: valgrind problems * Jens Gustedt <jens.gustedt@...ia.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#126.96.36.199p2 but that does not apply to accessing objects through a pointer
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.