- Is this really necessary - 10 Updates
| Juha Nieminen <nospam@thanks.invalid>: Aug 13 07:16AM > For making >2GB differences to always work reliably in 32-bit program > one needs to cast the pointers themselves first to an (u)int64 type, > then subtract. But then it is not subtraction of pointers any more. This works in practice, but if we are *really* strict about the standard, converting a pointer to an integer is not guaranteed to work (without loss of information). The C standard states: "Any pointer type may be converted to an integer type. Except as previously specified, the result is implementation-defined. If the result cannot be represented in the integer type, the behavior is undefined. The result need not be in the range of values of any integer type." Notice particularly the last sentence (and, consequently, the second-last sentence.) So, you can do it, but it's not guaranteed to give you the correct result that you expect. I assume the C++ standard says something similar. |
| mickspud@downthefarm.com: Aug 13 09:19AM On Thu, 12 Aug 2021 12:06:35 -0700 >> 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. >https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos Is that legal? Regardless, I suspect the original version of the NT kernel as designed by dave cutler was nice and clean as it didn't have to support any of the cruft of Win 3.1 or 95. I doubt the same could be said for the Win10 kernel after 30 years of hacks and bodges. Even the linux kernel has been suffering from bloat for some time now. |
| mickspud@downthefarm.com: Aug 13 09:26AM On Fri, 13 Aug 2021 07:16:43 -0000 (UTC) >specified, the result is implementation-defined. If the result cannot be >represented in the integer type, the behavior is undefined. The result need >not be in the range of values of any integer type." That sounds like simple arse covering. If unsigned long or unsigned long long on a system arn't large enough to hold INT_MAX or its 64 bit equivalent and yet somehow the compiler can still work with even larger numbers as memory addresses then either the compiler has been deliberately crippled or the CPU must use an entirely seperate set of registers to process addresses alone. Which would be an ... interesting design. |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Aug 13 03:30PM +0200 On 13 Aug 2021 09:16, Juha Nieminen wrote: > sentence.) > So, you can do it, but it's not guaranteed to give you the correct result > that you expect. If the implementation provides `uintptr_t` then you're guaranteed a correct result for roundtrip conversion. C99: "any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer" > I assume the C++ standard says something similar. The C++ standard implicitly adopts the C standard's requirements. In C++03 this was perhaps more clear because then the standard stated that the C standard "is incorporated into this Standard by reference". - Alf |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Aug 13 10:30AM -0400 > On Fri, 13 Aug 2021 07:16:43 -0000 (UTC) > Juha Nieminen <nospam@thanks.invalid> wrote: ... >> represented in the integer type, the behavior is undefined. The result need >> not be in the range of values of any integer type." > That sounds like simple arse covering. ... More like the advanced version: the committee knew of platforms which would not allow efficient implementation of an integer type that was wide enough to store a distinct value for all possible addresses. They wanted to make sure that a conforming implementation of C would be possible on such systems. They therefore deliberately chose to write the specification lenient enough to allow such implementations. |
| scott@slp53.sl.home (Scott Lurndal): Aug 13 02:32PM >sentence.) >So, you can do it, but it's not guaranteed to give you the correct result >that you expect. Indeed. Here's a research project that includes pointers larger than the largest native integer type. https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ |
| scott@slp53.sl.home (Scott Lurndal): Aug 13 02:35PM >Is that legal? Regardless, I suspect the original version of the NT kernel >as designed by dave cutler was nice and clean as it didn't have to support >any of the cruft of Win 3.1 or 95. Ah, but it _did_ have to support the cruft of earlier operating systems - and it did that through a subsystem called WoW (Windows on Windows), which you'll find in the aforementioned source distribution. |
| mickspud@downthefarm.com: Aug 13 02:58PM On Fri, 13 Aug 2021 10:30:15 -0400 >More like the advanced version: the committee knew of platforms which >would not allow efficient implementation of an integer type that was >wide enough to store a distinct value for all possible addresses. They Not allow efficient and not allow at all are 2 different things. |
| mickspud@downthefarm.com: Aug 13 02:58PM On Fri, 13 Aug 2021 14:35:09 GMT >Ah, but it _did_ have to support the cruft of earlier operating >systems - and it did that through a subsystem called WoW (Windows on Windows), >which you'll find in the aforementioned source distribution. WoW is a seperate process, its not part of the kernel. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Aug 13 11:18AM -0700 > The C++ standard implicitly adopts the C standard's requirements. > In C++03 this was perhaps more clear because then the standard stated > that the C standard "is incorporated into this Standard by reference". The wording in C++03 is a bit vague. 17.3.1.4 C Library [lib.structure.see.also] Paragraphs labelled "SEE ALSO:" contain cross-references to the relevant portions of this Standard and the ISO C standard, which is incorporated into this Standard by reference. That could be read to imply that the entire C standard is included by reference, but I believe it refers only to the library section (section 7). For example the behavior of printf for C++ is specified by reference to the C standard, but the behavior of addition is specified in the C++ standard itself -- and the C standard's specification of the type of character constants, for example, does not apply to C++. C++ defines its own semantics for integer/pointer conversions (and its specification happens to be very close to C's). C's specification for <stdint.h>, where uintptr_t is defined, applies to C++ (and a C++ implementation won't define uintptr_t if it has no integer type that meets is requirements). -- 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