svn commit: r216101 - head/sys/netinet

[Lawrence Stewart]

On 12/02/10 14:45, Bruce Evans wrote:
> 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.

hmm, thanks for the informative response. I'm not sure where I got it in
my head that NULL != 0 on all platforms, but you've now corrected that
bit of misunderstanding. For the record, the now known to be bogus
commit log was my own creation based on my (mis)understanding and did
not come from David.

When it comes time to MFC, should I use the bogus log message or correct
it to something like:

"Fix a minor style nit by passing NULL instead of 0 for the th pointer
value."

Cheers,
Lawrence