llvm dev - Jun 2021 - [cfe-dev] [RFC] Introducing a byte type to LLVM

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

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>