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

Groups > linux.debian.bugs.dist > #1264774 > unrolled thread

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

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

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

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

[toc] | [next] | [standalone]

#1264919

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web