[net.lang.c] code and comments disagreeing

mouse@mcgill-vision.UUCP (der Mouse) (02/18/86)

Found in our kernel code:

/* this should be SEQ_LT; is SEQ_LEQ for BBN vax TCP only */
		    (SEQ_LT(ti->ti_ack, tp->iss) ||

(gee, I wonder now, should I worry about posting "secret" code? :-)
-- 
					der Mouse

USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse
     philabs!micomvax!musocs!mcgill-vision!mouse
Europe: mcvax!decvax!utcsri!mcgill-vision!mouse
        mcvax!seismo!cmcl2!philabs!micomvax!musocs!mcgill-vision!mouse
ARPAnet: utcsri!mcgill-vision!mouse@uw-beaver.arpa

Hacker: One who accidentally destroys /
Wizard: One who recovers it afterward

guy@sun.uucp (Guy Harris) (02/23/86)

> Found in our kernel code:
> 
> /* this should be SEQ_LT; is SEQ_LEQ for BBN vax TCP only */
> 		    (SEQ_LT(ti->ti_ack, tp->iss) ||

You'll be happy to know this is fixed in 4.3beta; the comment is gone (and
the code uses SEQ_LEQ).  However, while looking up "iss", I found a worse
bug; "netinet/tcp_var.h" refers you to RFC783, which is the TFTP RFC, NOT
the TCP RFC, which is RFC793.  The copy of RFC793 we have is dated September
1981, not December 1981, and the sequence variables are defined on page 19,
not page 21.  This demonstrates how useful comments are.  (From my quick
reading of the code and the RFC, SEQ_LEQ seems to be correct; "tp->iss" is
the sequence number on the "SYN" sent out, and the other side should ACK
that SYN with the next sequence number it expects to see, which must be
greater than the one it just saw.)

> (gee, I wonder now, should I worry about posting "secret" code? :-)

This code is not AT&T code, it's Berkeley code (and may be descended from
BBN code).  I don't know whether there are any trade secret restrictions on
Berkeley's or BBN's TCP implementation, although since the US Federal
Gummint paid for the Berkeley work (and maybe the BBN work) I tend to doubt
it.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.arpa	(yes, really)