[vlc-devel] [PATCH] Add open_memstream replacement
remi at remlab.net
Thu Aug 25 16:08:00 CEST 2016
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.
More information about the vlc-devel