svn commit: r216101 - head/sys/netinet

[Bruce Evans]

On Thu, 2 Dec 2010, Lawrence Stewart wrote:

> Log:
>  Pass NULL instead of 0 for the th pointer value. NULL != 0 on all platforms.
>
>  Submitted by:	David Hayes <dahayes at swin edu au>
>  MFC after:	9 weeks
>  X-MFC with:	r215166
>
> Modified:
>  head/sys/netinet/tcp_timer.c
>
> Modified: head/sys/netinet/tcp_timer.c
> ==============================================================================
> --- head/sys/netinet/tcp_timer.c	Wed Dec  1 23:26:32 2010	(r216100)
> +++ head/sys/netinet/tcp_timer.c	Thu Dec  2 00:47:55 2010	(r216101)
> @@ -567,7 +567,7 @@ tcp_timer_rexmt(void * xtp)
> 	 */
> 	tp->t_rtttime = 0;
>
> -	cc_cong_signal(tp, 0, CC_RTO);
> +	cc_cong_signal(tp, NULL, CC_RTO);
>
> 	(void) tcp_output(tp);
>

Er this never passed 0, (provided a prototype is in scope), and can neverpass
either 0 or NULL, since 0 and NULL are null pointer constants and functions
cannot pass constants.

It used to pass a null pointer, after converting the null pointer
constant 0 according to the prototype.  Now it passes the same null
pointer after converting the possibly-different null pointer constant
NULL according to the prototype.

NULL == 0 on all platform, since both are null pointer constants, and
one of the following cases applies:
- if NULL is an integer constant with value 0, then of course it equals
   plain int 0.  Moreover, even if the type of NULL is different from
   the type of plain int 0, the types become identical before the
   comparison is done, since both operands are converted to a common
   type.
- if NULL is an integer constant with value 0 cast to (void *), then it
   certainly has a different type than plain int 0, and may have a
   different representation.  However, when compared with plain 0, both
   operands are converted to a common type, which is necessarily that
   of NULL.  This is a pointer type, so so both operands are null
   pointers.  These null pointers may have different representations,
   but any two null pointers to the same type are specified to compare
   equal.  So NULL == 0 in this case too.

The last case is essentially what applies in function calls.  Now the
conversion of either NULL or 0 or any other null pointer constant to a
null pointer is done according to the prototype.  The results are not
necessarily the same like I said above, but they compare the same.
Thus spelling the null pointer constant as 0 made no difference to
the higher-level results on any platform (unless you do something like
memcmp of null pointers, and use an exotic platform where null pointers
have different representations).  It was just a style bug.

Bruce