- Is this really necessary - 16 Updates
| Juha Nieminen <nospam@thanks.invalid>: Aug 11 05:39AM > 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). |
| Juha Nieminen <nospam@thanks.invalid>: Aug 11 05:45AM > 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. Also, doesn't mmap() in Linux map a file into "virtual memory"? Ostensibly this can be larger than the amount of physical RAM. |
| Juha Nieminen <nospam@thanks.invalid>: Aug 11 05:47AM > 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. Even if any of that were true, so what? Do you call an alcoholic a hypocrite for warning you about the dangers of alcohol? "Don't make the same mistakes I have made" is not hypocrisy. |
| David Brown <david.brown@hesbynett.no>: Aug 11 08:31AM +0200 >> *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. Apparently, yes. Certainly you don't appear to have learned anything. However, I think I will be taking the common advice here and basically ignoring you, for the good of the group. Feel free to reply with some sort of insult if it makes you feel better. |
| mickspud@downthefarm.com: Aug 11 08:44AM On Tue, 10 Aug 2021 11:27:16 -0700 >[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. If its typedef'd to a long then yes. |
| mickspud@downthefarm.com: Aug 11 08:45AM On Tue, 10 Aug 2021 11:29:58 -0700 >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! :) |
| mickspud@downthefarm.com: Aug 11 08:46AM On Wed, 11 Aug 2021 05:47:21 -0000 (UTC) >> certainly suffering either from severe stress or you're bipolar. >Even if any of that were true, so what? Do you call an alcoholic a hypocrite >for warning you about the dangers of alcohol? If an alcoholic who went around swearing and cursing at people told me I shouldn't swear and curse I'll tell him to bugger off and sort himself out first. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 11 05:26AM -0700 >> if there is swap space to hold it. > Also, doesn't mmap() in Linux map a file into "virtual memory"? > Ostensibly this can be larger than the amount of physical RAM. That's a more complicated question. I don't see anything in the documentation that rules out mapping a file larger than physical RAM, but I also don't see any indication that such cases must be supported, even if only conditionally supported. My comment about malloc() is based on first-hand experience; I don't have any corresponding first-hand experience with mmap(). |
| Paavo Helde <myfirstname@osa.pri.ee>: Aug 11 04:05PM +0300 >> 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. > If its typedef'd to a long then yes. Using 'long' for storing pointer differences is error-prone and may easily fail in current x64 Windows where long has the same size as int. Better use a type meant for storing pointer differences, i.e. ptrdiff_t. |
| scott@slp53.sl.home (Scott Lurndal): Aug 11 02:01PM >> if there is swap space to hold it. >Also, doesn't mmap() in Linux map a file into "virtual memory"? >Ostensibly this can be larger than the amount of physical RAM. mmap() maps a file into the application address space. For operating environments that run with address virtualization, such as the typical intel/amd/arm processors, the backing store for the pages is the original file itself. As with any virtual memory system, pressure on the physical address space will result in movement of pages between memory and backing store as required. mmap() can also map "anonymous" space, in which case swap space is allocated as backing store for the virtual addresses allocated by the mmap() system call. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Aug 11 07:05AM -0700 >>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 */ |
| scott@slp53.sl.home (Scott Lurndal): Aug 11 02:06PM >> Ostensibly this can be larger than the amount of physical RAM. >That's a more complicated question. I don't see anything in the >documentation that rules out mapping a file larger than physical The limit on mapping is the available virtual address space for the application. And note that Linux and Windows 32-bit systems, limit the application to two or three GB (depending on OS configuration) of virtual address space. The only way to map more that the size of the available VA space is to manually window the file over a subset of the VA space. On Unix/Linux systems, an additional limit (setrlimit(2) RLIMIT_AS) can be set by the administrator (and lowered, but not raised, by the application itself). An application that exceeds the RLIMIT_AS for the process will recieve a SIGSEGV when attempting to allocate virtual address space via any API (e.g. brk, sbrk, mmap). |
| mickspud@downthefarm.com: Aug 11 02:18PM On Wed, 11 Aug 2021 07:05:56 -0700 >> 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? :) |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 11 12:40PM -0700 > 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). |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 11 12:54PM -0700 > by default, limit the application to 2GB of virtual address space. > Malloc can't return more than the available user-mode VA space > allows. Here is a data point. I have a small C program, which uses malloc() to allocate a large region of memory (once for each input file, which is processed and then the allocated memory is freed). Running the program on a 32-bit linux system (with standard amd or intel hardware), I observe malloc() successfully allocating an area larger than 2 GB. My comment above about problems with ptrdiff_t and about malloc() returning a memory area larger than all of RAM follows directly from first-hand experience. I respect your knowledge and understanding of many different operating systems. But I wasn't just talking through my hat up there. |
| scott@slp53.sl.home (Scott Lurndal): Aug 11 08:20PM >freed). Running the program on a 32-bit linux system (with >standard amd or intel hardware), I observe malloc() successfully >allocating an area larger than 2 GB. I suspect that your implementation of malloc (glibc?, libc? eglibc?) uses mmap() for very large allocations. In which case, the page table entries won't be allocated and updated until the first time each page is accessed. (If you use 'strace' and 'ltrace' on your applications, you'll be able to tell if brk/sbrk/mmap were used). Did you touch one byte every page in your malloc()d region? It's likely that the page table entry is only filled in when the physical page is actually allocated, and you'd get a SIGSEGV (or SIGBUS) when you touch a page that exceeds any of the resource limits or the user va split. ulimit -aH will show the hard resource limits for your process if any have been established. >problems with ptrdiff_t and about malloc() returning a memory >area larger than all of RAM follows directly from first-hand >experience. I'd have to setup a 32-bit linux system (all mine are 64-bit) to check this, but if you have the kernel config for your distribution, it should show you whether your system has a 2GB or 3GB split on the VA space. In the latter case, a 2GB allocation will succeed, in the former case, if it succeeds, you've identified a bug (perhaps related to lazy allocation), since there is no physical way for an application to access more virtual address space than the user-side of the split, unless the kernel gives up some of the low-end of the kernel VA space, which I don't recall linux ever doing. |
| 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