casting on 64/32-bit environment

casting on 64/32-bit environment

[Mitja Ursic]

Hello,

Compiling of a cc program with g++ on 64-bit environment gives me a warning of 
a type “Warning: cast from pointer to integer of different size” on a place 
were casting really takes place. If I compile the same program on 32-bit 
environment I don’t have warning anymore.
Dose anyone have a reasonable explanation about that?

Best regards,
Mitja


____________________
http://www.email.si/

Re: casting on 64/32-bit environment

[Andrew Haley]

Mitja Ursic writes:

 > Compiling of a cc program with g++ on 64-bit environment gives me a warning of 
 > a type ?Warning: cast from pointer to integer of different size? on a place 
 > were casting really takes place. If I compile the same program on 32-bit 
 > environment I don?t have warning anymore.
 > Dose anyone have a reasonable explanation about that?

The problem here is that we don't know what you don't understand.

If you're casting a pointer to an (32-bit) int, then if you are on a
64-bit system, there will be overflow and some information will be
lost.  If you're on a 32-bit system then there won't be a problem.
This seems obvious: what's the problem?

Andrew.

Re: casting on 64/32-bit environment

[Tim Prince]

Mitja Ursic wrote:
> Hello,
> 
> Compiling of a cc program with g++ on 64-bit environment gives me a warning of 
> a type “Warning: cast from pointer to integer of different size” on a place 
> were casting really takes place. If I compile the same program on 32-bit 
> environment I don’t have warning anymore.
> Dose anyone have a reasonable explanation about that?

The usual meaning of the term 64-bit is that sizeof pointer storage is
increased, compared with 32-bit.  So it should hardly be a surprise when
this happens to non-portable code.

Re: casting on 64/32-bit environment

[Holger Eitzenberger]

"Mitja Ursic" <mitja.ursic@email.si> writes:

> Dose anyone have a reasonable explanation about that?

Hi,

make sure to use 'unsigned long' instead of 'unsigned int', as only the
first one will be 64bit in a 64bit environment, the latter still will
be 32bit.

  /holger

Re: casting on 64/32-bit environment

[Miles Bader]

Holger Eitzenberger <holger@eitzenberger.org> writes:
>> Dose anyone have a reasonable explanation about that?
>
> make sure to use 'unsigned long' instead of 'unsigned int', as only the
> first one will be 64bit in a 64bit environment, the latter still will
> be 32bit.

You can't really assume this -- apparently on ms-windows "long" is still
32 bit, even in a "64-bit" environment (stupid, I agree, but I guess MS
has too much badly written code that they don't want to break...).

-Miles
-- 
If you can't beat them, arrange to have them beaten.  [George Carlin]

Re: casting on 64/32-bit environment

[Andrew Haley]

Miles Bader writes:
 > Holger Eitzenberger <holger@eitzenberger.org> writes:
 > >> Dose anyone have a reasonable explanation about that?
 > >
 > > make sure to use 'unsigned long' instead of 'unsigned int', as only the
 > > first one will be 64bit in a 64bit environment, the latter still will
 > > be 32bit.
 > 
 > You can't really assume this -- apparently on ms-windows "long" is
 > still 32 bit, even in a "64-bit" environment (stupid, I agree, but
 > I guess MS has too much badly written code that they don't want to
 > break...).

Indeed.  ptrdiff_t and size_t and intptr_t are the types to use,
depending on exactly what is wanted.

Andrew.

Re: casting on 64/32-bit environment

[Andrew Haley]

Andrew Haley writes:
 > Tim Prince writes:
 >  > Andrew Haley wrote:
 >  > 
 >  > > Well, if this data structure is shared with FORTRAN you'll have to do
 >  > > something similar on the FORTRAN side.  It'll be a different type:
 >  > > INTEGER*8 or somesuch.  I'm not a FORTRAN programmer.
 >  > > 
 >  > > But yes, long will work on all gcc targets I'm aware of.
 >  > 
 >  > All maintained Fortran compilers, including gfortran, support c_ptr
 >  > data type.  You can't very well port intentionally non-portable
 >  > stuff to a different architecture unless you correct such
 >  > anachronisms.

One question: is c_ptr compatible with C pointers, or is it an integer
type compatible with intptr_t ?

Andrew.

Re: casting on 64/32-bit environment

[Andrew Haley]

Tim Prince writes:
 > Andrew Haley wrote:
 > 
 > > Well, if this data structure is shared with FORTRAN you'll have to do
 > > something similar on the FORTRAN side.  It'll be a different type:
 > > INTEGER*8 or somesuch.  I'm not a FORTRAN programmer.
 > > 
 > > But yes, long will work on all gcc targets I'm aware of.
 > 
 > All maintained Fortran compilers, including gfortran, support c_ptr
 > data type.  You can't very well port intentionally non-portable
 > stuff to a different architecture unless you correct such
 > anachronisms.

Hehe.  As far as I'm concerned, FORTRAN 77 is dangerously harmful
modernity.  :-)

To Mitja:

  Change the type on the C side of the interface to intptr_t.
  Change the type on the FORTRAN side of the interface to c_ptr.

Then you'll have a program that is portable to 32-bit and 64-bit
systems.

Thanks,
Andrew.

Re: casting on 64/32-bit environment

[Tim Prince]

Andrew Haley wrote:

> Well, if this data structure is shared with FORTRAN you'll have to do
> something similar on the FORTRAN side.  It'll be a different type:
> INTEGER*8 or somesuch.  I'm not a FORTRAN programmer.
> 
> But yes, long will work on all gcc targets I'm aware of.

All maintained Fortran compilers, including gfortran, support c_ptr data
type.  You can't very well port intentionally non-portable stuff to a
different architecture unless you correct such anachronisms.

Re: casting on 64/32-bit environment

[Andrew Haley]

Mitja Ursic writes:
 > > 
 > > You're casting from a pointer to an integer.  This is the wrong thing
 > > to do.
 > > 
 > 
 > >  > Down I give a part of a code:
 > >  > 
 > >  > //FUNC.CC
 > >  > void func ()
 > >  > {
 > >  >    ?
 > >  >    int iel=0;
 > >  >    ?
 > >  >    PtrF <EL> el01 = (EL*) iel; 	//line 105
 > > 
 > > Don't do this.  The answer to your problem is to not cast a pointer to
 > > an integer.  If you can explain why you want to do such casting, we'll
 > > be able to tell you how to avoid it.
 > > 

 > I did not write the program. Structure, which I gave last time, is
 > such that enables communication between Fortran and C++ on a way
 > that has historical reasons. So the structure is a fact, which
 > can't be changed.

Ha, right.  FORTRAN: that explains the weirdness.

 > There are no problems if the program is compiled on 32-bit
 > environment, but on 64-bit environment I get casting warnings.

 > The purpose of casting is to initialise arrays used by C++ and
 > Fortran. For test I have made a small program with that
 > structure. I found out (based also on info from this forum) that if
 > I use long instead of int, I do not have warnings any more. This
 > seems to be a solution, which I have not implemented yet.

Well, if this data structure is shared with FORTRAN you'll have to do
something similar on the FORTRAN side.  It'll be a different type:
INTEGER*8 or somesuch.  I'm not a FORTRAN programmer.

But yes, long will work on all gcc targets I'm aware of.

Andrew.

Re: casting on 64/32-bit environment

[John Love-Jensen]

Hi Mitja,

> So the structure is a fact, which can't be changed.

Then it cannot be compiled on 64-bit, since that changes the structure, and
also changes the assumptions the code is based upon.

HTH,
--Eljay

Re: casting on 64/32-bit environment

[Mitja Ursic]

> 
> You're casting from a pointer to an integer.  This is the wrong thing
> to do.
> 

>  > Down I give a part of a code:
>  > 
>  > //FUNC.CC
>  > void func ()
>  > {
>  >    ?
>  >    int iel=0;
>  >    ?
>  >    PtrF <EL> el01 = (EL*) iel; 	//line 105
> 
> Don't do this.  The answer to your problem is to not cast a pointer to
> an integer.  If you can explain why you want to do such casting, we'll
> be able to tell you how to avoid it.
> 
I did not write the program. Structure, which I gave last time, is such that 
enables communication between Fortran and C++ on a way that has historical 
reasons. So the structure is a fact, which can't be changed.
There are no problems if the program is compiled on 32-bit environment, but on 
64-bit environment I get casting warnings.
The purpose of casting is to initialise arrays used by C++ and Fortran. For 
test I have made a small program with that structure. I found out (based also 
on info from this forum) that if I use long instead of int, I do not have 
warnings any more. This seems to be a solution, which I have not implemented 
yet.

Mitja


____________________
http://www.email.si/

Re: casting on 64/32-bit environment

[Andrew Haley]

Mitja Ursic writes:
 > On Fri, 12 Oct 2007 at 15:46:14, Andrew Haley wrote:
 > > The problem here is that we don't know what you don't understand.
 > > 
 > > If you're casting a pointer to an (32-bit) int, then if you are on a
 > > 64-bit system, there will be overflow and some information will be
 > > lost.  If you're on a 32-bit system then there won't be a problem.
 > > This seems obvious: what's the problem?
 > 
 > Sorry for very late replay. My OS is 64 bit (Linux Red Hat 4 WS,
 > Update 4, 64- bit). I want to compile a program in 64-bit
 > environment but due to casting I don't trust to the compiled
 > program. So I want to figure out which steps are necessary to take
 > and than to compiled program on 64-bit without casting warnings. So
 > if you have any advice what to do I would be happy. Perhapse a part
 > of a code would help to figure out what is the cause of my
 > problems.

You're casting from a pointer to an integer.  This is the wrong thing
to do.

 > So, this is my casting warning:
 > func.cc: In function `void func()': func.cc:105: warning: cast to pointer from 
 > integer of different size
 > PtrF.h: In constructor `PtrF<Element>::PtrF(Element*) [with Element = el]': 
 > func.cc:105:   instantiated from here PtrF.h:39: warning: cast from pointer to 
 > integer of different size
 > 
 > Down I give a part of a code:
 > 
 > //FUNC.CC
 > void func ()
 > {
 >    ?
 >    int iel=0;
 >    ?
 >    PtrF <EL> el01 = (EL*) iel; 	//line 105

Don't do this.  The answer to your problem is to not cast a pointer to
an integer.  If you can explain why you want to do such casting, we'll
be able to tell you how to avoid it.

Andrew.

Re: casting on 64/32-bit environment

[Mitja Ursic]

On Fri, 12 Oct 2007 at 15:46:14, Andrew Haley wrote:
> The problem here is that we don't know what you don't understand.
> 
> If you're casting a pointer to an (32-bit) int, then if you are on a
> 64-bit system, there will be overflow and some information will be
> lost.  If you're on a 32-bit system then there won't be a problem.
> This seems obvious: what's the problem?
> 
> Andrew.

Sorry for very late replay. My OS is 64 bit (Linux Red Hat 4 WS, Update 4, 64-
bit). I want to compile a program in 64-bit environment but due to casting I 
don't trust to the compiled program. So I want to figure out which steps are 
necessary to take and than to compiled program on 64-bit without casting 
warnings. So if you have any advice what to do I would be happy. Perhapse a 
part of a code would help to figure out what is the cause of my problems.

So, this is my casting warning:
func.cc: In function `void func()': func.cc:105: warning: cast to pointer from 
integer of different size
PtrF.h: In constructor `PtrF<Element>::PtrF(Element*) [with Element = el]': 
func.cc:105:   instantiated from here PtrF.h:39: warning: cast from pointer to 
integer of different size

Down I give a part of a code:

//FUNC.CC
void func ()
{
   …
   int iel=0;
   …
   PtrF <EL> el01 = (EL*) iel; 	//line 105
…
}

//PTRF.H
template <class Element> 
class PtrF : public PtrC<Element>
{
public:
   …
   //constructor at line 39
   PtrF(Element* ele):Ptr<Element>(ele),_vide((int)ele) {}
   …
private :
   int _vide;
};

//CLASS PTR
template <class Element> 
class Ptr : public Obj
{
public:
   …
   //constructor
   Ptr(Element *pointerEl = 0):_impP(new ImpP<Element>(pointerEl)){} 
   …

protected:
   ImpP<Element> *_impP;  
};

//CLASS IMPP
template <class Element> class ImpP
{
…
private:
   Element* _ptr;
   …
   //constructor 
   ImpP(Element * element = 0):_ptr(element) {}
} ;

//EL CLASS
class EL : public Obj
{
…
public :
   // constructor
   EL(int vi,int vj, int vk):i(vi),j(vj),k(vk) {}
   …
   int i,j,k;
   …
};

Mitja

____________________
http://www.email.si/