Strangeness in 842 Fix

Fred Wright fw at fwright.net
Tue Apr 15 20:38:46 UTC 2025


On Mon, 14 Apr 2025, Hal Murray wrote:

>> If the values are identical, then it's not functionally incorrect, but
>> it's certainly conceptually incorrect to compare an SO_* value to a
>> cmsg_type field.  And if the values are identical, it wouldn't change the
>>  behavior to use the correct name.
>
> Sorry, I guess my previous message wasn't clear.  Let me try again.
>
> I tried what you expect.  It didn't work.  The reason it didn't work is
> because SCM_TIMESTAMPNS_OLD isn't defined, either on the reporter's system
> or on my reasonably current version of Linux.
>
> Poking around, I found that SCM_foo is defined by something like:
>  #define SCM_foo SO_foo
> So I changed the code to use SO_TIMESTAMPNS_OLD in the 2 places where it
> should use SCM_TIMESTAMPNS_OLD
> That also matched the debugging printout.
>
> What I forgot to do was put a comment in the code.  Sorry.  I'll do that
> after the release.

I agree that if it's functionally correct it's not a release blocker.  But 
I still don't understand why you did it the way you did.  To wit:

> Poking around, I found that SCM_foo is defined by something like:
>  #define SCM_foo SO_foo

If that's really true, then SCM_TIMESTAMPNS_OLD should be defined any time 
that SO_TIMESTAMPNS_OLD is defined, so using the correct macro should 
work.  If SCM_TIMESTAMPNS_OLD is *not* defined in this case (but the 
correct value is known), then it would be preferable to supply the missing 
definition and reference it correctly in the code, rather than referencing 
a wrong macro that just happens to have the right value.

This conforms to the principle of keeping the weirdness out of the body of 
the code.  Comments are no substitute for code that's sufficiently obvious 
that it doesn't require explanation. :-)

Fred Wright


More information about the devel mailing list