On Mon, 05 Dec 2011 23:13:44 +0100, Glenn Fowler <[email protected]>
wrote:
thanks for the report
thanks for the quick response and clarification...
this is an artifact of the underlying sfio buffered io library
the sfgetr() function that reads one record used to allow unlimited line
length
that worked fine until someone used it on a > 1Tib file that contained
no newline
and it proceeded to choke the system trying to allocate a > 1Tib buffer
we then added a firm limit (modifiable, but not via an sf*() function)
that was too small: 256*1024 = 256Kib for 64 bit systems
currently the default limit for 64 bit systems is 4*1024*1024 = 4Mib
we may have to revisit this given enough feedback
but the upshot is that the seemingly good idea of "no limits" is not
always a good idea
proof of concept: try this with bash on a system that you can reboot
with a physical button:
bash -c 'read line < /dev/zero'
btw, this test on the latest (to be released before the new year) ksh
exposeds a byte-at-a-time read(2) loop that should be optimized to
buffer-at-a-time
this will be fixed in the next release
discussion/opinions on "too small" vs "too big" vs shouldn't be any"
for the sfgetr() record limit welcome
just my 2c:
I realize that no limit implies calling for trouble in extreme cases. but
setting a limit causes problems much more often simply because the limit
is probably always lower than what the respective machine would tolerate.
so I would probably vote for "shouldn't be any".
at the very least it would be good to have a list of relevant limits
(there sure are others, e.g. max array size) included in the `ksh' manpage
so that users are (or could be ...) aware of them. I wasn't.
another problem (from my point view) is, that there is no 'limit exceeded'
notification (e.g. via a non-zero return status of `read'), so that one
really can corrupt one's data without noticing instantly (happened in my
case): if input is variable length, what you get _might_ be the correct
data.
j.
...
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
