strerror_r GNU flavor

strerror_r GNU flavor

[Jonny Grant]

Hello

Is it better to depreciate the GNU flavor of strerror_r now that there is a POSIX version?

I was reading "string.h" and the man page:

https://man7.org/linux/man-pages/man3/strerror.3.html

The man page does state :-

"The XSI-compliant strerror_r() is preferred for portable
applications.  It returns the error string in the user-supplied
buffer buf of length buflen."

Keeping the GNU version sounds reasonable, but at least marking it depreciated?

Some other queries :-
I noticed this page does not include the POSIX version of strerror_r

https://www.gnu.org/software/libc/manual/html_node/Error-Messages.html

Also, this page function definition says "size_t n" instead of the expected "size_t buflen", should that be changed? 

char * strerror_r (int errnum, char *buf, size_t n)

Cheers
Jonny

Re: strerror_r GNU flavor

[Adhemerval Zanella]

On 09/11/2021 07:33, Jonny Grant wrote:
> Hello
> 
> Is it better to depreciate the GNU flavor of strerror_r now that there is a POSIX version?
> 
> I was reading "string.h" and the man page:
> 
> https://man7.org/linux/man-pages/man3/strerror.3.html
> 
> The man page does state :-
> 
> "The XSI-compliant strerror_r() is preferred for portable
> applications.  It returns the error string in the user-supplied
> buffer buf of length buflen."
> 
> Keeping the GNU version sounds reasonable, but at least marking it depreciated?

The main problem is the GNU version is the one exported with _GNU_SOURCE.
It means to favor the XPG would require to export it as _GNU_SOURCE, which
leads to more potential breakage (since for programs that use _GNU_SOURCE
is likely to be troublesome to disable it). This is not a worthwhile change
and is definitely an *API* break.

> 
> Some other queries :-
> I noticed this page does not include the POSIX version of strerror_r
> 
> https://www.gnu.org/software/libc/manual/html_node/Error-Messages.html

Usually the manual favor on GNU extension, but I don't think this prevent
us to document POSIX functions as well.

> 
> Also, this page function definition says "size_t n" instead of the expected "size_t buflen", should that be changed? 

The variable name is meaningless in this context.

> 
> char * strerror_r (int errnum, char *buf, size_t n)
> 
> Cheers
> Jonny
> 

Re: strerror_r GNU flavor

[Jonny Grant]

On 09/11/2021 12:35, Adhemerval Zanella wrote:
> 
> 
> On 09/11/2021 07:33, Jonny Grant wrote:
>> Hello
>>
>> Is it better to depreciate the GNU flavor of strerror_r now that there is a POSIX version?
>>
>> I was reading "string.h" and the man page:
>>
>> https://man7.org/linux/man-pages/man3/strerror.3.html
>>
>> The man page does state :-
>>
>> "The XSI-compliant strerror_r() is preferred for portable
>> applications.  It returns the error string in the user-supplied
>> buffer buf of length buflen."
>>
>> Keeping the GNU version sounds reasonable, but at least marking it depreciated?
> 
> The main problem is the GNU version is the one exported with _GNU_SOURCE.
> It means to favor the XPG would require to export it as _GNU_SOURCE, which
> leads to more potential breakage (since for programs that use _GNU_SOURCE
> is likely to be troublesome to disable it). This is not a worthwhile change
> and is definitely an *API* break.

Thank you for your reply clarifying. Feels better to avoid defining _GNU_SOURCE so software is more portable.

> 
>>
>> Some other queries :-
>> I noticed this page does not include the POSIX version of strerror_r
>>
>> https://www.gnu.org/software/libc/manual/html_node/Error-Messages.html
> 
> Usually the manual favor on GNU extension, but I don't think this prevent
> us to document POSIX functions as well.

Would be good to document it. Should I raise a ticket for this somewhere?

>>
>> Also, this page function definition says "size_t n" instead of the expected "size_t buflen", should that be changed? 
> 
> The variable name is meaningless in this contex> 
>>
>> char * strerror_r (int errnum, char *buf, size_t n)

To me makes sense for everything to be consistent with the code, and POSIX which both use "buflen".  Of course we all know the compiler only matches the type, there don't need to be any parameter names at all there.

Kind regards
Jonny