Date: Sun, 19 Jan 2020 11:18:51 -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 05:46:15PM +0300, 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 > guaranteed that (intptr_t)&a[i] == (intptr_t)a + i * sizeof *a. Conceptually the _start is an array; that means it's fine to iterate over its elements, and we could even do so with the "correct" type. The problem is that _end is a different symbol and thereby inherently a "different object", and comparing against it with < is not valid; the compiler can legitimately optimize that out. I think with != would be valid, but I'm not sure we can trust compilers to honor any consistency for such "one past the end" comparisons. Casting to (uintptr_t) before doing the != comparison would absolutely be safe in the abstract machine; whether compilers honor this is unclear (because of the "provenance" stuff, which could break even the current code, so arguably we should have some "provenance barrier" here). Of course exit runs the array in reverse, which makes it even more of a mess. _end[-1] is clearly not valid when _end is an array object, and the compiler is free to break that. 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.