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 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-06-05 06:34 -0700 |
| Message-ID | <52a9a4de-790b-4f00-852f-8c74ff457af0n@googlegroups.com> |
| In reply to | #80161 |
On Saturday, 5 June 2021 at 16:06:41 UTC+3, 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(). So it couldn't be true that standard specifies it so: | If the expressions P and Q point to, respectively, elements | x[i] and x[j] of the same array object x, the expression P - Q has | the value i − j; otherwise, the behavior is undefined. I don't understand what supposedly stops it?
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-06-05 20:03 -0400 |
| Message-ID | <lhUuI.12113$341.6150@fx42.iad> |
| In reply to | #80161 |
On 6/5/21 9:06 AM, 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(). > Actually it is true. Char (and its relatives) do have a few special cases, as Any pointer is allowed to be converted into a pointer to char and back and still be used. Also I believe that any object can be treated as an array of char. So you can do the conversion to char and subtract for two pointers in the same object. It is still not defined if the pointers are to two separate objects. For machines with segmented memory, this can be an issue.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-08-07 12:59 -0700 |
| Message-ID | <86im0h2fi1.fsf@linuxsc.com> |
| In reply to | #80175 |
Richard Damon <Richard@Damon-Family.org> writes: > On 6/5/21 9:06 AM, 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(). > > Actually it is true. Char (and its relatives) do have a few special > cases, as Any pointer is allowed to be converted into a pointer to char > and back and still be used. Also I believe that any object can be > treated as an array of char. So you can do the conversion to char and > subtract for two pointers in the same object. In C the difference of two pointers might not work, in particular if the result doesn't fit in ptrdiff_t. I don't know if that rule is different in C++.
[toc] | [prev] | [next] | [standalone]
| From | MrSpud_85yGi2@1ahbfz.gov |
|---|---|
| Date | 2021-08-08 09:18 +0000 |
| Message-ID | <seo7hm$1b7s$1@gioia.aioe.org> |
| In reply to | #80791 |
On Sat, 07 Aug 2021 12:59:02 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >Richard Damon <Richard@Damon-Family.org> writes: > >> On 6/5/21 9:06 AM, 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(). >> >> Actually it is true. Char (and its relatives) do have a few special >> cases, as Any pointer is allowed to be converted into a pointer to char >> and back and still be used. Also I believe that any object can be >> treated as an array of char. So you can do the conversion to char and >> subtract for two pointers in the same object. > >In C the difference of two pointers might not work, in particular >if the result doesn't fit in ptrdiff_t. I don't know if that >rule is different in C++. Huh? Any type that can be used to hold a pointer address can also be used to hold the difference of 2 pointers. If the difference will be negative then simply invert it.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-08-08 09:23 -0400 |
| Message-ID | <seolt2$nuj$1@dont-email.me> |
| In reply to | #80795 |
On 8/8/21 5:18 AM, MrSpud_85yGi2@1ahbfz.gov wrote: > On Sat, 07 Aug 2021 12:59:02 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> Richard Damon <Richard@Damon-Family.org> writes: ... >>> Actually it is true. Char (and its relatives) do have a few special >>> cases, as Any pointer is allowed to be converted into a pointer to char >>> and back and still be used. Also I believe that any object can be >>> treated as an array of char. So you can do the conversion to char and >>> subtract for two pointers in the same object. >> >> In C the difference of two pointers might not work, in particular >> if the result doesn't fit in ptrdiff_t. I don't know if that >> rule is different in C++. > > Huh? Any type that can be used to hold a pointer address can also be used > to hold the difference of 2 pointers. If the difference will be negative then > simply invert it. "When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object; the result is the difference of the subscripts of the two array elements. The size of the result is implementation-defined, and its type (a signed integer type) is ptrdiff_t defined in the <stddef.h> header. If the result is not representable in an object of that type, the behavior is undefined." (C2011 6.5.6p9). If the result of a pointer subtraction were always guaranteed to be representable in ptrdiff_t, then that last sentence would be vacuous. In the C standard, 7.20.1.4p1 describes intptr_t and uintptr_t, and says "These types are optional". A fully conforming implementation may have pointers that are too big to be representable using any supported integer type, and the same is true of pointer differences.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-08-08 15:04 +0000 |
| Message-ID | <seorqi$8p9$1@gioia.aioe.org> |
| In reply to | #80796 |
James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > On 8/8/21 5:18 AM, MrSpud_85yGi2@1ahbfz.gov wrote: >> On Sat, 07 Aug 2021 12:59:02 -0700 >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> Richard Damon <Richard@Damon-Family.org> writes: > ... >>>> Actually it is true. Char (and its relatives) do have a few special >>>> cases, as Any pointer is allowed to be converted into a pointer to char >>>> and back and still be used. Also I believe that any object can be >>>> treated as an array of char. So you can do the conversion to char and >>>> subtract for two pointers in the same object. >>> >>> In C the difference of two pointers might not work, in particular >>> if the result doesn't fit in ptrdiff_t. I don't know if that >>> rule is different in C++. >> >> Huh? Any type that can be used to hold a pointer address can also be used >> to hold the difference of 2 pointers. If the difference will be negative then >> simply invert it. > > > "When two pointers are subtracted, both shall point to elements of the > same array object, or one past the last element of the array object; the > result is the difference of the subscripts of the two array elements. > The size of the result is implementation-defined, and its type (a signed > integer type) is ptrdiff_t defined in the <stddef.h> header. > If the result is not representable in an object of that type, the > behavior is undefined." (C2011 6.5.6p9). > > If the result of a pointer subtraction were always guaranteed to be > representable in ptrdiff_t, then that last sentence would be vacuous. > > In the C standard, 7.20.1.4p1 describes intptr_t and uintptr_t, and says > "These types are optional". A fully conforming implementation may have > pointers that are too big to be representable using any supported > integer type, and the same is true of pointer differences. Indeed. For example in x86 16-bit real mode (think MS-DOS) it may well be that a pointer is 32-bit (because it has to contain a segment and an offset) but ptrdiff_t may well be 16-bit, and the compiler may limit eg. arrays to 64 kilobytes (minus 1 byte) so that they will fit inside a segment. A difference between pointers will only give a valid (16-bit) result when they point to the same array (which would be within the same segment). Else you get garbage (if the two pointers are pointing to different segments).
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-08-08 13:14 -0400 |
| Message-ID | <WhUPI.1585$Aw7.830@fx15.iad> |
| In reply to | #80797 |
On 8/8/21 11:04 AM, Juha Nieminen wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >> On 8/8/21 5:18 AM, MrSpud_85yGi2@1ahbfz.gov wrote: >>> On Sat, 07 Aug 2021 12:59:02 -0700 >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>>> Richard Damon <Richard@Damon-Family.org> writes: >> ... >>>>> Actually it is true. Char (and its relatives) do have a few special >>>>> cases, as Any pointer is allowed to be converted into a pointer to char >>>>> and back and still be used. Also I believe that any object can be >>>>> treated as an array of char. So you can do the conversion to char and >>>>> subtract for two pointers in the same object. >>>> >>>> In C the difference of two pointers might not work, in particular >>>> if the result doesn't fit in ptrdiff_t. I don't know if that >>>> rule is different in C++. >>> >>> Huh? Any type that can be used to hold a pointer address can also be used >>> to hold the difference of 2 pointers. If the difference will be negative then >>> simply invert it. >> >> >> "When two pointers are subtracted, both shall point to elements of the >> same array object, or one past the last element of the array object; the >> result is the difference of the subscripts of the two array elements. >> The size of the result is implementation-defined, and its type (a signed >> integer type) is ptrdiff_t defined in the <stddef.h> header. >> If the result is not representable in an object of that type, the >> behavior is undefined." (C2011 6.5.6p9). >> >> If the result of a pointer subtraction were always guaranteed to be >> representable in ptrdiff_t, then that last sentence would be vacuous. >> >> In the C standard, 7.20.1.4p1 describes intptr_t and uintptr_t, and says >> "These types are optional". A fully conforming implementation may have >> pointers that are too big to be representable using any supported >> integer type, and the same is true of pointer differences. > > Indeed. For example in x86 16-bit real mode (think MS-DOS) it may > well be that a pointer is 32-bit (because it has to contain a > segment and an offset) but ptrdiff_t may well be 16-bit, and the > compiler may limit eg. arrays to 64 kilobytes (minus 1 byte) so > that they will fit inside a segment. > > A difference between pointers will only give a valid (16-bit) > result when they point to the same array (which would be within > the same segment). Else you get garbage (if the two pointers are > pointing to different segments). > And a key point is that typically ptrdiff_t will be of the sames size as size_t, only signed instead of unsigned. (This doesn't work if size_t is 16 bits, as ptrdiff_t needs to be at least 17-bits as I remember). This means that if size_t is 32 bits, and ptrdiff_t is also 32 bits, an array of char with size bigger than 0x80000000 can generate differences bigger than can be handled by ptrdiff_t.
[toc] | [prev] | [next] | [standalone]
| From | MrSpud_1dgrmf@dx58865qyrdw30lqllb.info |
|---|---|
| Date | 2021-08-09 08:21 +0000 |
| Message-ID | <seqohm$tct$1@gioia.aioe.org> |
| In reply to | #80797 |
On Sun, 8 Aug 2021 15:04:52 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >> On 8/8/21 5:18 AM, MrSpud_85yGi2@1ahbfz.gov wrote: >> In the C standard, 7.20.1.4p1 describes intptr_t and uintptr_t, and says >> "These types are optional". A fully conforming implementation may have >> pointers that are too big to be representable using any supported >> integer type, and the same is true of pointer differences. > >Indeed. For example in x86 16-bit real mode (think MS-DOS) it may >well be that a pointer is 32-bit (because it has to contain a >segment and an offset) but ptrdiff_t may well be 16-bit, and the >compiler may limit eg. arrays to 64 kilobytes (minus 1 byte) so >that they will fit inside a segment. > >A difference between pointers will only give a valid (16-bit) >result when they point to the same array (which would be within >the same segment). Else you get garbage (if the two pointers are >pointing to different segments). I was discussing from the POV of a proper OS, not some half baked monitor program from the 70s. However if you can't work out how to get a valid diff from the above then clearly your maths skills need some work.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-08-09 08:53 +0000 |
| Message-ID | <seqqeb$1nrs$1@gioia.aioe.org> |
| In reply to | #80803 |
MrSpud_1dgrmf@dx58865qyrdw30lqllb.info wrote: > On Sun, 8 Aug 2021 15:04:52 -0000 (UTC) > Juha Nieminen <nospam@thanks.invalid> wrote: >>James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >>> On 8/8/21 5:18 AM, MrSpud_85yGi2@1ahbfz.gov wrote: >>> In the C standard, 7.20.1.4p1 describes intptr_t and uintptr_t, and says >>> "These types are optional". A fully conforming implementation may have >>> pointers that are too big to be representable using any supported >>> integer type, and the same is true of pointer differences. >> >>Indeed. For example in x86 16-bit real mode (think MS-DOS) it may >>well be that a pointer is 32-bit (because it has to contain a >>segment and an offset) but ptrdiff_t may well be 16-bit, and the >>compiler may limit eg. arrays to 64 kilobytes (minus 1 byte) so >>that they will fit inside a segment. >> >>A difference between pointers will only give a valid (16-bit) >>result when they point to the same array (which would be within >>the same segment). Else you get garbage (if the two pointers are >>pointing to different segments). > > I was discussing from the POV of a proper OS, not some half baked monitor > program from the 70s. However if you can't work out how to get a valid diff > from the above then clearly your maths skills need some work. The standard (neither the C nor the C++ standard) doesn't care what kind of OS is running the program. And, on top of that, what I described is a feature of the x86 architecture, not a feature of the OS. If the OS, any OS, runs in 16-bit real mode, it will have to deal with that problem somehow. The fact is that the standard only supports calculating the difference between two pointers if they point to the same object or the same array (or one past the end of the array). In any other situation the behavior is undefined. I gave a practical example of where this could cause an issue if you ignore the standard.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2021-08-09 19:53 +0200 |
| Message-ID | <serq3a$a4d$1@dont-email.me> |
| In reply to | #80804 |
On 9 Aug 2021 10:53, Juha Nieminen wrote: > MrSpud_1dgrmf@dx58865qyrdw30lqllb.info wrote: >> On Sun, 8 Aug 2021 15:04:52 -0000 (UTC) >> Juha Nieminen <nospam@thanks.invalid> wrote: >>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >>>> On 8/8/21 5:18 AM, MrSpud_85yGi2@1ahbfz.gov wrote: >>>> In the C standard, 7.20.1.4p1 describes intptr_t and uintptr_t, and says >>>> "These types are optional". A fully conforming implementation may have >>>> pointers that are too big to be representable using any supported >>>> integer type, and the same is true of pointer differences. >>> >>> Indeed. For example in x86 16-bit real mode (think MS-DOS) it may >>> well be that a pointer is 32-bit (because it has to contain a >>> segment and an offset) but ptrdiff_t may well be 16-bit, and the >>> compiler may limit eg. arrays to 64 kilobytes (minus 1 byte) so >>> that they will fit inside a segment. >>> >>> A difference between pointers will only give a valid (16-bit) >>> result when they point to the same array (which would be within >>> the same segment). Else you get garbage (if the two pointers are >>> pointing to different segments). >> >> I was discussing from the POV of a proper OS, not some half baked monitor >> program from the 70s. However if you can't work out how to get a valid diff >> from the above then clearly your maths skills need some work. > > The standard (neither the C nor the C++ standard) doesn't care what kind of > OS is running the program. And, on top of that, what I described is a > feature of the x86 architecture, not a feature of the OS. If the OS, any OS, > runs in 16-bit real mode, it will have to deal with that problem somehow. > > The fact is that the standard only supports calculating the difference > between two pointers if they point to the same object or the same array > (or one past the end of the array). In any other situation the behavior > is undefined. I gave a practical example of where this could cause an > issue if you ignore the standard. True, but. `std::less` & family impose a total order on pointers of the same type, where for directly comparable pointers (i.e. within the same array or single-object-as-size-one-array) that order is the same as the `<` order. That implies that internally these functions compute some absolute representation of pointers, mapping segment selectors to lower level addresses as necessary. I would guess that an argument can be made that in practice you will always get that absolute representation by converting to `void*` and then to `uintptr_t`. However, as far as I know that's not guaranteed or formally implied by the standard. It would have been nice if the standard /had/ exposed the internal workings here, just as it would have been nice if the standard /had/ exposed e.g. the internal non-throwing string representation used in exceptions. Alas. - Alf
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-08-10 05:22 +0000 |
| Message-ID | <set2em$bss$1@gioia.aioe.org> |
| In reply to | #80808 |
Alf P. Steinbach <alf.p.steinbach@gmail.com> wrote: > True, but. `std::less` & family impose a total order on pointers of the > same type, where for directly comparable pointers (i.e. within the same > array or single-object-as-size-one-array) that order is the same as the > `<` order. That implies that internally these functions compute some > absolute representation of pointers, mapping segment selectors to lower > level addresses as necessary. Since pointers, like any object, by necessity have a bit representation, they can be compared and strictly ordered. However, that doesn't mean that their difference is meaningful (or that ptrdiff_t needs to be unambiguous for every single pair of pointers you subtract from each other).
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-10 14:54 +0000 |
| Message-ID | <3rwQI.20474$6p.6686@fx36.iad> |
| In reply to | #80814 |
Juha Nieminen <nospam@thanks.invalid> writes: >Alf P. Steinbach <alf.p.steinbach@gmail.com> wrote: >> True, but. `std::less` & family impose a total order on pointers of the >> same type, where for directly comparable pointers (i.e. within the same >> array or single-object-as-size-one-array) that order is the same as the >> `<` order. That implies that internally these functions compute some >> absolute representation of pointers, mapping segment selectors to lower >> level addresses as necessary. > >Since pointers, like any object, by necessity have a bit representation, >they can be compared and strictly ordered. I would argue against the latter part of your statement by referring to various extant and future architectures where your statement is not true, some of which even have C compilers. I'm familiar with one extant architecture (Clearpath) where pointers are not as you describe, and one potential future architecture (which is currently under NDA, but similar to the CHERI research project) where the pointers are not simple offsets from the start of memory.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-08-10 11:41 -0700 |
| Message-ID | <871r71f8hp.fsf@nosuchdomain.example.com> |
| In reply to | #80830 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Juha Nieminen <nospam@thanks.invalid> writes:
>>Alf P. Steinbach <alf.p.steinbach@gmail.com> wrote:
>>> True, but. `std::less` & family impose a total order on pointers of the
>>> same type, where for directly comparable pointers (i.e. within the same
>>> array or single-object-as-size-one-array) that order is the same as the
>>> `<` order. That implies that internally these functions compute some
>>> absolute representation of pointers, mapping segment selectors to lower
>>> level addresses as necessary.
>>
>>Since pointers, like any object, by necessity have a bit representation,
>>they can be compared and strictly ordered.
>
> I would argue against the latter part of your
> statement by referring to various extant
> and future architectures where your statement is not true, some of
> which even have C compilers.
>
> I'm familiar with one extant architecture (Clearpath) where pointers
> are not as you describe, and one potential future architecture
> (which is currently under NDA, but similar to the CHERI research
> project) where the pointers are not simple
> offsets from the start of memory.
I think what he meant is that since pointers have a bit-level
representation, it's always possible to have a strict ordering of that
representation. The ordering isn't necessarily semantically meaningful,
but sometimes it can be useful to have a *meaningless* total ordering,
as long as it's consistent.
Having said that, if a pointer value can have two or more different bit
representations, you can't do even a semantically meaningless total
ordering unless you can impose some kind of canonical representation.
Presumably that's what makes implementing std::less potentially
complicated (though it's likely to be almost trival for most
implementations).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-08-11 05:39 +0000 |
| Message-ID | <sevnqp$djr$1@gioia.aioe.org> |
| In reply to | #80841 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > scott@slp53.sl.home (Scott Lurndal) writes: >> Juha Nieminen <nospam@thanks.invalid> writes: >>>Alf P. Steinbach <alf.p.steinbach@gmail.com> wrote: >>>> True, but. `std::less` & family impose a total order on pointers of the >>>> same type, where for directly comparable pointers (i.e. within the same >>>> array or single-object-as-size-one-array) that order is the same as the >>>> `<` order. That implies that internally these functions compute some >>>> absolute representation of pointers, mapping segment selectors to lower >>>> level addresses as necessary. >>> >>>Since pointers, like any object, by necessity have a bit representation, >>>they can be compared and strictly ordered. >> >> I would argue against the latter part of your >> statement by referring to various extant >> and future architectures where your statement is not true, some of >> which even have C compilers. >> >> I'm familiar with one extant architecture (Clearpath) where pointers >> are not as you describe, and one potential future architecture >> (which is currently under NDA, but similar to the CHERI research >> project) where the pointers are not simple >> offsets from the start of memory. > > I think what he meant is that since pointers have a bit-level > representation, it's always possible to have a strict ordering of that > representation. The ordering isn't necessarily semantically meaningful, > but sometimes it can be useful to have a *meaningless* total ordering, > as long as it's consistent. After all, pointers need to be comparable with == and !=, so there must be *some* way for those comparisons to be possible, and there are very strict requirements for them (pointers to the same object need to always compare equal, and pointers to different objects need to always compare unequal). I can't think of any fathomable architecture where this is possible, but less-than comparison of, at the very least, the bit representation of these pointers, is not. Even if the *difference* between these bit representations is completely meaningless and essentially garbage (as long as it's consistent), a consistent strictly-ordering less-than comparison is still very useful (for example it allows doing binary search on an array of pointers to find a particular one, for instance).
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2021-08-08 20:01 +0100 |
| Message-ID | <20210808200155.fae8198a3b836c06d27fde24@cvine--nospam--.freeserve.co.uk> |
| In reply to | #80796 |
On Sun, 8 Aug 2021 09:23:46 -0400 James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > On 8/8/21 5:18 AM, MrSpud_85yGi2@1ahbfz.gov wrote: > > On Sat, 07 Aug 2021 12:59:02 -0700 > > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Richard Damon <Richard@Damon-Family.org> writes: > ... > >>> Actually it is true. Char (and its relatives) do have a few special > >>> cases, as Any pointer is allowed to be converted into a pointer to char > >>> and back and still be used. Also I believe that any object can be > >>> treated as an array of char. So you can do the conversion to char and > >>> subtract for two pointers in the same object. > >> > >> In C the difference of two pointers might not work, in particular > >> if the result doesn't fit in ptrdiff_t. I don't know if that > >> rule is different in C++. > > > > Huh? Any type that can be used to hold a pointer address can also be used > > to hold the difference of 2 pointers. If the difference will be negative then > > simply invert it. > > > "When two pointers are subtracted, both shall point to elements of the > same array object, or one past the last element of the array object; the > result is the difference of the subscripts of the two array elements. > The size of the result is implementation-defined, and its type (a signed > integer type) is ptrdiff_t defined in the <stddef.h> header. > If the result is not representable in an object of that type, the > behavior is undefined." (C2011 6.5.6p9). > > If the result of a pointer subtraction were always guaranteed to be > representable in ptrdiff_t, then that last sentence would be vacuous. > > In the C standard, 7.20.1.4p1 describes intptr_t and uintptr_t, and says > "These types are optional". A fully conforming implementation may have > pointers that are too big to be representable using any supported > integer type, and the same is true of pointer differences. Note that "array" has a different meaning in C and C++. In C it is (according to C11 §6.2.5/20) "a contiguously allocated nonempty set of objects with a particular member object type, called the element type". Furthermore in C (according to C11 §6.2.6.1/2) "Except for bit-fields, objects are composed of contiguous sequences of one or more bytes, the number, order, and encoding of which are either explicitly specified or implementation-defined". This has been taken to mean that in C the internal bytes comprising an object can themselves be treated as, and iterated over as, an array of char, aided of course by the fact that dereferencing pointers to char pointing to the internals of such objects does not infringe the strict aliasing rule (§6.5/7 of C11). That is, on my reading, no longer true in C++. Although by analogy with C "An object of trivially copyable or standard-layout type shall occupy contiguous bytes of storage" (C++20 §6.7.2/8.4), arrays in C++ have a different definition than in C. As I read C++20 (and I am willing to be corrected), an array is something meeting the requirements of C++20 §9.3.3.4. Accordingly, an array is something declared as an array following the C++ array syntax described there. Merely having a contiguous storage of bytes is not enough (on that reading) for the object concerned to be treated as an array of char in C++. This means that any iteration over a standard layout object using a char pointer type where that object is not actually an array of char, or any pointer arithmetic respecting such char pointer types, results in undefined behaviour by virtue of the restrictions on pointer arithmetic in C++20 §7.6.6/4 and /5. I don't imagine any compilers do anything other than what is hoped for when using pointers to char to iterate over standard layout objects: for one thing, g++ even allows you to carry out pointer arithmetic on void pointers. But it does follow a pattern of C++ turning common and reasonable coding practices, as adopted from C, into apparent undefined behaviour. I would be interested to know if you have different reading. I would be pleased to be wrong.
[toc] | [prev] | [next] | [standalone]
| From | MrSpud_ifhov@nldls6_1kg3nl2qnwv.biz |
|---|---|
| Date | 2021-08-09 08:19 +0000 |
| Message-ID | <seqoel$s5l$1@gioia.aioe.org> |
| In reply to | #80796 |
On Sun, 8 Aug 2021 09:23:46 -0400 James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >On 8/8/21 5:18 AM, MrSpud_85yGi2@1ahbfz.gov wrote: >> On Sat, 07 Aug 2021 12:59:02 -0700 >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> Richard Damon <Richard@Damon-Family.org> writes: >.... >>>> Actually it is true. Char (and its relatives) do have a few special >>>> cases, as Any pointer is allowed to be converted into a pointer to char >>>> and back and still be used. Also I believe that any object can be >>>> treated as an array of char. So you can do the conversion to char and >>>> subtract for two pointers in the same object. >>> >>> In C the difference of two pointers might not work, in particular >>> if the result doesn't fit in ptrdiff_t. I don't know if that >>> rule is different in C++. >> >> Huh? Any type that can be used to hold a pointer address can also be used >> to hold the difference of 2 pointers. If the difference will be negative then > >> simply invert it. > > >"When two pointers are subtracted, both shall point to elements of the >same array object, or one past the last element of the array object; the >result is the difference of the subscripts of the two array elements. >The size of the result is implementation-defined, and its type (a signed >integer type) is ptrdiff_t defined in the <stddef.h> header. >If the result is not representable in an object of that type, the >behavior is undefined." (C2011 6.5.6p9). > >If the result of a pointer subtraction were always guaranteed to be >representable in ptrdiff_t, then that last sentence would be vacuous. Then don't use ptrdiff_t. I suspect like most people I wasn't even aware it existed. >In the C standard, 7.20.1.4p1 describes intptr_t and uintptr_t, and says >"These types are optional". A fully conforming implementation may have >pointers that are too big to be representable using any supported >integer type, and the same is true of pointer differences. So long as mathematical operations can be done on the pointer types (which is a given or they'd be no use as pointers) then they are de facto integer types and that statement is wrong.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-08-09 08:55 +0000 |
| Message-ID | <seqqi2$1nrs$2@gioia.aioe.org> |
| In reply to | #80802 |
MrSpud_ifhov@nldls6_1kg3nl2qnwv.biz wrote: > So long as mathematical operations can be done on the pointer types (which > is a given or they'd be no use as pointers) then they are de facto integer > types and that statement is wrong. You are assuming that a pointer is internally not only an integer, but a single integer. That's not necessarily the case.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-08-09 12:16 -0400 |
| Message-ID | <serkdg$jh8$1@dont-email.me> |
| In reply to | #80802 |
On 8/9/21 4:19 AM, MrSpud_ifhov@nldls6_1kg3nl2qnwv.biz wrote: > On Sun, 8 Aug 2021 09:23:46 -0400 > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: ... >> "When two pointers are subtracted, both shall point to elements of the >> same array object, or one past the last element of the array object; the >> result is the difference of the subscripts of the two array elements. >> The size of the result is implementation-defined, and its type (a signed >> integer type) is ptrdiff_t defined in the <stddef.h> header. >> If the result is not representable in an object of that type, the >> behavior is undefined." (C2011 6.5.6p9). >> >> If the result of a pointer subtraction were always guaranteed to be >> representable in ptrdiff_t, then that last sentence would be vacuous. > > Then don't use ptrdiff_t. I suspect like most people I wasn't even aware > it existed. I hope you're wrong about that - it's a fairly basic aspect of C, like [u]intptr_t or size_t. But my degree was in Physics, not CS, so I don't have any idea how bad the average CS major's education might have been. If you never need to store the result of pointer subtractions, there's no need to use ptrdiff_t. If you're calculating the difference between pointers, and know enough about the calculation to at least roughly estimate the minimum and maximum possible values that might result, and know that both the minimum and maximum differences are small enough to be stored in an integer of a given type, you can use an integer of that type to store the result. ptrdiff_t is needed only if you have no other information to go on about the size of a pointer difference that you need to store - and if ptrdiff_t cannot represent such a value, it's likely to be the case that there is no integer type supported by that implementation that can. If there were such a type, it would have been used as ptrdiff_t. >> In the C standard, 7.20.1.4p1 describes intptr_t and uintptr_t, and says >> "These types are optional". A fully conforming implementation may have >> pointers that are too big to be representable using any supported >> integer type, and the same is true of pointer differences. > > So long as mathematical operations can be done on the pointer types (which > is a given or they'd be no use as pointers) then they are de facto integer > types and that statement is wrong. Yes, but when these issues come into play, the relevant mathematical operations cannot be done on pointer types. The result of a pointer subtraction has the type ptrdiff_t, and if an actual difference results in a value that cannot be represented in that type, the behavior is undefined, and on real-life implementations where this can happen, the likely result will be the same as trying to calculate a value by any other means that is too large to be represented in that type. That wording is deliberately vague, because the "likely result" I'm referring to can be (and probably is) different for different implementations. Possible results include rolling over large positive differences to become large negative ones and vice-versa, or saturation arithmetic, or the raising of a signal. How many cases do you know of where any one of those three results would be acceptable? You're used to systems where ptrdiff_t and [u]intptr_t can be defined by the implementation to be types that are big enough to store any pointer difference, and any suitably-converted pointer value, respectively. So am I. But the standard was written by a committee that, collectively, had far broader experience than either you or I, and that wording was added because the committee was well aware of systems for which that was not the case. Unless you know which systems the committee thought had that issue, and can authoritatively tell them that they were wrong about those systems, your beliefs to the contrary don't count for much.
[toc] | [prev] | [next] | [standalone]
| From | MrSpud_HG@_0b772d8ha3yjo0xb.edu |
|---|---|
| Date | 2021-08-09 16:23 +0000 |
| Message-ID | <serkpm$36i$1@gioia.aioe.org> |
| In reply to | #80806 |
On Mon, 9 Aug 2021 12:16:46 -0400 James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >On 8/9/21 4:19 AM, MrSpud_ifhov@nldls6_1kg3nl2qnwv.biz wrote: >> On Sun, 8 Aug 2021 09:23:46 -0400 >> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >> Then don't use ptrdiff_t. I suspect like most people I wasn't even aware >> it existed. > >I hope you're wrong about that - it's a fairly basic aspect of C, like >[u]intptr_t or size_t. But my degree was in Physics, not CS, so I don't >have any idea how bad the average CS major's education might have been. Ooo look at you, supercilious and patronising all in one go. Well done,have a scooby snack. >If you never need to store the result of pointer subtractions, there's >no need to use ptrdiff_t. If you're calculating the difference between >pointers, and know enough about the calculation to at least roughly Any parser beyond the most basic needs to do pointer arithmetic and I've written a LOT of them. >type to store the result. ptrdiff_t is needed only if you have no other >information to go on about the size of a pointer difference that you >need to store - and if ptrdiff_t cannot represent such a value, it's >likely to be the case that there is no integer type supported by that >implementation that can. If there were such a type, it would have been >used as ptrdiff_t. I should have clarified in my origional post that I was refering to programming in grown up OS's on grown up CPUs. Not on DOS with 1970s x86 segmentation. >> So long as mathematical operations can be done on the pointer types (which >> is a given or they'd be no use as pointers) then they are de facto integer >> types and that statement is wrong. > >Yes, but when these issues come into play, the relevant mathematical >operations cannot be done on pointer types. The result of a pointer They can in *nix which is good enough for me.
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2021-08-09 21:50 +0100 |
| Message-ID | <ses4ec$si1$1@dont-email.me> |
| In reply to | #80807 |
On 09/08/2021 17:23, MrSpud_HG@_0b772d8ha3yjo0xb.edu wrote: > I should have clarified in my origional post that I was refering to programming > in grown up OS's on grown up CPUs. Not on DOS with 1970s x86 segmentation. You're probably not aware then that the CD DS ES SS registers from that 1970s x86 are still alive and well under the hood, even though they often point to the same address space, and the offsets are 32 or 64 bit. What bothers me about ptr_diff_t is the size. The difference between two 32-bit pointers is plus or minus 4GB. Which needs a 33 bit value :( It's the same with 64 bit. As it happens it's never been a practical problem as I've never had a 32 bit system with more than 2GB RAM, and don't expect the 64 bit limit to be a problem any time soon. Andy
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c++
csiph-web