Way back when I must have been dealing with u8* versus char* rather than u8[] versus char[], but that slight bit of confusion on my part does not change my suggestion:-)
Burt On Thu, Apr 27, 2017 at 4:09 PM, Burt Silverman <bur...@gmail.com> wrote: > 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