Moving to AMD64 bit and porting issues

Moving to AMD64 bit and porting issues

[Ernest L. Williams Jr.]

Hi,

I have been going down the 64-bit only path for building C/C++
applications.  Of course, I have been running into portability issues
when converting older 32-bit apps to build/run on a 64-bit OS.

Specifically in my case; I am using an AMD64 running RedHat Enterprise
Linux WS Release 4 update 2 (RHEL4 WS up2).  So, the version of GCC
follows:
==========================================================================
[williams@sns-hp-eval1 medm]$ gcc -v
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --
disable-checking --with-system-zlib --enable-__cxa_atexit --disable-
libunwind-exceptions --enable-java-awt=gtk --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)
===========================================================================

When I compile an old 32-bit app, the build works but at run-time it
crashes and burns.  Well, it has to do with using "NULL" versus "0"
Now here is a portability question:

Should we use "NULL" to represent a null pointer or "0" to represent a
null pointer?


When I replace "0" with NULL in the code the crash no longer occurred.


What else can I expect when moving 32-bit apps to the 64-bit platform.

Re: Moving to AMD64 bit and porting issues

[Alex J. Dam]

On Sat, Oct 22, 2005 at 01:26:12AM -0400, Ernest L. Williams Jr. wrote:
> Should we use "NULL" to represent a null pointer or "0" to represent a
> null pointer?

AFAIK, according to C++, they are equivalent.  See, for example,

http://www.research.att.com/~bs/bs_faq2.html#null

Re: Moving to AMD64 bit and porting issues

[random]

Alex J. Dam wrote:

>On Sat, Oct 22, 2005 at 01:26:12AM -0400, Ernest L. Williams Jr. wrote:
>  
>
>>Should we use "NULL" to represent a null pointer or "0" to represent a
>>null pointer?
>>    
>>
>
>AFAIK, according to C++, they are equivalent.  See, for example,
>
>http://www.research.att.com/~bs/bs_faq2.html#null
>  
>

This is true, they are equivalent. I would still advise using NULL
myself, as then g++ will produce some (I feel) helpful warnings, for
example 'NULL==1' or 'NULL + 1' will both produce "warning: NULL used in
arithmetic".

Chris

Re: Moving to AMD64 bit and porting issues

[Ernest L. Williams Jr.]

On Mon, 2005-10-24 at 08:25 -0200, Alex J. Dam wrote:
> On Sat, Oct 22, 2005 at 01:26:12AM -0400, Ernest L. Williams Jr. wrote:
> > Should we use "NULL" to represent a null pointer or "0" to represent a
> > null pointer?
> 
> AFAIK, according to C++, they are equivalent.  See, for example,
> 
> http://www.research.att.com/~bs/bs_faq2.html#null

Well, then what we are experiencing:
0 is an int and most likely 32 bits, 
NULL is a pointer and 64 bits in the 64-bit architecture.


This then must be the problem, which makes using 0 to represent a NULL
pointer not portable?  Or would this be considered a bug with GCC for a
64-bit environment?





Thanks,
Ernesto

Re: Moving to AMD64 bit and porting issues

[Ian Lance Taylor]

"Ernest L. Williams Jr." <ernesto@ornl.gov> writes:

> Well, then what we are experiencing:
> 0 is an int and most likely 32 bits, 
> NULL is a pointer and 64 bits in the 64-bit architecture.
> 
> 
> This then must be the problem, which makes using 0 to represent a NULL
> pointer not portable?  Or would this be considered a bug with GCC for a
> 64-bit environment?

You can reliably use 0 as a null pointer constant with one exception.
When calling a varargs function which expects a pointer as an unnamed
argument, and when pointers are 64-bits but int is 32-bits, then you
must either use NULL or you must cast 0 to a pointer type.

For example:

char *
foo (int i, ...) 
{
  va_list va;
  va_start (va, i);
  char *p = va_arg (va, char *);
  va_end (va);
  return p;
}

char *bar () { return foo (1, 0); }

This will do the wrong thing if pointers are 64-bits.  You must do
this instead:

char *bar () { return foo (1, (char *) 0); }

This is not a bug in gcc.

Ian

Re: Moving to AMD64 bit and porting issues

[Segher Boessenkool]

> You can reliably use 0 as a null pointer constant with one exception.
> When calling a varargs function which expects a pointer as an unnamed
> argument, and when pointers are 64-bits but int is 32-bits, then you
> must either use NULL or you must cast 0 to a pointer type.

Using NULL in this case is not portable; you *must*
use a cast to the exact pointer type that the
varargs function expects to see.  Different pointer
types can have different representation.


Segher

Re: Moving to AMD64 bit and porting issues

[Ernest L. Williams Jr.]

On Fri, 2005-11-04 at 12:28 +0100, Segher Boessenkool wrote:
> > You can reliably use 0 as a null pointer constant with one exception.
> > When calling a varargs function which expects a pointer as an unnamed
> > argument, and when pointers are 64-bits but int is 32-bits, then you
> > must either use NULL or you must cast 0 to a pointer type.
> 
> Using NULL in this case is not portable; you *must*
> use a cast to the exact pointer type that the
> varargs function expects to see.  Different pointer
> types can have different representation.

However, it does seem that must platforms understand NULL and assigns
the correct type.  I do agree that for portability we should use the
cast.



Ernest



> 
> 
> Segher
> 

Re: Moving to AMD64 bit and porting issues

[Segher Boessenkool]

>> Using NULL in this case is not portable; you *must*
>> use a cast to the exact pointer type that the
>> varargs function expects to see.  Different pointer
>> types can have different representation.
>
> However, it does seem that must platforms understand NULL and assigns
> the correct type.  I do agree that for portability we should use the
> cast.

Sure; with GCC, all targets (that I know of) use the same
representation (and ABI) for pointers to any data object.
This is not true for pointers to function, though.  So in
practice the code [with plain NULL instead of (type *)0]
will work fine; it is still not correct C code, though.

I thought we had a warning for this nowadays, btw?


Segher