bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dinkumware test of glibc


From: Andreas Jaeger
Subject: Re: dinkumware test of glibc
Date: Sun, 15 Jun 2003 17:00:26 +0200
User-agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.4 (Portable Code, linux)

Xose Vazquez Perez <address@hidden> writes:

> hi,
>
> dinkumware folks have found several bugs(who knows) in glibc
> with 'Dinkum Quick Proofer'(close source and $$):
>
> more info at http://www.dinkumware.com/conform_c.html#glibc230_results
>
> --cut--
> Red Hat LiNUX 8.0 + Glibc V2.3 C Library
>
> o C95
>
> - This version of Glibc supports the C95 standard with no failures, and
>   partially supports the optional math tests. The math functions are all
>   declared, but the accuracy of these optional functions is not always good.
>
> * The following list of math functions failed to pass our accuracy tests:
>   acosf, asinf, atanf, atan2f,tanf, coshf, expf, logf, log10f, powf, sinhf,
>   tanhf, ceill, fabsl, floorl, fmodl, frexpl, frexpl, ldexpl, modfl, acosl,
>   asinl, atanl, atan2l, tanl, coshl, expl, logl, log10l, powl, sinhl, and 
> tanhl.

Without details, we cannot do anything - and the glibc team is not
going to buy these tests.  glibc's own tests do not show these problems.
>
> o C++

These are issues regarding GCC that are outside of glibc.

> - The same issues that were found during the C95 testing are also present when
> compiling the tests as C++ code, plus the following.
>
> * The macro LC_MESSAGE is not defined in locale.h.
> * The overloads for abs(double) and pow(double, int) are not declared in 
> math.h.
> * The long int overloads of the functions abs and div are not defined in the
>   Standard header stdlib.
> * Not all the signatures called for by the C++ Standard for memchr, strchr,
>   strpbrk, strchr and strstr are declared in string.h.
> * The float and the long double versions of the functions ceil, fabs, floor,
>   fmod, frexp, ldexp, modf, acos, asin, atan, atan2, cos, sin, tan, cosh, exp,
>   log, log10, sinh, sqrt, and tanh are not defined in math.h.
> * Not all the signatures called for by the C++ Standard for wmemchr, wcspbrk,
>   wcschr, wcsrchr, and wcsstr are dclared in wchar.h.
>
> o C99
>
> - C99 support is far less consistent.
>
> * The macros INTN_C can cause compile time failures if certain valid 
> parameters
>   are passed as the value.
> * The hh specifier for d, i, o, u, x, or X conversion specifier does not 
> convert
>   the value to a signed or unsigned char before printing. This applies to both
>   the wide and narrow versions of the input/output functions.

I'll look into this.


> * The INTN_C(value) macros defined in stdint.h cause a compile-time error when
>   the parameter value is INT_LEAST64_MAX, UINT_LEAST8_MAX, UINT_LEAST16_MAX,
>   UINT_LEAST32_MAX, INTMAX_MAX, or a similar type parameter. The 
> implementation
>   is appending a suffix to the name, generating an undeclared variable.

Let's check this.

> * The SCN macros for unsigned integers that correspond to the X specifier for
>   fscanf in inttypes.h are not implemented.
> * If L"" is passed as the format parameter to vwprintf a negative value is
>   returned, indicating an error occurred.
> * fsetpos and fgetpos do not work on a stream that has had wide characters
>   written to the stream.

We need testcases for these.

> * The macro math_errhandling is not defined in math.h

Known limitation - needs help from the compiler.

> * The math functions fmal, fma, creall, cimagl, crealf, cimagf, cmplx, and 
> csqrt
>   failed accuracy tests.

Testcase?

> * The type generic macros carg, cimag, creal, and fabs fail to expand to the
>   appropriate type. Argument types float, double, and long double were tested.
> * The type generic macro ilogb does not expand to an int with the parameters 
> of
>   double or long double.

> * The type generic macros llrint and llround do not expand to a long long with
>   the parameters of float and long double.

Fixed already some time ago.

> * The type generic macros lrint and lround do not expand to a long with the
>   parameters of double and long double.
> --end--

Can you generate self contained testcases from this?  Without
testcases we cannot do much ourselves...

Andreas
-- 
 Andreas Jaeger
  SuSE Labs address@hidden
   private address@hidden
    http://www.suse.de/~aj

Attachment: pgpxoeTOgPql_.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]