Warnings in GMP.H, and potentially more serious problem

[delta trinity]

>From: Kevin Ryde <user42 at zip.com.au>
>To: "delta trinity" <deltatrinity at hotmail.com>
>CC: gmp-bugs at swox.com
>Subject: Re: Warnings in GMP.H, and potentially more serious problem
>Date: Sun, 16 May 2004 08:05:55 +1000
>
>"delta trinity" <deltatrinity at hotmail.com> writes:
> >
> > [C++ Warning] gmp.h(1595): W8008 Condition is always true
> > [C++ Warning] gmp.h(1596): W8041 Negating unsigned value
> >
> > Those are only warnings, and does not cause the compilation to fail.
>
>They're also a bit over zealous really, but we should be able to avoid
>them.  I'm looking at something like the following.
>
>unsigned long
>mpz_get_ui (mpz_srcptr __gmp_z) __GMP_NOTHROW
>{
>   mp_ptr __gmp_p = __gmp_z->_mp_d;
>   mp_size_t __gmp_n = __gmp_z->_mp_size;
>   mp_limb_t __gmp_l = __gmp_p[0];
>   /* This is a "#if" rather than a plain "if" so as to avoid gcc warnings
>      about "<< GMP_NUMB_BITS" exceeding the type size, and to avoid 
>Borland
>      C++ 6.0 warnings about condition always true for something like
>      "__GMP_ULONG_MAX < GMP_NUMB_MASK".  */
>#if GMP_NAIL_BITS == 0 || defined (_LONG_LONG_LIMB)
>   /* limb==long and no nails, or limb==longlong, one limb is enough */
>   return (__gmp_n != 0 ? __gmp_l : 0);
>#else
>   /* limb==long and nails, need two limbs when available */
>   __gmp_n = __GMP_ABS (__gmp_n);
>   if (__gmp_n <= 1)
>     return (__gmp_n != 0 ? __gmp_l : 0);
>   else
>     return __gmp_l + (__gmp_p[1] << GMP_NUMB_BITS);
>#endif
>}

That solution seem to work.  I don't have warnings anymore.  I wander if 
MSVC would have give the same warnings.  I don't know as I don't have it...  
anyway...

If you say that it's the option that will be kept, I could make the change 
to the file I've put on my ftp server (pre-compiled shared library), in an 
erratum directory for example.

> > Looking at the code, at the second warning, could (__gmp_n != 0) give
> > problems if a compiler decide to evaluate the expression to anything
> > other than 1.
>
>No, the relational operators always give 1 or 0.

Ok, I'm not sure abour the ANSI standard.  If it always evaluate to 0 or 1, 
then, there should be no problem.

> > The warnings themself are seen when I compile C++ console application.
> > I tried compiling a C console application and they didn't show.
> > Probably the compiler use two different core for C and C++.
>
>Or it's just the nature of c++ to be pedantic, g++ is pickier than gcc
>too.

Probably.  There's a lot of warnings I don't get when compiling 'c' instead 
of c++.  I just noticed it though, as it's one of the first time I write a 
project in plain 'c' rather than c++ (for portability reasons).  Luckily 
though, I get other warnings when I make mistakes.

For example:

...
mpf_t x;
mpz_init(x);
...

In c++, I get
<<Cannot convert '__mpf_struct *' to '__mpz_struct *'>> as a compile error.

In c, I don't get the error, but I get
<<Suspicious pointer conversion>> as a warning.

c++ seem to protect more agains't coding error, often requiring type cast.  
c seem to be made to be more compatible with ANSI C, thus, letting legal 
ANSI C statements compile.

For example

...
int i;
mpf_t *mpf_array;
mpf_array = malloc(sizeof(mpf_array[0]) * 10);
for (i=0; i<10; i++)
   mpf_init(mpf_array[i]);
...

would give a cast error for malloc (cannot convert void* to __mpf_struct **) 
in c++, requiring you to do 'mpf_array = (mpf_t *)malloc...', but pass 
without warning at all in c.

Regards

Eric

_________________________________________________________________
Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! 
http://join.msn.click-url.com/go/onm00200362ave/direct/01/