Re: [musl] Minor style patch to exit.c

[Alexander Cherepanov <ch3root@openwall.com>]

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.

-- 
Alexander Cherepanov