[PATCH] New functions wprintf, fwprintf, swprintf, vwprintf, vfwprintf, vswprintf

Howland Craig D (Craig) howland@LGSInnovations.com
Tue Mar 10 03:03:00 GMT 2009


I've been looking in detail at the new wprintf functions, and have a few
questions.  (I've also found a few problems, for which I've developed
patches.  I'll send them later, once at least some of these issues
get resolved.)
 
1)  There's a comment in vfwprintf.c (copied verbatim from vfprintf.c,
so this is nothing new) regarding the POSIX "'" flag (an extension to
C99):

/* The ' flag is required by POSIX, but not C99.
   In the C locale, LC_NUMERIC requires
   thousands_sep to be the empty string.  And since
   no other locales are supported (yet), this flag
   is currently a no-op.  */
 
Is the statement regarding no other locales still true given the recent
updates to the locale stuff?  That is, could this ' flag be made
operable now?
(If other locales can be used such that ' could actually work from the
locale point of view, we ought to modify the documentation to point
out that ' is currently a no-op despite locale working.  Otherwise the
docs could be left alone.)
 
2)  In the string form of the functions, there's an odd return check,
which has also been copied from the non-wide starting-point code.  For
example, lines 583-586 of swprintf.c:
 
  ret = _svfwprintf_r (ptr, &f, fmt, ap);
  va_end (ap);
  if (ret < EOF)
    ptr->_errno = EOVERFLOW;
 
As far as I could see from a brief look through _svfwprintf_r(), it
cannot
return anything < EOF.  (Nor can _svfprintf_r().)  The EOVERFLOW return
for the conditions described in the docs is handled further up, before
_svfwprintf_r() is called.  Does anyone know what the real purpose of
this check is?  (It is not a simple typo for "if(ret < 0)" assuming that
the only error return from _svfwprintf_r() is that it ran out of space,
as _svfwprintf_r() does not return an error if it ran out of space in
the string.  Rather, it returns how many characters would have been put
into the string while only putting in one less than the max, allowing
room for '\0' to be appended.)
     I think that it should be modified to be:

  ret = _svfwprintf_r (ptr, &f, fmt, ap);
  va_end (ap);
  if (ret >= size)
    ptr->_errno = EOVERFLOW;
 
(I presently have done this in my local testing copy, along with the
other changes that I have, but wanted to get a second opinion since the
original if does not make sense to me.)
 
3)  The documentation says only POSIX-1.2008.  Was C99 purposely left
out?
I'd think that C99 should be mentioned, and the POSIX extensions to C99
highlighted in the documentation.  (If there's agreement that this
approach makes sense, I'll do so when I send patches later for the bug
fixes that I have so far.)
 
4)  Should the POSIX extensions be conditionally able to be left out?
(I'm not inclined at the moment to do all the work involved to do so,
but could add #if !defined(POSIX_EXT) (or something similar) that
would allow it easily to be added later to configure, since now is a
good time to put it in the source while I'm thinking about it and have
all the information at hand.  In this way, they'd be in by default and
could be left out later if the need arose.  If someone else that was
familiar with configure were to help, we could add it now, with the
default
of no POSIX extensions.)  I'm asking this since the base claim of Newlib
is being a "simple ANSI C library" (from README), so it seems that
skipping extras should be easy.  Thoughts?  (Sounds like something for
which the end answer needs Jeff's opinion in addition to everyone
else's.)
 
FYI, the aforementioned problems that I found and have developed fixes
for are that the string forms do not correctly put the terminating '\0'
in (at least not when sizeof(wchar_t) > 1), and that the string forms
are supposed to return an error if size is exceeded.  (The POSIX man
page fails to mention this part of the C99 standard, but it is still a
requirement since POSIX explicitly defers to C99.)  The former fault
is probably due to unclear coding in vfprintf.c, so that when porting to
wide it was not obvious that a wide change was needed.  The latter is
due
to the oversight (error) in the POSIX manual.
 
Craig



More information about the Newlib mailing list