public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: Jonny Grant <jg@jguk.org>, libc-alpha@sourceware.org
Subject: Re: glibc strerrorname_np
Date: Thu, 4 Nov 2021 20:28:32 -0300	[thread overview]
Message-ID: <77e058e8-2f54-46a5-2180-9784f23040e7@linaro.org> (raw)
In-Reply-To: <9613b21a-3ab0-3303-9321-7bf4e36ce7ed@jguk.org>



On 04/11/2021 19:52, Jonny Grant wrote:
> Hi Adhemerval, Thank you for you reply.
> 
> On 04/11/2021 20:46, Adhemerval Zanella wrote:
>>
>>
>> On 04/11/2021 17:23, Jonny Grant wrote:
>>> Hi Carlos
>>> I was pleased to see you added strerrorname_np()
>>>
>>> May I ask, I couldn't find the file your implementation is in - could you point it out to me in the glibc repository please?
>>
>> It is on string/strerrorname_np.c, which calls __get_errname() defined at
>> stdio-common/errlist.c.
> 
> Ok yes, I see in glibc/stdio-common/errlist.c the __get_errname() implementation.
> 
>>> I noticed on the man page it may return NULL, which is a shame, as then it means we always need to check that before using in every printf etc :-
>>>
>>> printf("err %s\n", strerrorname_np(myerr)?strerrorname_np(myerr), "Unknown err");
>>
>> I didn't considered printf() when I added strerrorname_np(). Maybe an empty string ("")
>> would be better than NULL.
> 
> Yes, "" empty string sounds great.
>  
>>> I'd done my own version a while ago as strerrno_s(), and assumed I could never get it accepted anywhere like glibc.
>>> Probably I should have tried to submit it to glibc!
>>> https://github.com/jonnygrant/safec/blob/master/strerrno.c
>>>
>>> Would something like my implementation ever be accepted?
>>> errno_t strerrno_s(char * const buf, const rsize_t buflen, const errno_t errnum)
>>
>> So this is basically:
>>
>>   int strerrno_s (char *buf, size_t buflen, int errnum)
>>   {
>>     const char *r = strerrorname_np (errnum);
>>     __snprintf (buf, buflen, "%s", r == NULL ? "" : r);
>>     return errnum;
>>   }
>>
>> I don't see much gain on adding another wrapper to format errno, the idea of
>> strerrorname_np() was to provide a async-signal-safe way to map errno to
>> string (by avoiding translation).
> 
> Yes, I should migrate to your strerrorname_np() version soon. If you could change it to return "" instead of NULL, that would be very much appreciated to avoid any accidental SEGV.

This is most likely an ABI break and I really like to avoid it since it would
require an new version and another implementation for such symbol.

  reply	other threads:[~2021-11-04 23:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-04 20:23 Jonny Grant
2021-11-04 20:46 ` Adhemerval Zanella
2021-11-04 22:52   ` Jonny Grant
2021-11-04 23:28     ` Adhemerval Zanella [this message]
2021-11-05 11:51       ` Jonny Grant
2021-11-05 13:01         ` Adhemerval Zanella
2021-11-05 22:23           ` Jonny Grant
2021-11-06 12:51             ` Adhemerval Zanella
2021-11-07 17:37               ` Zack Weinberg
2021-11-08 13:56                 ` Adhemerval Zanella
2021-11-08 18:42                   ` Zack Weinberg
2021-11-08 18:52                     ` Adhemerval Zanella
2021-11-08 19:56                       ` Florian Weimer
2021-11-08 20:28                         ` Adhemerval Zanella
2021-11-08 22:22               ` Jonny Grant
2021-11-09 12:30                 ` Adhemerval Zanella
2021-11-09 23:01                   ` Jonny Grant
2021-11-10  1:37                     ` Adhemerval Zanella
2021-11-08  8:36 ` Florian Weimer
2021-11-08 13:36   ` Jonny Grant
2021-11-08 13:42     ` Florian Weimer
2021-11-08 22:14       ` Jonny Grant
2021-11-08 14:01   ` Adhemerval Zanella

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=77e058e8-2f54-46a5-2180-9784f23040e7@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=jg@jguk.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).