From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@labs.coraid.com>
Date: Thu, 19 Jan 2012 17:12:30 -0500
To: 9fans@9fans.net
Message-ID: <1f84be967187ad0ab70e35a0fc1f7063@coraid.com>
In-Reply-To: <9900fab97779679305fe3fceec64a38d@coraid.com>
References: <3456bc974ba7b432c1e61cb5a5492314@ladd.quanstro.net>
	<87B8E7AD-7956-4F2F-8F59-566651922EED@corpus-callosum.com>
	<9900fab97779679305fe3fceec64a38d@coraid.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [9fans] dns vs. textrr
Topicbox-Message-UUID: 5facebc8-ead7-11e9-9d60-3106f5b1d025

it turns out that the problem with ndb is actually a bio
problem Brdline() freaks out and returns nil if the line
in question is longer than b->bsize and doesn't increment
the file pointer, so you've got an infinite loop.

i had thought that this was clearly in violation of
what the man page says, but on second read, i'm not so
sure.  i would think that Brdline() should return a
buffer if there are bytes available=E2=80=94otherwise it
could be confused with eof,  but that's clearly not
what the code does.

it seems from the existing bio code the only reasonable way
eat lines that are too long is=20

	/* get a line (ignoreing long ones) */
	dump =3D 0;
	for(;;){
		if((line =3D Brdline(b, '\n')) =3D=3D 0){
			if(Blinelen(b)>0){
				Bseek(b, Blinelen(b), 1);
				dump =3D 1;
				continue;
			}
			break;
		}
		if(dump){
			dump =3D 0;
			continue;
		}
		break;
	}

that seems a bit ... goofy. it would seem better for
bio to do this internally?  surely there isn't code that
relies on this behavior?

- erik