Re: [PATCH] Fix __fp_lock_all() and __fp_unlock_all()

Sebastian Huber <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <[email protected]>
On 19/05/2022 14:02, Corinna Vinschen wrote:
> On May 18 19:13, Sebastian Huber wrote:
>> For _REENT_GLOBAL_STDIO_STREAMS, lock/unlock all FILE objects.  In the
>> repository, this function is only used by Cygwin during process forks.  Since
>> Cygwin enabled _REENT_GLOBAL_STDIO_STREAMS recently, without this fix no FILE
>> object at all was locked.
>> ---
>>   newlib/libc/stdio/findfp.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/newlib/libc/stdio/findfp.c b/newlib/libc/stdio/findfp.c
>> index 6933ff1db..a39082387 100644
>> --- a/newlib/libc/stdio/findfp.c
>> +++ b/newlib/libc/stdio/findfp.c
>> @@ -333,6 +333,8 @@ __fp_lock_all (void)
>>   #ifndef _REENT_GLOBAL_STDIO_STREAMS
>>     ptr = _REENT;
>>     (void) _fwalk_sglue (ptr, __fp_lock, &ptr->__sglue);
>> +#else
>> +  (void) _fwalk_sglue (NULL, __fp_lock, &__sglue);
>>   #endif
> 
> The resulting __fp_lock_all/__fp_unlock_all functions look a bit weird
> to me, codewise. Counter-proposal:
> 
> diff --git a/newlib/libc/stdio/findfp.c b/newlib/libc/stdio/findfp.c
> index 118637a18f5b..ebfbf0976de5 100644
> --- a/newlib/libc/stdio/findfp.c
> +++ b/newlib/libc/stdio/findfp.c
> @@ -329,31 +329,24 @@ __fp_unlock (struct _reent * ptr __unused, FILE * fp)
>     return 0;
>   }
>   
> +#ifdef _REENT_GLOBAL_STDIO_STREAMS
> +# define _PTR NULL
> +# define _GLUE __sglue
> +#else
> +# define _PTR _REENT
> +# define _GLUE _PTR->__sglue
> +#endif
> +
>   void
>   __fp_lock_all (void)
>   {
> -#ifndef _REENT_GLOBAL_STDIO_STREAMS
> -  struct _reent *ptr;
> -#endif
> -
> -  __sfp_lock_acquire ();
> -
> -#ifndef _REENT_GLOBAL_STDIO_STREAMS
> -  ptr = _REENT;
> -  (void) _fwalk_sglue (ptr, __fp_lock, &ptr->__sglue);
> -#endif
> +  _fwalk_sglue (_PTR, __fp_lock, &_GLUE);
>   }
>   
>   void
>   __fp_unlock_all (void)
>   {
> -#ifndef _REENT_GLOBAL_STDIO_STREAMS
> -  struct _reent *ptr;
> -
> -  ptr = _REENT;
> -  (void) _fwalk_sglue (ptr, __fp_unlock, &ptr->__sglue);
> -#endif
> -
> +  _fwalk_sglue (_PTR, __fp_unlock, &_GLUE);
>     __sfp_lock_release ();
>   }
>   #endif
> 
> What do you think?

This patch was a preparation for this proposal:

https://sourceware.org/pipermail/newlib/2022/019735.html

It is a behaviour change for the default Newlib configuration, however, 
from my point of view it is more or less a bug fix.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: [email protected]
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.