[Gdal-dev] Re: VC7 build log

[Chapman, Martin]

Frank,

You will only lose precision if what's in the size_t is bigger than an
int.  Are you storing anything bigger than that in the size_t?  If not,
turn off the warning.  If so, perhaps you can shift the bits manually
from a size_t to the int where needed.  Then you could keep the warning
turned on and convert it cleanly.  Again, this warning is not applicable
in your case it sounds like and that's why it's a warning and not an
error.

Martin

-----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