Juneyoung Lee via llvm-dev
2021-Jun-07 04:25 UTC
[llvm-dev] [cfe-dev] [RFC] Introducing a byte type to LLVM
According to C17 it is legal: 6.5.9.p6 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*. On Mon, Jun 7, 2021 at 6:25 AM Joerg Sonnenberger via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Sun, Jun 06, 2021 at 11:52:13AM -0700, Marshall Clow via llvm-dev wrote: > > On Jun 6, 2021, at 12:54 AM, James Courtier-Dutton via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > > > > > > Hi, > > > > > > I would also oppose adding a byte type, but mainly because the bug > > > report mentioned (https://bugs.llvm.org/show_bug.cgi?id=37469) is not > > > a bug at all. > > > The example in the bug report is just badly written C code. > > > Specifically: > > > > > > int main() { > > > int A[4], B[4]; > > > printf("%p %p\n", A, &B[4]); > > > if ((uintptr_t)A == (uintptr_t)&B[4]) { > > > store_10_to_p(A, &B[4]); > > > printf("%d\n", A[0]); > > > } > > > return 0; > > > } > > > > > > "int B[4];" allows values between 0 and 3 only, and referring to 4 in > > > &B[4] is undef, so in my view, it is correctly optimised out which is > > > why it disappears in -O3. > > > > Taking the address of the “one-past-the end” element of an array is > perfectly legal in both C and C++. > > *Dereferencing* that pointer is UB. > > Not just dereferencing, but also comparing it to a random other point? > > Joerg > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Juneyoung Lee Software Foundation Lab, Seoul National University -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210607/57a7146f/attachment.html>
Mehdi AMINI via llvm-dev
2021-Jun-07 05:37 UTC
[llvm-dev] [cfe-dev] [RFC] Introducing a byte type to LLVM
On Sun, Jun 6, 2021 at 9:25 PM Juneyoung Lee via llvm-dev < llvm-dev at lists.llvm.org> wrote:> According to C17 it is legal: > > 6.5.9.p6 > > 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*. >This is interesting, I'm curious (we're a bit off-topic though) how is the part about "that happens to immediately follow the first array object in the address space" defined?> > > > On Mon, Jun 7, 2021 at 6:25 AM Joerg Sonnenberger via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Sun, Jun 06, 2021 at 11:52:13AM -0700, Marshall Clow via llvm-dev >> wrote: >> > On Jun 6, 2021, at 12:54 AM, James Courtier-Dutton via cfe-dev < >> cfe-dev at lists.llvm.org> wrote: >> > > >> > > Hi, >> > > >> > > I would also oppose adding a byte type, but mainly because the bug >> > > report mentioned (https://bugs.llvm.org/show_bug.cgi?id=37469) is not >> > > a bug at all. >> > > The example in the bug report is just badly written C code. >> > > Specifically: >> > > >> > > int main() { >> > > int A[4], B[4]; >> > > printf("%p %p\n", A, &B[4]); >> > > if ((uintptr_t)A == (uintptr_t)&B[4]) { >> > > store_10_to_p(A, &B[4]); >> > > printf("%d\n", A[0]); >> > > } >> > > return 0; >> > > } >> > > >> > > "int B[4];" allows values between 0 and 3 only, and referring to 4 in >> > > &B[4] is undef, so in my view, it is correctly optimised out which is >> > > why it disappears in -O3. >> > >> > Taking the address of the “one-past-the end” element of an array is >> perfectly legal in both C and C++. >> > *Dereferencing* that pointer is UB. >> >> Not just dereferencing, but also comparing it to a random other point? >> >> Joerg >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > > -- > > Juneyoung Lee > Software Foundation Lab, Seoul National University > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210606/10e0fcde/attachment.html>