I am not a fan of shunk_t. I think the abstraction adds too much complexity. Things are already hard enough to understand for outsiders.
Paul Sent from mobile device > On Jan 21, 2019, at 13:40, Andrew Cagney <[email protected]> wrote: > > This came up in an offline discussion. While chunk_t is intended for > bytes and shunk_t is intended for characters, they do both provide > pointer+length abstractions. This begs the question: should they be > merged? It turns out that they have a critical difference: > > - chunk_t points at writable data but shunk_t points at read-only data > > so I'd argue no. For instance, a construct like: > > const char string[4] = { 'H', 'e', 'l', 'p', }; > shunk_t s = { .ptr = string, .len = sizeof(string), }; > > is valid (unlike strspn() et.al., shunks don't assume NUL > termination), where as: > > chunk_t c = { .ptr = (uint8_t*) string, .len = sizeof(string), }; > > is not. > > What might useful are: > > - think of a better name - string_t would be terrible, slice_t might be better > - change .ptr to 'const uint8_t*', but that would break things like > .ptr = "a string" :-( > > Andrew > _______________________________________________ > Swan-dev mailing list > [email protected] > https://lists.libreswan.org/mailman/listinfo/swan-dev _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
