[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130616192929.GR29800@brightrain.aerifal.cx>
Date: Sun, 16 Jun 2013 15:29:29 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: valgrind problems
On Sun, Jun 16, 2013 at 09:25:47PM +0200, Szabolcs Nagy wrote:
> * Jens Gustedt <jens.gustedt@...ia.fr> [2013-06-16 20:02:00 +0200]:
> > as I said up-thread, this is not my own opinion (I personally would
> > argue as you do) but expressed in a recent discussion on the list of
> > the C standards committee. In addition there is an 10 year old reply
> > to a DR that goes in that direction.
>
> i see
>
> > And to clarify that, this is not about UB, but about the stability of
> > the value.
>
> i don't see any way "unstable" value can be allowed in c
> without invoking UB
>
> objects have to retain their last stored value or their
> initial value
> (so object access cannot be unstable)
>
> the abstract machine is defined in terms of sequencing
> side effects and value computations
> (so indeterminate values can only have unstable meaning
> if all operators have well defined semantics for them:
> eg. the semantics of '+' should say that the value of
> the result is the sum of the operands or indeterminate
> if any of the operands is indeterminate)
I agree completely. From an optimizing compiler standpoint, I _wish_
the language admitted such propagation of indeterminate values without
invoking full UB, but I don't see any way that the current language of
the standard could be interpreted as allowing that. At one point,
indeterminate values were deemed to invoke UB (see the vestigial item
in J.2) but it seems that the standard has been amended so that
indeterminate values are "safe" in most cases as long as the type does
not have trap representations.
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.
