From: Sebastian Huber <sebastian.huber@embedded-brains.de>
To: newlib@sourceware.org
Subject: Re: [PATCH] Proper locking for getchar() and putchar()
Date: Mon, 07 Aug 2017 11:18:00 -0000 [thread overview]
Message-ID: <d59199e1-a84f-8988-274d-de64ed9fef26@embedded-brains.de> (raw)
In-Reply-To: <20170807110821.GB21011@calimero.vinschen.de>
On 07/08/17 13:08, Corinna Vinschen wrote:
> On Aug 7 12:53, Sebastian Huber wrote:
>> On 07/08/17 11:49, Corinna Vinschen wrote:
>>
>>> Hi Sebastian,
>>>
>>> On Aug 7 08:33, Sebastian Huber wrote:
>>>> +#ifdef __SINGLE_THREAD__
>>>> +#define getc(_p) __sgetc_r(_REENT, _p)
>>>> +#define putc(_c, _p) __sputc_r(_REENT, _c, _p)
>>>> +#define getchar() _getchar_unlocked()
>>>> +#define putchar(_c) _putchar_unlocked(_c)
>>>> +#endif /* __SINGLE_THREAD__ */
>>>> #endif /* __cplusplus */
>>> That looks good, but I wonder, wouldn't it make sense to replace the
>>> inline _getchar_unlocked/_putchar_unlocked with inline
>>> _getc_unlocked/_puts_unlocked?
>>>
>>> I'm asking because that would allow to #define all four,
>>> getc/putc/getchar/putchar, so that the parameters are only evaluated
>>> once.
>>>
>>> What do you think?
>> For getc()/putc() you have the FILE object already and only need _REENT.
>>
>> For getchar()/putchar() you have nothing and need the _REENT plus
>> stdin/stdout.
>>
>> I don't know how you would unify/simplify this further?
> I wasn't thinking of simplification. You said it yourself, your
> implementation has the benefit of evaluating the reent pointer only
> once. While looking into your patch, it immediately struck me as
> beneficial to getc/putc, too. So I was thinking of something like
>
> inline _getc_unlocked (_p)
> {
> struct _reent *_ptr = _REENT;
This would be the 2st call to __getreent().
> return (__sgetc_r(_ptr, _p)_;
> }
> #define getc(_p) _getc_unlocked(_p)
> #define getchar() _getc_unlocked(_stdin_r(_REENT))
This would be the 1nd call to __getreent().
>
> Does that make sense?
Not if you want to avoid multiple calls to __getreent().
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
next prev parent reply other threads:[~2017-08-07 11:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-07 6:33 Sebastian Huber
2017-08-07 9:50 ` Corinna Vinschen
2017-08-07 10:53 ` Sebastian Huber
2017-08-07 11:08 ` Corinna Vinschen
2017-08-07 11:18 ` Sebastian Huber [this message]
2017-08-07 11:57 ` Corinna Vinschen
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=d59199e1-a84f-8988-274d-de64ed9fef26@embedded-brains.de \
--to=sebastian.huber@embedded-brains.de \
--cc=newlib@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).