Path: csiph.com!news.mixmin.net!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c++
Subject: Re: C++20 concepts rocks
Date: Tue, 19 Apr 2022 02:21:25 -0700
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <86wnfl8m3u.fsf@linuxsc.com>
References: <stj7m4$bim$1@dont-email.me> <stmeik$a9k$1@redfloyd.dont-email.me> <stmgvd$r0s$1@dont-email.me> <stn5hs$23i$1@redfloyd.dont-email.me> <sto2hk$4ha$1@dont-email.me> <sto62g$b91$1@dont-email.me> <87mtj4qd0h.fsf@bsb.me.uk> <86fsovkdjw.fsf@linuxsc.com> <877da7r7ap.fsf@bsb.me.uk> <86bkzjjs3c.fsf@linuxsc.com> <87k0e6q4j8.fsf@bsb.me.uk> <8635kukb17.fsf@linuxsc.com> <878rumptie.fsf@bsb.me.uk> <86leymiga7.fsf@linuxsc.com> <877da3n2au.fsf@bsb.me.uk> <86czjvi97y.fsf@linuxsc.com> <87czjulvm9.fsf@bsb.me.uk> <868ruhikqf.fsf@linuxsc.com> <su61id$an$1@dont-email.me> <86zgmsh7nh.fsf@linuxsc.com> <suh0kq$pna$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="dca78489ef0b00bc0e84cad62da1ae52"; logging-data="20574"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19snQm9wCYO2m48AqLOpzoaS63A+84Zazc="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:OCJEvRRStoPmejp7J28OjdlLg0E= sha1:KnkTK3jDDUKgJq1Y6Tw/ChR/GCo=
Xref: csiph.com comp.lang.c++:83636

"Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:

> On 15 Feb 2022 09:10, Tim Rentsch wrote:
>
>> "Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
>>
>>> On 11 Feb 2022 14:41, Tim Rentsch wrote:
>>>
>>>> [snip]
>>>> Even if the reading proposed above holds, set_elements() can be
>>>> written in a way that avoids the putative undefined behavior:
>>>>
>>>>       void
>>>>       set_elements( int *v, size_t n, int value ){
>>>>           while(  n-- > 0  ){
>>>>               *(int*)( (char*)v + n * sizeof *v ) = value;
>>>>           }
>>>>       }
>>>>
>>>> This code has to work for the call that passes '(int*)&foo',
>>>> because all objects have an implied character array that overlays
>>>> the entire object, which is all of foo in this case.
>>>
>>> Again, for C++ (though I understand you're discussing the C case)
>>> you're colliding with a formal brick wall.
>>>
>>> The general consensus is that only `memcpy` plus one more mechanism I
>>> don't recall now (citing lack of coffee plus excessive blood sugar
>>> etc.) is sufficiently formally supported to avoid formal UB for
>>> copying bytes of objects.
>>
>> There is no copying of bytes in the above code.
>>
>>> In particular a `reinterpret_cast`, in the above code expressed as a C
>>> style cast, is a good way to let loose the strict aliasing demons of
>>> the g++ compiler.  [...]
>>
>> In the context the above code is used, there are no violations of
>> type-based aliasing rules.  Hence no "strict aliasing demons".
>
> The C style `(int*)` expresses a C++ `reinterpret_cast<int*>` of a
> `char*`.
>
> It doesn't matter for the formal that, taking into account how
> that char*` is produced, both we and any reasonable compiler know
> that the addresses that result are the addresses of items in an
> `int` array.
>
> The byte copying you failed to see ("no copying of bytes") while
> referring to it ("character array that overlays") is the copying
> of the bytes of `value` to each array item

Look again.  The code shown performs no accesses of any kind through
any character array.  Hence there is no copying of bytes in the
above code.