https://bugs.kde.org/show_bug.cgi?id=497977
--- Comment #11 from Paul Floyd <pjfl...@wanadoo.fr> --- The smallest unsigned long that also looks like a signed long is 0x8000000000000000. That's 8 exbibytes. How many 256Gbyte DDR modules is that? About 33.5 million of them (32 mebimodules if you like). Let's say 20W each. That means over 600MW just for the system RAM. That's about 5 large data centres. It's going to take a couple of decades of Moore's Law (assuming that it doesn't run out of steam or in this case atoms) before that becomes practical. The two cases where I see this arising are 1. Bugs due to signed to unsigned conversion 2. Artificial testcases. For 32bit there is a fairly strong case for allowing addresses in the top half of the address space. I see no justification at all for 64bit (at least probably not in my lifetime). We could change the message to be something like "Argument '%s' of function %s has a fishy (possibly negative) value: %ld (signed) or %lu (unsigned)\n", That would give ==4026== Argument 'size' of function malloc has a fishy (possibly negative) value: -1 (signed) 18446744073709551615 (unsigned) ==4026== at 0x484D2E4: malloc (vg_replace_malloc.c:450) ==4026== by 0x2017E5: main (malloc3.c:15) or on 32 bit ==4037== Argument 'size' of function malloc has a fishy (possibly negative) value: -1 (signed) 4294967295 (unsigned) ==4037== at 0x74C1C42: malloc (vg_replace_malloc.c:450) ==4037== by 0x401629: main (malloc3.c:15) With a size of 0x8000000000000000 that gives ==4064== Argument 'size' of function malloc has a fishy (possibly negative) value: -9223372036854775808 (signed) 9223372036854775808 (unsigned) ==4064== at 0x484D2E4: malloc (vg_replace_malloc.c:450) ==4064== by 0x201846: main (malloc3.c:19) In this case both signed and unsigned values are nonsense. I don't see that as much of an improvement. -- You are receiving this mail because: You are watching all bug changes.
