[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130616174008.GF6548@port70.net>
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#6.3.2.1p2
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.
