I started my inquiry as a mere minor nuisance to my custom vim build
script. Little did I realize that it was of far greater significance.
Thanks for the report to the grep dev folk. There are some (many) utils
where I always assume any upgrade is progress & safe. I sent an email to
Patrick
On 2016-11-13, Gary Johnson wrote:
> On 2016-11-13, Guido wrote:
> > I found a post on LQ about this. It's affecting LOTS more stuff
> > than just vim. I reverted to grep-2.25 & will wait for the
> > upstream community to decide what to do.
>
> That seems like the best idea for now.
>
> >
On 2016-11-13, Guido wrote:
> On Sunday, November 13, 2016 at 1:02:00 PM UTC-8, Gary Johnson wrote:
> > On 2016-11-13, Guido wrote:
> > > On Saturday, November 5, 2016 at 1:19:49 PM UTC-7, Guido wrote:
> > > > During the make cycle, cc* (.c, .o, .s, .le, .ls) appear, then
> > > > are removed in
On Sunday, November 13, 2016 at 1:02:00 PM UTC-8, Gary Johnson wrote:
> On 2016-11-13, Guido wrote:
> > On Saturday, November 5, 2016 at 1:19:49 PM UTC-7, Guido wrote:
> > > During the make cycle, cc* (.c, .o, .s, .le, .ls) appear, then
> > > are removed in /tmp.
> > >
> > > In 8.0.0055, I'm left
On 2016-11-13, Guido wrote:
> On Saturday, November 5, 2016 at 1:19:49 PM UTC-7, Guido wrote:
> > During the make cycle, cc* (.c, .o, .s, .le, .ls) appear, then
> > are removed in /tmp.
> >
> > In 8.0.0055, I'm left with 3 empty .c, .o, .le files + a .ld
> > file giving the allowable ld options
On Saturday, November 5, 2016 at 1:19:49 PM UTC-7, Guido wrote:
> During the make cycle, cc* (.c, .o, .s, .le, .ls) appear, then are removed in
> /tmp.
>
>
> In 8.0.0055, I'm left with 3 empty .c, .o, .le files + a .ld file giving the
> allowable ld options since it did not like an option or
Hi Bram and list,
How to reproduce:
- Start vanilla Vim with two buffers.
$ vim -Nu NONE -o a b
- buffer 'a' to modified.
:set modofied
- exec :hide command with trail comment
:hide " command
Expected behavior:
- :hide command succeed.
Actual behavior:
- Occurred 'E474: Invalid argument'
Hi
afl-fuzz found another case of use of free memory with
vim-8.0.84 and older.
Steps to reproduce:
$ cat > use-free-mem.vim < vg.log
And vg.log contains:
==5261== Memcheck, a memory error detector
==5261== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==5261== Using
Patch 8.0.0084
Problem:Using freed memory when adding to a quickfix list. (Domenique
Pelle)
Solution: Clear the directory name.
Files: src/quicfix.c, src/testdir/test_quickfix.vim
*** ../vim-8.0.0083/src/quickfix.c 2016-11-12 18:14:39.605896756 +0100
---
Dominique Pellé wrote:
> afl-fuzz found another case which causes
> use of free memory in vim-8.0.82 and older.
>
> Steps to reproduce it:
>
> $ cat >use-free-mem.vim < lexpr 0
> lopen
> fun X(c)
> let save_efm=
> set efm=%D%f
> if a:c == 'c'
> caddexpr '::'
> else
> laddexpr
Dominique Pellé wrote:
> afl-fuzz found this case which causes vim-8.0.81 and
> older to use free memory:
>
> $ cat >use-free-mem.vim < tabedit X
> tabfirst
> copen
> only
> echo win_getid(1, 1)
> EOF
>
> $ valgrind vim -u NONE -S use-free-mem.vim -cqa 2> vg.log
>
> And vg.log contains:
>
>
Patch 8.0.0083
Problem:Using freed memory with win_getid(). (Domenique Pelle)
Solution: For the current tab use curwin.
Files: src/window.c, src/testdir/test_window_id.vim
*** ../vim-8.0.0082/src/window.c2016-11-10 20:01:41.201582868 +0100
--- src/window.c2016-11-13
12 matches
Mail list logo
