yes, there have been reports, but they seem to be ignoring them.

Victor
----- Original Message ----- 
From: "Felipe Sateler" 
To: "Developer discussions" 
Sent: Saturday, March 22, 2008 6:31 PM
Subject: Re: [Cs-dev] strtod() issue


> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/


--------------------------------------------------------------------------------


> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think that I am with Steven here.  If the C library functions cannot be
relied upon in all circumstances, then Csound should probably parse the
numbers itself.

I noticed some problems with code in argdecode.c and sscanf() too but not
related to locale, I think, so I will create a new topic.

Anthony

Steven Yi wrote on 3/22/08 3:10 PM:

> Is there an LGPL strtod implementation we can use and hardcode to use
> periods?  That seems like the most optimal solution to me.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Victor.Lazzarini@nuim.ie wrote:
> OK, that sounds like a plan. Does anyone have a replacement
> code handy, or knows how to write one quickly?

I just looked at glib's code:

 * g_ascii_strtod:
 * @nptr:    the string to convert to a numeric value.
 * @endptr:  if non-%NULL, it returns the character after
 *           the last character used in the conversion.
 *
 * Converts a string to a #gdouble value.
 * This function behaves like the standard strtod() function
 * does in the C locale. It does this without actually
 * changing the current locale, since that would not be
 * thread-safe.
 *
 * This function is typically used when reading configuration
 * files or other non-user input that should be locale independent.
 * To handle input from the user you should normally use the
 * locale-sensitive system strtod() function.

Sounds like what we need, doesn't it? glib is under GNU lesser public
license.

> ----- Original Message -----
> From: Anthony Kozar 
> Date: Sunday, March 23, 2008 8:06 pm
> Subject: Re: [Cs-dev] strtod() issue
> To: Csound Developer list 
> 
>> I think that I am with Steven here.  If the C library
>> functions cannot be
>> relied upon in all circumstances, then Csound should probably
>> parse the
>> numbers itself.
>>
>> I noticed some problems with code in argdecode.c and sscanf()
>> too but not
>> related to locale, I think, so I will create a new topic.
>>
>> Anthony
>>
>> Steven Yi wrote on 3/22/08 3:10 PM:
>>
>> > Is there an LGPL strtod implementation we can use and hardcode
>> to use
>> > periods?  That seems like the most optimal solution to me.


-- 
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Here's another alternative: http://pastebin.com/m5d7f82bb
It's a bit more elegant and lightweight (as all code by Andy Ross :),
and does not use strtod at all.

Steven Yi wrote:
> Interesting, I took a look at the code and it looks like it converts
> any periods to the locale used, then uses strtod.  Anyways, the code
> looks like we could definitely use it as a start and modify to not use
> gdouble, etc.
> 
> On Sun, Mar 23, 2008 at 2:49 PM, Jonatan Liljedahl  wrote:
>> Victor.Lazzarini@nuim.ie wrote:
>>
>>> OK, that sounds like a plan. Does anyone have a replacement
>>  > code handy, or knows how to write one quickly?
>>
>>  I just looked at glib's code:
>>
>>   * g_ascii_strtod:
>>   * @nptr:    the string to convert to a numeric value.
>>   * @endptr:  if non-%NULL, it returns the character after
>>   *           the last character used in the conversion.
>>   *
>>   * Converts a string to a #gdouble value.
>>   * This function behaves like the standard strtod() function
>>   * does in the C locale. It does this without actually
>>   * changing the current locale, since that would not be
>>   * thread-safe.
>>   *
>>   * This function is typically used when reading configuration
>>   * files or other non-user input that should be locale independent.
>>   * To handle input from the user you should normally use the
>>   * locale-sensitive system strtod() function.
>>
>>  Sounds like what we need, doesn't it? glib is under GNU lesser public
>>  license.
>>
>>
>>  > ----- Original Message -----
>>  > From: Anthony Kozar 
>>  > Date: Sunday, March 23, 2008 8:06 pm
>>  > Subject: Re: [Cs-dev] strtod() issue
>>  > To: Csound Developer list 
>>  >
>>  >> I think that I am with Steven here.  If the C library
>>  >> functions cannot be
>>  >> relied upon in all circumstances, then Csound should probably
>>  >> parse the
>>  >> numbers itself.
>>  >>
>>  >> I noticed some problems with code in argdecode.c and sscanf()
>>  >> too but not
>>  >> related to locale, I think, so I will create a new topic.
>>  >>
>>  >> Anthony
>>  >>
>>  >> Steven Yi wrote on 3/22/08 3:10 PM:
>>  >>
>>  >> > Is there an LGPL strtod implementation we can use and hardcode
>>  >> to use
>>  >> > periods?  That seems like the most optimal solution to me.
>>
>>
>>  --
>>  /Jonatan         [ http://kymatica.com ]
>>
>>  -------------------------------------------------------------------------
>>
>>
>> This SF.net email is sponsored by: Microsoft
>>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>>  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>  _______________________________________________
>>  Csound-devel mailing list
>>  Csound-devel@lists.sourceforge.net
>>  https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-- 
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net