public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
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.

  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).