- Is this really necessary - 8 Updates
| mickspud@downthefarm.com: Aug 12 08:20AM On Wed, 11 Aug 2021 12:40:38 -0700 >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. >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. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 12 03:42AM -0700 >> allocating an area larger than 2 GB. > I suspect that your implementation of malloc (glibc?, libc? > eglibc?) uses mmap() for very large allocations. [...] I have no interest in pursuing an answer to that question. I am simply reporting some observed behavior of a program written in standard C, running on what is TTBOMK a conforming implementation. Moreover as long as such an implementation /could/ be conforming, AFAIAC that is all that matters, so any question about what is going "under the hood" is moot. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 12 03:50AM -0700 > 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. Any C program that subtracts one pointer value from another depends on the definition of ptrdiff_t, whether the program's author is aware of that fact or not. > It would be trivial to simply use (u)int64_t on a 32 bit system > instead. It isn't possible to avoid depending on the definition of ptrdiff_t in C code that subtracts pointer values. There is no way to substitute another type in such cases. |
| mickspud@downthefarm.com: Aug 12 02:58PM On Thu, 12 Aug 2021 03:50:56 -0700 >It isn't possible to avoid depending on the definition of >ptrdiff_t in C code that subtracts pointer values. There is no >way to substitute another type in such cases. Rubbish. Memory addresses are simply numbers, not voodoo. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 12 08:29AM -0700 >> ptrdiff_t in C code that subtracts pointer values. There is no >> way to substitute another type in such cases. > Rubbish. Memory addresses are simply numbers, The C standard says otherwise, which is easy to verify. C implementations follow the semantic descriptions given in the C standard, which is also easy to verify. |
| mickspud@downthefarm.com: Aug 12 03:39PM On Thu, 12 Aug 2021 08:29:58 -0700 >>> way to substitute another type in such cases. >> Rubbish. Memory addresses are simply numbers, >The C standard says otherwise, which is easy to verify. Ah ok. What are they then, ascii strings? >C implementations follow the semantic descriptions given in >the C standard, which is also easy to verify. I don't need to verify anything, pointer values are numbers. They may have seperate parts and addressing might not be linear on some archaic CPUs, but they're numbers, end of. |
| Paavo Helde <myfirstname@osa.pri.ee>: Aug 12 08:07PM +0300 > I don't need to verify anything, pointer values are numbers. They may have > seperate parts and addressing might not be linear on some archaic CPUs, but > they're numbers, end of. I think what Tim wants to say is that when calculating the difference of pointers, the result is inherently ptrdiff_t. If this is inadequate for holding the actual difference, then it's already too late to convert it to int64, it is already ruined. 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 is not obvious and not trivial. Luckily it won't come up often in practice, >2GB byte arrays in 32-bit programs are rare. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 12 12:06PM -0700 >> 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. https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos |
| 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