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 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-08-09 20:57 -0400 |
| Message-ID | <M9kQI.3747$6h1.3139@fx39.iad> |
| In reply to | #80809 |
On 8/9/21 4:50 PM, Vir Campestris wrote: > 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 Since for 16 bit size_t ptrdiff_t has a requirement to be at least 17 bits, I think the committee decided that it was unlikely for an application with a 32-bit address space to have over half of its memory dedicated to a single char array (the only real case where you can have this issue). Machines with 16 bit size_t are going to need to be segmented systems, so having over 32k in an array is plausable, so ptrdif_t needs to be big enough for that. From what I remember of minumum limits, a machine with only 64k of address space can't really be fully conforming, so if that machine makes ptrdif_t be only 16 bits to save space, that isn't the only non-conformity. Maybe if 32-bit environments that actually used the segments like was used in the 16-bit segmented world to increase memory space were common, then the standard might have required 33-bit ptrdif_t for those systems.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-10 01:12 +0000 |
| Message-ID | <CnkQI.22662$Fx8.9604@fx45.iad> |
| In reply to | #80810 |
Richard Damon <Richard@Damon-Family.org> writes: >On 8/9/21 4:50 PM, Vir Campestris wrote: >> 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 > >Since for 16 bit size_t ptrdiff_t has a requirement to be at least 17 >bits, I think the committee decided that it was unlikely for an >application with a 32-bit address space to have over half of its memory >dedicated to a single char array (the only real case where you can have >this issue). In all the years that I've been using ptrdiff_t, every single case has involved subtracting a base pointer from an element pointer; the result is always positive and always within positive value range of ptrdiff_t. And given the split virtual address space of most modern operating environments, the maximum unsigned difference for a user application will generally be representable in 31 bits anyway absent buggy code. It's not like programmers are willy-nilly subtracting random pointers and expecting a meaningful result.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-08-09 21:21 -0400 |
| Message-ID | <RwkQI.2803$Mc.2310@fx34.iad> |
| In reply to | #80811 |
On 8/9/21 9:12 PM, Scott Lurndal wrote: > Richard Damon <Richard@Damon-Family.org> writes: >> On 8/9/21 4:50 PM, Vir Campestris wrote: >>> 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 >> >> Since for 16 bit size_t ptrdiff_t has a requirement to be at least 17 >> bits, I think the committee decided that it was unlikely for an >> application with a 32-bit address space to have over half of its memory >> dedicated to a single char array (the only real case where you can have >> this issue). > > In all the years that I've been using ptrdiff_t, every single case > has involved subtracting a base pointer from an element pointer; > the result is always positive and always within positive value range > of ptrdiff_t. > > And given the split virtual address space of most modern operating > environments, the maximum unsigned difference for a user application will > generally be representable in 31 bits anyway absent buggy code. > > It's not like programmers are willy-nilly subtracting random > pointers and expecting a meaningful result. > I have had cases where I subtract pointers to elements in the array where the pointers might be in the reversed order, and thus I get a negative difference. I will admit, that it is less common than the case you describe, but it does happen.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-08-10 07:13 -0700 |
| Message-ID | <86tujxz8t4.fsf@linuxsc.com> |
| In reply to | #80810 |
Richard Damon <Richard@Damon-Family.org> writes: > On 8/9/21 4:50 PM, Vir Campestris wrote: [...] >> 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. > > Since for 16 bit size_t ptrdiff_t has a requirement to be at least 17 > bits, I think the committee decided that it was unlikely for an > application with a 32-bit address space to have over half of its memory > dedicated to a single char array (the only real case where you can have > this issue). A few weeks ago I happened to write a small C program that does part of its work in a single large dynamically allocated memory area. In that memory area there are character arrays, character pointers, and various offset values (unsigned integers). The program runs just fine on a 64-bit linux system (in one case the memory area allocated was about 180 GB). Prompted by this discussion, I took the program and tried compiling and running it on a 32-bit linux system. The memory area allocated was a little over 2 GB, and the program fell down miserably. Limiting the size of the memory area allocated to PTRDIFF_MAX, with no other changes, got it working again. So problems due to the limited range of ptrdiff_t definitely can occur in practical programs. > [...] > > From what I remember of minumum limits, a machine with only 64k > of address space can't really be fully conforming, [...] The rule for being able to have a 64 KB object applies only to hosted implementations. It's easy to make a fully conforming freestanding implementation for a machine with limited address space, even one much less than 64 KB.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-08-10 05:29 +0000 |
| Message-ID | <set2r9$fl3$1@gioia.aioe.org> |
| In reply to | #80809 |
Vir Campestris <vir.campestris@invalid.invalid> wrote: > 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. I might be completely wrong on this, but I remember reading somewhere that thread-local variables are often implemented (in x86 systems) by using one of the segment registers, and having it different for each thread. This way all the code can address these thread-local variables with the exact same memory address, but they will still be pointing to different variables. If that's the case then it means that the segment registers are still actually useful.
[toc] | [prev] | [next] | [standalone]
| From | MrSpud_12tus_Atff@bya886olr5o8dhu9.ac.uk |
|---|---|
| Date | 2021-08-10 07:28 +0000 |
| Message-ID | <set9qc$v2s$1@gioia.aioe.org> |
| In reply to | #80815 |
On Tue, 10 Aug 2021 05:29:15 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >Vir Campestris <vir.campestris@invalid.invalid> wrote: >> 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. > >I might be completely wrong on this, but I remember reading somewhere that >thread-local variables are often implemented (in x86 systems) by using >one of the segment registers, and having it different for each thread. >This way all the code can address these thread-local variables with the >exact same memory address, but they will still be pointing to different >variables. I don't see how that'll work in 32 or particularly 64 bit.
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2021-08-10 15:34 +0100 |
| Message-ID | <vsWdncqLt5v7E4_8nZ2dnUU78QPNnZ2d@brightview.co.uk> |
| In reply to | #80818 |
On 10/08/2021 08:28, MrSpud_12tus_Atff@bya886olr5o8dhu9.ac.uk wrote: > On Tue, 10 Aug 2021 05:29:15 -0000 (UTC) > Juha Nieminen <nospam@thanks.invalid> wrote: >> Vir Campestris <vir.campestris@invalid.invalid> wrote: >>> 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. >> >> I might be completely wrong on this, but I remember reading somewhere that >> thread-local variables are often implemented (in x86 systems) by using >> one of the segment registers, and having it different for each thread. >> This way all the code can address these thread-local variables with the >> exact same memory address, but they will still be pointing to different >> variables. > > I don't see how that'll work in 32 or particularly 64 bit. > One of the segment registers is configured by Windows to address the thread environment block (TEB) which is thread specific. I'm pretty sure that it was FS register on 32-bit windows, but maybe that's changed for 64-bit. The scheduler context switches between threads saves and restores the segment registers, so the TEB will always be correctly addressed as threads switch. For example, for 32-bit Windows, you may notice as part of the function prolog code, the pointer at FS:0 is updated, then restored on return - that's the structured exception handling frame pointer, which is per-thread as you'd expect. (Similarly the last error stored by many APIs and retrieved through Get/SetLastError() is somewhere in the TEB. Regards, Mike.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-10 14:59 +0000 |
| Message-ID | <XuwQI.20476$6p.9418@fx36.iad> |
| In reply to | #80818 |
MrSpud_12tus_Atff@bya886olr5o8dhu9.ac.uk writes: >On Tue, 10 Aug 2021 05:29:15 -0000 (UTC) >Juha Nieminen <nospam@thanks.invalid> wrote: >>Vir Campestris <vir.campestris@invalid.invalid> wrote: >>> 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. >> >>I might be completely wrong on this, but I remember reading somewhere that >>thread-local variables are often implemented (in x86 systems) by using >>one of the segment registers, and having it different for each thread. >>This way all the code can address these thread-local variables with the >>exact same memory address, but they will still be pointing to different >>variables. > >I don't see how that'll work in 32 or particularly 64 bit. If you download a copy of the Intel (or AMD) processor manual set, you'll find sufficient information within to educate you on this particular topic. It works and is widely used. Or, in the usenet vernacular, RTFM.
[toc] | [prev] | [next] | [standalone]
| From | MrSpud_wPgnov999o@vv7a6.tv |
|---|---|
| Date | 2021-08-10 15:54 +0000 |
| Message-ID | <seu7eq$igk$1@gioia.aioe.org> |
| In reply to | #80832 |
On Tue, 10 Aug 2021 14:59:03 GMT scott@slp53.sl.home (Scott Lurndal) wrote: >MrSpud_12tus_Atff@bya886olr5o8dhu9.ac.uk writes: >>On Tue, 10 Aug 2021 05:29:15 -0000 (UTC) >>Juha Nieminen <nospam@thanks.invalid> wrote: >>>Vir Campestris <vir.campestris@invalid.invalid> wrote: >>>> 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. >>> >>>I might be completely wrong on this, but I remember reading somewhere that >>>thread-local variables are often implemented (in x86 systems) by using >>>one of the segment registers, and having it different for each thread. >>>This way all the code can address these thread-local variables with the >>>exact same memory address, but they will still be pointing to different >>>variables. >> >>I don't see how that'll work in 32 or particularly 64 bit. > >If you download a copy of the Intel (or AMD) processor manual set, >you'll find sufficient information within to educate you on this >particular topic. It works and is widely used. > >Or, in the usenet vernacular, RTFM. In a similar vein why don't you FOAD you patronising cunt. I'm sure if you knew the answer you'd post it but its much easier to crawl out from under your bridge isn't it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-08-10 11:29 -0700 |
| Message-ID | <875ywdf909.fsf@nosuchdomain.example.com> |
| In reply to | #80838 |
MrSpud_wPgnov999o@vv7a6.tv writes:
[...]
> In a similar vein why don't you FOAD you patronising cunt. I'm sure if you
> knew the answer you'd post it but its much easier to crawl out from under
> your bridge isn't it.
A note to other readers: This user appears to use a different user name
for each post, but as far as I can tell it always starts with "MrSpud".
You may need to take that into account when adding an entry to your
killfile.
--
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 | mickspud@downthefarm.com |
|---|---|
| Date | 2021-08-11 08:45 +0000 |
| Message-ID | <sf02n0$o2e$1@gioia.aioe.org> |
| In reply to | #80840 |
On Tue, 10 Aug 2021 11:29:58 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >MrSpud_wPgnov999o@vv7a6.tv writes: >[...] >> In a similar vein why don't you FOAD you patronising cunt. I'm sure if you >> knew the answer you'd post it but its much easier to crawl out from under >> your bridge isn't it. > >A note to other readers: This user appears to use a different user name >for each post, but as far as I can tell it always starts with "MrSpud". >You may need to take that into account when adding an entry to your >killfile. Yes, that'll work! :)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-08-11 07:05 -0700 |
| Message-ID | <87pmukhy9n.fsf@nosuchdomain.example.com> |
| In reply to | #80847 |
mickspud@downthefarm.com writes:
> On Tue, 10 Aug 2021 11:29:58 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>MrSpud_wPgnov999o@vv7a6.tv writes:
>>[...]
>>> In a similar vein why don't you FOAD you patronising cunt. I'm sure if you
>>> knew the answer you'd post it but its much easier to crawl out from under
>>> your bridge isn't it.
>>
>>A note to other readers: This user appears to use a different user name
>>for each post, but as far as I can tell it always starts with "MrSpud".
>>You may need to take that into account when adding an entry to your
>>killfile.
>
> Yes, that'll work! :)
You are deliberately changing your user name to force your content onto
people who don't want to read it. That is pathetic, and it will not
work.
--
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 | mickspud@downthefarm.com |
|---|---|
| Date | 2021-08-11 14:18 +0000 |
| Message-ID | <sf0m86$1mst$1@gioia.aioe.org> |
| In reply to | #80852 |
On Wed, 11 Aug 2021 07:05:56 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >mickspud@downthefarm.com writes: >> On Tue, 10 Aug 2021 11:29:58 -0700 >> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>>MrSpud_wPgnov999o@vv7a6.tv writes: >>>[...] >>>> In a similar vein why don't you FOAD you patronising cunt. I'm sure if you >>>> knew the answer you'd post it but its much easier to crawl out from under >>>> your bridge isn't it. >>> >>>A note to other readers: This user appears to use a different user name >>>for each post, but as far as I can tell it always starts with "MrSpud". >>>You may need to take that into account when adding an entry to your >>>killfile. >> >> Yes, that'll work! :) > >You are deliberately changing your user name to force your content onto >people who don't want to read it. Actually thats not the reason, but it is a nice side effect :) >That is pathetic, and it will not work. Seems like it does given you replied! IIRC you've already claimed to have killfiled me twice. 3rd time lucky? :)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-10 14:57 +0000 |
| Message-ID | <FtwQI.20475$6p.8987@fx36.iad> |
| In reply to | #80815 |
Juha Nieminen <nospam@thanks.invalid> writes: >Vir Campestris <vir.campestris@invalid.invalid> wrote: >> 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. > >I might be completely wrong on this, but I remember reading somewhere that >thread-local variables are often implemented (in x86 systems) by using >one of the segment registers, and having it different for each thread. That is the case for linux on x86 %fs is used for the user-mode thread-local storage base and %gs is used for the kernel-model per-cpu storage. > >If that's the case then it means that the segment registers are still >actually useful. The modern architectures (e.g. x86_64) treat them as general purpose registers for all intents and purposes - the descriptor tables (gdt/ldt) don't come into play (see, for example, the SWAPGS instruction).
[toc] | [prev] | [next] | [standalone]
| From | MrSpud_pb9bpp7Ej@6urvt16b9fax.gov.uk |
|---|---|
| Date | 2021-08-10 07:23 +0000 |
| Message-ID | <set9gm$qnh$1@gioia.aioe.org> |
| In reply to | #80809 |
On Mon, 9 Aug 2021 21:50:20 +0100 Vir Campestris <vir.campestris@invalid.invalid> wrote: >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 And invisible in 32 bit protected mode and not used at all in 64 bit so irrelevant to this discussion.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-10 15:02 +0000 |
| Message-ID | <lywQI.20477$6p.18995@fx36.iad> |
| In reply to | #80816 |
MrSpud_pb9bpp7Ej@6urvt16b9fax.gov.uk writes: >On Mon, 9 Aug 2021 21:50:20 +0100 >Vir Campestris <vir.campestris@invalid.invalid> wrote: >>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 > >And invisible in 32 bit protected mode and not used at all in 64 bit so >irrelevant to this discussion. Funny, I recall a processor feature addition from 2005 which honored the DS limit register in long mode. Added specifically to support XEN (recall that AMD added long mode and Intel adopted it later) before SVM was introduced to the Opterons.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-08-10 06:11 -0700 |
| Message-ID | <8635rh1m2i.fsf@linuxsc.com> |
| In reply to | #80809 |
Vir Campestris <vir.campestris@invalid.invalid> writes: [..stuff about 64 bit systems removed..] > 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 > :( > > As it happens it's never been a practical problem as I've never had a > 32 bit system with more than 2GB RAM, It isn't necessary for there to be more than 2GB of RAM for problems with ptrdiff_t to manifest (in 32-bit linux). A call to malloc() will gladly return a memory area larger than all of RAM if there is swap space to hold it.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2021-08-10 16:13 +0200 |
| Message-ID | <inffroF5l5hU1@mid.individual.net> |
| In reply to | #80823 |
On 2021-08-10 at 15:11, Tim Rentsch wrote: > Vir Campestris <vir.campestris@invalid.invalid> writes: > > [..stuff about 64 bit systems removed..] > >> 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 >> :( >> >> As it happens it's never been a practical problem as I've never had a >> 32 bit system with more than 2GB RAM, > > It isn't necessary for there to be more than 2GB of RAM for > problems with ptrdiff_t to manifest (in 32-bit linux). A call to > malloc() will gladly return a memory area larger than all of RAM > if there is swap space to hold it. > There still has to be a contiguous address space that is free of already allocated memory blocks and not in a range reserved by the operating system. I'm no Linux expert, but on Windows configured for LargeAddressAware programs, with 3 GB user + 1 GB OS, it is extremely unlikely to find a 2.x GB hole for the heap. Or that you have a program that needs exactly 1 such block for byte sized operations.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-08-11 12:40 -0700 |
| Message-ID | <86bl63zs5l.fsf@linuxsc.com> |
| In reply to | #80825 |
Bo Persson <bo@bo-persson.se> writes: > On 2021-08-10 at 15:11, Tim Rentsch wrote: > >> Vir Campestris <vir.campestris@invalid.invalid> writes: >> >> [..stuff about 64 bit systems removed..] >> >>> 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 >>> :( >>> >>> As it happens it's never been a practical problem as I've never had a >>> 32 bit system with more than 2GB RAM, >> >> It isn't necessary for there to be more than 2GB of RAM for >> problems with ptrdiff_t to manifest (in 32-bit linux). A call to >> malloc() will gladly return a memory area larger than all of RAM >> if there is swap space to hold it. > > There still has to be a contiguous address space that is free of > already allocated memory blocks and not in a range reserved by the > operating system. True. > I'm no Linux expert, but on Windows configured for LargeAddressAware > programs, with 3 GB user + 1 GB OS, it is extremely unlikely to find a > 2.x GB hole for the heap. That depends on the program doesn't it? And so is more unlikely for some programs than others? Of course it certainly is within the realm of possibility that on Microsoft Windows the virtual address space is all chopped up right from the get go. The developers there are real geniuses, who knows what they might have come up with. > Or that you have a program that needs > exactly 1 such block for byte sized operations. Note that "byte sized operations" might be nothing more than using character pointers to delimit region boundaries within the memory area, and using pointer subtraction to determine the size of various sub-areas. Note also that there may be more than one such block provided there is only one at a time. In addition to malloc() there is also free(). I ran a test case (on a 32-bit linux system) that allocated five large memory regions, one at a time, each of which was larger than 2 GB (and so larger than PTRDIFF_MAX in that C implementation).
[toc] | [prev] | [next] | [standalone]
| From | mickspud@downthefarm.com |
|---|---|
| Date | 2021-08-12 08:20 +0000 |
| Message-ID | <sf2ljh$14ur$1@gioia.aioe.org> |
| In reply to | #80855 |
On Wed, 11 Aug 2021 12:40:38 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >right from the get go. The developers there are real geniuses, >who knows what they might have come up with. If they're the same level of genius as MS's current UI designers then the internals of the windows kernel are probably a horror show. >there is only one at a time. In addition to malloc() there is >also free(). I ran a test case (on a 32-bit linux system) that >allocated five large memory regions, one at a time, each of which >was larger than 2 GB (and so larger than PTRDIFF_MAX in that >C implementation). Which probably underlines the fact that - despite what some people on here seem to think - no one uses that macro or the ptrdiff_t type. It would be trivial to simply use (u)int64_t on a 32 bit system instead.
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c++
csiph-web