https://bugs.kde.org/show_bug.cgi?id=497977
--- Comment #10 from Vincent Lefèvre <vincent-...@vinc17.net> --- (In reply to Florian Krohm from comment #9) > I agree that this message could be improved. Clearly, the bit pattern being > passed as 'size' argument is being > interpreted as an unsigned value. So it cannot possibly be negative. > Perhaps: > Argument 'size' of function malloc is excessively large: <value in hex>. > Perhaps a negative value of <negative value here> was passed. Yes, this would be much better. > I guess most people will agree that ~(SizeT)0 >>1 as malloc size is also > likely a symptom of a bug. But as it does not pass valgrind's fishiness > definition there will be no complaint. Which makes me think that being able > to provide a fishy value threshold on the command line might be worth > considering. IIRC, the only cases where I saw a huge allocation request were: * A test with a huge value on purpose as in the GNU MPFR testsuite (not a bug). * An attempt to allocate the space just because I was asking too much (not a bug), probably with GP/PARI or Maple. * The following bug in GMP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863217 where a negative value was really be passed, due to a size computation with the 32-bit int type and an integer overflow: -2^31 (which is INT_MIN). I think that this bug was fixed by the following commit, which changed the type of some variables from int to size_t: https://gmplib.org/repo/gmp/rev/725745f3637f -- You are receiving this mail because: You are watching all bug changes.
