[vlc-devel] [vlc-commits] strings: use vlc_memstream in vlc_xml_encode()

[Filip Roséen]

Hi Rémi,

I am sad to see that you left out parts of my reply, especially those
regarding my contributions and how they result in a waste of time, how
my patches are "framed" (which I still do not know what you mean by),

On 2017-02-25 13:30, Rémi Denis-Courmont wrote:

> Le lauantaina 25. helmikuuta 2017, 11.13.22 EET Filip Roséen a écrit :
> > Hi Rémi,
> > 
> > On 2017-02-25 11:33, Rémi Denis-Courmont wrote:
> > > > But the VLC implemementation is not the only one, so that argument is
> > > > moot.
> > > 
> > > No and I already explained why.
> > 
> > I do not agree with your explanation, so we can probably agree on
> > disagreeing.
> 
> The explanation is factual. One does not get to agree or disagree with it.

Ok, now I completely am out of words. I thought this was a discussion,
not a place where "factual" statements expressed by one party are the
only truth, and opinions of the other party does not matter.

> > > > `vlc_memstream_open` can fail. If you consider it so unlikely
> > > > that one should not bother checking the *return-value* I do not see
> > > > why you put it there in the first place.
> > > 
> > > This is a red herring.
> > 
> > It is very much relevant to the discussion and cuts straight to what
> > you wrote about the unlikelihood of the function to fail (and not
> > having to check it).
> 
> You are again making the false dichotomy which you yourself deny.
> There is an error return because there is a possible error case.
> There is no "missing check" (and no VLC_USED qualifier) because the
> error can be safely ignored.

I think I have explained my ground in previous posts, but to
summarize:

 - I do not see why it is so bad introducing checks for the
   *return-value* (because I do not agree with your statement
   regarding how non-trivial an implemenation becomes), and;

 - I certainly do not see why removing the *return-value* would be
   foolish (when actually handling it is, as stated, wrong in most
   (all) cases).

/F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20170225/61d836ec/attachment.html>