Date: Fri, 7 Aug 2020 18:06:18 +0200
Guys, with all due respect,
Exact discussion like that tells me that C++ is heading in the wrong
direction.
Programming languages are used only in business environments. Do you really
think that something like the discussion we are having now has a place in
the business world?
Guys...
On Fri, Aug 7, 2020 at 5:43 PM language.lawyer--- via Std-Discussion <
std-discussion_at_[hidden]> wrote:
> On 07/08/2020 18:16, Jason McKesson via Std-Discussion wrote:
> > On Fri, Aug 7, 2020 at 10:06 AM <language.lawyer_at_[hidden]> wrote:
> >>
> >> On 07/08/2020 16:51, Jason McKesson via Std-Discussion wrote:
> >>> The cast is legal. Accessing the `unsigned char` at that address is
> >>> legal.
> >>
> >> You can't access `unsigned char` objects, `reinterpret_cast<unsigned
> char*>(buf)` points to the object of `mybyte` type.
> >
> > According to [basic.lval]/8.8, I can:
> >
> >> If a program attempts to access the stored value of an object through a
> glvalue of other than one of the
> > following types the behavior is undefined:
> >> ...
> >> a char, unsigned char, or std::byte type.
> >
> > So it doesn't matter what `T1` is; you can access that byte as an
> > `unsigned char`. And indeed, if you could get a pointer to *any* byte
> > within `T1`, you can access it as an `unsigned char`.
> >
> > It's getting a pointer to those bytes that is the problem.
>
> That is what was meant by "you can't access `unsigned char` objects". You
> can't get a pointer to them.
>
> >> But accessing an object of `mybyte` type through a glvalue of `unsigned
> char` type is indeed legal, because an enumeration with a fixed underlying
> type has the same values as the underlying type.
> >
> > Actually, that's not true. I mean, it is true that the value
> > representations are the same, but that doesn't mean you can access
> > them through different types. [basic.lval] has no special provisions
> > for an enum and its underlying type.
>
> I was speaking exactly about the case of `enum mybyte : unsigned char`.
> If there were no rule explicitly saying
> > For an enumeration whose underlying type is fixed, the values of the
> enumeration are the values of the underlying type.
>
> accessing an object of `mybyte` type through an `unsigned char` glvalue
> would be UB because of [expr.pre]/4, even though [basic.lval] "allows" such
> access.
>
>
> Your
> > The cast is legal. Accessing the `unsigned char` at that address is
> legal. But without P1839, actually doing the pointer arithmetic needed to
> access more than one such byte is not.
>
> sounds like that now, without P1839, there is some "access to one byte",
> which is not the case.
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
Exact discussion like that tells me that C++ is heading in the wrong
direction.
Programming languages are used only in business environments. Do you really
think that something like the discussion we are having now has a place in
the business world?
Guys...
On Fri, Aug 7, 2020 at 5:43 PM language.lawyer--- via Std-Discussion <
std-discussion_at_[hidden]> wrote:
> On 07/08/2020 18:16, Jason McKesson via Std-Discussion wrote:
> > On Fri, Aug 7, 2020 at 10:06 AM <language.lawyer_at_[hidden]> wrote:
> >>
> >> On 07/08/2020 16:51, Jason McKesson via Std-Discussion wrote:
> >>> The cast is legal. Accessing the `unsigned char` at that address is
> >>> legal.
> >>
> >> You can't access `unsigned char` objects, `reinterpret_cast<unsigned
> char*>(buf)` points to the object of `mybyte` type.
> >
> > According to [basic.lval]/8.8, I can:
> >
> >> If a program attempts to access the stored value of an object through a
> glvalue of other than one of the
> > following types the behavior is undefined:
> >> ...
> >> a char, unsigned char, or std::byte type.
> >
> > So it doesn't matter what `T1` is; you can access that byte as an
> > `unsigned char`. And indeed, if you could get a pointer to *any* byte
> > within `T1`, you can access it as an `unsigned char`.
> >
> > It's getting a pointer to those bytes that is the problem.
>
> That is what was meant by "you can't access `unsigned char` objects". You
> can't get a pointer to them.
>
> >> But accessing an object of `mybyte` type through a glvalue of `unsigned
> char` type is indeed legal, because an enumeration with a fixed underlying
> type has the same values as the underlying type.
> >
> > Actually, that's not true. I mean, it is true that the value
> > representations are the same, but that doesn't mean you can access
> > them through different types. [basic.lval] has no special provisions
> > for an enum and its underlying type.
>
> I was speaking exactly about the case of `enum mybyte : unsigned char`.
> If there were no rule explicitly saying
> > For an enumeration whose underlying type is fixed, the values of the
> enumeration are the values of the underlying type.
>
> accessing an object of `mybyte` type through an `unsigned char` glvalue
> would be UB because of [expr.pre]/4, even though [basic.lval] "allows" such
> access.
>
>
> Your
> > The cast is legal. Accessing the `unsigned char` at that address is
> legal. But without P1839, actually doing the pointer arithmetic needed to
> access more than one such byte is not.
>
> sounds like that now, without P1839, there is some "access to one byte",
> which is not the case.
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
-- Best regards *Artur Czajkowski* https://marketplace.visualstudio.com/items?itemName=GitAtomic.GitAtomic
Received on 2020-08-07 11:09:55