[vlc-devel] [PATCH] Add open_memstream replacement

Rémi Denis-Courmont remi at remlab.net
Thu Aug 25 15:13:15 CEST 2016

Le torstaina 25. elokuuta 2016, 13.58.57 EEST Derek Buitenhuis a écrit :
> On 8/25/2016 1:53 PM, Rémi Denis-Courmont wrote:
> >> To be clear, this is kinda what I mean (rad the disclaimed at the top):
> >>     https://gist.github.com/dwbuiten/66f007058d27bf04663c362732f9be2a
> > 
> > That´s awful.
> 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.

I don´t trust myself to do that right, and I trust others even less in this 
respect. Because in this case, that trust would be clearly undeserved. That 
really is not a matter of taste. And there are no performance concerns here.

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.

> >> That kind of thing, in my mind, is preferable to a 'convenient' solution
> >> that is less portable.
> > 
> > I utterly disagree. And FWIW, even the kernel (!) has introduced
> > convenience helpers for buffer formatting - for pretty much the same
> > purposes/reasons.
> 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.

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

Rémi Denis-Courmont

More information about the vlc-devel mailing list