Loading ...
Sorry, an error occurred while loading the content.
 

Re: vim73 windows warnings

Expand Messages
  • Mike Williams
    ... 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
    Message 1 of 3 , Jun 1, 2010
      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.
      >
      > 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.)

      TTFN

      Mike
      --
      Don't marry for money; you can borrow it cheaper.

      --
      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
    • Bram Moolenaar
      ... 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
      Message 2 of 3 , Jun 1, 2010
        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 -- Bram@... -- 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
      Your message has been successfully submitted and would be delivered to recipients shortly.