From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Lyndon Nerenberg In-Reply-To: <44c2a0c73c586878a569ee074cdd084a@coraid.com> Date: Thu, 19 Jan 2012 16:11:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7A76A074-BE06-4FCC-BD78-7E4DFC12CA43@orthanc.ca> References: <3456bc974ba7b432c1e61cb5a5492314@ladd.quanstro.net> <87B8E7AD-7956-4F2F-8F59-566651922EED@corpus-callosum.com> <9900fab97779679305fe3fceec64a38d@coraid.com> <1f84be967187ad0ab70e35a0fc1f7063@coraid.com> <44c2a0c73c586878a569ee074cdd084a@coraid.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] dns vs. textrr Topicbox-Message-UUID: 5fd2c762-ead7-11e9-9d60-3106f5b1d025 On 2012-01-19, at 3:56 PM, erik quanstrom wrote: > it's probablly the best option, > if the goal is to rehabilitate Brdline(). i'm wondering if it = shouldn't > just be considered depricated. If you don't think of Brdline() as a 'C char *' construct, it's a useful = vessel to escape from one of the most evil parts of parsing text. I = won't begin to recount the pain I've endured dealing with text protocol = parsers that didn't get the \r\n split across the buffer boundary right. If you're claiming to read a line, just do it. I don't care if you have = to buy dictionaries to hold the words, and front-end loaders from which = to fill them! Certainly some smarts can be added to deal with inflated buffers when = they are no longer needed. But for now, dying from malloc(HUGE) isn't = much worse than the current behaviour. --lyndon=