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 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 Subject: gcvt and leading zeroes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/ ]