Mail Archives: djgpp-workers/2003/05/03/10:02:55
Richard Dawe wrote:
>
> 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?
If it were up to me I would certainly include the leading 0. For
at least Pascal, this is part of the language specification. It
avoids silly errors.
I wonder if the gcvt code results from an earlier mistake in that
configure script which inverted its test?
--
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
- Raw text -