From: Jonny Grant <jg@jguk.org>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>,
GNU C Library <libc-alpha@sourceware.org>
Subject: Re: strerror_r GNU flavor
Date: Tue, 9 Nov 2021 22:53:55 +0000 [thread overview]
Message-ID: <685e0693-88d5-1147-df9c-2eb98a50adca@jguk.org> (raw)
In-Reply-To: <8ef62689-64fc-1f47-a6b0-6af0c1dca8fe@linaro.org>
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
prev parent reply other threads:[~2021-11-09 22:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-09 10:33 Jonny Grant
2021-11-09 12:35 ` Adhemerval Zanella
2021-11-09 22:53 ` Jonny Grant [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=685e0693-88d5-1147-df9c-2eb98a50adca@jguk.org \
--to=jg@jguk.org \
--cc=adhemerval.zanella@linaro.org \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).