Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #80156 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2021-06-05 12:53 +0200 |
| Last post | 2021-06-07 14:52 +0000 |
| Articles | 20 on this page of 156 — 33 participants |
Back to article view | Back to comp.lang.c++
Is this really necessary Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-05 12:53 +0200
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 14:19 +0200
Re: Is this really necessary Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-05 14:27 +0200
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 14:33 +0200
Re: Is this really necessary Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-05 15:06 +0200
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 15:29 +0200
Re: Is this really necessary Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-05 17:38 +0200
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 17:51 +0200
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-05 11:56 -0400
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-05 19:08 -0400
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-06 11:24 +0200
Re: Is this really necessary Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-06-06 10:33 +0100
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-06 07:56 -0400
Re: Is this really necessary Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-06-06 15:00 +0100
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 16:20 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-07 00:44 -0700
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-07 12:13 -0700
Re: Is this really necessary Bo Persson <bo@bo-persson.se> - 2021-06-07 21:58 +0200
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 10:25 -0700
Re: Is this really necessary Bo Persson <bo@bo-persson.se> - 2021-08-07 21:21 +0200
Re: Is this really necessary Öö Tiib <ootiib@hot.ee> - 2021-06-05 06:34 -0700
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-05 20:03 -0400
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 12:59 -0700
Re: Is this really necessary MrSpud_85yGi2@1ahbfz.gov - 2021-08-08 09:18 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-08 09:23 -0400
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-08 15:04 +0000
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-08-08 13:14 -0400
Re: Is this really necessary MrSpud_1dgrmf@dx58865qyrdw30lqllb.info - 2021-08-09 08:21 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-09 08:53 +0000
Re: Is this really necessary "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-08-09 19:53 +0200
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-10 05:22 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 14:54 +0000
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 11:41 -0700
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-11 05:39 +0000
Re: Is this really necessary Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-08-08 20:01 +0100
Re: Is this really necessary MrSpud_ifhov@nldls6_1kg3nl2qnwv.biz - 2021-08-09 08:19 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-09 08:55 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-09 12:16 -0400
Re: Is this really necessary MrSpud_HG@_0b772d8ha3yjo0xb.edu - 2021-08-09 16:23 +0000
Re: Is this really necessary Vir Campestris <vir.campestris@invalid.invalid> - 2021-08-09 21:50 +0100
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-08-09 20:57 -0400
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 01:12 +0000
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-08-09 21:21 -0400
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-10 07:13 -0700
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-10 05:29 +0000
Re: Is this really necessary MrSpud_12tus_Atff@bya886olr5o8dhu9.ac.uk - 2021-08-10 07:28 +0000
Re: Is this really necessary Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-08-10 15:34 +0100
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 14:59 +0000
Re: Is this really necessary MrSpud_wPgnov999o@vv7a6.tv - 2021-08-10 15:54 +0000
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 11:29 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-11 08:45 +0000
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-11 07:05 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-11 14:18 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 14:57 +0000
Re: Is this really necessary MrSpud_pb9bpp7Ej@6urvt16b9fax.gov.uk - 2021-08-10 07:23 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 15:02 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-10 06:11 -0700
Re: Is this really necessary Bo Persson <bo@bo-persson.se> - 2021-08-10 16:13 +0200
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-11 12:40 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-12 08:20 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-12 03:50 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-12 14:58 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-12 08:29 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-12 15:39 +0000
Re: Is this really necessary Paavo Helde <myfirstname@osa.pri.ee> - 2021-08-12 20:07 +0300
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-13 07:16 +0000
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-13 09:26 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-13 10:30 -0400
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-13 14:58 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-14 08:07 +0000
Re: Is this really necessary "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-08-14 10:40 -0700
Re: Is this really necessary "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-08-14 10:38 -0700
Re: Is this really necessary "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-08-13 15:30 +0200
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-13 11:18 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-14 03:20 -0700
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-14 13:24 -0700
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-14 20:33 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-15 00:40 -0400
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-15 07:02 -0700
Re: Is this really necessary "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-08-15 21:19 +0200
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-08-15 15:42 -0400
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-21 12:38 -0700
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-14 08:13 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-14 02:58 -0700
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-13 14:32 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-14 02:28 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-14 03:00 -0700
Re: Is this really necessary Bart <bc@freeuk.com> - 2021-08-14 14:03 +0100
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-14 15:06 +0000
Re: Is this really necessary "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-08-12 12:06 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-13 09:19 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-13 14:35 +0000
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-13 14:58 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 15:03 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-11 12:54 -0700
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 20:20 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-12 03:42 -0700
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-11 05:45 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-11 05:26 -0700
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 14:06 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 14:01 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-09 23:20 -0400
Re: Is this really necessary MrSpud_m7k7yilq_8@u6w.biz - 2021-08-10 07:26 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-10 07:51 +0000
Re: Is this really necessary MrSpud_ggBp1lq0@lxz.tv - 2021-08-10 07:59 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-10 12:24 +0000
Re: Is this really necessary MrSpud_u7lm@bxuc3wy1g3cxiqu5j2x1_7iu.com - 2021-08-10 15:51 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-11 05:47 +0000
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-11 08:46 +0000
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-08-10 11:20 +0200
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-10 10:27 -0400
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-08-10 17:44 +0200
Re: Is this really necessary MrSpud_885p_dugji@l6zhsgj_v6t3dbj.tv - 2021-08-10 15:50 +0000
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-08-11 08:31 +0200
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-10 10:27 -0400
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 11:27 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-11 08:44 +0000
Re: Is this really necessary Paavo Helde <myfirstname@osa.pri.ee> - 2021-08-11 16:05 +0300
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-10 06:41 -0700
Re: Is this really necessary Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-06 18:48 +0300
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-06 14:26 -0400
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 16:10 -0700
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-06 21:30 -0400
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 18:49 -0700
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 18:51 -0700
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-06 22:57 -0400
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-07 09:43 -0700
Re: Is this really necessary Öö Tiib <ootiib@hot.ee> - 2021-06-07 09:51 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 10:22 -0700
Re: Is this really necessary "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-06-07 10:13 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 10:22 -0700
Re: Is this really necessary "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-08-07 12:40 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 12:54 -0700
Re: Is this really necessary Öö Tiib <ootiib@hot.ee> - 2021-06-06 23:17 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-07 09:19 -0700
Re: Is this really necessary Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-07 21:58 +0300
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-10 11:29 -0700
Re: Is this really necessary Öö Tiib <ootiib@hot.ee> - 2021-06-05 05:38 -0700
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 15:41 +0200
Re: Is this really necessary Öö Tiib <ootiib@hot.ee> - 2021-06-05 08:18 -0700
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-05 11:58 -0400
Re: Is this really necessary MrSpook_rs7x@4hhtozmpj299zx.tv - 2021-06-05 16:00 +0000
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 18:16 +0200
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-06 17:34 +0200
Re: Is this really necessary MrSpook_ie@q67rq6_2ly9ut44j.org - 2021-06-06 13:55 +0000
Re: Is this really necessary Bo Persson <bo@bo-persson.se> - 2021-06-05 19:50 +0200
Re: Is this really necessary MrSpook_zn7@4tzq7j92.gov - 2021-06-06 13:59 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-05 17:42 -0400
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-06 11:05 +0200
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-07 00:27 -0700
Re: Is this really necessary Vir Campestris <vir.campestris@invalid.invalid> - 2021-06-06 21:27 +0100
Re: Is this really necessary "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-06-07 00:22 +0200
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-06-07 14:53 +0000
Re: Is this really necessary Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-07 18:02 +0200
Re: Is this really necessary Vir Campestris <vir.campestris@invalid.invalid> - 2021-06-16 21:38 +0100
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-06-07 14:52 +0000
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-06-05 12:53 +0200 |
| Subject | Is this really necessary |
| Message-ID | <s9fl3f$ha7$1@dont-email.me> |
Consider the following code:
size_t s( int *begin, int *end )
{
return (end - begin) * sizeof(int);
}
This is MSVC's disassembly:
sub rdx, rcx
and rdx, -4
mov rax, rdx
ret 0
This is gcc's disassembly:
movq %rsi, %rax
subq %rdi, %rax
ret
It the masking really necessary or just an optimizer weakness;
it seems to me MSVC sees that two bits are shifted out and "in"
and replaces this with a mask.
I think that the language-standard assumes equally aligned data
among same types for the above code and gcc is corcect, but I'm
not sure.
[toc] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-05 14:19 +0200 |
| Message-ID | <s9fq58$3qr$1@dont-email.me> |
| In reply to | #80156 |
On 05/06/2021 12:53, Bonita Montero wrote:
> Consider the following code:
>
>
> size_t s( int *begin, int *end )
> {
> return (end - begin) * sizeof(int);
> }
>
> This is MSVC's disassembly:
>
> sub rdx, rcx
> and rdx, -4
> mov rax, rdx
> ret 0
>
> This is gcc's disassembly:
>
> movq %rsi, %rax
> subq %rdi, %rax
> ret
>
> It the masking really necessary or just an optimizer weakness;
> it seems to me MSVC sees that two bits are shifted out and "in"
> and replaces this with a mask.
> I think that the language-standard assumes equally aligned data
> among same types for the above code and gcc is corcect, but I'm
> not sure.
>
I can't help thinking that putting a non-aligned value into an int
pointer is undefined behaviour - but I can't find a reference to that in
the C standards (and I don't know the C++ standards well enough to look
there). However, when you subtract two pointers, the behaviour is only
defined if they both point to elements inside the same array (or one
past the end). It doesn't matter how they are aligned, as the offset
from the standard "int" alignment will be the same for both pointers.
(This applies also to 8-bit systems where you might have 16-bit int but
8-bit alignment for int.) Thus gcc's code is fine.
MSVC has a tradition of being more conservative in its optimisations,
while gcc has a tradition of expecting people to write valid code and
optimise on the assumption that undefined behaviour does not occur.
This is, I think, because MSDOS and Windows programmers have a tradition
of assuming their code runs on one platform and one compiler, and "it
worked when I tested it" means "it is correct". (Your own misstatements
about undefined behaviour have demonstrated that.) gcc users are more
likely to understand that their code could be used on different
platforms and different processors, and pay a bit more attention to the
rules of the language.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-06-05 14:27 +0200 |
| Message-ID | <s9fqkc$c14$1@dont-email.me> |
| In reply to | #80157 |
> I can't help thinking that putting a non-aligned value into an int > pointer is undefined behaviour - but I can't find a reference to that > in the C standards (and I don't know the C++ standards well enough to > look there). However, when you subtract two pointers, the behaviour > is only defined if they both point to elements inside the same array > (or one past the end). ... And in a struct with two ints ? > MSVC has a tradition of being more conservative in its optimisations, > ... MSVC is not more conservative, but more stupid because it lacks many safe optimizations.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-05 14:33 +0200 |
| Message-ID | <s9fqvh$ich$1@dont-email.me> |
| In reply to | #80158 |
On 05/06/2021 14:27, Bonita Montero wrote: >> I can't help thinking that putting a non-aligned value into an int >> pointer is undefined behaviour - but I can't find a reference to that >> in the C standards (and I don't know the C++ standards well enough to >> look there). However, when you subtract two pointers, the behaviour >> is only defined if they both point to elements inside the same array >> (or one past the end). ... > > And in a struct with two ints ? > No. Subtraction of pointers is defined as the difference in their indexes within a single array. >> MSVC has a tradition of being more conservative in its optimisations, >> ... > > MSVC is not more conservative, but more stupid because it lacks many > safe optimizations. I was not being judgemental about what is a good or bad implementation. I personally prefer gcc's philosophy, but I know other people have preferences that are somewhere in between. (You have posted in the past about your beliefs about how compilers handle some kinds of undefined behaviour - and shown why there is a market for such conservative compilers.)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-06-05 15:06 +0200 |
| Message-ID | <s9fssi$i74$1@dont-email.me> |
| In reply to | #80159 |
> No. Subtraction of pointers is defined as the difference in their > indexes within a single array. That coudn't be true because you can cast any pointer-pair to char *, subtract them and use the difference for memcpy().
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-05 15:29 +0200 |
| Message-ID | <s9fu8h$c2j$1@dont-email.me> |
| In reply to | #80161 |
On 05/06/2021 15:06, Bonita Montero wrote: >> No. Subtraction of pointers is defined as the difference in their >> indexes within a single array. > > That coudn't be true because you can cast any pointer-pair > to char *, subtract them and use the difference for memcpy(). > Look it up. You can do lots of things in C and C++ that are syntactically correct, but might have undefined behaviour.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-06-05 17:38 +0200 |
| Message-ID | <s9g5pq$jqg$1@dont-email.me> |
| In reply to | #80162 |
>> That coudn't be true because you can cast any pointer-pair >> to char *, subtract them and use the difference for memcpy(). > Look it up. > You can do lots of things in C and C++ that are syntactically correct, > but might have undefined behaviour. I don't believe that memcpy()ing this way is UB.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-05 17:51 +0200 |
| Message-ID | <s9g6ib$2a6$1@dont-email.me> |
| In reply to | #80166 |
On 05/06/2021 17:38, Bonita Montero wrote: >>> That coudn't be true because you can cast any pointer-pair >>> to char *, subtract them and use the difference for memcpy(). > >> Look it up. >> You can do lots of things in C and C++ that are syntactically correct, >> but might have undefined behaviour. > > I don't believe that memcpy()ing this way is UB. > Can you give an example of what you are thinking about?
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-06-05 11:56 -0400 |
| Message-ID | <59NuI.72058$Mz2.6384@fx14.iad> |
| In reply to | #80166 |
On 6/5/21 11:38 AM, Bonita Montero wrote: >>> That coudn't be true because you can cast any pointer-pair >>> to char *, subtract them and use the difference for memcpy(). > >> Look it up. >> You can do lots of things in C and C++ that are syntactically correct, >> but might have undefined behaviour. > > I don't believe that memcpy()ing this way is UB. > The memcpy might not be, but subtracting two pointers that don't point to elements of the same array is.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-06-05 19:08 -0400 |
| Message-ID | <s9h061$u9d$1@dont-email.me> |
| In reply to | #80162 |
Apologies to David, who has already received two versions of this message as e-mail, because I keep hitting the Thunderbird "Reply" button instead of their new "Followup" button. On 6/5/21 9:29 AM, David Brown wrote: > On 05/06/2021 15:06, Bonita Montero wrote: >>> No. Subtraction of pointers is defined as the difference in their >>> indexes within a single array. >> >> That coudn't be true because you can cast any pointer-pair >> to char *, subtract them and use the difference for memcpy(). >> > > Look it up. That works in C because every C object can be accessed as an array of char. C++ allows more complicated possibilities, including objects that are not contiguous. But it works in C++ if the relevant objects are required to be contiguous. If two such objects are both sub-objects of the same larger object, the difference between those pointers satisfies that requirement, otherwise the subtraction is undefined.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-06 11:24 +0200 |
| Message-ID | <s9i47l$mrg$1@dont-email.me> |
| In reply to | #80174 |
On 06/06/2021 01:08, James Kuyper wrote:
> Apologies to David, who has already received two versions of this
> message as e-mail, because I keep hitting the Thunderbird "Reply" button
> instead of their new "Followup" button.
No problem. It makes me feel special :-)
>
> On 6/5/21 9:29 AM, David Brown wrote:
>> On 05/06/2021 15:06, Bonita Montero wrote:
>>>> No. Subtraction of pointers is defined as the difference in their
>>>> indexes within a single array.
>>>
>>> That coudn't be true because you can cast any pointer-pair
>>> to char *, subtract them and use the difference for memcpy().
>>>
>>
>> Look it up.
>
>
> That works in C because every C object can be accessed as an array of
> char. C++ allows more complicated possibilities, including objects that
> are not contiguous. But it works in C++ if the relevant objects are
> required to be contiguous. If two such objects are both sub-objects of
> the same larger object, the difference between those pointers satisfies
> that requirement, otherwise the subtraction is undefined.
>
When you do that, however, you are not subtracting the original pointers
- you are subtracting two char* pointers. And that subtraction works as
the difference of their indexes into an array (of char type).
So if you have:
struct A {
int x;
iny y;
};
A a;
the expression "&a.x - &a.y" is not defined by the C or C++ standards.
You have to cast the pointers to character type, and then you are
subtracting two pointers that are part of the same array, rather than
subtracting pointers to two ints in a structure.
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2021-06-06 10:33 +0100 |
| Message-ID | <20210606103347.06e3663e23b85fa28ff9cd39@cvine--nospam--.freeserve.co.uk> |
| In reply to | #80174 |
On Sat, 5 Jun 2021 19:08:49 -0400 James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > Apologies to David, who has already received two versions of this > message as e-mail, because I keep hitting the Thunderbird "Reply" button > instead of their new "Followup" button. > > On 6/5/21 9:29 AM, David Brown wrote: > > On 05/06/2021 15:06, Bonita Montero wrote: > >>> No. Subtraction of pointers is defined as the difference in their > >>> indexes within a single array. > >> > >> That coudn't be true because you can cast any pointer-pair > >> to char *, subtract them and use the difference for memcpy(). > >> > > > > Look it up. > > That works in C because every C object can be accessed as an array of > char. C++ allows more complicated possibilities, including objects that > are not contiguous. But it works in C++ if the relevant objects are > required to be contiguous. If two such objects are both sub-objects of > the same larger object, the difference between those pointers satisfies > that requirement, otherwise the subtraction is undefined. Assuming C++20, on my (possibly faulty) reading you could _not_ access any given object as an array of char, but you could access it as an array of unsigned char or std::byte. This is because you can construct any object in an array of unsigned char or of std::byte, so that even where some other storage for a particular object has in fact been provided, such an array will implicitly arise in consequence of the carrying out of any pointer arithmetic which prods around in the object's internals. So although the strict aliasing rule is not offended by the use of char* for this purpose, I suspect the rules on pointer arithmetic are.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-06-06 07:56 -0400 |
| Message-ID | <rJ2vI.289637$N_4.135388@fx36.iad> |
| In reply to | #80182 |
On 6/6/21 5:33 AM, Chris Vine wrote: > On Sat, 5 Jun 2021 19:08:49 -0400 > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >> Apologies to David, who has already received two versions of this >> message as e-mail, because I keep hitting the Thunderbird "Reply" button >> instead of their new "Followup" button. >> >> On 6/5/21 9:29 AM, David Brown wrote: >>> On 05/06/2021 15:06, Bonita Montero wrote: >>>>> No. Subtraction of pointers is defined as the difference in their >>>>> indexes within a single array. >>>> >>>> That coudn't be true because you can cast any pointer-pair >>>> to char *, subtract them and use the difference for memcpy(). >>>> >>> >>> Look it up. >> >> That works in C because every C object can be accessed as an array of >> char. C++ allows more complicated possibilities, including objects that >> are not contiguous. But it works in C++ if the relevant objects are >> required to be contiguous. If two such objects are both sub-objects of >> the same larger object, the difference between those pointers satisfies >> that requirement, otherwise the subtraction is undefined. > > Assuming C++20, on my (possibly faulty) reading you could _not_ access > any given object as an array of char, but you could access it as an > array of unsigned char or std::byte. This is because you can construct > any object in an array of unsigned char or of std::byte, so that even > where some other storage for a particular object has in fact been > provided, such an array will implicitly arise in consequence of the > carrying out of any pointer arithmetic which prods around in the > object's internals. > > So although the strict aliasing rule is not offended by the use of > char* for this purpose, I suspect the rules on pointer arithmetic are. > I haven't poured over the standard recently, but my memory was that the type family char / signed char / unsigned char all had this property, but if you actually accessed the values, signed char (and char is signed) had the possibility of a trap value (-0). unsigned char had the natural property that its values were precisely defined by the standard, but any character type could be used, if only because of ancient code that used char for this purpose.
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2021-06-06 15:00 +0100 |
| Message-ID | <20210606150001.874efb642fbf55d927add18f@cvine--nospam--.freeserve.co.uk> |
| In reply to | #80185 |
On Sun, 6 Jun 2021 07:56:07 -0400 Richard Damon <Richard@Damon-Family.org> wrote: > On 6/6/21 5:33 AM, Chris Vine wrote: > > On Sat, 5 Jun 2021 19:08:49 -0400 > > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: [snip] > >> That works in C because every C object can be accessed as an array of > >> char. C++ allows more complicated possibilities, including objects that > >> are not contiguous. But it works in C++ if the relevant objects are > >> required to be contiguous. If two such objects are both sub-objects of > >> the same larger object, the difference between those pointers satisfies > >> that requirement, otherwise the subtraction is undefined. > > > > Assuming C++20, on my (possibly faulty) reading you could _not_ access > > any given object as an array of char, but you could access it as an > > array of unsigned char or std::byte. This is because you can construct > > any object in an array of unsigned char or of std::byte, so that even > > where some other storage for a particular object has in fact been > > provided, such an array will implicitly arise in consequence of the > > carrying out of any pointer arithmetic which prods around in the > > object's internals. > > > > So although the strict aliasing rule is not offended by the use of > > char* for this purpose, I suspect the rules on pointer arithmetic are. > > > > I haven't poured over the standard recently, but my memory was that the > type family char / signed char / unsigned char all had this property, > but if you actually accessed the values, signed char (and char is > signed) had the possibility of a trap value (-0). > > unsigned char had the natural property that its values were precisely > defined by the standard, but any character type could be used, if only > because of ancient code that used char for this purpose. I wasn't thinking of the point concerning the assigning of indeterminate values into narrow character types (permitted for unsigned but not for signed), although I imagine that may come into play. The issue I was referring was that (i) new objects can be constructed (either by placement new or as implicit-lifetime types) in an array of unsigned char or array of std::byte if properly aligned ([intro.object]/3 and /4), (ii) iterating by pointer arithmetic can only be carried out in respect of arrays ([expr.add]/4), (iii) in C++20 arrays (but not necessarily their elements) are implicit-lifetime types, (iv) implicit-lifetime types arise spontaneously where necessary to obtain defined behaviour, and (v) accordingly you can iterate over an object as if it were stored in an array of unsigned char or std::byte even if it isn't[1]. I imagine that in practice you can construct an object in an array of char on any compilers in widespread use but it is not formally supported by the standard. I don't know why there is that restriction. It cannot be entirely down to indeterminate values, because you can put an indeterminate value in a char object if the char type is in fact unsigned, but that is not true of constructing an object in an array of char using placement new. This is as I understand it. But my understanding may not be complete. [1]: It is this that enables you to implement your own version of std::memcpy() in standard C++20. That was impossible in C++17.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-06-06 16:20 -0700 |
| Message-ID | <87mts2vavc.fsf@nosuchdomain.example.com> |
| In reply to | #80185 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 6/6/21 5:33 AM, Chris Vine wrote:
>> On Sat, 5 Jun 2021 19:08:49 -0400
>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>> Apologies to David, who has already received two versions of this
>>> message as e-mail, because I keep hitting the Thunderbird "Reply" button
>>> instead of their new "Followup" button.
>>>
>>> On 6/5/21 9:29 AM, David Brown wrote:
>>>> On 05/06/2021 15:06, Bonita Montero wrote:
>>>>>> No. Subtraction of pointers is defined as the difference in their
>>>>>> indexes within a single array.
>>>>>
>>>>> That coudn't be true because you can cast any pointer-pair
>>>>> to char *, subtract them and use the difference for memcpy().
>>>>>
>>>>
>>>> Look it up.
>>>
>>> That works in C because every C object can be accessed as an array of
>>> char. C++ allows more complicated possibilities, including objects that
>>> are not contiguous. But it works in C++ if the relevant objects are
>>> required to be contiguous. If two such objects are both sub-objects of
>>> the same larger object, the difference between those pointers satisfies
>>> that requirement, otherwise the subtraction is undefined.
>>
>> Assuming C++20, on my (possibly faulty) reading you could _not_ access
>> any given object as an array of char, but you could access it as an
>> array of unsigned char or std::byte. This is because you can construct
>> any object in an array of unsigned char or of std::byte, so that even
>> where some other storage for a particular object has in fact been
>> provided, such an array will implicitly arise in consequence of the
>> carrying out of any pointer arithmetic which prods around in the
>> object's internals.
>>
>> So although the strict aliasing rule is not offended by the use of
>> char* for this purpose, I suspect the rules on pointer arithmetic are.
>
> I haven't poured over the standard recently, but my memory was that the
> type family char / signed char / unsigned char all had this property,
> but if you actually accessed the values, signed char (and char is
> signed) had the possibility of a trap value (-0).
I think you meant "(and char *if* signed)".
As of C++17, signed types including signed char can use two's
complement, ones' complement, or signed magnitude, but:
For unsigned narrow character types, each possible bit pattern of
the value representation represents a distinct number. These
requirements do not hold for other types.
which means that plain char and signed char have no trap representations
and no padding bits.
Drafts of C++20 permit only two's complement for signed integer types.
(You're unlikely to find a pre-C++20 implementation that doesn't already
meet that requirement.)
I haven't looked into what the standard says about aliasing arbitrary
objects with arrays of signed char.
> unsigned char had the natural property that its values were precisely
> defined by the standard, but any character type could be used, if only
> because of ancient code that used char for this purpose.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-06-07 00:44 -0700 |
| Message-ID | <86y2bmce64.fsf@linuxsc.com> |
| In reply to | #80203 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> I haven't poured over the standard recently, but my memory was that
>> the type family char / signed char / unsigned char all had this
>> property, but if you actually accessed the values, signed char (and
>> char is signed) had the possibility of a trap value (-0).
>
> I think you meant "(and char *if* signed)".
>
> As of C++17, signed types including signed char can use two's
> complement, ones' complement, or signed magnitude, but:
> For unsigned narrow character types, each possible bit pattern of
> the value representation represents a distinct number. These
> requirements do not hold for other types.
> which means that plain char and signed char have no trap representations
> and no padding bits.
The passage quoted is about _un_signed narrow character types.
It doesn't apply to signed char or to plain char of the signed
variety.
An earlier sentence (in the C++17 standard) says this
For narrow character types, all bits of the object
representation participate in the value representation.
which does rule out padding bits, but it still admits the
possibility of there being a trap representation.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-06-07 12:13 -0700 |
| Message-ID | <87y2blqyhj.fsf@nosuchdomain.example.com> |
| In reply to | #80212 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>> I haven't poured over the standard recently, but my memory was that
>>> the type family char / signed char / unsigned char all had this
>>> property, but if you actually accessed the values, signed char (and
>>> char is signed) had the possibility of a trap value (-0).
>>
>> I think you meant "(and char *if* signed)".
>>
>> As of C++17, signed types including signed char can use two's
>> complement, ones' complement, or signed magnitude, but:
>> For unsigned narrow character types, each possible bit pattern of
>> the value representation represents a distinct number. These
>> requirements do not hold for other types.
>> which means that plain char and signed char have no trap representations
>> and no padding bits.
>
> The passage quoted is about _un_signed narrow character types.
> It doesn't apply to signed char or to plain char of the signed
> variety.
>
> An earlier sentence (in the C++17 standard) says this
>
> For narrow character types, all bits of the object
> representation participate in the value representation.
>
> which does rule out padding bits, but it still admits the
> possibility of there being a trap representation.
True, but C++17 has this rather odd wording later in the same paragraph:
For each value i of type unsigned char in the range 0 to 255
inclusive, there exists a value j of type char such that the result
of an integral conversion (7.8) from i to char is j, and the result
of an integral conversion from j to unsigned char is i.
I believe this implies that there must be 256 distinct values of type
signed char (and plain char if it's signed), disallowing treating -0 or
-128 as a trap representation.
What's odd about it is that it uses the value 255, so it wouldn't apply
that same requirement if CHAR_BIT > 8.
C++20 (at least in the draft I have) requires 2**CHAR_BIT distinct
values for the narrow character types (char, unsigned char, signed char,
and char8_t).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2021-06-07 21:58 +0200 |
| Message-ID | <ii7c3lFbug3U1@mid.individual.net> |
| In reply to | #80221 |
On 2021-06-07 at 21:13, Keith Thompson wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>> Richard Damon <Richard@Damon-Family.org> writes: >>>> I haven't poured over the standard recently, but my memory was that >>>> the type family char / signed char / unsigned char all had this >>>> property, but if you actually accessed the values, signed char (and >>>> char is signed) had the possibility of a trap value (-0). >>> >>> I think you meant "(and char *if* signed)". >>> >>> As of C++17, signed types including signed char can use two's >>> complement, ones' complement, or signed magnitude, but: >>> For unsigned narrow character types, each possible bit pattern of >>> the value representation represents a distinct number. These >>> requirements do not hold for other types. >>> which means that plain char and signed char have no trap representations >>> and no padding bits. >> >> The passage quoted is about _un_signed narrow character types. >> It doesn't apply to signed char or to plain char of the signed >> variety. >> >> An earlier sentence (in the C++17 standard) says this >> >> For narrow character types, all bits of the object >> representation participate in the value representation. >> >> which does rule out padding bits, but it still admits the >> possibility of there being a trap representation. > > True, but C++17 has this rather odd wording later in the same paragraph: > > For each value i of type unsigned char in the range 0 to 255 > inclusive, there exists a value j of type char such that the result > of an integral conversion (7.8) from i to char is j, and the result > of an integral conversion from j to unsigned char is i. > > I believe this implies that there must be 256 distinct values of type > signed char (and plain char if it's signed), disallowing treating -0 or > -128 as a trap representation. > > What's odd about it is that it uses the value 255, so it wouldn't apply > that same requirement if CHAR_BIT > 8. > Not so odd really. On the CHAR_BIT == 9 system that I once used (Univac, and for C not C++), the char size was *not* chosen to get additional character values, but because the hardware had part-word operations that let you extract any quarter of the 36-bit word. That made using four 9-bit characters per word a lot more efficient than four-and-a-half 8-bit characters.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-08-07 10:25 -0700 |
| Message-ID | <86tuk12mlb.fsf@linuxsc.com> |
| In reply to | #80221 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>> Richard Damon <Richard@Damon-Family.org> writes: >>> >>>> I haven't poured over the standard recently, but my memory was that >>>> the type family char / signed char / unsigned char all had this >>>> property, but if you actually accessed the values, signed char (and >>>> char is signed) had the possibility of a trap value (-0). >>> >>> I think you meant "(and char *if* signed)". >>> >>> As of C++17, signed types including signed char can use two's >>> complement, ones' complement, or signed magnitude, but: >>> For unsigned narrow character types, each possible bit pattern of >>> the value representation represents a distinct number. These >>> requirements do not hold for other types. >>> which means that plain char and signed char have no trap representations >>> and no padding bits. >> >> The passage quoted is about _un_signed narrow character types. >> It doesn't apply to signed char or to plain char of the signed >> variety. >> >> An earlier sentence (in the C++17 standard) says this >> >> For narrow character types, all bits of the object >> representation participate in the value representation. >> >> which does rule out padding bits, but it still admits the >> possibility of there being a trap representation. > > True, but C++17 has this rather odd wording later in the same paragraph: > > For each value i of type unsigned char in the range 0 to 255 > inclusive, there exists a value j of type char such that the result > of an integral conversion (7.8) from i to char is j, and the result > of an integral conversion from j to unsigned char is i. > > I believe this implies that there must be 256 distinct values of type > signed char (and plain char if it's signed), disallowing treating -0 or > -128 as a trap representation. > > What's odd about it is that it uses the value 255, so it wouldn't apply > that same requirement if CHAR_BIT > 8. > > C++20 (at least in the draft I have) requires 2**CHAR_BIT distinct > values for the narrow character types (char, unsigned char, signed char, > and char8_t). Ahhh, as usual for the C++ standard. Yes repeat no. Thank you for the additional information.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2021-08-07 21:21 +0200 |
| Message-ID | <in84pdFki27U1@mid.individual.net> |
| In reply to | #80787 |
On 2021-08-07 at 19:25, Tim Rentsch wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>> >>>> Richard Damon <Richard@Damon-Family.org> writes: >>>> >>>>> I haven't poured over the standard recently, but my memory was that >>>>> the type family char / signed char / unsigned char all had this >>>>> property, but if you actually accessed the values, signed char (and >>>>> char is signed) had the possibility of a trap value (-0). >>>> >>>> I think you meant "(and char *if* signed)". >>>> >>>> As of C++17, signed types including signed char can use two's >>>> complement, ones' complement, or signed magnitude, but: >>>> For unsigned narrow character types, each possible bit pattern of >>>> the value representation represents a distinct number. These >>>> requirements do not hold for other types. >>>> which means that plain char and signed char have no trap representations >>>> and no padding bits. >>> >>> The passage quoted is about _un_signed narrow character types. >>> It doesn't apply to signed char or to plain char of the signed >>> variety. >>> >>> An earlier sentence (in the C++17 standard) says this >>> >>> For narrow character types, all bits of the object >>> representation participate in the value representation. >>> >>> which does rule out padding bits, but it still admits the >>> possibility of there being a trap representation. >> >> True, but C++17 has this rather odd wording later in the same paragraph: >> >> For each value i of type unsigned char in the range 0 to 255 >> inclusive, there exists a value j of type char such that the result >> of an integral conversion (7.8) from i to char is j, and the result >> of an integral conversion from j to unsigned char is i. >> >> I believe this implies that there must be 256 distinct values of type >> signed char (and plain char if it's signed), disallowing treating -0 or >> -128 as a trap representation. >> >> What's odd about it is that it uses the value 255, so it wouldn't apply >> that same requirement if CHAR_BIT > 8. >> >> C++20 (at least in the draft I have) requires 2**CHAR_BIT distinct >> values for the narrow character types (char, unsigned char, signed char, >> and char8_t). > > Ahhh, as usual for the C++ standard. Yes repeat no. > > Thank you for the additional information. > Things change. :-) One difference is that C++20 requires two's complement (in another section), so it can know what value a bit pattern represents.
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c++
csiph-web