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

vim73 windows warnings

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

      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
    • 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 2 of 3 , Jun 1, 2010
      • 0 Attachment
        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 3 of 3 , Jun 1, 2010
        • 0 Attachment
          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.