[Bug c/67999] Wrong optimization of pointer comparisons

[msebor at gcc dot gnu.org]

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.