[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d8bd0b30-d732-5926-9c37-3674ab241218@openwall.com>
Date: Mon, 20 Jan 2020 00:02:04 +0300
From: Alexander Cherepanov <ch3root@...nwall.com>
To: musl@...ts.openwall.com
Subject: Re: Minor style patch to exit.c
On 19/01/2020 19.22, Rich Felker wrote:
>> Even if we know that _start + k == _end it doesn't mean that we
>> allowed to subtract them.
>
> Consider a function that takes a pointer p, an array a, and a length
> l, and does:
>
> for (i=0; i<l; i++) if (a+i == p) return p-a;
>
> Can f(_end,_start,k) and f(_start+k,_start,k) legitimately differ,
> despite _end==_start+k?
I guess it depends on what you mean by "legitimately" and "differ".
Given that _start and _end are different arrays the first variant is
undefined.
Counter-intuitive behavior of equal pointers could be demonstrated much
easier. Suppose x and y are two objects of the same type and &x + 1 ==
&y. Is it valid to evaluate the following expressions: *(&x + 1), &x +
2, (&y)[-1]?
> I think the answer is no, in the existing C
> language, in that the result of an expression is a pure function of
> the *values* put into it.
The fact that two values are equal doesn't mean that they are the same
value.
Take floating-point zeroes for example. They are equal but have
different provenances: one came from the right, another one -- from the
left:-)
> But compiler folks do not want to interpret
> it this way and are pushing through hidden "provenance" state, so...
IIUC they are not happy about it too but the alternatives are not that
great.
--
Alexander Cherepanov
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.
