Re: Compilation (W98-BCC5) fails using Active Perl 5.10

[mattn]

In last week, I wrote a patch for perl 5.10.

http://groups.google.co.jp/group/vim_dev/browse_thread/thread/f7404ac9a2dd7cc1/53d537e69d6271c5?hl=ja&lnk=gst&q=5.10

Please try the patch.

On Mon, Jan 21, 2008 at 3:08 AM, Patrick Texier <[EMAIL PROTECTED]> wrote:
>
> I'm using:
>
> - Windows 98
> - Vim 7.1.236 sources
> - Borland C++ 5.5.1 (with PERL_VER = 510 in makefile).
> - Active Perl 5.10.0 build 1002 [283697]
>
>
> link fails with unresolved references about Perl:
>
> Compiling WIN32 gvim.exe , with: GUI OLE MBYTE IME(dynamic) GETTEXT
> ICONV CSCOPE
>  NETBEANS PERL(dynamic) cpu=-5 Align=-a4
>copy /y MAKE0004.@@@ WIN32\oleobj\bcc.cfg
>1 fichier(s) copié(s)
>c:\borland\bcc55\BIN\ILink32 @MAKE0001.@@@
> Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
> Error: Unresolved external '_Perl_Imarkstack_max_ptr' referenced from
> C:\SRC\VIM71\SRC\WIN32\OLEOBJ\IF_PERL.OBJ
> Error: Unresolved external '_Perl_IXpv_ptr' referenced [...]
> Error: Unresolved external '_Perl_ISv_ptr' referenced [...]
> Error: Unresolved external '_Perl_Itmps_ix_ptr' referenced [...]
> Error: Unresolved external '_Perl_Itmps_floor_ptr' referenced [...]
> Error: Unresolved external '_Perl_Iop_ptr' referenced [...]
> Error: Unresolved external '_Perl_Istack_max_ptr' referenced [...]
> Error: Unresolved external '_Perl_Ina_ptr' referenced [...]
> Error: Unresolved external '_Perl_Imarkstack_ptr_ptr' referenced [...]
> Error: Unresolved external '_Perl_Istack_base_ptr' referenced [...]
> Error: Unresolved external '_Perl_Istack_sp_ptr' referenced [...]
>
> --
> Patrick Texier,
> Frulon, 36190 Orsennes, France (46°31'N, 01°41'E)
> 
> 
>
> >
>



-- 
- Yasuhiro Matsumoto

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Syntax highlighting through comment hash for sh

[Charles E. Campbell, Jr.]

Pascal Christoph wrote:

>Hello you guys-making-the-most-useful-tool-in-VR (of course I am not 
>speaking only of myself),
>
>proud to have found a little thing that, be fixed, would improve the 
>improved vi even a nearly unsubstantial-tiny bit more:
>
>If you use syntax highlighting, and programm shell scripts, then there 
>is a tiny misinterpretation, an issue with the comment-sign  ("hash") '#' :
>  
>
v98 of syntax/sh.vim has had this since mid-March; it may have been 
inserted earlier.

Regards,
Chip Campbell


--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: [patch] fixed 3 bugs with invalid utf-8 sequences

[Dominique Pelle]

On Sun, Jun 29, 2008 at 4:10 PM, Bram Moolenaar wrote:

> Dominique Pelle wrote:
>
>> Here is another bug because of invalid utf-8 sequence:
>>
>> ==21329== Conditional jump or move depends on uninitialised value(s)
>> ==21329==at 0x811C4C7: utf_ptr2char (mbyte.c:1390)
>> ==21329==by 0x811C83F: utf_composinglike (mbyte.c:1498)
>> ==21329==by 0x811CD96: utfc_ptr2len_len (mbyte.c:1756)
>> ==21329==by 0x80FEAF1: msg_outtrans_len_attr (message.c:1355)
>> ==21329==by 0x80FE9D0: msg_outtrans_len (message.c:1292)
>> ==21329==by 0x80B9D7F: draw_cmdline (ex_getln.c:2641)
>> ==21329==by 0x80BAA99: redrawcmd (ex_getln.c:3126)
>> ==21329==by 0x80BAF82: nextwild (ex_getln.c:3317)
>> ==21329==by 0x80B6D3B: getcmdline (ex_getln.c:803)
>> ==21329==by 0x80B912E: getexline (ex_getln.c:2101)
>> ==21329==by 0x80A33FC: do_cmdline (ex_docmd.c:991)
>> ==21329==by 0x81280DD: nv_colon (normal.c:5181)
>> ==21329==by 0x8121772: normal_cmd (normal.c:1152)
>> ==21329==by 0x80E4E8A: main_loop (main.c:1177)
>> ==21329==by 0x80E49DA: main (main.c:936)
>>
>> ==21434== Conditional jump or move depends on uninitialised value(s)
>> ==21434==at 0x811C4C7: utf_ptr2char (mbyte.c:1390)
>> ==21434==by 0x811C28C: utf_ptr2cells (mbyte.c:1268)
>> ==21434==by 0x805D084: ptr2cells (charset.c:746)
>> ==21434==by 0x80FEC65: msg_outtrans_len_attr (message.c:1394)
>> ==21434==by 0x80FE9D0: msg_outtrans_len (message.c:1292)
>> ==21434==by 0x80B9D7F: draw_cmdline (ex_getln.c:2641)
>> ==21434==by 0x80BAA99: redrawcmd (ex_getln.c:3126)
>> ==21434==by 0x80BAF82: nextwild (ex_getln.c:3317)
>> ==21434==by 0x80B6D3B: getcmdline (ex_getln.c:803)
>> ==21434==by 0x80B912E: getexline (ex_getln.c:2101)
>> ==21434==by 0x80A33FC: do_cmdline (ex_docmd.c:991)
>> ==21434==by 0x81280DD: nv_colon (normal.c:5181)
>> ==21434==by 0x8121772: normal_cmd (normal.c:1152)
>> ==21434==by 0x80E4E8A: main_loop (main.c:1177)
>> ==21434==by 0x80E49DA: main (main.c:936)
>>
>> It's easy to reproduce:
>>
>> 1/ Create a file names with invalid utf-8 name:
>>
>>$ mkdir testcase
>>$ touch testcase/$(perl -e 'print chr(0xfb)')
>>
>> 2/ Start Vim in 'no compatible' mode with Valgrind:
>>
>>$ valgrind vim -u NONE -c -N 2> vg.log
>>
>> 4/ In ex mode, enter:
>>
>>:e testcase/
>>
>>When pressing  key (file completion), vim should display
>>file name with invalid utf-8 sequence 'testcase/'
>>and observe in vg.log that valgrind reports above errors.
>>
>> The 2 error messages are actually 2 distinct bugs.
>>
>> - First error: in mbyte.c:1756, calling
>>   UTF_COMPOSINGLIKE(p + prevlen, p + len) is unsafe, since it
>>   can read bytes beyond size.  So in theory, there is a small risk
>>   that vim combines characters when it should not.
>>
>>   Attached patch "fix1-invalid-utf8-seq.patch" fixes this first
>>   error, by calling utf_ptr2len_len(p + len, size - len) before
>>   UTF_COMPOSINGLIKE(...) to ensure that UTF_COMPOSINGLIKE(...)
>>   can't access beyond size.
>>
>> - Second error: in message.c:1394, calling ptr2cells(str) is
>>   unsafe since it can read bytes in str beyond len (which are
>>   uninitialized).  At line 1394, we know that the character is
>>   only 1 byte long (mb_l is 1) so it should call char2cells(*str).
>>   mb_l is 1 here because of incomplete utf-8 sequence so calling
>>   ptr2cells(str) overflows.
>>
>>   Attached patch "fix2-invalid-utf8-seq.patch" fixes it.
>>
>> After fixing these 2 bugs, valgrind no longer complains with
>> the above testcase.
>>
>> However, there is a 3rd bug which can be triggered with a slightly
>> different test case, using file  instead of .  The difference
>> is that  is an invalid utf-8 sequence, whereas  was an
>> incomplete utf-8 sequence:
>>
>> 1/ Create a file names with invalid utf-8 names:
>>
>>$ mkdir testcase
>>$ touch testcase/$(perl -e 'print chr(0xff)')
>>
>> 2/ Start Vim in 'no compatible' mode with Valgrind:
>>
>>$ valgrind vim -u NONE -c -N 2> vg.log
>>
>> 3/ In ex mode, enter:
>>
>>:e testcase/
>>
>>When pressing  key (file completion), vim should display
>>file name with invalid utf-8 sequence 'e: testcase/' (without
>>valgrind errors after above patches) then when processing 
>>again, vim displays next file 'e: testcase/' but observe
>>that valgrind reports following error:
>>
>> ==22527== Conditional jump or move depends on uninitialised value(s)
>> ==22527==at 0x811C4CB: utf_ptr2char (mbyte.c:1390)
>> ==22527==by 0x811C843: utf_composinglike (mbyte.c:1498)
>> ==22527==by 0x811CDC8: utfc_ptr2len_len (mbyte.c:1769)
>> ==22527==by 0x80FEAF1: msg_outtrans_len_attr (message.c:1355)
>> ==22527==by 0x80FE9D0: msg_outtrans_len (message.c:1292)
>> ==22527==by 0x80B9D7F: draw_cmdline (ex_getln.c:2641)
>> ==22527==by 0x80BAA99: redrawcmd (ex_getln.c:3126)
>> ==22527==by 0x80BAF82: nextwild (ex_getln.c:3317)
>> ==22527==by

Re: [patch] fixed typos in help files

[Adri Verhoef]

On Wed, Jun 25, 2008 at 20:26:59 +, Dominique Pelle wrote:
> *** version7.txt  24 Jun 2008 22:33:14 -  1.217
> --- version7.txt  25 Jun 2008 20:11:22 -
> ***
> *** 263,269 
>   Ruby|ft-ruby-omni|
>   SQL |ft-sql-omni|
>   XML |ft-xml-omni|
> ! any language wih syntax highligting |ft-syntax-omni|
>   
>   You can add your own omni completion scripts.
>   
> --- 263,269 
>   Ruby|ft-ruby-omni|
>   SQL |ft-sql-omni|
>   XML |ft-xml-omni|
> ! any language with syntax highligting|ft-syntax-omni|

Also notice that it should be 'highlighting'.

Cheers,
Adri

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Vim Patches Project. [Was: updated 'relativenumber' patch]

[Ag. D. Hatzimanikas]

On Sun, Jun 29, at 03:19 Bram Moolenaar wrote:
> 
> 
> Richard -
> 
> > On Fri, Jun 27, 2008 at 01:23, Markus Heidelberg
> > <[EMAIL PROTECTED]> wrote:
> > 
> > > I have adapted my relativenumber patch to Vim 7.2a, initial version
> > > was from 21.02.2008. Unfortunately it didn't get into mainline yet.
> > 
> > I did not test it against 7.2a, but the feature does have its uses.
> > Bram, are you
> > willing to accept this patch? Is there something you want to see from the
> > community before you consider adding it?
> 
> I don't know.  I can see it's somewhat useful, but it's also a "yet
> another option" thing.
>

Besides that it looks like a useful option, (with this chance) I would
like to suggest a new project, with the simple purpose to gather or to link,
to all those patches from different sources for different purposes and
needs, that are not *yet* on the mainline or for some reasons they will
never be.

This will help:

- to redirect people when looking for a feature that is not yet
  available in the mainline
- to help Bram integrate a patch, when the patch is mature or there
  is a demand for it
- to be easy to contribute for a (possible) better implementation
  or for a simple fix
- to have a centralized place to all those patches, to help users
  extend their vim in various (sometimes unlimited) ways

I know at least (besides Markus Heidelberg's relativenumber patch):

[1] Vince Negri's Conseal patch
[2] Bill McCArthy's & Ben Schmidt's (some more math functions)
[3] Konstantin Korikov's langmapmb  (very useful in multibyte locales)
[4] vimGdb
[5] vimshell

... and I am sure there might be others.

As a host I would suggest code google [6], as it has svn access, an issue
tracker and a wiki. A link to this project from the official vim site, will
be appropriate (with the usual warnings), although not strictly
necessary. A link also from the vim wiki it seems natural.

Just an idea.

1. http://vince.negri.googlepages.com/
2. http://groups.google.com/group/vim_dev/browse_thread/thread/995aa20aac6b7bd4#
3. 
http://lostclus.linux.kiev.ua/Other_Works/Patches?action=AttachFile&do=get&target=vim71-langmapmb-4.patch
   http://tech.groups.yahoo.com/group/vim-multibyte/message/2232?l=1
4. http://clewn.sourceforge.net/
5. http://www.wana.at/vimshell/
   http://www.wogri.at/pipermail/vimshell/2007-August/000648.html
6. http://code.google.com/hosting/

Regards,

Ag.

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Patch 7.2a.010

[Bram Moolenaar]

Patch 7.2a.010
Problem:When a file name has an illegal byte sequence Vim may read
uninitialised memory.
Solution:   Don't use UTF_COMPOSINGLIKE() on an illegal byte.  In
msg_outtrans_len_attr() use char2cells() instead of ptr2cells().
In utf_ptr2char() don't check second byte when first byte is
illega.  (Dominique Pelle)
Files:  src/mbyte.c, src/message.c


*** ../vim-7.2a.009/src/mbyte.c Tue Jun 24 23:15:45 2008
--- src/mbyte.c Sun Jun 29 16:00:54 2008
***
*** 1387,1393 
return p[0];
  
  len = utf8len_tab[p[0]];
! if ((p[1] & 0xc0) == 0x80)
  {
if (len == 2)
return ((p[0] & 0x1f) << 6) + (p[1] & 0x3f);
--- 1387,1393 
return p[0];
  
  len = utf8len_tab[p[0]];
! if (len > 1 && (p[1] & 0xc0) == 0x80)
  {
if (len == 2)
return ((p[0] & 0x1f) << 6) + (p[1] & 0x3f);
***
*** 1753,1766 
  #endif
  while (len < size)
  {
!   if (p[len] < 0x80 || !UTF_COMPOSINGLIKE(p + prevlen, p + len))
break;
  
/* Skip over composing char */
  #ifdef FEAT_ARABIC
prevlen = len;
  #endif
!   len += utf_ptr2len_len(p + len, size - len);
  }
  return len;
  }
--- 1753,1779 
  #endif
  while (len < size)
  {
!   int len_next_char;
! 
!   if (p[len] < 0x80)
!   break;
! 
!   /*
!* Next character length should not go beyond size to ensure that
!* UTF_COMPOSINGLIKE(...) does not read beyond size.
!*/
!   len_next_char = utf_ptr2len_len(p + len, size - len);
!   if (len_next_char > size - len)
!   break;
! 
!   if (!UTF_COMPOSINGLIKE(p + prevlen, p + len))
break;
  
/* Skip over composing char */
  #ifdef FEAT_ARABIC
prevlen = len;
  #endif
!   len += len_next_char;
  }
  return len;
  }
*** ../vim-7.2a.009/src/message.c   Sat Jun 28 16:09:31 2008
--- src/message.c   Sun Jun 29 15:57:17 2008
***
*** 1391,1397 
plain_start = str + 1;
msg_puts_attr(s, attr == 0 ? hl_attr(HLF_8) : attr);
}
!   retval += ptr2cells(str);
++str;
}
  }
--- 1391,1397 
plain_start = str + 1;
msg_puts_attr(s, attr == 0 ? hl_attr(HLF_8) : attr);
}
!   retval += char2cells(*str);
++str;
}
  }
*** ../vim-7.2a.009/src/version.c   Sun Jun 29 13:59:48 2008
--- src/version.c   Sun Jun 29 16:12:49 2008
***
*** 678,679 
--- 678,681 
  {   /* Add new patch number below this line */
+ /**/
+ 10,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
118. You are on a first-name basis with your ISP's staff.

 /// 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.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: [patch] fixed 3 bugs with invalid utf-8 sequences

[Bram Moolenaar]

Dominique Pelle wrote:

> Here is another bug because of invalid utf-8 sequence:
> 
> ==21329== Conditional jump or move depends on uninitialised value(s)
> ==21329==at 0x811C4C7: utf_ptr2char (mbyte.c:1390)
> ==21329==by 0x811C83F: utf_composinglike (mbyte.c:1498)
> ==21329==by 0x811CD96: utfc_ptr2len_len (mbyte.c:1756)
> ==21329==by 0x80FEAF1: msg_outtrans_len_attr (message.c:1355)
> ==21329==by 0x80FE9D0: msg_outtrans_len (message.c:1292)
> ==21329==by 0x80B9D7F: draw_cmdline (ex_getln.c:2641)
> ==21329==by 0x80BAA99: redrawcmd (ex_getln.c:3126)
> ==21329==by 0x80BAF82: nextwild (ex_getln.c:3317)
> ==21329==by 0x80B6D3B: getcmdline (ex_getln.c:803)
> ==21329==by 0x80B912E: getexline (ex_getln.c:2101)
> ==21329==by 0x80A33FC: do_cmdline (ex_docmd.c:991)
> ==21329==by 0x81280DD: nv_colon (normal.c:5181)
> ==21329==by 0x8121772: normal_cmd (normal.c:1152)
> ==21329==by 0x80E4E8A: main_loop (main.c:1177)
> ==21329==by 0x80E49DA: main (main.c:936)
> 
> ==21434== Conditional jump or move depends on uninitialised value(s)
> ==21434==at 0x811C4C7: utf_ptr2char (mbyte.c:1390)
> ==21434==by 0x811C28C: utf_ptr2cells (mbyte.c:1268)
> ==21434==by 0x805D084: ptr2cells (charset.c:746)
> ==21434==by 0x80FEC65: msg_outtrans_len_attr (message.c:1394)
> ==21434==by 0x80FE9D0: msg_outtrans_len (message.c:1292)
> ==21434==by 0x80B9D7F: draw_cmdline (ex_getln.c:2641)
> ==21434==by 0x80BAA99: redrawcmd (ex_getln.c:3126)
> ==21434==by 0x80BAF82: nextwild (ex_getln.c:3317)
> ==21434==by 0x80B6D3B: getcmdline (ex_getln.c:803)
> ==21434==by 0x80B912E: getexline (ex_getln.c:2101)
> ==21434==by 0x80A33FC: do_cmdline (ex_docmd.c:991)
> ==21434==by 0x81280DD: nv_colon (normal.c:5181)
> ==21434==by 0x8121772: normal_cmd (normal.c:1152)
> ==21434==by 0x80E4E8A: main_loop (main.c:1177)
> ==21434==by 0x80E49DA: main (main.c:936)
> 
> It's easy to reproduce:
> 
> 1/ Create a file names with invalid utf-8 name:
> 
>$ mkdir testcase
>$ touch testcase/$(perl -e 'print chr(0xfb)')
> 
> 2/ Start Vim in 'no compatible' mode with Valgrind:
> 
>$ valgrind vim -u NONE -c -N 2> vg.log
> 
> 4/ In ex mode, enter:
> 
>:e testcase/
> 
>When pressing  key (file completion), vim should display
>file name with invalid utf-8 sequence 'testcase/'
>and observe in vg.log that valgrind reports above errors.
> 
> The 2 error messages are actually 2 distinct bugs.
> 
> - First error: in mbyte.c:1756, calling
>   UTF_COMPOSINGLIKE(p + prevlen, p + len) is unsafe, since it
>   can read bytes beyond size.  So in theory, there is a small risk
>   that vim combines characters when it should not.
> 
>   Attached patch "fix1-invalid-utf8-seq.patch" fixes this first
>   error, by calling utf_ptr2len_len(p + len, size - len) before
>   UTF_COMPOSINGLIKE(...) to ensure that UTF_COMPOSINGLIKE(...)
>   can't access beyond size.
> 
> - Second error: in message.c:1394, calling ptr2cells(str) is
>   unsafe since it can read bytes in str beyond len (which are
>   uninitialized).  At line 1394, we know that the character is
>   only 1 byte long (mb_l is 1) so it should call char2cells(*str).
>   mb_l is 1 here because of incomplete utf-8 sequence so calling
>   ptr2cells(str) overflows.
> 
>   Attached patch "fix2-invalid-utf8-seq.patch" fixes it.
> 
> After fixing these 2 bugs, valgrind no longer complains with
> the above testcase.
> 
> However, there is a 3rd bug which can be triggered with a slightly
> different test case, using file  instead of .  The difference
> is that  is an invalid utf-8 sequence, whereas  was an
> incomplete utf-8 sequence:
> 
> 1/ Create a file names with invalid utf-8 names:
> 
>$ mkdir testcase
>$ touch testcase/$(perl -e 'print chr(0xff)')
> 
> 2/ Start Vim in 'no compatible' mode with Valgrind:
> 
>$ valgrind vim -u NONE -c -N 2> vg.log
> 
> 3/ In ex mode, enter:
> 
>:e testcase/
> 
>When pressing  key (file completion), vim should display
>file name with invalid utf-8 sequence 'e: testcase/' (without
>valgrind errors after above patches) then when processing 
>again, vim displays next file 'e: testcase/' but observe
>that valgrind reports following error:
> 
> ==22527== Conditional jump or move depends on uninitialised value(s)
> ==22527==at 0x811C4CB: utf_ptr2char (mbyte.c:1390)
> ==22527==by 0x811C843: utf_composinglike (mbyte.c:1498)
> ==22527==by 0x811CDC8: utfc_ptr2len_len (mbyte.c:1769)
> ==22527==by 0x80FEAF1: msg_outtrans_len_attr (message.c:1355)
> ==22527==by 0x80FE9D0: msg_outtrans_len (message.c:1292)
> ==22527==by 0x80B9D7F: draw_cmdline (ex_getln.c:2641)
> ==22527==by 0x80BAA99: redrawcmd (ex_getln.c:3126)
> ==22527==by 0x80BAF82: nextwild (ex_getln.c:3317)
> ==22527==by 0x80B6CC6: getcmdline (ex_getln.c:790)
> ==22527==by 0x80B912E: getexline (ex_getln.c:2101)
> ==22527==by 0x80A33FC: do_cmdline (ex_docmd

Re: updated 'relativenumber' patch

[Bram Moolenaar]

Richard -

> On Fri, Jun 27, 2008 at 01:23, Markus Heidelberg
> <[EMAIL PROTECTED]> wrote:
> 
> > I have adapted my relativenumber patch to Vim 7.2a, initial version
> > was from 21.02.2008. Unfortunately it didn't get into mainline yet.
> 
> I did not test it against 7.2a, but the feature does have its uses.
> Bram, are you
> willing to accept this patch? Is there something you want to see from the
> community before you consider adding it?

I don't know.  I can see it's somewhat useful, but it's also a "yet
another option" thing.

- Bram

-- 
FIXME and XXX are two common keywords used to mark broken or incomplete code
not only since XXX as a sex reference would grab everbodys attention but
simply due to the fact that Vim would highlight these words.
-- Hendrik Scholz

 /// 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.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Patch 7.2a.009

[Bram Moolenaar]

Patch 7.2a.009
Problem:cygwin_conv_to_posix_path() does not specify buffer size.
Solution:   Use new Cygwin function: cygwin_conv_path(). (Corinna Vinschen)
Files:  src/main.c, src/os_unix.c


*** ../vim-7.2a.008/src/main.c  Wed Jun 25 00:33:06 2008
--- src/main.c  Sat Jun 28 17:07:03 2008
***
*** 20,26 
  
  #ifdef __CYGWIN__
  # ifndef WIN32
! #  include  /* for cygwin_conv_to_posix_path() */
  # endif
  # include 
  #endif
--- 20,28 
  
  #ifdef __CYGWIN__
  # ifndef WIN32
! #  include 
! #  include  /* for cygwin_conv_to_posix_path() and/or
!* cygwin_conv_path() */
  # endif
  # include 
  #endif
***
*** 2213,2219 
--- 2215,2225 
{
char posix_path[PATH_MAX];
  
+ # if CYGWIN_VERSION_DLL_MAJOR >= 1007
+   cygwin_conv_path(CCP_WIN_A_TO_POSIX, p, posix_path, PATH_MAX);
+ # else
cygwin_conv_to_posix_path(p, posix_path);
+ # endif
vim_free(p);
p = vim_strsave(posix_path);
if (p == NULL)
*** ../vim-7.2a.008/src/os_unix.c   Tue Jun 24 23:13:23 2008
--- src/os_unix.c   Sat Jun 28 17:08:30 2008
***
*** 58,64 
  
  #ifdef __CYGWIN__
  # ifndef WIN32
! #  include  /* for cygwin_conv_to_posix_path() */
  # endif
  #endif
  
--- 58,66 
  
  #ifdef __CYGWIN__
  # ifndef WIN32
! #  include 
! #  include  /* for cygwin_conv_to_posix_path() and/or
!* for cygwin_conv_path() */
  # endif
  #endif
  
***
*** 2312,2318 
--- 2314,2324 
  /*
   * This helps for when "/etc/hosts" is a symlink to "c:/something/hosts".
   */
+ # if CYGWIN_VERSION_DLL_MAJOR >= 1007
+ cygwin_conv_path(CCP_WIN_A_TO_POSIX, fname, posix_fname, MAXPATHL);
+ # else
  cygwin_conv_to_posix_path(fname, posix_fname);
+ # endif
  fname = posix_fname;
  #endif
  
*** ../vim-7.2a.008/src/version.c   Sat Jun 28 16:09:31 2008
--- src/version.c   Sun Jun 29 13:56:55 2008
***
*** 678,679 
--- 678,681 
  {   /* Add new patch number below this line */
+ /**/
+ 9,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
112. You are amazed that anyone uses a phone without a modem on it...let
 alone hear actual voices.

 /// 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.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

[patch] fixed 3 bugs with invalid utf-8 sequences

[Dominique Pelle]

Here is another bug because of invalid utf-8 sequence:

==21329== Conditional jump or move depends on uninitialised value(s)
==21329==at 0x811C4C7: utf_ptr2char (mbyte.c:1390)
==21329==by 0x811C83F: utf_composinglike (mbyte.c:1498)
==21329==by 0x811CD96: utfc_ptr2len_len (mbyte.c:1756)
==21329==by 0x80FEAF1: msg_outtrans_len_attr (message.c:1355)
==21329==by 0x80FE9D0: msg_outtrans_len (message.c:1292)
==21329==by 0x80B9D7F: draw_cmdline (ex_getln.c:2641)
==21329==by 0x80BAA99: redrawcmd (ex_getln.c:3126)
==21329==by 0x80BAF82: nextwild (ex_getln.c:3317)
==21329==by 0x80B6D3B: getcmdline (ex_getln.c:803)
==21329==by 0x80B912E: getexline (ex_getln.c:2101)
==21329==by 0x80A33FC: do_cmdline (ex_docmd.c:991)
==21329==by 0x81280DD: nv_colon (normal.c:5181)
==21329==by 0x8121772: normal_cmd (normal.c:1152)
==21329==by 0x80E4E8A: main_loop (main.c:1177)
==21329==by 0x80E49DA: main (main.c:936)

==21434== Conditional jump or move depends on uninitialised value(s)
==21434==at 0x811C4C7: utf_ptr2char (mbyte.c:1390)
==21434==by 0x811C28C: utf_ptr2cells (mbyte.c:1268)
==21434==by 0x805D084: ptr2cells (charset.c:746)
==21434==by 0x80FEC65: msg_outtrans_len_attr (message.c:1394)
==21434==by 0x80FE9D0: msg_outtrans_len (message.c:1292)
==21434==by 0x80B9D7F: draw_cmdline (ex_getln.c:2641)
==21434==by 0x80BAA99: redrawcmd (ex_getln.c:3126)
==21434==by 0x80BAF82: nextwild (ex_getln.c:3317)
==21434==by 0x80B6D3B: getcmdline (ex_getln.c:803)
==21434==by 0x80B912E: getexline (ex_getln.c:2101)
==21434==by 0x80A33FC: do_cmdline (ex_docmd.c:991)
==21434==by 0x81280DD: nv_colon (normal.c:5181)
==21434==by 0x8121772: normal_cmd (normal.c:1152)
==21434==by 0x80E4E8A: main_loop (main.c:1177)
==21434==by 0x80E49DA: main (main.c:936)

It's easy to reproduce:

1/ Create a file names with invalid utf-8 name:

   $ mkdir testcase
   $ touch testcase/$(perl -e 'print chr(0xfb)')

2/ Start Vim in 'no compatible' mode with Valgrind:

   $ valgrind vim -u NONE -c -N 2> vg.log

4/ In ex mode, enter:

   :e testcase/

   When pressing  key (file completion), vim should display
   file name with invalid utf-8 sequence 'testcase/'
   and observe in vg.log that valgrind reports above errors.

The 2 error messages are actually 2 distinct bugs.

- First error: in mbyte.c:1756, calling
  UTF_COMPOSINGLIKE(p + prevlen, p + len) is unsafe, since it
  can read bytes beyond size.  So in theory, there is a small risk
  that vim combines characters when it should not.

  Attached patch "fix1-invalid-utf8-seq.patch" fixes this first
  error, by calling utf_ptr2len_len(p + len, size - len) before
  UTF_COMPOSINGLIKE(...) to ensure that UTF_COMPOSINGLIKE(...)
  can't access beyond size.

- Second error: in message.c:1394, calling ptr2cells(str) is
  unsafe since it can read bytes in str beyond len (which are
  uninitialized).  At line 1394, we know that the character is
  only 1 byte long (mb_l is 1) so it should call char2cells(*str).
  mb_l is 1 here because of incomplete utf-8 sequence so calling
  ptr2cells(str) overflows.

  Attached patch "fix2-invalid-utf8-seq.patch" fixes it.

After fixing these 2 bugs, valgrind no longer complains with
the above testcase.

However, there is a 3rd bug which can be triggered with a slightly
different test case, using file  instead of .  The difference
is that  is an invalid utf-8 sequence, whereas  was an
incomplete utf-8 sequence:

1/ Create a file names with invalid utf-8 names:

   $ mkdir testcase
   $ touch testcase/$(perl -e 'print chr(0xff)')

2/ Start Vim in 'no compatible' mode with Valgrind:

   $ valgrind vim -u NONE -c -N 2> vg.log

3/ In ex mode, enter:

   :e testcase/

   When pressing  key (file completion), vim should display
   file name with invalid utf-8 sequence 'e: testcase/' (without
   valgrind errors after above patches) then when processing 
   again, vim displays next file 'e: testcase/' but observe
   that valgrind reports following error:

==22527== Conditional jump or move depends on uninitialised value(s)
==22527==at 0x811C4CB: utf_ptr2char (mbyte.c:1390)
==22527==by 0x811C843: utf_composinglike (mbyte.c:1498)
==22527==by 0x811CDC8: utfc_ptr2len_len (mbyte.c:1769)
==22527==by 0x80FEAF1: msg_outtrans_len_attr (message.c:1355)
==22527==by 0x80FE9D0: msg_outtrans_len (message.c:1292)
==22527==by 0x80B9D7F: draw_cmdline (ex_getln.c:2641)
==22527==by 0x80BAA99: redrawcmd (ex_getln.c:3126)
==22527==by 0x80BAF82: nextwild (ex_getln.c:3317)
==22527==by 0x80B6CC6: getcmdline (ex_getln.c:790)
==22527==by 0x80B912E: getexline (ex_getln.c:2101)
==22527==by 0x80A33FC: do_cmdline (ex_docmd.c:991)
==22527==by 0x81280F5: nv_colon (normal.c:5181)
==22527==by 0x812178A: normal_cmd (normal.c:1152)
==22527==by 0x80E4E8A: main_loop (main.c:1177)
==22527==by 0x80E49DA: main (main.c:936)

This bug happens because utf_ptr2char(p) does

Re: updated 'relativenumber' patch

[Richard Hartmann]

On Fri, Jun 27, 2008 at 01:23, Markus Heidelberg
<[EMAIL PROTECTED]> wrote:

> I have adapted my relativenumber patch to Vim 7.2a, initial version was from
> 21.02.2008. Unfortunately it didn't get into mainline yet.

I did not test it against 7.2a, but the feature does have its uses.
Bram, are you
willing to accept this patch? Is there something you want to see from the
community before you consider adding it?


Richard

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---