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

[Alexander Cherepanov <ch3root@openwall.com>]

On 19/01/2020 17.46, Alexander Monakov wrote:
> On Sun, 19 Jan 2020, 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.
> 
> Yeah, I think usually such linker-provided symbols are declared as
> extern arrays. I'm surprised that isn't the case in musl.  I don't think
> declaring them as arrays helps with making casts pedantically suitable for
> calculating number of elements though - as you said, any bijection between
> intptr_t and pointers would be a valid implementation of a cast, you're not

Well, we want use from C some outside info, there could be no pedantic 
way to do this. Let's see, we know that the _end array follows the 
_start array in memory. This means that &_start[i] == &_end[0] for some 
i. But different provenance of the pointers means that we cannot do it 
just like that. Adding a cast should fix this. Summarizing, it should 
look like this:

for (size_t i = 0; (uintptr_t)&_start[i] != (uintptr_t)&_end[0]; i++)

or

for (type *p = _start; (uintptr_t)p != (uintptr_t)_end; p++)

> guaranteed that (intptr_t)&a[i] == (intptr_t)a + i * sizeof *a.

While you are inside one object, I think this should be safe in 
practice. For gcc, this is more or less guaranteed by [3]. BTW there is 
an explicit restriction there:

"When casting from pointer to integer and back again, the resulting 
pointer must reference the same object as the original pointer, 
otherwise the behavior is undefined. That is, one may not use integer 
arithmetic to avoid the undefined behavior of pointer arithmetic as 
proscribed in C99 and C11 6.5.6/8."

[3] 
https://gcc.gnu.org/onlinedocs/gcc/Arrays-and-pointers-implementation.html

-- 
Alexander Cherepanov