Re: Fw: [PATCH 03/14] Add _REENT_ERRNO(ptr)

On Jul 12 18:38, Sebastian Huber wrote:
> On 12/07/2022 18:11, Corinna Vinschen wrote:
> > On Jun 23 12:55, Sebastian Huber wrote:
> > > On 21/06/2022 16:41, C Howland wrote:
> > > > The new name is more consistent with the rest of the
> > > > things being done, while the old name is established and errno is a more
> > > > specialized case.  It probably would be a good idea to either
> > > > 1)  use __errno_r() instead of creating _REENT_ERRNO() or
> > > > 2)  replace __errno_r() with _REENT_ERRNO() as part of adding the latter.
> > > I would not remove an existing macro, so option 1) would be preferred by me.
> > Really?  Your followup patches introduce a lot of new _REENT_foo macros,
> > so defining one of them with a different name doesn't make a lot of sense,
> > does it?
> 
> There are lots of *_r() functions (for example _strdup_r()) so I assumed
> that this __errno_r() might be used outside of Newlib.
> 
> > 
> > Either all these macros should be called __foo_r(), or __errno_r() should
> > actually be removed or at least be defined in terms of _REENT_errno(),
> > if you really think we should keep it.
> 
> The original patch defined __errno_r() like this:
> 
> #define __errno_r(ptr) _REENT_ERRNO(ptr)
> 
> I think naming of the new _REENT_*() macros is quite consistent with the
> stuff we already have in <sys/reent.h>.
> 
> > Given that it's used only in
> > iconv/lib kind of shows that it was never meant for consumption outside
> > newlib anyway, isn't it?
> 
> What about renaming the existing __errno_r() uses in Newlib to
> _REENT_ERRNO() with a definition of __errno_r() in <sys/errno.h> for
> potential users outside of Newlib?

Sounds good to me.


Corinna