Fred Wright said:
> 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)
There are a couple of shoulds in there.
SCM_TIMESTAMPNS_OLD is not mentioned in my /usr/include/
I looked at the kernel sources. It has things like:
put_cmsg(msg, SOL_SOCKET,
SO_TIMESTAMPNS_NEW,
sizeof(ts), &ts);
The kernel sources have this line in several files:
#define SCM_TIMESTAMPNS SO_TIMESTAMPNS
./include/uapi/asm-generic/socket.h
./tools/include/uapi/asm-generic/socket.h
./tools/testing/selftests/net/rxtimestamp.c
./arch/mips/include/uapi/asm/socket.h
./arch/alpha/include/uapi/asm/socket.h
./arch/parisc/include/uapi/asm/socket.h
./arch/sparc/include/uapi/asm/socket.h
There is no other mention of SCM_TIMESTAMPNS nor any mention of
SCM_TIMESTAMPNS_OLD or _NEW
> 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.
In another hack header file?
like include/hack-ancient-openssl.h
> 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. :-)
It's not obvious to me that splitting a simple idea over two widely
separated chunks of code is a great principle. It's good in the sense of
reducing clutter if you are just looking at that section of code, but
makes it harder if you are down in the bits and trying to figure out what
is really going on.
I'm happy to write the code tha way if that's your preference. I know
what's going on so I don't care much about how we do it.
Do you have a good reference for that idea? Thanks for the discussion --
keeps me learning.
_______________________________________________
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
