On Sat, 21 Jan 2023, 14:04 , <language.lawyer_at_[hidden]> wrote:

> On 21/01/2023 18:19, Edward Catmur wrote:
> > On Sat, 21 Jan 2023, 13:09 , <language.lawyer_at_[hidden]> wrote:
> >> On 21/01/2023 18:01, Edward Catmur wrote:
> >>> On Sat, 21 Jan 2023, 12:57 , <language.lawyer_at_[hidden]> wrote:
> >>>> On 21/01/2023 17:49, Edward Catmur wrote:
> >>>>> On Sat, 21 Jan 2023, 12:40 , <language.lawyer_at_[hidden]> wrote:
> >>>>>> On 21/01/2023 17:37, Edward Catmur wrote:
> >>>>>>> On Sat, 21 Jan 2023, 12:34 , <language.lawyer_at_[hidden]> wrote:
> >>>>>>>> On 21/01/2023 17:31, Edward Catmur wrote:
> >>>>>>>>> On Sat, 21 Jan 2023, 12:25 language.lawyer--- via Std-Proposals,
> <
> >>>>>>>>> std-proposals_at_[hidden]> wrote:
> >>>>>>>>>> On 20/01/2023 12:42, Jens Maurer via Std-Proposals wrote:
> >>>>>>>>>>> Anyway, the "i++" is undefined behavior per [expr.add] p6:
> >>>>>>>>>>>
> >>>>>>>>>>>> For addition or subtraction, if the expressions P or Q have
> type
> >>>>>>>>>> “pointer to cv T”,
> >>>>>>>>>>>> where T and the array element type are not similar (7.3.6),
> the
> >>>>>>>>>> behavior is undefined.
> >>>>>>>>>>
> >>>>>>>>>> In f(b), first we get array-to-pointer conversion to get a
> pointer
> >>>> to
> >>>>>>>> the
> >>>>>>>>>> first array element, and then conversion to pointer to its I
> base
> >>>>>> class
> >>>>>>>>>> subobject, so the pointer type and the object it points to are
> >>>>>> aligned.
> >>>>>>>>>> Which means there is no UB per [expr.add]/6.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> "similar" isn't specified in terms of alignment.
> >>>>>>>>
> >>>>>>>> "aligned" == "coherent/matching/in agreement"
> >>>>>>>>
> >>>>>>>
> >>>>>>> I have no idea what you mean by that. Are you saying that the array
> >>>>>> element
> >>>>>>> type and the base class type are similar?
> >>>>>>
> >>>>>> I mean that doing pointer arithmetic on a «pointer to I» which
> points
> >> at
> >>>>>> object of type I is OK from [expr.add]/6 POV.
> >>>>>>
> >>>>>
> >>>>> The base class subobject and pointer type are similar, but the array
> >>>>> element type is not.
> >>>>
> >>>> How can T in «pointer to T» expression type be similar to the type of
> >> the
> >>>> base class subobject, and not similar to the «array element type» at
> the
> >>>> same time, when array element here is the base class subobject?
> >>>>
> >>>
> >>> The array element type is B.
> >>
> >> How `b` array's element type is relevant here? We do not use a pointer
> to
> >> `b`'s element.
> >>
> >
> > Yes we do. The pointer being incremented points to an array of element
> type B.
>
> The pointer points neither to an array nor to an object of type B.
>
> > Which array of element type I do you identify in the program?
> https://timsong-cpp.github.io/cppwp/n4861/basic.compound#3.sentence-12,
> no? [expr.add] even has a reminder about it (
> https://timsong-cpp.github.io/cppwp/n4861/expr.add#footnote-76)
>

Right. The existence of that unary array is somewhat questionable, since it
would not be possible to create such an array within the program. That
aside, you are correct which means that the UB occurs in the next
iteration, when the past the end iterator is indirected.

>