Mike Williams wrote:
> On 01/06/2010 10:51, Mike Williams wrote:
> > Hi,
> >
> > I compiled VIM on my home machine over the weekend and got a few warnings:
> >
> > misc2.c(6277) : warning C4244: '=' : conversion from 'long_u' to 'int',
> > possible loss of data
> > undo.c(828) : warning C4267: '=' : conversion from 'size_t' to 'int',
> > possible loss of data
> > undo.c(1630) : warning C4311: 'type cast' : pointer truncation from
> > 'u_header_T *' to 'long'
> > undo.c(1635) : warning C4311: 'type cast' : pointer truncation from
> > 'u_header_T *' to 'long'
> > undo.c(1640) : warning C4311: 'type cast' : pointer truncation from
> > 'u_header_T *' to 'long'
> > undo.c(1645) : warning C4311: 'type cast' : pointer truncation from
> > 'u_header_T *' to 'long'
> >
> > At home I am using:
> >
> > VC 2005 Express
> > Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762
> > for 80x86
> >
> > Build command I am using is:
> >
> > nmake -f make_mvc.mak GUI=yes POSTSCRIPT=yes PYTHON=e:\python26
> > PYTHON_VER=26 DYNAMIC_PYTHON=yes
> >
> > What is odd is that with the same sources and build line I don't get
> > these warnings on my work machine. The difference is that that is using
> > a commercial version of VC 2005. Ah, for some reason the 64 bit warnings
> > are not being enabled - do that and I do get the above warnings. The
> > warnings in undo.c indicate code that will cause errors with Windows 64
> > bit builds - uh_seq should be an intptr_t or whatever the final decision
> > was on type name for 64 bit integers that can hold pointer values.
We actually use the pointer fields to store a long, it works as
intended. How to shut up the compiler? Probably requires using
#pragma.
I suppose the proper way to do this is using a union.
> > I'll work on a patch for the makefile to ensure the 64 bit warnings get
> > produced in both the Express and full versions of VC8 - unless someone
> > else gets there before me.
>
> Lack of warnings now fixed with the attached patch.
>
> The problem was that defining the 64 warnings flag was dependent on a
> variable that was defined later in the makefile. I have just moved the
> definition of MSVCVER up in the makefile. I have put it before the
> inclusion of win32.mak since I have a copy whose contents may depend on
> what MSVCVER has been set to.
>
> Note - this does mean that people using some versions of Visual Studio
> and the Windows SDK may result in a change in the built executable (for
> example, one copy of if the SDK win32.mak I have turns on buffer checks
> for VC7 builds.)
Instead of moving the MSVCVER check up, I think it's better to move the
lines for /Wp64 down. Actually, instead of adding this to DEFINES it
should be added to CFLAGS, like the other compiler arguments.
I'll do it that way, please check the updated file tomorrow.
--
hundred-and-one symptoms of being an internet addict:
136. You decide to stay in a low-paying job teaching just for the
free Internet access.
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
