[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