Uri Guttman <[EMAIL PROTECTED]> writes:
> >>>>> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>
> PS> At 08:50 PM 8/19/00 -0400, [EMAIL PROTECTED] wrote:
> >> I do believe thbis is one of the reasons sysread is there
> >>
> >> perldoc -f sysread
>
> PS> Au contraire; sysread reads exactly the number of characters
> PS> requested; what I want is a way for programs that do <FH> all over
> PS> the place to be protected if someone throws a gargantuan number of
> PS> characters at FH without a newline. The $/ = ref_to_int feature
> PS> is exactly the kind of feature I was expecting to do this and I
> PS> was disappointed that it didn't.
>
>
> and what happens to the partial line left in the input buffer? does it
> get read in the next time you call <> or is it thrown out? the semantics
> of <> in line mode is it reads a whole line. leaving the partial line to
> be read next time is bad. throwing out the leftover text is also bad.
If I understand the context of the OP's suggestion, he'd want to flag
an error if the maximal line length is exceeded.
> better to have <> work as now and the code just truncates the line with
> substr.
This is not practical to the OP. He has an application that is
waiting to read a line of data from some (untrusted) source. If the
source feeds in 128GB of data with no line termination, Perl will
require at least 128GB of swap to read it all in. This is an easy
denial of service attack (for large values of "128"). Using substr
would not be an option, as the damage is done before substr ever gets
to see the "line".
A better solution would be a tied-filehandle module which would do its
own buffered reading and croak on long lines; presumably it would use
sysread internally.
--
Ariel Scolnicov |"GCAAGAATTGAACTGTAG" | [EMAIL PROTECTED]
Compugen Ltd. |Tel: +972-2-6795059 (Jerusalem) \ We recycle all our Hz
72 Pinhas Rosen St. |Tel: +972-3-7658514 (Main office)`---------------------
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555 http://3w.compugen.co.il/~ariels
