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

[Corinna Vinschen]

On Jun 23 12:55, Sebastian Huber wrote:
> On 21/06/2022 16:41, C Howland wrote:
> > > 
> > > ------------------------------
> > > *From:* Newlib<newlib-bounces+craig.howland=caci.com@sourceware.org>  on
> > > behalf of Sebastian Huber<sebastian.huber@embedded-brains.de>
> > > *Sent:* Tuesday, June 21, 2022 8:49 AM
> > > *To:*newlib@sourceware.org  <newlib@sourceware.org>
> > > *Subject:* [PATCH 03/14] Add _REENT_ERRNO(ptr)
> > > 
> > > 
> > > 
> > > From: Matt Joyce<matthew.joyce@embedded-brains.de>
> > > 
> > > Add a _REENT_ERRNO() macro to encapsulate the access to the
> > > _errno member of struct reent. This will help to replace the
> > > structure member with a thread-local storage object in a follow
> > > up patch.
> > > ---
> > > 
> > There already exists an __errno_r() macro that does the very same function
> > (defined in sys/errno.h).  (Its use, however, is limited, only being used
> > in files under iconv/lib.)  Having the same thing done both ways probably
> > doesn't make sense.  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?

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

Jeff?


Corinna