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

[Pierre Ynard]

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

Yes, I tend to agree that there has to be a limit. But semantically it
has to be an API parameter.

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

I'm not sure what you mean. As far as I understand, the input thread can
read only one line at a time; so it's the same principle as the stream
buffer or picture pools. Unless you're talking about several inputs at
the same time, but then that doesn't change the point.

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

Okay, thanks for the tip, thanks for showing me wrong. Now that could be
part of a solution.

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

It does use peek(), but only at the beginning of the loop iteration.
Then it uses read() before looping back to the next iteration. So that
works only if the error happens in the first iteration, that is, only if
the line is shorter than the 2 kB iteration slice.

That's what I'm proposing to change though, so that it does always
indeed use peek() internally. So perhaps we're in agreement here.

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

Do you think I'm offering to write a patch just to troll you?

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."