https://bugs.kde.org/show_bug.cgi?id=217695
Mark Wielaard <m...@klomp.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |m...@klomp.org
--- Comment #2 from Mark Wielaard <m...@klomp.org> ---
(In reply to Ashe David Goulding from comment #1)
> Can be reproducible by calling `calloc()` with values that would result in
> overflow. All the dynamic memory allocation system calls(malloc, calloc,
> realloc) set `errno` to ENOMEM when they return NULL. This is POSIX
> compliant.
>
> Granted, no one checks errno. We all assume that allocation failed when the
> functions return NULL. But there are use cases where errno is used for
> diagnostic purposes. That's how I found this bug anyway.
>
> This bug is 11 years old. Would someone please at least give this bug a
> verdict? I'd take WONTFIX as an answer.
In theory this (setting errno to ENOMEM on an allocation function returning
NULL) could be supported. But it is not that easy to do correct without knowing
how the libc the program is running against handles errno. In practice this is
always glibc, so maybe we can try.
To show why this is non-trivial from errno(3):
errno is defined by the ISO C standard to be a modifiable lvalue
of type int, and must not be explicitly declared; errno may be a
macro.
And glibc defines it as:
extern int *__errno_location (void) __THROW __attribute__ ((__const__));
#define errno (*__errno_location ())
Now the malloc intercepts actually run on the simulated cpu (see
coregrind/m_replacemalloc/vg_replace_malloc.c) and could in theory use the
above definition to set errno to ENOMEM in ALLOC_or_NULL (when NULL).
But that would make that vg_replace_malloc rely on a libc that has the magic
__errno_location function.
--
You are receiving this mail because:
You are watching all bug changes.
