mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Pascal Cuoq <cuoq@trust-in-soft.com>
To: "musl@lists.openwall.com" <musl@lists.openwall.com>
Subject: Re: [musl] Minor style patch to exit.c
Date: Sun, 19 Jan 2020 14:49:56 +0000	[thread overview]
Message-ID: <7C15E000-57F3-4B69-B29D-DBEE9BE14EAF@trust-in-soft.com> (raw)
In-Reply-To: <20200119142401.GG2020@voyager>


> On 19 Jan 2020, at 15:24, Markus Wichmann <nullplan@gmx.net> wrote:
> 
> 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.

The clause is 6.5.9:6 in C11:

Two pointers compare equal if and only if both are null pointers, both are pointers to the same object (including a pointer to an object and a subobject at its beginning) or function, both are pointers to one past the last element of the same array object, or one is a pointer to one past the end of one array object and the other is a pointer to the start of a different array object that happens to immediately follow the first array object in the address space.

With a footnote:

Two objects may be adjacent in memory because they are adjacent elements of a larger array or adjacent members of a structure with no padding between them, or because the implementation chose to place them so, even though they are unrelated. […]



The way GCC developers have decided to interpret this clause is that if the two arrays had to be adjacent in memory because they were part of the same aggregate, the pointers will reliably be equal iff one is one-past-the-end of the first one and the other is at the beginning of the second one. Otherwise, compilers will sometimes optimize “&a + 1 == b” to 0, that is, they implement a rule that could be paraphrased as “two pointers *may* compare equal if one is to the end of an array object and the other is to the beginning of another array objects that happens to lie immediately after the first one”.

https://gcc.godbolt.org/z/NfmTV9

> 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.

If they did, they would not have written an optimization that transforms “a + 1 == b” into 0 regardless of the actual addresses of a and b.

(Every object is an array for the purpose of this discussion, that's 6.5.9:7, but it doesn't help.)

Pascal


  reply	other threads:[~2020-01-19 14:50 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 [this message]
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

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=7C15E000-57F3-4B69-B29D-DBEE9BE14EAF@trust-in-soft.com \
    --to=cuoq@trust-in-soft.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).