Open System Services Programmer's Guide

Different Behavior for C Language I/O Functions
The SPT library intercepts calls to C language I/O functions (such as fgetc(), fprintf(), and
so forth) made by SPT application modules and, because it processes certain outcomes internally,
never reports that an operation failed because of a situation in which errno would be set to
EWOULDBLOCK (or to values describing a few other similar situations).
Because the logic of the PUT Model library is different, calls to C language I/O functions can
complete with errno set to values that report that an operation failed but that the operation might
succeed if retried. Consequently, the logic of an application module that calls a C language I/O
function might need to be revised if the input-ouput resource accessed by the applicable FILE *
can terminate with errno set to one of these values. For information about the behaviors and
possible errno values for a function, see the reference page for that function either online or in
the Open System Services Library Calls Reference Manual.
The SPT library functions implement C language I/O behavior by calling the corresponding C
run-time library (RTL) I/O functions. Those C RTL functions perform the actual I/O operations by
calling process-blocking file system functions (for example, fread() calls read() to obtain data
from the file). In contrast, when applications use the PUT Model library, the C RTL I/O function
services calls non-blocking thread-library functions provided by the PUT Model library. This difference
can invalidate application logic that depends upon the behavior of library logic.
For example, assume a client provides a logging facility that, to guarantee the log data written to
the file is contiguous (that is, no other thread can intersperse any data), depends upon output
operations being executed without the possibility of a thread switch:
• Calling fprintf() to output trace data to the log file is safe for an application that uses the
SPT library but not for an application that uses the PUT Model library. An application that
uses the PUT Model library fprintf() logic could call a PUT Model library version of a
write function that initiates a non-blocking output operation and then allows a different thread
to become active.
• To maintain the SPT library behavior, the application logic must change. For example, you
could replace the fprintf() call with a call to sprintf() followed by a call to write().
Note that even this example works only if the logging logic is in an application module
compiled with macro _PUT_MODEL_ undefined. (Compiling the module with macro
_PUT_MODEL_ defined would translate the textual reference to system function write() into
code that calls the PUT non-blocking write function. The behavior would then be equivalent
to that of fprintf().)
An application module could call the SPT variant of a C language I/O function directly; for example,
spt_fread(). Such calls must be replaced with calls to the base function; for example, fread().
The functions of this kind are:
putc()fread()fclose()
putchar()fwrite()fflush()
puts()getc()fgetc()
putw()getchar()fgets()
putwc()gets()fgetwc()
putwchar()getw()fprintf()
vfprintf()getwc()fputc()
vprintf()getwchar()fputs()
printf()fputwc()
Thread-Aware Signal Handling
An application that uses the SPT library can either enable thread-aware signal handling or leave
this behavior disabled. For an application that uses the PUT Model library, thread-aware signal
handling is always enabled. Consequently, if an application that uses the SPT library is not prepared
Converting Applications that use the SPT Library 427