On Sun, 2020-08-02 at 19:29 +0000, Thorsten Glaser wrote: > Ben Hutchings dixit: > > >ip(7) also doesn't document IP_PKTOPIONS. > > Hmm, I don’t use IP_PKTOPIONS though. I’m not exactly sure I found > the correct place in the kernel for what I do. The first instance of put_cmsg(...IP_TOS...) you found in net/ipv4/ip_sockglue.c implements that socket option. [...] > >I see no point in changing the IPv6 behaviour: it seems to be > >consistent with itself and with the standard > > Not really: if the kernel writes an int and userspace reads > its first byte, it only works by accident on little endian, > but not elsewhere. The RFC says that the IPV6_TCLASS option's value is an int, and that "the first byte of cmsg_data[] will be the *first byte of the integer* traffic class" (my emphasis). We can infer from "the first byte of" that cmsg_data[] will hold more than one byte. And "the integer" suggests that it's a C int, like the socket option. > >so only risks breaking user-space that works today. > > Hrm. It risks breaking userspace that reads an int. But the > RFC clearly says it should read the first byte, not an int. [...] No, the wording is *not* clear. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one.
Attachment:
signature.asc
Description: This is a digitally signed message part