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

Reply via email to