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

Reply via email to