standards/51292: [PATCH] add ecvt()/fcvt()/gcvt() functions (SUSv3)

Sergey A. Osokin osa at freebsd.org.ru
Fri Apr 25 05:40:16 PDT 2003


The following reply was made to PR standards/51292; it has been noted by GNATS.

From: "Sergey A. Osokin" <osa at freebsd.org.ru>
To: Alexey Zelkin <phantom at FreeBSD.org.ua>
Cc: FreeBSD-gnats-submit at freebsd.org
Subject: Re: standards/51292: [PATCH] add ecvt()/fcvt()/gcvt() functions (SUSv3)
Date: Fri, 25 Apr 2003 16:32:10 +0400

 On Fri, Apr 25, 2003 at 03:19:37PM +0300, Alexey Zelkin wrote:
 > On Fri, Apr 25, 2003 at 12:38:51PM +0400, Sergey A. Osokin wrote:
 > 
 > > > > >Number:         51292
 > > > > >Category:       standards
 > > > > >Synopsis:       [PATCH] add ecvt()/fcvt()/gcvt() functions (SUSv3)
 > > > 
 > > > Few questions related to code:
 > > > 
 > > > 1. What's a reason to have some LANG handling logic here ?
 > > 
 > > Because standart says:
 > > The radix character is determined by the current locale.
 > > Follow this way: check LANG, then set locale.
 > 
 > First sentence is correct, but second one is wrong.  radix character
 > is a 'property' of LC_NUMERIC locale category.  So, having LANG=C
 > and LC_NUMERIC=ru_RU.KOI8-R should use russian locale radix character.
 
 OK.
 
 > Actually, all these cases should be handled by setlocale() itself.  And
 > after call to 'setlocale()' you should use lconv() to receive current
 > radix character.
 > I also would object to using of setlocale() from libc's function internally.
 
 Hmm, but from SUSv3:
 <quote>
 The radix character is determined by the current locale.  If
 setlocale() has not been called successfully, the default locale,
 POSIX, is used.  The default locale specifies a period
 ( '.' ) as the radix character.
 </quote>
 
 > It's a application's problem to decide which locale to use and [fge]cvt()
 > should use locale previously set by application.
 
 AFAIK only gcvt() have locale-specific "problem".  I can't find
 any locale-specific words in documentation of [ef]cvt.  Correct
 me if I'm wrong...
 
 > > > 2. Did you check correctness of dtoa()'s usage here ?  It's not easy
 > > > and after last netlib's import it become more uneasy.
 > 
 > >From reading of SUSv3's section related to these functions I'd suggest
 > following way to check a function (and maybe write a regression-test
 > for these funcs).
 > 
 > 1. declare some set of floating values (more than one)
 > 2. and try comapring result of gcvt() against of result of printf("%g").
 > same for others.
 > 3. check these results against predefined values (if you'll write a
 > regression test program)
 
 OK.
 
 -- 
 
 Rgdz,                        /"\  ASCII RIBBON CAMPAIGN
 Sergey Osokin aka oZZ,       \ /    AGAINST HTML MAIL
 http://ozz.pp.ru/             X          AND NEWS
                              / \


More information about the freebsd-standards mailing list