Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3EB39994.5B197777@phekda.freeserve.co.uk>
Date:	Sat, 03 May 2003 11:27:32 +0100
From:	Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer:	Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language:	de,fr
MIME-Version:	1.0
To:	DJGPP workers <djgpp-workers AT delorie DOT com>
Subject:	gcvt and leading zeroes
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

The Perl configure script says that DJGPP's gcvt behaves unexpectedly. This is
because it does not return a zero before the decimal point for numbers < 1.

It seems to be intentional. src/libc/compat/stdlib/gcvt.c has this code to
remove the zero:

    /* It seems they expect us to return .XXXX instead of 0.XXXX  */
    if (*p == '-')
      p++;
    if (*p == '0' && p[1] == '.')
      memmove (p, p + 1, strlen (p + 1) + 1);

Who are "they"?

SUSv2 says that gcvt should produce output like %g:

"Converts value to a null-terminated string (similar to that of the %g format
of printf()) in the array pointed to by buf and returns buf. It produces
ndigit significant digits (limited to an unspecified value determined by the
precision of a double) in %f if possible, or %e (scientific notation)
otherwise. A minus sign is included in the returned string if value is less
than 0. A radix character is included in the returned string if value is not a
whole number. Trailing zeros are suppressed where value is not a whole number.
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. The LC_NUMERIC
category determines the value of the radix character within the current
locale."

Are we trying to be compatible with some Unix implementation?

I searched the djgpp-workers mailing list for "gcvt", but nothing that looked
relevant was found.

Thanks, bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]

- Raw text -