From: Alexander Cherepanov <ch3root@openwall.com>
To: musl@lists.openwall.com
Subject: Re: [musl] Minor style patch to exit.c
Date: Mon, 20 Jan 2020 00:34:31 +0300 [thread overview]
Message-ID: <e9c82028-524c-ba86-d507-4194f8ff97ea@openwall.com> (raw)
In-Reply-To: <20200119163936.GF30412@brightrain.aerifal.cx>
On 19/01/2020 19.39, Rich Felker wrote:
> On Sun, Jan 19, 2020 at 07:33:08PM +0300, Alexander Cherepanov wrote:
>> 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++)
>
> This works for forward walk, not backwards walk.
Oops, then asm barriers look more attractive.
>>> 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
>
> GCC is badly wrong here, and it breaks XOR linked lists and other
> things.
Why is that? Integers (and pointers as it turned out) could have several
provenances as tracked by gcc, so XOR linked lists should be fine.
> It's also worded imprecisely.
Sure.
> What does it mean if arithmetic
> is performed on the value between the cast and cast back. What if two
> pointers go into the arithmetic, but complex mathematical relations
> result in one of the original values coming out, and the compiler can
> only "see" the other pointer going in? Will it then wrongly assume
> that the result points to the same object as the pointer it "saw" go
> in?
I looked into exactly this about 3 week ago:-) Rediscovered an old gcc
bug and found that the problem happens even without any casts -- see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330#c28 .
> This whole provenance thing is a trashfire.
Pluses of the provenance thing: `a[i] = 1;` could be moved over `b[j] =
2;` when `a` and `b` are different array while `i` and `j` are unknown.
Minuses of the provenance thing: slight inconvenience in cases like with
_start & _end. The pluses seem to outweigh the minuses. Did I miss
something important?
What I recently found definitely wrong is instability of equality `&x +
1 == &y`. This leads to outright nonsense.
--
Alexander Cherepanov
prev parent reply other threads:[~2020-01-19 21:34 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-19 11:07 Markus Wichmann
2020-01-19 11:12 ` Markus Wichmann
2020-01-19 11:31 ` Szabolcs Nagy
2020-01-19 12:17 ` Markus Wichmann
2020-01-19 13:33 ` Alexander Cherepanov
2020-01-19 14:24 ` Markus Wichmann
2020-01-19 14:49 ` Pascal Cuoq
2020-01-19 15:53 ` Alexander Cherepanov
2020-01-19 16:22 ` Rich Felker
2020-01-19 21:02 ` Alexander Cherepanov
2020-01-19 14:46 ` Alexander Monakov
2020-01-19 16:18 ` Rich Felker
2020-01-19 17:11 ` Alexander Monakov
2020-01-19 17:17 ` Alexander Monakov
2020-01-19 17:19 ` Rich Felker
2020-01-19 17:32 ` Alexander Monakov
2020-01-19 17:38 ` Rich Felker
2020-01-19 19:13 ` Alexander Monakov
2020-01-19 16:33 ` Alexander Cherepanov
2020-01-19 16:39 ` Rich Felker
2020-01-19 21:34 ` Alexander Cherepanov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e9c82028-524c-ba86-d507-4194f8ff97ea@openwall.com \
--to=ch3root@openwall.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).