Re: crash due to -fstack-protector false positive

2007-02-24 Thread Yakov Lerner

On 2/24/07, Bram Moolenaar [EMAIL PROTECTED] wrote:

 -char_u   di_key[1];  /* key (actually longer!) */
 +char_u   di_key[];   /* key (actually longer!) */


I think this is c99 vs c89 difference. C99 allows x[] as last member
of the struct, but c89 does not. As Bram mentioned, vim is written in
c89, not c99.


This won't work for standard C compilers, they will complain about
unkown size for di_key.

The problem is in the compiler, so fix the compiler.  Or perhaps there
is a way to silence the compiler?


Yakov


Regular expression warning E54 when saving arbitrary files (backslash-issue) including FIX

2007-02-24 Thread Basti Grembowietz

Hi vim-developers!

  I have a small bug-report with including fix.

WHAT:
  On my home PC the saving of a file always raised two E54 warnings. 
Yesterday this was annoying to much (having to press some key before 
working on normally, so I investigated a bit. And fixed it =) Open 
source is nice.


  It showed up that my chosen username in Windows XP was the cause of 
these warnings - it is (rax). This implies that my temporary 
directory is located at C:\DOKUME~1\(rax)\LOKALE~1\Temp\. And that 
was the reason for these E54 warnings.


  E54 means unmatched bracket (.  Usually backslashes will be 
replaced by [\/] when they are allowed as means to describe paths.


WHERE IT HAPPENS IN THE SOURCE:

	While saving, there are some paths added (for a purpose I do not see / 
but also do not need in this context):


fileio.c!buf_write():
3238 #ifdef FEAT_WILDIGN
3239if (dobackup  *p_bsk != NUL  match_file_list(p_bsk, sfname, 
ffname))

3240dobackup = FALSE;
3241 #endif

p_bsk	was set to 
C:\DOKUME~1\(rax)\LOKALE~1\Temp\*,C:\DOKUME~1\(rax)\LOKALE~1\Temp\*	


This goes then to fileio.c!match_file_list(), then to 
fileio.c!file_pat_to_reg_pat() - and there is the bug.


WANTED BEHAVIOUR:
file_pat_to_reg_pat should convert
C:\DOKUME~1\(rax)\LOKALE~1\Temp\ to
^C:[\/]DOKUME\~1[\/](rax)[\/]LOKALE\~1[\/]Temp[\/]  

CURRENT BEHAVIOUR:
file_pat_to_reg_pat converts
C:\DOKUME~1\(rax)\LOKALE~1\Temp\ to
^C:[\/]DOKUME\~1\(rax)[\/]LOKALE\~1[\/]Temp[\/] 


THE FIX
change

fileio.cpp!file_pat_to_reg_pat()
9368   if ((vim_isfilec(p[1]) || p[1] == '*' || p[1] == '?' )
9369 p[1] != '+')

to this:

fileio.cpp!file_pat_to_reg_pat()
9368   if ((vim_isfilec(p[1]) || p[1] == '*' || p[1] == '?' || p[1] == 
'(' )

9369 p[1] != '+')

NOTES
Maybe this behaviour can also be fixed for ')' as first character of a 
directory, as it will raise the same behaviour in VIM.


As I am new to vim-dev, who usually submits this to the repository? Can 
anyone make a cvs/svn/whateveryouuse-account?


Cheers,
Basti

PS: vim rocks.


PGP.sig
Description: Signierter Teil der Nachricht


RE: Win64-related patches

2007-02-24 Thread Michael Wookey
Hi Bram,

 Michael Wookey wrote:
 
   One bug that I didn't fix. Build gvim.exe with OLE=no, run 'gvim -
 register',
   and watch it crash while trying to display an error message.
 
  This seems to fix the bug...
 
  Index: src/message.c
  ===
  --- src/message.c   (revision 212)
  +++ src/message.c   (working copy)
  @@ -2987,7 +2987,7 @@
* If 'verbosefile' is set write message in that file.
* Must come before the rest because of updating msg_col.
*/
  -if (*p_vfile != NUL)
  +if (p_vfile  *p_vfile != NUL)
  verbose_write(s, maxlen);
 
   if (redir_fd != NULL
  Index: src/misc2.c
  ===
  --- src/misc2.c (revision 212)
  +++ src/misc2.c (working copy)
  @@ -1748,7 +1748,7 @@
  return NULL;
   }
   #endif
  -while ((b = *p) != NUL)
  +while (p  (b = *p) != NUL)
   {
  if (b == c)
  return p;
 
 
 Well, that may fix it, but the problem is that the order of
 initializations is violated.  Normally all option pointers are not
 NULL.

I think I've found it.  In src/main.c:main(), the call to gui_prepare()
needs to occur after set_init_1() for two reasons:

1. set_init_1() ends up initialising the options table - and therefore
p_vfile.

2. The win32 implementation of gui_mch_prepare() as called from
gui_prepare() calls ole_error() in an error path. ole_error() calls
through to EMSG2() which eventually uses p_vfile.  However since
gui_prepare() is called before set_init_1(), p_vfile has not yet been
initialised.

The attached patch demonstrates the solution by moving gui_prepare()
after set_init_1().

cheers



ole_register.patch
Description: ole_register.patch


RE: Win64-related patches

2007-02-24 Thread Michael Wookey
 Hi Bram,
 
  Michael Wookey wrote:
 
One bug that I didn't fix. Build gvim.exe with OLE=no, run 'gvim
 -
  register',
and watch it crash while trying to display an error message.
  
   This seems to fix the bug...
  
   Index: src/message.c
  
===
   --- src/message.c (revision 212)
   +++ src/message.c (working copy)
   @@ -2987,7 +2987,7 @@
 * If 'verbosefile' is set write message in that file.
 * Must come before the rest because of updating msg_col.
 */
   -if (*p_vfile != NUL)
   +if (p_vfile  *p_vfile != NUL)
 verbose_write(s, maxlen);
  
if (redir_fd != NULL
   Index: src/misc2.c
  
===
   --- src/misc2.c   (revision 212)
   +++ src/misc2.c   (working copy)
   @@ -1748,7 +1748,7 @@
 return NULL;
}
#endif
   -while ((b = *p) != NUL)
   +while (p  (b = *p) != NUL)
{
 if (b == c)
 return p;
  
 
  Well, that may fix it, but the problem is that the order of
  initializations is violated.  Normally all option pointers are not
  NULL.
 
 I think I've found it.  In src/main.c:main(), the call to
gui_prepare()
 needs to occur after set_init_1() for two reasons:
 
 1. set_init_1() ends up initialising the options table - and therefore
 p_vfile.
 
 2. The win32 implementation of gui_mch_prepare() as called from
 gui_prepare() calls ole_error() in an error path. ole_error() calls
 through to EMSG2() which eventually uses p_vfile.  However since
 gui_prepare() is called before set_init_1(), p_vfile has not yet been
 initialised.
 
 The attached patch demonstrates the solution by moving gui_prepare()
 after set_init_1().

I was over anxious! - attached is the correct patch.  The gui_prepare()
must also appear before command_line_scan() so that the -register is
recognised.

cheers


ole_register_corrected.patch
Description: ole_register_corrected.patch


Bug? in vimgrep with g flag and long lines.

2007-02-24 Thread A.J.Mechelynck
When cycling through matches using :cnext, if there are several matches in a 
single long line, the line is only shortened the first time (but _not_ the 
2nd, 3rd, etc.,) to avoid a Hit-Enter prompt.


Reproducible: every time.

Steps to reproduce:
1. :set wrap  I'm not sure this is necessary
2. :vimgrep /pattern/g filename
where:
- filename is a file or files with a number of lines longer than 'cmdheight' 
times 'columns'

- /pattern/ will happen more than once in some long lines
3. :cn
4. Go to step 3.

Notice that the first match in any given line never produces a Hit-enter 
prompt. Too-long lines have part of their non-matching text replaced by 


Actual result: 2nd, 3rd, etc. matches in any given line produces a Hit-enter 
prompt; the line is displayed in full, overflowing the command-line.


Expected result: No hit-enter prompts.

Additional info: I've been seeing this for as long as I've used :vimgrep 
(i.e., since shortly after that command was introduced) and I'm still seeing 
it in gvim 7.0.201. I just never came around to report it. (I didn't use the 
quickfix commands much before :vimgrep appeared, except for :helpgrep where 
lines are shorter than 80 characters.)



Best regards,
Tony.
--
I'm going to Boston to see my doctor.  He's a very sick man.
-- Fred Allen


Re: gvim, Windows NAS share of a unix file system, hard links

2007-02-24 Thread A.J.Mechelynck

Nathan Coulter wrote:

bug report
==

version:

VIM - Vi IMproved 7.0 (2006 May 7, compiled May  7 2006 16:23:43)
MS-Windows 32 bit GUI version with OLE support

problem:

Writing to a file on a windows share where the underlying filesystem
supports hard links, modifying a file using gvim (w command) causes 
the file to
acquire a new inode.  Contrast with the behavior of notepad.exe 
(file - save), which

respects the hard link, keeping the inode intact.



Apparently no patches were included: there are 201 official patches to date 
for Vim 7.0, the latest was a few days ago (see their table of contents at 
http://ftp.vim.org/pub/vim/patches/7.0/ ). Get updated distributions of Vim 
for Windows at 
https://sourceforge.net/project/showfiles.php?group_id=43866package_id=39721


I think this behaviour is related to how Vim handles backups. Set 'backupcopy' 
(q.v.) to yes in order to prevent renaming of the existing file:


  set bkc=yes
Vim copies the file to create a backup, then edits the old file
Advantage: all permission and ownership bits are conserved

  set bkc=no
Vim renames the existing file to create a backup, then edits a new file 
with the old name

advantage: faster

  set bkc=auto  default
same as no except when Vim can detect that this could cause problems 
(e.g., sees that the existing file is a link).

advantage: tries to combine the advantages of the other two.

Apparently in the case you mention, Vim-for-Windows doesn't detect that the 
target file is a hard link.



Best regards,
Tony.
--
Every group has a couple of experts.  And every group has at least one
idiot.  Thus are balance and harmony (and discord) maintained.  It's
sometimes hard to remember this in the bulk of the flamewars that all
of the hassle and pain is generally caused by one or two
highly-motivated, caustic twits.
-- Chuq Von Rospach, about Usenet