[vlc-devel] [PATCH] Add open_memstream replacement

[Rémi Denis-Courmont]

Le torstaina 25. elokuuta 2016, 14.33.53 EEST Derek Buitenhuis a écrit :
> > It´s not a question or liking or disliking it. It´s a matter of
> > experience,
> > especially but not limited to within this project. We keep screwing up
> > manual buffer formatting. The history is riddled with such bugs, a lot of
> > which turned out as security issues.
> 
> Then state the reason as such. Simply stating "that's awful" helps in
> absolutely no way, and is a 100% useless email to send.

First email: "[monster format strings] have conveyed bugs times and times"

Second email: "[hand-coded memory management] is a error-prone, 
unmaintainable, and widely considered and documented as a very bad practice 
(not just by me)."

Third email: "even the kernel (!) has introduced convenience 
helpers for buffer formatting - for pretty much the same purposes/reasons"

Forth email: "We keep screwing up manual buffer formatting. The history is 
riddled with such bugs, a lot of which turned out as security issues."

I don´t think I withheld the concerns here.

> > Because in this case, that trust would be clearly undeserved. That
> > really is not a matter of taste.
> 
> Thanks, man.

This is not referring to you, since you have not contributed any such code to 
VLC. I am unable to trust the devs involved (including myself) much with that 
kind of things.

> > I also happen to find hand-coded buffer formatting harder to read and
> > understand, which might be a matter of taste. Although even then, there
> > are
> > high chances that I´d end up having to maintain the code so my taste might
> > actually matter.
> 
> So do I, but I'd still take "works on Windows and is ugly" over "doesn't
> work at all", given the choice.

I´d rather take "works on Linux and does not regress on Windows", over "is 
ugly, hard to maintainable and potentially broken and insecure".

I might have thought differently 13 years ago when I started.

> Again, perhaps you should actually communicate your reasons the first time
> then, and not expect the person whose idea or code you are reviewing to use
> their telepathy powers to divine that the reason for a vague "no".

I think I did.

-- 
Rémi Denis-Courmont
http://www.remlab.net/