[vlc-devel] [PATCH 5a/5] stream_ReadLine: control maximum length with object variable

[Rémi Denis-Courmont]

Le maanantaina 7. syyskuuta 2020, 14.48.31 EEST Pierre Ynard via vlc-devel a 
écrit :
> > There are no valid use cases for doing this in Lua. You have not
> > exhibited any line-based file formats that needs larger lines. As
> > François and I already reminded you multiples times, HTML is NOT
> > line-based.
> 
> You're invoking the semantic argument here, that HTML is not lines so
> stream_ReadLine() shouldn't be used.

Where did I write that it should not be used? I wrote that HTML is not a use 
case for the purpose, and thus the semantics, of the API.

> But you're trying to have it both
> ways: the current API you defend is semantically broken.

I fail to see why.

> It doesn't even honor what it says it does - it's called ReadLine(),
> not ReadBoundLine().

Now that's sophistry. There has to be a limit. 200,000 is much longer than any 
reasonable use.

> The hardcoded limit isn't documented, neither its
> existence nor its length. As I think we've already established, the
> limit's concern for memory starvation is irrelevant at that order of
> magnitude, and its concern for what the consumer can handle is out of
> place.

It is not irrelevant. Could we read a 16 MiB line at once? Yes. But unlike say 
the stream buffer or the picture pools, there can be many read lines 
concurrently.

Besides, the limit is defined from what is (much more than) reasonable to 
expect, not what is manageable to handle but utterly insane to expect.

> Rejection semantics are completely wrong too. The API doesn't
> differentiate between actual failure, purposefully rejecting lines over
> the limit, and EOF.
(...)

That's just plain false. You can check vlc_stream_Eof() if you want to 
differentiate, much like regular standard I/O functions.

> It also consumes the stream data and then trashes it if the line is
> incomplete. 
(...)

That's also false. vlc_stream_ReadLine() use peek internally so as to preserve 
the read offset on error.

So seems like the arguments about "proper semantics" are just trolling.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/