From owner-freebsd-standards@FreeBSD.ORG Fri Apr 25 05:40:15 2003 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAD2637B401 for ; Fri, 25 Apr 2003 05:40:15 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2F7443F3F for ; Fri, 25 Apr 2003 05:40:14 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h3PCeEUp052865 for ; Fri, 25 Apr 2003 05:40:14 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h3PCeEhw052858; Fri, 25 Apr 2003 05:40:14 -0700 (PDT) Date: Fri, 25 Apr 2003 05:40:14 -0700 (PDT) Message-Id: <200304251240.h3PCeEhw052858@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: "Sergey A. Osokin" Subject: Re: standards/51292: [PATCH] add ecvt()/fcvt()/gcvt() functions (SUSv3) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Sergey A. Osokin" List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2003 12:40:16 -0000 The following reply was made to PR standards/51292; it has been noted by GNATS. From: "Sergey A. Osokin" To: Alexey Zelkin Cc: FreeBSD-gnats-submit@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: 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. > 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 / \