This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


This must have been a lot of work.
 
A couple of philosophical questions.  (I took a quick scan, for
starters.)
 
Since the wide-character functions were introduced for C99, which also
introduced and requires the long long (and long double) types, does it
make sense to propagate the printf _WANT_IO_LONG_LONG configuration
option to the wide functions?
 
Should the Newlib printf flag extensions (DOUq) be kept for wprintf?
 
I propose that the answer to both is no, some arguments being as
follows.
(If there is agreement that either or both of these should be
removed, I'd be happy to do so.)

This is a clean start.  There is no code using the extensions to worry
about breaking upon removal; printf cannot be cleaned up due to
historical reasons, but wprintf has no such history to be used as the
argument.
 
If these two items are desirable for some reason such that they should
be kept, they ought to be disabled by default, since the best default
is standard-compliant.  The user should have to add extensions on
purpose,
in general.  Of course, this becomes tricky as it would be undesirable
to
have two different option names for the printf vs. wprintf, and the
former is not desired to be changed for historical purposes.  This is
why not having the options is better, as it avoids this false dilemma.
 
Regarding the flags specifically, none of them are worth it.  q probably
exists from before ll was introduced.  Standing for "quad", it does not
even mean that on many systems today, as 32-bit int is common so 64
is really only double.  (Not only that, but the q flag extension is a
back door around the _WANT_IO_LONG_LONG option.  If you want to skip
long long to somehow save code space, you really are not doing do
because
the long long decoding needs to be pulled in for q, anyway.)  Since
D, O, and U are just shorthand (%D -> %ld, %O -> %lo, %U -> %lu), they
are of no practical value, and are even negative value as their use
makes people's code non-portable.
 
Craig

-----Original Message-----
From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
On Behalf Of Corinna Vinschen
Sent: Thursday, March 05, 2009 1:03 PM
To: newlib@sourceware.org
Subject: [PATCH] New functions wprintf, fwprintf, swprintf, vwprintf,
vfwprintf, vswprintf

Hi,

attached inline is a patch which adds the wprintf family of functions
according to the POSIX-1.2008 definition.

Basically the functions are copied from their non-w counterparts.
However, there's one big change.  So far there were multiple versions of
the __sprint_r functions defined.  Since these functions can be shared
between all versions of vfprintf/vfwprintf, and since especially the
STRING_ONLY variant of these functions is not that small, I made an
additional effort to have only one __sprint_r function and only one
__ssprint_r function, the latter being the STRING_ONLY version.  Using
different names was necessary because the functions are naturally not
static anymore.

The handling of the s, ls, c, lc format specifier follows exactly the
POSIX-1.2008 definition.

Of course I tested this new functionality on Cygwin.  Having said that,
I would very much appreciate if other people on this list would give
this functionality some additional testing.  printf is such a complex
function, I could hardly test it all.

wscanf anybody?


Corinna


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]