Email List: Xaustin-group-lX
[All Lists]

Re: Proposed submissions for the revision from The Open Group

To: yyyyyyyyyyyyyy@xxxxxxxxxxxxx, yyyyyyy@xxxxxxxxxxxxx
Subject: Re: Proposed submissions for the revision from The Open Group
From: Glenn Fowler <yyy@xxxxxxxxxxxxxxxx>
Date: Wed, 11 Jan 2006 14:14:48 -0500 (EST)
Organization: AT&T Research
References: <1060109184758.ZM17257@skye.rdg.opengroup.org> <17346.48571.685761.731503@khavrinen.csail.mit.edu> <43c3f58c.DCRQQCxQd+2zWxCK%gunnarr@acm.org> <43C53F98.nail90I217O41@burner> <17349.19525.422425.947653@khavrinen.csail.mit.edu>
re: getline() and friends

its important to have an overall max line size
regardless of the buffer management

whether that max size is fixed or set via another function
or getline-like() argument is up to the designers

we ran into a case (reported here a while back) where
our no-limits get-a-line function acted as a complete
system denial of service when an application was
presented a ~100Gb input file that contained no delimiters

the function merrily grabbed memory and the system obliged
to the point where even root had trouble killing the offender

one could argue that the system should have handled the
situation better, but absent that the max line size keeps
the rogues in check on the majority of systems that don't

(we chose a default limit that is managed process/thread-wise
 via a separate library function ala umask() -- since we chose
 the default all of our apps simply use the default and don't
 bother with max line size management -- that default is 64*1024
 in deference to a recent glut of mainframe data where the max record
 length is typically limited to a size integer of 15 or 16 bits)

-- Glenn Fowler -- AT&T Research, Florham Park NJ --

<Prev in Thread] Current Thread [Next in Thread>