Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #82946
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: C++20 concepts rocks |
| Date | 2022-02-06 19:03 -0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <86bkzjjs3c.fsf@linuxsc.com> (permalink) |
| References | (8 earlier) <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> |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> "Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
>>>
>>>> The code using `(&result)[1]` involves a couple of extra conversions
>>>
>>> Eh? char *ep = r + sizeof(r); involves one array-to-pointer conversion
>>> just as char *ep = (&r)[1]; does.
>>>
>>>> and indirections and is thus needlessly complex, plus it's formally
>>>> UB,
>>>
>>> Can you point to where this is made UB in the C++ standard?
>>>
>>> There is an ambiguous phrase in the C standard ("undefined behaviour if
>>> the * is evaluated") but that phrase is entirely missing in the C++
>>> text. And I got lost in the forest of rvalues, lvalues, prvalues,
>>> xvalues and glvalues without finding anything undefined. Can you find
>>> it? [...]
>>
>> Let me take a stab at explaining. There is undefined behavior in
>> the code that Alf originally responded to, but where the UB is
>> and why it is UB has not been explained very well. Two points to
>> start: there is nothing wrong with the original initializing
>> declaration; and the aspect of dereferencing is a red herring.
>>
>> To begin suppose we have this code:
>>
>> char foo[2][20];
>> char *p = foo[1];
>>
>> There is nothing wrong with this code. After these declarations
>> the variable p points at the first element of foo[1];
>>
>> But a problem happens if we want to use p to create pointer
>> values that point to elements of foo[0], as for example
>>
>> char *p_prime = p-1;
>>
>> The rules for pointer arithmetic don't allow this. The reason
>> is p points an element of foo[1], but p-1 doesn't. In both C
>> and C++ the semantic description for adding an integer to a
>> pointer defines the result only if P and P+N are both elements
>> of the same array (or one past the last element). But that
>> isn't true here. The variable p unambiguously points at an
>> element of foo[1], but p-1 does not. If we have two pointers
>> p and q
>>
>> char foo[2][20];
>> char *p = foo[1];
>> char *q = foo[0] + 20;
>>
>> the pointers p and q will (and must) compare equal, but they are
>> not interchangeable, because they point into different subarrays
>> of foo.
>>
>> Going back to the earlier code, we have
>>
>> char *ep = (&result)[1];
>>
>> There is nothing wrong with this initialization. But by virtue
>> of taking the address of result, which is an array, we have in
>> effect created a two-dimensional array, and have initialized ep
>> with a pointer that points into the "second subarray" of that
>> two-dimensional array. The created pointer value is not allowed
>> to participate in arithmetic that would take it into the first
>> subarray. So later in the earlier code when we use this
>> expression
>>
>> ep - 4
>>
>> the code is asking for a pointer to an object in (&result)[1].
>> But there is no such object. The expressions
>>
>> ep - 0
>>
>> and
>> ep + 0
>>
>> would both be okay, but only because what is being added or
>> subtracted is zero; if any non-zero value were used there
>> is undefined behavior, because the resulting pointer value
>> does not point to an object in the same subarray. (In effect
>> there is one and only one object in the second subarray, but
>> trying to access that mythical object also falls into the
>> realm of undefined behavior.)
>>
>> References: section 6.5.6 paragraph 8 for C (n1570);
>> section 7.6.6 paragraph 4.2 for C++ (N4860).
>
> So given
>
> int i;
> char *cp = (void *)(&i + 1);
>
> accessing the bytes of i from cp is also undefined.
No, accessing cp[-1], etc, is defined behavior. The two situations
are not analogous. The reason is that in this case there is only
one array, without any subarrays. The expression (&i+1) has type
pointer to int; it points to one past the last element of the
implicit array that surrounds a non-array object. Because that
expression points to (or just past) an element of the one array, C
allows access to other elements of that array, namely the bytes of
(&i)[0].
By analogy, if we were to do this
char result[20];
char *ep = (void*)(&result + 1);
then ep can be used to access the bytes in result, because the
pointer being converted points to an element of &result, rather
than to an element of (&result)[1]: in the first case the value
points to an element of the first level array, whereas in the
second case the value points to an element of the second level
array (which is a subarray, so the pointer value points into
the subarray rather than to the subarray as a whole). Similarly,
char result[20];
char *ep = (void*) &(&result)[1];
allows ep to be used to access the bytes in result, because
the pointer being converted points to an element of &result.
In the original case
char result[20];
char *ep = (&result)[1];
what kills us is the implicit conversion from (char[20]) to
(char *). That conversion gives a pointer that points /into/
(&result)[1] rather than a pointer /to/ an element of &result.
Taking the address of (&result)[1] -- ie, &(&result)[1] --
solves the undefined behavior aspect, but of course then the
expression does not have type (char *), so some kind of casting
would be needed.
> [...] While I don't think I've ever used the (&array)[1] pointer
> before now as anything other than an "end marker" for comparison
> (which is defined), I'm pretty sure I've written something like the
> above more than once. It just seems simpler than adding sizeof (i)
> to (char *)&i.
If you don't mind using a cast or compound literal, you can use
the &x+1 form regardless of whether x is a scalar or an array:
char result[20];
char *ep = (void*){ &result + 1 };
and sidestep the problem with undefined behavior. (Unfortunately
the compound literal form works only with function locals, and not
at the top level.)
For the record, I think your idiom is very nice, and I am quite
disappointed that it inadvertently wanders into the land of
undefined behavior.
>> For the record, IMO neither the C standard nor the C++ standard
>> describes plainly enough what the rules are for multi-dimensional
>> arrays. I understand why the rules are the way they are, but I
>> would like to see one or both standards state how things work in
>> a more lucid fashion.
>>
>> Does this help clear things up?
>
> It explains something else, but not what I was asking about. I did not
> consider the problem of "going backwards", so thank you for that. (I
> originally asked for citations to support what Alf thought was UB about
> the (&array)[1] construct because C++ and C are worded differently
> there.)
I must confess I find some of Alf's statements hard to understand,
so unfortunately I can't help you there. AFAICT the construct
(&array)[1] does not by itself have undefined behavior in either
C or C++.
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-04 13:54 +0100
Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-04 14:25 +0000
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-04 15:31 +0100
Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-04 14:54 +0000
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-04 17:41 +0100
Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-05 11:31 +0000
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-05 12:49 +0100
Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-05 12:20 +0000
Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-04 16:15 +0000
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-04 17:43 +0100
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-05 01:51 +0100
Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-05 01:59 +0000
Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-04 23:05 -0500
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-05 11:56 +0100
Re: C++20 concepts rocks David Brown <david.brown@hesbynett.no> - 2022-02-05 13:53 +0100
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-05 14:12 +0100
Re: C++20 concepts rocks Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2022-02-12 11:13 -0800
Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-12 22:18 -0500
Re: C++20 concepts rocks Richard Damon <Richard@Damon-Family.org> - 2022-02-13 12:51 -0500
Re: C++20 concepts rocks Paavo Helde <eesnimi@osa.pri.ee> - 2022-02-13 20:16 +0200
Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-13 14:12 -0500
Re: C++20 concepts rocks Richard Damon <Richard@Damon-Family.org> - 2022-02-13 16:22 -0500
Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-13 17:18 -0500
Re: C++20 concepts rocks Öö Tiib <ootiib@hot.ee> - 2022-02-14 00:51 -0800
Re: C++20 concepts rocks "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-02-14 08:29 -0800
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-04 23:37 -0800
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-05 11:58 +0100
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 02:16 -0800
Re: C++20 concepts rocks "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-02-05 12:35 -0800
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 05:54 -0800
Re: C++20 concepts rocks Manfred <noname@add.invalid> - 2022-02-06 19:43 +0100
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-04 23:53 -0800
Re: C++20 concepts rocks red floyd <no.spam.here@its.invalid> - 2022-02-05 10:10 -0800
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-05 19:51 +0100
Re: C++20 concepts rocks red floyd <no.spam.here@its.invalid> - 2022-02-05 16:42 -0800
Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-06 01:39 +0000
Re: C++20 concepts rocks red floyd <no.spam.here@its.invalid> - 2022-02-05 18:02 -0800
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-06 09:57 +0100
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-06 10:57 +0100
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-06 12:40 +0100
Re: C++20 concepts rocks Öö Tiib <ootiib@hot.ee> - 2022-02-06 03:53 -0800
Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-06 14:35 +0000
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 11:20 -0800
Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-06 21:53 +0000
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 19:03 -0800
Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-07 11:50 +0000
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-07 06:26 -0800
Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-07 15:48 +0000
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-07 12:16 -0800
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-07 22:27 -0800
Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-09 21:43 +0000
Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-09 21:07 -0500
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-09 21:25 -0800
Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-10 13:05 +0000
Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-10 11:19 -0500
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-11 05:41 -0800
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-11 17:06 +0100
Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-11 11:50 -0500
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-11 21:13 +0100
Re: C++20 concepts rocks scott@slp53.sl.home (Scott Lurndal) - 2022-02-11 17:06 +0000
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-15 00:10 -0800
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-15 20:58 +0100
Re: C++20 concepts rocks Juha Nieminen <nospam@thanks.invalid> - 2022-02-16 06:40 +0000
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-16 09:54 +0100
Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-16 09:00 +0000
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-16 20:25 +0100
Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-17 08:53 +0000
Re: C++20 concepts rocks Paavo Helde <eesnimi@osa.pri.ee> - 2022-02-17 16:11 +0200
Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-17 10:58 -0500
Re: C++20 concepts rocks Juha Nieminen <nospam@thanks.invalid> - 2022-02-17 07:32 +0000
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-19 02:21 -0700
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-04-19 11:56 +0200
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 03:02 -0700
Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-12 00:01 +0000
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-14 23:55 -0800
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-07 18:31 +0100
Re: C++20 concepts rocks scott@slp53.sl.home (Scott Lurndal) - 2022-02-07 17:43 +0000
Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-06 14:25 -0500
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 02:01 -0800
Re: C++20 concepts rocks red floyd <no.spam.here@its.invalid> - 2022-02-06 19:37 -0800
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-07 10:18 +0100
Re: C++20 concepts rocks Paavo Helde <eesnimi@osa.pri.ee> - 2022-02-07 11:32 +0200
Re: C++20 concepts rocks red floyd <no.spam.here@its.invalid> - 2022-02-07 07:55 -0800
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 02:11 -0800
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-06 13:13 +0100
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 04:58 -0800
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-06 14:08 +0100
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-05 12:48 +0100
Re: C++20 concepts rocks Juha Nieminen <nospam@thanks.invalid> - 2022-02-04 20:15 +0000
Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-05 11:32 +0000
Re: C++20 concepts rocks Juha Nieminen <nospam@thanks.invalid> - 2022-02-06 08:28 +0000
Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-07 09:52 +0000
Re: C++20 concepts rocks Juha Nieminen <nospam@thanks.invalid> - 2022-02-08 07:05 +0000
Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-08 09:25 +0000
Re: C++20 concepts rocks Juha Nieminen <nospam@thanks.invalid> - 2022-02-08 10:09 +0000
Re: C++20 concepts rocks Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-02-04 12:10 -0800
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-05 13:41 +0100
Re: C++20 concepts rocks "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-02-05 19:28 -0800
A little benchmark: Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-05 13:22 +0100
A better benchmark Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-06 14:56 +0100
A improved routine Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-07 15:19 +0100
Re: A better benchmark Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-07 06:57 -0800
Re: A better benchmark Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-07 18:30 +0100
csiph-web