Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!floyd!cmcl2!rna!n44a!wjh12!genrad!decvax!mulga!kre From: kre@mulga.UUCP Newsgroups: net.bugs.4bsd Subject: Re: Definite portability bug in 4.2 getty Message-ID: <221@mulga.UUCP> Date: Mon, 27-Feb-84 02:35:48 EST Article-I.D.: mulga.221 Posted: Mon Feb 27 02:35:48 1984 Date-Received: Tue, 28-Feb-84 12:56:37 EST References: <502@axiom.UUCP> Lines: 49 To: Steven M Kramer @ Axiom (posted as a correction of earlier news) I'm glad that you approve of the 4.2bsd getty (which is one of my small contributions), however, your bug fixes really just aren't ... Easiest is your "fix" to the delay setting tables. There you simply have not read the code. If you look in adelay() in subr.c, you will see that the delay tables are searched in ascending order of delay values, stopping when a delay greater than, or equal to, the requested delay is encountered. To stop such a search, I have used a '0' as a sentinal value, a fairly common technique I think. An alternative would be to use a value bigger than anything anyone would ever request - but how big is that? The '0' means "anything bigger than the previous value", and should obviously result in the longest possible delay, not none! Adelay() has a special case for a requested delay of 0. The "portability" bug in the handling of the flag bits is really just an implementation technique, perhaps not the best possible, but not really a bug either. Getty uses the new, 4.2bsd, #defines of CRTBS, CTLECH, etc, which aren't available on previous systems (really they're not intended for use outside the kernel on 4.2, but getty is a pretty special program). These names are defined to be (LCRTBS<<16) (etc) - they must have 16 low order zero bits, and cannot conflict with any of the sg_flags bits used with TIOCSETP. If you are going to port getty from 4.2 to some other system, you should port the #defines as well, I guess that you have assumed that CRTBS is just a new name for LCRTBS; such is not the case, LCRTBS is still there, and has the same value that it always had. It hasn't been "moved". It is true, as you suggest, that the code would be a little cleaner if the "standard" flags and the "local" flags were handled by distinct routines - that is while the distinction between them remains, which it didn't on 4.1c bsd, where the 4.2 getty was developed. Its quite likely that sometime the distinction will vanish again, after all, they're all just flags ... Robert Elz decvax!mulga!kre ps: just in case anyone hasn't guessed, I'm suggesting that you ignore the suggested fixes to getty, and leave it as it is.