Hi,
Thanks for the detailed bug report.
On 21/08/2025 21:36, Chris Packham wrote:
But according to strerror(3) there are two possible implementations of
strerror_r().
int strerror_r(int errnum, char *buf, size_t buflen);
/* XSI-compliant */
char *strerror_r(int errnum, char *buf, size_t buflen);
/* GNU-specific */
strerror_r():
The XSI-compliant version is provided if:
(_POSIX_C_SOURCE >= 200112L) && ! _GNU_SOURCE
Otherwise, the GNU-specific version is provided.
GCC-14 now has _POSIX_C_SOURCE set to something higher than 200112L so we
appear to be getting the XSI compliant version of strerror_r() so simply adding
a cast is insufficient (and may lead to a null deference by the caller of
stringErrorReport()). This probably needs to be written as
static char err_message[128];
strerror_r(errno, err_message,128);
return err_message;
Or something should define _GNU_SOURCE to get the old behaviour.
I think you're right that the fix to 1074933 was incorrect, but I wonder
whether we should behave differently based on the feature test macros
that are set (i.e. that efence should be able to cope with either
version of strerror_r)? so something like
#if (_POSIX_C_SOURCE >= 200112L) && ! _GNU_SOURCE/* expect int return
*/#else
/* expect char * return */#endif?
Regards,
Matthew
