public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Corinna Vinschen <vinschen@redhat.com>
To: newlib@sourceware.org
Subject: Re: Broken getchar() and putchar() macros?
Date: Wed, 02 Aug 2017 12:37:00 -0000	[thread overview]
Message-ID: <20170802123722.GI25551@calimero.vinschen.de> (raw)
In-Reply-To: <80e430fc-e931-d9a0-173e-8a66e2a494b6@embedded-brains.de>

[-- Attachment #1: Type: text/plain, Size: 2579 bytes --]

On Aug  2 13:36, Sebastian Huber wrote:
> Hello,
> 
> we have via <stdio.h>
> 
> #define    getchar()    getc(stdin)
> #define    putchar(x)    putc(x, stdout)
> 
> which is
> 
> #ifndef __CYGWIN__
> #ifndef lint
> #define    getc(fp)    __sgetc_r(_REENT, fp)
> #define putc(x, fp)    __sputc_r(_REENT, x, fp)
> #endif /* lint */
> #endif /* __CYGWIN__ */
> #endif /* __cplusplus */
> 
> which is mostly
> 
> #define __sgetc_r(__ptr, __p) __sgetc_raw_r(__ptr, __p)
> 
> #define __sputc_r(__ptr, __c, __p) __sputc_raw_r(__ptr, __c, __p)
> 
> which is
> 
> /*
>  * The __sfoo macros are here so that we can
>  * define function versions in the C library.
>  */
> #define       __sgetc_raw_r(__ptr, __f) (--(__f)->_r < 0 ? __srget_r(__ptr,
> __f) : (int)(*(__f)->_p++))
> 
> _ELIDABLE_INLINE int __sputc_r(struct _reent *_ptr, int _c, FILE *_p) {
> #ifdef __SCLE
>     if ((_p->_flags & __SCLE) && _c == '\n')
>       __sputc_r (_ptr, '\r', _p);
> #endif
>     if (--_p->_w >= 0 || (_p->_w >= _p->_lbfsize && (char)_c != '\n'))
>         return (*_p->_p++ = _c);
>     else
>         return (__swbuf_r(_ptr, _c, _p));
> }
> 
> which modifies FILE members without protection of the FILE lock!
> [...]
> What is the purpose of these macros?

If you search for them in newlib, you'll notice that the macros are used
from a couple of places in libc/stdio.

The fact that they are directly called on non-Cygwin platforms is probably
historical, as usual.  They are reentrant.  As such, and under the
assumption that we're on embedded platforms without preemptive
multi-tasking, the macros work nicely and are faster than the function
calls.

I can think of four ways to solve this:

1.  Just add RTEMS to the exceptions, same as Cygwin.

2. Replace

    #define    getc(fp)    __sgetc_r(_REENT, fp)
    #define putc(x, fp)    __sputc_r(_REENT, x, fp)

  with 

    #define    getc_unlocked(fp)    __sgetc_r(_REENT, fp)
    #define putc_unlocked(x, fp)    __sputc_r(_REENT, x, fp)

  and let getc/putc simply call the functions.

3. Add a newlib setting to sys/config.h and use that in stdio.h, rather
   than excluding targets explicitely.  Best is probably an opt-in
   config.

4. Move the macros to libc/stdio/local.h and don't use them from
   user space at all.  This may be a bit harsh on some embedded
   targets, but actually I don't know.  Most targets have space
   constraints and a function would be more prudent then, I guess.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

      reply	other threads:[~2017-08-02 12:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-02 11:36 Sebastian Huber
2017-08-02 12:37 ` Corinna Vinschen [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=20170802123722.GI25551@calimero.vinschen.de \
    --to=vinschen@redhat.com \
    --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).