RE: wcstod/wcstof

["Howland Craig D (Craig)" <howland at LGSInnovations dot com>]

The exact same approach question applies to wcsftime.  In my version of
it (that I just mentioned yesterday in a different email thread), I
took the second approach.  The reasons that I took the second approach
for
it follow.  But first, a third method, which is a variation of the
second:
 
o Share source code that compiles to either strtod or wcstod
   + Maintenance is much easier than the copy approach
   + As fast as strtod.
   + Reliable endptr.
   - Much bigger code.
(A minor variation of this would be to generate the files from a common
starting point.  I chose to use the preprocessor to differentiate rather
than needing other support scripts like sed|awk|sh|etc.)

A thought and a question on the bigger code negative:
It is only much bigger if a user uses both functions (i.e. if both
the normal and wide char versions actually are linked).
Do applications that use wide-char functions also typically use the
same respective plain char functions?
 
To make the following discussion easier to say, I'll define some new
terms:
Corinna's first approach (wchar-mb conversion) is a "coupled-function"
approach (because wsctod is coupled to--calls--strtod).
Corinna's second is the "copied-code parallel-function" approach (the
method of paralleling is to copy, "copied-code" for short).
My addition is the "shared-code parallel-function" method, "shared-code"
for short.
 
My reasoning for selecting the shared-code approach for wcsftime back in
December was:
1)  A user is not that likely to use both strftime and wcsftime at the
same time.  (This might be reasonable for wcsftime, but quite possibly
not for strtod.)  Especially not if overall object size was of big
concern.
2)  FreeBSD's wcsftime, using the coupled-function approach, is not
exactly tiny.  And worse, it contains comments that the approach taken
might not work properly in all situations.
3)  The coupled-function approach relies on strftime properly handling
strings with mb characters.  Testing this would be non-trivial.  (I know
that it is supposed to per the C99 standard, but that doesn't mean that
it does or has already been tested for it.  The "[PATCH] gethex doesn't
cope with multibyte decimalpoints" thread that Corinna started today
helps to demonstrate that the concern about coupling has a valid basis.)
4)  The copied-code method is undesirable in terms of maintenance, as
any problems found need to be fixed (most likely) in two places.  The
shared and coupled approaches do not have this problem.

So for wcsftime with the shared-code method, I decided that the pros
clearly outweighed the cons.  (But even though I chose the
parallel-function approach, I was still wondering if the
coupled-function approach should be available via #defines as you are
also asking.  But at the time I decided not to bother, thinking that if
someone were to need both wcsftime and strftime at the same time and
had very stringent size restrictions that the alternate approach could
be
added at that time.  The FreeBSD comments scared me the most.)
 
I had been waiting until swprintf was available to put these out for
consideration, but I'll include them now for observation since the
general
question about approaches is identical.  Refer to the attached files
wcsftime.c (a very simple wrapper), and strftime.c (a modification of
the present strftime.c to allow for either str or wcs to be done--not as
pretty as I would have liked, but not too bad).  (These are just for
looking at to help decide approaches.  I'll send a proper patch later
with these and the associated other changes needed.)
 
Craig


-----Original Message-----
From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
On Behalf Of Corinna Vinschen
Sent: Friday, February 06, 2009 6:31 AM
To: newlib@sourceware.org
Subject: Re: wcstod/wcstof

On Feb  6 11:29, Corinna Vinschen wrote:
> Hi,
> 
> there are two possible ways to implement wcstod/wcstof:
> 
> o Convert the wchar string to multibyte and call strtod.
> 
>   + Very tiny code.  Good for embedded targets.
>   - The endptr position is not reliable.
>   - Slower than strtod.
> 
> o Copy the entire code from strtod.c and just 

...convert all chars to wchars.

> 
>   + As fast as strtod.
>   + Reliable endptr.
>   - Much bigger code.
> 
> Which solution is preferrable for newlib?  Maybe both, dependent on
> PREFER_SIZE_OVER_SPEED/__OPTIMIZE_SIZE__?


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

Attachment: wcsftime.c
Description: wcsftime.c

Attachment: strftime.c
Description: strftime.c