Danek Duvall wrote: > On Solaris, at least: > > $ pwd [...] > 72754 /1@1: -> vim_free(0x82d3188, 0x0) > > In os_unix.c, the path we trace through mch_FullName() grabs the cwd > into "buf" (an input parameter) with mch_dirname(), which succeeds, > since it's just short enough to fit into the 1024-byte buffer (with > the trailing NUL). We then get the strlen() of buf, returning 1023, > as the truss output shows on line 72731. We then compare that value > to the input parameter "len", which is the size of "buf", and since > 1023 is not >= 1024, we assume we can add a slash to the end, > overwriting the end of the buffer. > > Looks like this code has been in place since at least vim 7.0 (in > fact, the code has looked like this since vim 6.0, and prior to that, > the behavior here was even worse), so it's been in all versions of vim > shipped in Solaris. > > If we instead compare "l >= len - 1", we avoid any of that, return > failure from mch_FullName(), and let vim handle that appropriately > higher up. We could try to fix it so that cwds of arbitrary lengths > are handled here, but it appears that vim handles it well enough, that > this simple fix is sufficient for now. > > And the patch that fixes the problem:
Good catch. I'll include it soon. -- Life is a gift, living is an art. (Bram Moolenaar) /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.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
