On 06/10/2025 00:03, Matthew Vernon wrote: > 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? > I do wonder if using strerror_r() is making things harder than it needs to be. It seems to be making stringErrorReport() non re-entrant anyway so why not just use strerror() and avoid the conflicting definitions of strerror_r() completely.
