[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200119162233.GD30412@brightrain.aerifal.cx>
Date: Sun, 19 Jan 2020 11:22:33 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Minor style patch to exit.c
On Sun, Jan 19, 2020 at 06:53:49PM +0300, Alexander Cherepanov wrote:
> On 19/01/2020 17.24, Markus Wichmann wrote:
> >On Sun, Jan 19, 2020 at 04:33:47PM +0300, Alexander Cherepanov wrote:
> >>Couldn't _start defined as an array? Then separate values could be accessed
> >>simply as elements of this array. And casts to integers could be limited to
> >>calculating the number of elements, the terminating value or something.
> >
> >That reminds me of something I read in the C standard: Two pointers must
> >compare equal if, among other possibilities, one is a pointer to
> >one-past its underlying array, and the other is a pointer to the start
> >of its array, and the arrays happen to lie behind one another in address
> >space.
>
> One[1] of the gcc bug reports I mentioned is exactly about this
> issue. DR 260[2] allows to take the provenance of the pointers into
> account when comparing them and gcc really does this.
>
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
> [2] http://open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm
>
> As a side note, I thinks this is the wildest gcc bug report, it
> contains really mind-blowing comments (like comment 3). I don't mean
> it in a bad way at all and if you want to turn your understanding of
> C language inside-out you can try to read it. OTOH I think it's all
> wrong after all and I have some hope for it to be settled after my
> recent comments there. But I don't hold my breath.
>
> >Therefore, if _start and _end were arrays, even the GCC devs must agree
> >that there might be an integer i such that _start + i == _end. For the C
> >language, _start and _end would be arrays that happen to lie adjacent in
> >address space.
> >
> >And if we have guarantees from the outside attesting to that, then
> >_end - _start is no longer an undefined expression, right?
>
> 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 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. But compiler folks do not want to interpret
it this way and are pushing through hidden "provenance" state, so...
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.
