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

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.

— Marshall

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