Michal Hlavinka wrote:
> On 12/05/2011 11:13 PM, Glenn Fowler wrote:
>>
>> thanks for the report
>>
>> 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
>
> I know both no-limit/limit can cause problems, but I think no-limit is
> better option. I know a few users who use ksh for things I could not
> imagine (or even consider sane). With limits I know I can expect
> questions from them sooner or later: "Hey, I have 64GiB RAM, why I
> can't read 3 GiB file? I don't care if it's wrong idea or not. It was
> working for ages." So I vote for no limits option :) Anyway, 4Mib (I
> guess you meant 4MiB) is way too small for "these people".
>
> Michal
> _______________________________________________
> ast-users mailing list
> [email protected]
> https://mailman.research.att.com/mailman/listinfo/ast-users
>
In the real world there are always limits. Ignoring them can lead to
security problems like the denial-of-service demonstrated in Glenn's
bash example. I'm in favor of the safer approach. Besides, as I
demonstrated in my last posting, there is a (hopefully safe) way around
this limit.
Terrence Doyle
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
