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

[Juneyoung Lee via cfe-dev]

Hi Mehdi,

I couldn't find a paragraph explicitly specifying how objects are located
from the text.
It seems it is deliberately underspecified to allow compilations to exotic
target machines.
However, I could find a few paragraphs that look interesting:

6.2.4p2: An object exists, has a constant address,33) and retains its
last-stored value throughout its lifetime.
33) The term “constant address” means that two pointers to the object
constructed at possibly different times will compare equal. The address may
be different during two different executions of the same program.

6.3.2.3.p5 68)
The mapping functions for converting a pointer to an integer or an integer
to a pointer are intended to be consistent with the addressing structure of
the execution environment.

7.22.3p1
... Each such allocation shall yield a pointer to an object disjoint from
any other object. The pointer returned points to the start (lowest byte
address) of the allocated space. ...

https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf


Going back to the bug report, I don't think these paragraphs affect the
validity of the example.

Thanks,
Juneyoung

On Mon, Jun 7, 2021 at 2:38 PM Mehdi AMINI <joker.eph at gmail.com> wrote:

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

-- 

Juneyoung Lee
Software Foundation Lab, Seoul National University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210607/cb8ad900/attachment-0001.html>