«

(Gopi Subramanian) wrote in message news:<. com>...
> I am porting a c++ source from suse linux to windows,and my code does
> a lot of binary file manipulation, during a debug session found that
> NULL values are different in VC ++ and g++, VC++ defines NULL as 0 and
> g++ defines it as a (void *) 0, is there any way to make sure that
> both of them matches ?

I ran into this problem before. It's not the GNU compiler.
As long as you have a *.cpp file, it should compile against the
version that defines NULL as 0.
If you have a C file (*.c) then it will compile against the (void*)0
definition.

If you're getting this from a *.cpp file, more then likely your
compiler is pointing to the wrong set of header files.
This could happen if the GNU compiler was installed incorrectly, or if
you have your make file redirecting the search path for the includes
in the wrong directory.

Look for your -I options, and make sure they're correct.

(foo) wrote in message news:<. com>...
> (Gopi Subramanian) wrote in message news:<. com>...
> > I am porting a c++ source from suse linux to windows,and my code does
> > a lot of binary file manipulation, during a debug session found that
> > NULL values are different in VC ++ and g++, VC++ defines NULL as 0 and
> > g++ defines it as a (void *) 0, is there any way to make sure that
> > both of them matches ?
>
> I ran into this problem before. It's not the GNU compiler.
> As long as you have a *.cpp file, it should compile against the
> version that defines NULL as 0.
> If you have a C file (*.c) then it will compile against the (void*)0
> definition.
>
> If you're getting this from a *.cpp file, more then likely your
> compiler is pointing to the wrong set of header files.
> This could happen if the GNU compiler was installed incorrectly, or if
> you have your make file redirecting the search path for the includes
> in the wrong directory.
>
> Look for your -I options, and make sure they're correct.

The version of GCC i am using is 2.95.3 and it defines NULL as below
#if defined (_STDDEF_H) || defined (__need_NULL)
#undef NULL /* in case <stdio.h> has defined it. */
#ifdef __GNUG__
#define NULL __null
#else /* G++ */
#define NULL ((void *)0)
#endif /* G++ */
#endif /* NULL not defined and <stddef.h> or need NULL. */
#undef __need_NULL

So it indicates that even for g++ NULL is void* )
The problem arises when i am reading 0x0 from a binary file. Its read
as different characters in linux and windows ?

On 24 Jun 2003 23:20:46 -0700, Gopi Subramanian <> wrote:

>> > I am porting a c++ source from suse linux to windows,and my code does
>> > a lot of binary file manipulation, during a debug session found that
>> > NULL values are different in VC ++ and g++, VC++ defines NULL as 0 and
>> > g++ defines it as a (void *) 0, is there any way to make sure that
>> > both of them matches ?
>>
[snip]
> The problem arises when i am reading 0x0 from a binary file. Its read
> as different characters in linux and windows ?

I see no possible way that the definition of NULL can have any effect on
data read from a file.

--
Sam Holden

"Gopi Subramanian" <> wrote in message news: om...

> So it indicates that even for g++ NULL is void* )
> The problem arises when i am reading 0x0 from a binary file. Its read
> as different characters in linux and windows ?

Are you sure you opened the file in binary mode. On UNIX/LINUX there's
no difference between text and binary modes, on Windoze there is.

On 25 Jun 2003 23:22:33 -0700, (Gopi
Subramanian) wrote:

>"Ron Natalie" <> wrote in message news:<>...
>> "Gopi Subramanian" <> wrote in message news: om...
>>
>> > So it indicates that even for g++ NULL is void* )
>> > The problem arises when i am reading 0x0 from a binary file. Its read
>> > as different characters in linux and windows ?
>>
>> Are you sure you opened the file in binary mode. On UNIX/LINUX there's
>> no difference between text and binary modes, on Windoze there is.
>
>
>While debugging the application both in linux and windows i found that
>during one instance character '\0' is read and stored in unsigned
>character, the equivalent windows stores ''. So internally when these
>characters are treated will there be any difference, like suppose
>there is a buffer which has this '\0' character in the middle and
>linux carries it out properly but windows thinks that is end of line
>and skips the rest of the buffer ?

You'll have to post the code you're using - there is a problem in your
code, not in the compilers, since it is perfectly possible to
correctly read in a binary file with the same code with both MSVC and
G++.

Tom