Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.bugs.dist > #1264919

Bug#1111781: electric-fence: incorrect usage of strerror_r()

From Chris Packham <Chris.Packham@alliedtelesis.co.nz>
Newsgroups linux.debian.bugs.dist
Subject Bug#1111781: electric-fence: incorrect usage of strerror_r()
Date 2025-10-05 22:20 +0200
Message-ID <LCDn3-30CP-1@gated-at.bofh.it> (permalink)
References <Lmkop-9lyc-3@gated-at.bofh.it> <LCuMN-2UIW-1@gated-at.bofh.it> <Lmkop-9lyc-3@gated-at.bofh.it> <LCuMN-2UIW-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

Bug#1111781: electric-fence: incorrect usage of strerror_r() Matthew Vernon <matthew@debian.org> - 2025-10-05 13:10 +0200
  Bug#1111781: electric-fence: incorrect usage of strerror_r() Chris Packham <Chris.Packham@alliedtelesis.co.nz> - 2025-10-05 22:20 +0200

csiph-web