[PATCH] Fix problem with file locking used before initialised

[Jeff Johnston]

Patch applied.  I noticed a flaw in that __sinit was unlocked so you could 
conceivably have two threads that called it in a race condition.  I added a lock 
for it and added a check once you acquire the lock that __sdidinit wasn't 
already set.

Thanks,

-- Jeff J.

Antony KING wrote:
> Please find attached a revised version of the following patch (replacing 
> the original submission) which adds some missing #includes of "local.h" 
> in files which had CHECK_INIT() calls added.
> 
> (I have also attached the patch file as text this time instead of as a 
> gzip'd attachment for easier perusal).
> 
> Cheers,
> 
> Antony.
> 
> Antony King wrote:
> 
>> Please find attached a patch against libc in newlib to fix I a problem 
>> I have encountered in the use of the _flockfile/_funlockfile API on 
>> the standard I/O streams (stderr, stdout and stdin).
>>
>> The problems stems from the fact that the FILE objects for these I/O 
>> streams are initially statically allocated in the global re-entrancy 
>> structure (aka the "impure" pointer) and they are not 100% initialised 
>> by static initialisation. This is overcome by the use of the 
>> CHECK_INIT and _REENT_SMALL_CHECK_INIT macros which complete the 
>> initialisation of the standard FILE I/O objects in a re-entrancy 
>> structure. As part of the initialisation of the standard I/O FILE 
>> objects the file lock objects are initialised.
>>
>> Unfortunately the _flockfile/_funlockfile functions are used before 
>> CHECK_INIT is called and therefore the FILE lock object could end up 
>> in an unknown state depending on the implementation of the FILE lock 
>> object and the method of initialisation. To solve this problem it is 
>> necessary to call CHECK_INIT before _flockfile/_funlockfile are called 
>> in any function that takes a FILE * object as an argument (which 
>> normally is a user level function). The attached patch attempts to fix 
>> this problem.
>>
>> Note that I have modified some machine specific files unfortunately I 
>> am unable to test so you may not wish to commit these changes (powerpc 
>> and arm files).
>>
>> Cheers,
>>
>> Antony.