If I were coding, in addition to Jon's change, I probably would change "u8" to "char" for the type of hostname elements in the dhcp_client_config and dhcp_compl_event in dhcp.api, because way back when I liked to think of u8 as a hint that the array is a vector style string, i.e., not terminated with a null. I don't know how carefully we maintained the convention years ago, and I haven't looked at much code recently. I didn't write "unsigned char" above because strings are usually "char".
Burt On Thu, Apr 27, 2017 at 2:19 PM, Luke, Chris <chris_l...@comcast.com> wrote: > > Jon Loeliger said: > >> On Thu, Apr 27, 2017 at 12:19 PM, Luke, Chris <mailto: > chris_l...@comcast.com> wrote: > >> [...] What I am not sure of is NUL in DHCP hostname strings – I > remember reading somewhere > >> it’s optional, so I suspect that means the TLV length is used to > determine the string length; > >> meaning it might be possible to have a hostname that is 64 printable > characters long. Maybe. > > > > According to my RFC digging, 1 to 63 characters. > > > > NUL is not a valid hostname character. > > What it actually says is: > > sname 64 Optional server host name, null terminated string. > > So yes, you're semantically correct. I forgot in the original DHCP this > was a static field and not a TLV. In DHCPv6 however it doesn't exist. > > Chris. > _______________________________________________ > vpp-dev mailing list > vpp-dev@lists.fd.io > https://lists.fd.io/mailman/listinfo/vpp-dev
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
