This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH] Fix potential reent issue
- From: Corinna Vinschen <vinschen at redhat dot com>
- To: newlib at sourceware dot org
- Cc: Jeff Johnston <jjohnstn at redhat dot com>
- Date: Mon, 24 Jun 2013 11:37:42 +0200
- Subject: Re: [PATCH] Fix potential reent issue
- References: <BLU0-SMTP2494D64FD9A74C0AB89A85FF9890 at phx dot gbl> <51C73627 dot 50004 at op dot pl> <BLU0-SMTP192C475E7CC269954808547F9890 at phx dot gbl> <51C756D6 dot 3050207 at op dot pl>
- Reply-to: newlib at sourceware dot org
On Jun 23 22:13, Freddie Chopin wrote:
> W dniu 2013-06-23 21:40, Federico Terraneo pisze:
> >On 06/23/2013 07:53 PM, Freddie Chopin wrote:
> >>Hi!
> >>
> >>Wouldn't it be cleaner/simpler to use "_REENT" symbol (which is
> >>either "_impure_ptr" or "__getreent()") in place of faulty uses of
> >>_impure_ptr?
> >>
> >
> >The problem is that when _REENT_ONLY is defined, _REENT does not get
> >defined (look at sys/reent.h). I think it's this fact that caused the
> >faulty use of _impure_ptr, but if the definition of _REENT is enclosed
> >in an #ifndef _REENT_ONLY, there's probably a reason.
>
> Yes, you're right...
>
> Looking at repo history it seems that the _impure_ptr solution was
> older, then - 11 years ago - the one using _REENT was added, but the
> old variant remained unchanged for years.
>
> It seems to me that the "right" solution for _REENT_ONLY build would
> be to undefine stdin/stdout/stderr - delete the offending lines
> using _impure_ptr...
>
> If that solution is not feasible then your approach is probably the
> best one.
>
> BTW - I've CCed the list, you probably forgot about that.
I leave this problem for Jeff.
Corinna
--
Corinna Vinschen
Cygwin Maintainer
Red Hat