From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94344 invoked by alias); 7 Aug 2017 11:18:31 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 94324 invoked by uid 89); 7 Aug 2017 11:18:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=3.3 required=5.0 tests=AWL,BAYES_00,FOREIGN_BODY,RCVD_IN_DNSWL_NONE,SPF_PASS,T_FILL_THIS_FORM_SHORT autolearn=no version=3.3.2 spammy=Fax, Phone, phone X-HELO: dedi548.your-server.de Received: from dedi548.your-server.de (HELO dedi548.your-server.de) (85.10.215.148) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 07 Aug 2017 11:18:29 +0000 Received: from [78.47.166.52] (helo=sslproxy04.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1deg3H-0006xf-P5 for newlib@sourceware.org; Mon, 07 Aug 2017 13:18:27 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy04.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1deg3H-0003Pq-Eu for newlib@sourceware.org; Mon, 07 Aug 2017 13:18:27 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 421F92A004F for ; Mon, 7 Aug 2017 13:18:48 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id lgWZEYk3eQDs for ; Mon, 7 Aug 2017 13:18:47 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id EB5F92A1677 for ; Mon, 7 Aug 2017 13:18:46 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OKIjqyGd3aZT for ; Mon, 7 Aug 2017 13:18:46 +0200 (CEST) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 991E22A004F for ; Mon, 7 Aug 2017 13:18:46 +0200 (CEST) Subject: Re: [PATCH] Proper locking for getchar() and putchar() To: newlib@sourceware.org References: <20170807063330.16281-1-sebastian.huber@embedded-brains.de> <20170807094957.GA18389@calimero.vinschen.de> <5b3ee17d-6e9f-4421-b1d2-5279a7de9a28@embedded-brains.de> <20170807110821.GB21011@calimero.vinschen.de> From: Sebastian Huber Message-ID: Date: Mon, 07 Aug 2017 11:18:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170807110821.GB21011@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00727.txt.bz2 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 =3D _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(). --=20 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=C3=A4ftliche Mitteilung im Sinne des EHUG.