Query concerning use of flockfile/funlockfile in stdio FILE related functions

[Jeff Johnston]

Antony KING wrote:
> Hello,
> 
> I have a query concerning the use of the flockfile/funlockfile functions 
>  in the stdio sub-component of newlib. It relates to a requirement we 
> have of being able to call the sprintf/sscanf class of functions from 
> interrupt handlers in our RTOS.
> 
> One of the restrictions of interrupt handlers in our RTOS is that they 
> cannot block on synchronisation objects which is unfortunate since the 
> sprintf/sscanf class of objects implicitly use the locking API defined 
> in sys/lock.h via flockfile/funlockfile (I have implemented the locking 
> API using the synchronisation objects available in our RTOS).
>

Anthony, in the sprintf/sscanf case, as you have noted, the lock object is only 
known to the sprintf or sscanf functions (they are part of local FILE objects). 
  Thus, there should never be a blocking situation which technically meets the 
"letter of the law" stated above.  Is the restriction more strict than you have 
noted?

I have noticed that the local FILE lock objects are not being initialized which 
is an error :(.

> This restriction is not a problem when using FILE objects created via 
> fopen et al since they normally refer to resources which require the 
> proper thread protection afforded by the locking API. However for the 
> sprintf/sscanf class of functions using the locking API is unnecessary 
> since the FILE objects created by these functions for use by the "real" 
> functions _vfprintf_r/__svfscanf_r should be inherently thread safe (as 
> they are allocated off the stack).
> 
> It should therefore be possible to dynamically detect this scenario and 
> not use the locking API and hence allow me to use the sprintf/sscanf 
> functions from my interrupt handlers.
> 
> Ideally I would like to add a flag to the _flags field of the FILE 
> structure to indicate whether a lock object is present or not but 
> unfortunately there are no free bits left. Another possibility would 
> have been to use the fact that the sprintf/sscanf fucntions set the 
> _file field of the FILE structure to -1 but thus is not reliable since 
> it can take the value of -1 in other instances.
> 
> One thought is to extend the locking API to to include "not initialised" 
> initialiser APIs whose purpose is to allow the locking API acquire and 
> release methods detect this state and ignore the lock/unlock requests. 
> Its not very nice but would work without changing the layout of the FILE 
> structure (by increasing the size of the _flags field from 16 bits to 32 
> bits). Also I am uncertain how this change to the locking API would 
> impact other implementations (e.g. linux/cygwin).
> 

The locking API should not be changed.  It is easy enough to check for the 
__SSTR flag to avoid locking.  This flag is set for all the string printf 
operations but isn't currently used for the sscanf set.

-- Jeff J.