https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |msebor at gcc dot gnu.org
--- Comment #27 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to Alexander Cherepanov from comment #4)
> Interesting. In particular, this means that the warning "Argument 'size' of
> function malloc has a fishy (possibly negative) value" from valgrind is a
> serious thing. Is this gcc limitation documented somewhere? Is there a
> better reference than this bug?
GCC 7 and later mention it in the documentation of the
-Walloc-size-larger-than=n option. It should be documented more prominently.
They also diagnose the program in comment #0:
pr67999.c: In function ‘main’:
pr67999.c:7:15: warning: argument 1 value ‘3221225472’ exceeds maximum object
size 2147483647 [-Walloc-size-larger-than=]
char *buf = malloc(len);
^~~~~~~~~~~
In file included from pr67999.c:2:
/usr/include/stdlib.h:427:14: note: in a call to allocation function ‘malloc’
declared here
extern void *malloc (size_t __size) __THROW __attribute_malloc__ __wur;
^~~~~~
>
> Am I right that the C standards do not allow for such a limitation (and
> hence this should not be reported to glibc as a bug) and gcc is not
> standards-compliant in this regard? Or I'm missing something?
I think malloc() should fail for such large requests because objects that big
don't satisfy the basic requirements on pointer arithmetic.
