vsscanf() - sscanf() with a va_list parameter
#include <slack/vsscanf.h>
int vsscanf(const char *str, const char *fmt, va_list args);
Similar to sscanf(3) with the variable argument list specified directly as for vprintf(3).
Note that this may not be identical in behaviour to the sscanf(3) on your system because this was implemented from scratch for systems that lack vsscanf(). So your sscanf(3) and this vsscanf() share no common code. Your sscanf(3) may support extensions that vsscanf() does not support. vsscanf() complies with all of the relevant ISO C requirements for sscanf() except:
fmt
may not be a multibyte character string; and
Scanning a pointer ("%p"
) may not exactly match the format that your
printf(3) uses to print pointers on your system. This version accepts pointers as a
hexadecimal number with or without a preceeded 0x
.
MT-Safe if and only if no thread calls setlocale(3). Since locales are inherently non-threadsafe as they are currently
defined, this shouldn't be a problem. Just call setlocale(LC_ALL, "")
once after program initialisation and never again (at least not after
creating any threads). If it is a problem, just change localeconv()-
decimal_point[0]> in the source to '.'
and it will be MT-Safe at the expense of losing locale support.
gcc(1) warns that:
warning: ANSI C does not support the `L' length modifier warning: use of `l' length character with `e' type character
However, the ANSI C standard (Section 7.9.6.2) states that:
``Finally, the conversion specifiers e
, f
, and g
shall be preceeded by l
if the corresponding argument is a pointer to double rather than a pointer to float
, or by L
if it is a pointer to long double.``
I have chosen to disregard the gcc(1) warnings in favour of the standard. If you see the above warnings when compiling the unit tests for vsscanf(), just ignore them.
libslack(3), sscanf(3)
20011109 raf <raf@raf.org>