No subject

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetse
rv/html/ws03-64-bitwindevover.asp

/WP64: Getting the Compiler to Warn You of Potential Issues
The Microsoft(r) Visual C and Microsoft(r) Visual C++(r) .NET 2002
compilers added the /WP64 switch, which allows you to test your 32-bit
code for 64-bit compatibility issues. The compiler will issue warnings
about things like pointer truncation and improper casts. One of the
first steps in porting your 32-bit application to the 64-bit version of
Windows is to turn on this flag and compile your code like you normally
would. The first time, expect to get several errors. For example, take a
look at this snippet of code:

DWORD i = 0;
size_t x = 100;

i = x; // C4267: warning C4267: '=' : conversion from 
    // 'size_t' to 'DWORD', possible loss of data.
On a 32-bit platform this code would compile fine, because size_t is
32-bits, but on a 64-bit platform size_t is a 64-bit integer. With /WP64
enabled, the compiler will warn you about situations like this.

Additional examples:

void func(DWORD context)
{
  char* sz = (char*)context; // C4312: warning C4312: 
                // 'type cast' : conversion 
                // from 'DWORD' to 'char *' of
                // greater size
  // Do something with sz..
}

char* string = "the quick brown fox jumped over the lazy dog.";

func((DWORD)string); // C4311: warning C4311: 'type cast' :
           // pointer truncation from 'char *' 
           // to 'DWORD'
Once you fix these errors, test your 32-bit code. You want to make sure
that your 32-bit code continues to work as expected. Your 32-bit and
64-bit binaries should build from the same code base. This is a key
concept for writing Windows applications moving forward. You need to
think about both 32-bit and 64-bit issues from the beginning, and code
your application to work for both platforms.

New Data Types
The 64-bit version of Windows uses the LLP64 data model. What this means
is that the standard C types int and long remain 32-bit integers. The
data type size_t is mapped to the processor's word size (32-bits for
IA32 and 64-bits for IA64), and __int64 is a 64-bit integer. This was
done to assist in porting 32-bit code. The significance is that you can
have the same code base for both the 32-bit and 64-bit version of your
application. 

There is another data model called LP64, which maps the standard C type
long to a 64-bit integer; and int remains a 32-bit integer. This data
model is common on Unix platforms, but can make it harder to create both
32-bit and 64-bit versions of your application from a single code base.
You might notice a common theme here. The idea of a 32-bit versus a
64-bit platform is that you should be able to build both versions of
your application from a single code base. If you can't do that, then you
may want to revisit your design. Having a single code base is a huge
win, especially if you plan to ship both versions.


-----Original Message-----
From: Frank Warmerdam [mailto:warmerdam at pobox.com] 
Sent: Wednesday, March 10, 2004 11:27 AM
To: Roger James
Cc: gdal-dev
Subject: [Gdal-dev] Re: VC7 build log



Roger (or others),

\Vterrain\APIs\gdal\alg\gdalwarpoperation.cpp(637) : warning C4312:
'type cast' : conversion from 'long' to 'void *' of greater size

This code looks like:
     ((void **) pThreadData)[2] = (void *) (long) eErr;

Given that I want to convert an enumerated error code into a pointer is
there any more "proper" way of doing it than this?

> \Vterrain\APIs\gdal\frmts\envisat\envisatdataset.cpp(546) : warning
> C4267: '=' : conversion from 'size_t' to 'int', possible loss of data


Ahh yes, all these.  Very annoying.  I have generally used "int" as
equivelent to size_t and it is warning every time there is a cast back
or forth.   This does not cause a complain under gcc -Wall and I am not
inclined to make a comprehensive pass through fixing it at this time.

I would note that a non-trivial number of the warnings are in libpng,
libjpeg,
and libz which I don't have any influence over.  If I fix the copy in
GDAL
then the changes will just be lost on my next upgrade.

 > The problem is that at some point the size_t typedef on windows
became
 > an unsigned int. I think it is something to do with 64 bit
 > compatability. C4267 is definitely a very bad warning to disable. I
for
 > one am very much in the "every warning masks a potential error" camp.
I
 > have mailed you a build log separately.

Death to C4267!  Err, I mean, I give up on it for now.

Re: file.lst files:
 > Not that I am aware of but maybe somebody else knows.I do not think
it
 > would be beyond possibility (but beyond my own knowledge and
timetable)
 > to make a perl script to edit the vcproj files. However, I am happy
to
 > keep the files reasonably up to date and send you updates. My
comments
 > on not wanting responsibility were of the legalistic nature seeing as
 > the files did not have any disclaimer associated with them. I did not
 > mean to wash my hands of them completely.

Well, I am not keen on update scripts.  I will commit the project files
to CVS, and I would be happy to offer you CVS commit access if you would
like to update them (and even fix warnings carefully).

Also, please don't mind my crankiness too much.  I am having a
frustrating
time keeping on top of actual paying work as well as the many requests
for
help, bug fixes and so forth on my many libraries.  My days often have a
peak frustration around noon, when I am pretty much dug out of overnight
requests for help, and ready to start on real work.  Less than half the
requests for help I get come via public mailing lists where others can
help
out, and of course there are a number of other projects I am involved
beside
GDAL itself.

Best regards,
-- 
---------------------------------------+--------------------------------
------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Gdal-dev mailing list
Gdal-dev at remotesensing.org
http://remotesensing.org/mailman/listinfo/gdal-dev