[vlc-devel] [PATCH] Add open_memstream replacement

[Rémi Denis-Courmont]

Le torstaina 25. elokuuta 2016, 13.19.45 EEST Derek Buitenhuis a écrit :
> > With the current vlc_uri_compose(), I counted 104 different combination of
> > formats, and it doesn´t even support URI fragments yet. With the other
> > call
> > sites, I can´t even see how you´d use printf() directly as we can´t
> > express
> > loops within a single printf() function call.
> 
> I did not suggest solely to use format printing. There's no reason
> vlc_uri_compose can't be implemented using various (including non-printf!)
> functions, other than "it's inconvenient".

Oone _can_ reimplement *s*printf() and even open_memstream() functionality 
using hand-coded memory management and free-standing format conversions.

Can but should not. It´s a error-prone, unmaintainable, and widely considered 
and documented as a very bad practice (not just by me).

> > I only know three string buffers in C, open_memstream/fmemopen (POSIX),
> > funopen (BSD) and fopencookie (GNU). The first one is the most standard.
> > And perhaps more importantly it is also the least generic, so it can be
> > reimplemented with the other two. The reverse is not true.
> 
> And it seems pretty silly to me to include entire 200 line reimplemntations
> and also not supporting Windows, in order to use the latter two, when it
> is not 100% required. Of course, I am not: a) A VLC developer or b) A
> VideoLAN Board member, so my opniion isn't worth much here; I'm the peanut
> gallery.
> > Now if you know a better C string buffers API, please advise. snprintf()
> > is
> > NOT a better C string buffers API, and I don´t suppose you suggest
> > switching to C++.
> 
> [...]
> 
> >> < Daemon404> (also, fyi, the current
> >> open_memstream based impl will fail hard if there is an alloc failure,
> >> since all the writes to the buffer are unchecked)
> > 
> > I fail to see how realloc() will make a difference there. If memory
> > allocation fails, the best you can do is hope the process won´t be killed
> > and return an error to the caller (which we do, AFAIK).
> 
> I meant this in a "the current implementation will already fail on
> alloc failure" way, not to suggest that realloc is better at this.
> I do think a realloc() failure is easier checked in a more explicitly
> way than a memory back FILE having a realloc failure, though. As above,
> I'm not a VLC developer, so I don't know VLC's policies on explicit
> OOM/allco failure checking.

The VLC policy on OOM is to not crash, not trigger undefined behaviour and not 
raise potential security issues. Though most certainly, there are plenty of 
side channel attacks there and elsewhere, e.g. involving timing. There are 
also plenty of misbehaviour, as many code paths fail to distinguish error from 
lack of value/result or the like (using NULL in both cases).

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