2016-01-23 14:08 GMT+03:00 Theo Buehler <t...@math.ethz.ch>: > On Sat, Jan 23, 2016 at 11:03:39AM +0100, Martijn van Duren wrote: >> Here's a small update: >> On 01/22/16 21:18, Martijn van Duren wrote: >> >3) 3_vi_remove_progname.diff: Don't keep a copy of the progname in >> >memory, use getprogname instead. >> Attached without the setprogname. The reason I included setprogname was >> because getprogname in the manpage doesn't mention that it always returns a >> stripped version and it's a strict requirement of vi. >> >4) 4_vi_remove_tail.diff: Use basename instead of tail >> The second basename is inside #define DEBUG, so I missed it in the compile >> check. >> Furthermore it's only used for msgq, which uses it it vsnprint and I can't >> imagine it can hurt in there. >> As for the input, it's used with a variable file and __FILE__, so it >> shouldn't cause any more harm than tail. > > patches 1-4 and 6 are fine with me now, modulo s/baneame/basename in > vi/vs_refresh.c:477 (I think that's what zhuk@ meant). > > I must say I liked the previous version of 5 better. > > I haven't checked all of 5, but the addition of these msgq(..) calls in > common/{screen.c,seq.c} looks wrong to me. The error paths goto mem* > already contain such a call to msgq.
I absolutely agree that those calls look like wrong and could do bad things in case of ENOMEM. My point is that we should make them visible first, by doing a simple, reviewable change like unmacrosing the C module files, and only then remove/rework stuff. -- WBR, Vadim Zhukov