[GiNaC-devel] Fix the compliation error *for real*

Sergei Steshenko sergstesh at yahoo.com
Sat Aug 8 01:04:46 CEST 2009



--- On Fri, 8/7/09, Alexei Sheplyakov <varg at metalica.kh.ua> wrote:

> From: Alexei Sheplyakov <varg at metalica.kh.ua>
> Subject: [GiNaC-devel] Fix the compliation error *for real*
> To: "GiNaC development list" <ginac-devel at ginac.de>
> Date: Friday, August 7, 2009, 1:22 PM
> Dear Jens,
> 
> On Fri, Jul 31, 2009 at 12:50:26PM +0200, Jens Vollinga
> wrote:
> 
> > commit eaf81b3115697a8e883848ace0ceb919cf443b2c
> > Author: Jens Vollinga <jensv at balin.nikhef.nl>
> > Date:   Fri Jul 31 11:14:01 2009 +0200
> > 
> >     Fixed cast that caused compile
> error on 64bit machines.
> 
> Unfortunately the error is still here:
> 
> libtool: compile:  ccache g++-4.1 -DHAVE_CONFIG_H -I.
> -I../../../../work/sw/GiNaC/ginac -I../config
> -I/home/pc7135/varg/target/x86_64-linux-gnu/include -Wall
> -O2 -g -pipe -funroll-loops -ffast-math -finline-limit=1200
> -m64 -march=k8 -mfpmath=sse -msse2 -MT parser.lo -MD -MP -MF
> .deps/parser.Tpo -c
> ../../../../work/sw/GiNaC/ginac/parser/parser.cpp 
> -fPIC -DPIC -o .libs/parser.o
> ../../../../work/sw/GiNaC/ginac/parser/parser.cpp: In
> member function `GiNaC::ex
> GiNaC::parser::parse_identifier_expr()':
> ../../../../work/sw/GiNaC/ginac/parser/parser.cpp:73:
> error: cast from `GiNaC::ex (*)(const GiNaC::exvector&)'
> to `unsigned int' loses precision
> 
> 
> A simple test case:
> $ cat > test.cc << EOF 
> unsigned test(const void* ptr)
> {
>     return
> reinterpret_cast<unsigned>(ptr);
> }
> EOF
> $ g++ test.cc
> test.cc: In function `unsigned int test(const void*)':
> test.cc:3: error: cast from `const void*' to `unsigned int'
> loses precision
> 
> 
> I think the compiler is right since [expr.reinterpret.cast]
> says:
> "A pointer can be explicitly converted to any integral type
> large enough
> to hold it."
> 
> 
> The patch below fixes the problem.
> 
> From: Alexei Sheplyakov <varg at metalica.kh.ua>
> Subject: [PATCH] Fix compilation error on 64-bit
> architectures for real.
> 
> According to [expr.reinterpret.cast] it's not ok to convert
> a pointer
> into an integer of a different size.
> 
> ---
>  ginac/parser/parser.cpp |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/ginac/parser/parser.cpp
> b/ginac/parser/parser.cpp
> index 6ed364f..cfa313b 100644
> --- a/ginac/parser/parser.cpp
> +++ b/ginac/parser/parser.cpp
> @@ -70,7 +70,8 @@ ex parser::parse_identifier_expr()
>      // pointers.
>      GiNaC::function* f = NULL;
>      try {
> -        f = new
> GiNaC::function(reinterpret_cast<unsigned>(reader->second),
> args);
> +        unsigned serial =
> (unsigned)(unsigned long)(void *)(reader->second);
> +        f = new
> GiNaC::function(serial, args);
>      }
>      catch ( std::runtime_error ) {
>          if ( f ) delete f;
> -- 
> 1.6.3.3
> 
> Best regards,
>     Alexei
> 
> 
> _______________________________________________
> GiNaC-devel mailing list
> GiNaC-devel at ginac.de
> https://www.cebix.net/mailman/listinfo/ginac-devel
> 

Guys, I think a much more conceptually correct solution (even though this
one works) would be to use

size_t

instead of

unsigned long
.

The following links explain why:

http://www.embedded.com/columns/programmingpointers/201803576
http://en.wikipedia.org/wiki/Stdlib.h#size_t
http://www.cplusplus.com/reference/clibrary/cstddef/size_t/
.

To put it shortly - size_t is big enough to represent output of sizeof(foo)
for _any_ foo, so it is big enough to represent numeric value of _any_
pointer.

Regards,
  Sergei.


      


More information about the GiNaC-devel mailing list