- Is this really necessary - 7 Updates
| David Brown <david.brown@hesbynett.no>: Aug 10 05:44PM +0200 On 10/08/2021 16:27, James Kuyper wrote: > example. Do you know of any particular modern system, preferably as > widely used as possible, where ptrdiff_t was not big enough to store all > possible pointer differences, or where [u]intptr_t is not supported? I know of a system where ptrdiff_t is, like size_t, 16-bit - but where there are pointer types that are 24-bit. The gcc port for the AVR is my usual first choice of example here, since it is a gcc target and the microcontrollers concerned are in common use, with new devices being developed on a regular basis. (i.e., they are not some brain-dead outdated cpu with only sort-of-C compilers such as the 8051 or 8086 - these are modern devices with modern C and C++ tools, albeit with only limited language support libraries for C++). In particular, comparing (or subtracting) pointers from different address spaces is completely meaningless, and if you have two 24-bit "__memx" pointers that target different physical memory types in the chip, then subtracting them is not going to fit in a 16-bit ptrdiff_t. <https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html> For most C and C++ implementations, ptrdiff_t is a signed type of the same width as the full address space of the device (ignoring devices like the AVR with multiple independent address spaces). If you have full control over the linking setup and other aspects of making a binary for the device - as you often do for freestanding embedded code - you can easily construct arrays that are bigger than half the address space. Subtracting a pointer to the first element of such an array from a pointer to its last object will give you an integer result that is too big for ptrdiff_t. There is no constraint error, but it is undefined behaviour (6.5.6p9). A quick test using godbolt.org with 32-bit ARM compilers shows that gcc will not compile "extern char data[0xc0000000];", but clang for these devices accepts it. ptrdiff_t, however, is not big enough to store the differences between all pointers to elements within that one array. I don't know of any systems where uintptr_t does not exist, sorry. Perhaps some "capability pointer" systems would count, but I am not at all familiar with them. |
| MrSpud_885p_dugji@l6zhsgj_v6t3dbj.tv: Aug 10 03:50PM On Tue, 10 Aug 2021 11:20:52 +0200 >> embedded C will be 32 bit linear. >That makes it clear that you are so ignorant about the world outside of >*nix that you have no idea how ignorant you are. If all your Oh ok. I guess all my PIC development not to mention arduino counts for nothing then? If you say so. |
| MrSpud_u7lm@bxuc3wy1g3cxiqu5j2x1_7iu.com: Aug 10 03:51PM On Tue, 10 Aug 2021 12:24:44 -0000 (UTC) >Being nice and polite to people is genuinely more rewarding and gives >yourself more happiness in the long run than being rude, aggressive and >confrontational, which will just make you miserable in the long run. Take your own advice hypocrit. The fact that you flip flop between being some kind of comedy psychologist and a rude prick tells me that you're almost certainly suffering either from severe stress or you're bipolar. |
| MrSpud_wPgnov999o@vv7a6.tv: Aug 10 03:54PM On Tue, 10 Aug 2021 14:59:03 GMT >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. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Aug 10 11:27AM -0700 >>I'm sorry - people who confess to being unfamiliar with fairly basic >>aspects of C tend to produce feelings of superiority in me. > In 25 years I've never ever seen that type used [snip] If you've done pointer subtraction in C or C++, you've used ptrdiff_t. You might not have referred to it by that name. -- 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 */ |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Aug 10 11:29AM -0700 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 */ |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Aug 10 11:41AM -0700 > (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 */ |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment