Date: Tue, 04 Apr 2000 00:16:51 -0700 From: Peter Wemm <peter@netplex.com.au> To: Gary Jennejohn <garyj@muc.de> Cc: Bruce Evans <bde@zeta.org.au>, freebsd-current@FreeBSD.ORG Subject: Re: MLEN and crashes Message-ID: <20000404071651.841C31CD7@overcee.netplex.com.au> In-Reply-To: Message from Gary Jennejohn <garyj@peedub.muc.de> of "Tue, 04 Apr 2000 08:59:41 %2B0200." <200004040659.IAA25879@peedub.muc.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Gary Jennejohn wrote: > Peter Wemm writes: > >Gary Jennejohn wrote: > >> Bruce Evans writes: > >> >On Mon, 3 Apr 2000, Gary Jennejohn wrote: > >> > > >> >> Bruce Evans writes: > >> >> >On Sun, 2 Apr 2000, Gary Jennejohn wrote: > >> >> >> I think we should nuke csu_hdr since it's not used anywhere. Is that > >> >> >> what you really mean ? > >> >> > > >> >> >Yes. I'm trying the following patch. Only tested at compile time. > >> >> > > >> >> [patch snipped] > >> >> > >> >> Thank you, Bruce ! This is pretty much the same patch I tested. > >> >> > >> >> So, should I commit it ? > >> > > >> >If you have tested it :-). > >> > > >> > >> I'm running with the change right now. No problems. > > > >I would prefer that we did this: > > > >#define MAX_LEN (min(128, MLEN)) > > > >or something like that. This should stop Bad Things happening if > >somebody recompiles with MLEN set specifically to 128 (and is an ideal > >MFC candidate for 4.x for when people set MLEN to 256 over there). > > > > This is a pretty good idea, too. But I already deleted csu_hdr in -current. > It would be easy enough to back out the change if there's consensus. No, leave csu_hdr deleted. I am only talking about also changing the #define MAX_LEN to something that's safe even if MLEN is overridden. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000404071651.841C31CD7>