Bernd Edlinger <bernd.edlin...@hotmail.de> writes:
> If you want to have at least a chance to survive something like:
>
>
> dd if=/dev/zero of=test.c bs=10240 count=10000000
>
> gcc -Wall test.c
>
>
> Then you should change the implementation of read_line to
> _not_ returning something like 100GB of zeros.
I'd say that in that case, we'd rather just die in an OOM condition and
be done with it. Otherwise, If fear that read_line might become too
slow; you'd have to detect that the content is just zeros, for instance.
> IMHO it would be nice to limit lines returned to 10.000 bytes,
> maybe add "..." or "<line too long>" if the limit is reached.
In general, setting a limit for pathological cases like this is a good
idea, I think. But that seems a bit ouf of the scope of this particular
bug fix; we'd need to e.g, define a new command line argument to extend
that limit if need be, for instance. If people really feel strongly
about this I can propose a later patch to set a limit in get_line and
define a command like argument that would override that parameter.
> And maybe it would make the life of read_line's callers lots easier
> if the zero-chars are silently replaced with spaces in the returned
> line buffer.
As speed seemed to be a concern (even if, in my opinion, we are dealing
with diagnostics that are being emitted when the compilation has been
halted anyway, so we shouldn't be too concerned, unless we are talking
about pathological cases), I think that read_line should be fast by
default. If a particular caller doesn't want to see the zeros (and thus
is ready to pay the speed price) then it can replace the zeros with
white space. Otherwise, let's have read_line be as fast as possible.
Also keep in mind that in subsequent patches, read_line might be re-used
by e.g, gcov in nominal contexts where we don't have zeros in the middle
of the line. In that case, speed can be a concern.
Thanks for the helpful thoughts.
--
Dodji
