[vlc-devel] [PATCH] Add open_memstream replacement

[Derek Buitenhuis]

On 8/25/2016 2:13 PM, Rémi Denis-Courmont wrote:
>> It's a matter of priorities and taste. Furthermore, that's not even a
>> legitimate technical review of the idea. It's akin to saying "I don't
>> like it, so no."
> 
> 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.

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

Thanks, man.

> And there are no performance concerns here.

Nobody mentioned performance.

> 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 can only agree to disagree. If it's the difference between using the
>> above, or not supporting Windows, a major OS, *at all*, in this function,
>> I'd choose the string-based book-keeping-filled code every day of the week.
> 
> First, I don´t see why open_memstream() can´t be added to Mingw. It´s not like 
> the construct is impossible or hard to implement on Windows. And then, I don´t 
> mind a sane alternative convenience wrappers set, so long as I don´t have to 
> write it or debug it on my unpaid time.

I recall them brushing off the idea on IRC at one point in time, because of
"the scope of the project" or something. This was years ago, however. Perhaps
they have changed their tune nowadays.

As for "sane alternative convenience wrappers", that's something I mentioned
as an idea on IRC yesterday. The internal implementation wouldn't be much better
than the example code I linked today, which was, in fact, an example for idea's
sake. It could live in a wrapper.

> No effense intended, but my experience prevents me from considering your 
> prototype reasonable in general. Even more so for the other two existing call 
> sites.

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".

- Derek