[Swan-dev] shunk_t vs chunk_t

[Andrew Cagney]

On Mon, 1 Mar 2021 at 10:17, D. Hugh Redelmeier <hugh at mimosa.com> wrote:
>
> In shunk_t
>         const void *ptr;

BTW, it started out as const char * because it was being used on
strings.  It changed to const void * as part of being made more
generic.

The nice thing about 'const void *' is that C compilers are ok with it
being assigned to const pointers without a cast vis:
   const uint8_t *p = shunk.ptr;
vs the bug:
   uint8_t *p = (uint8_t*)shunk.ptr;

> In chunk_t
>         uint8_t *ptr;


> I understand why the former is const and the latter isn't.
> But why do the base types differ?

History. chunk_t being (unsigned) bytes is pretty entrenched.

> I stubbed my toe on this yesterday.
>
> ================
>
> Sometimes security labels are passed around in shunk_t and sometimes
> chunk_t.  This is awkward and widespread.  I'm not sure if there is a good
> cure because I haven't looked carefully.

> I chose to make the a and b parameters to se_label_match to have type
> chunk_t * because that required the fewest casts.

Where?

- the sec label provided by the acquire is NUL terminated byte stream
(note, not string) (I hacked IKEv1 to enforce this, somewhere I've a
patch for IKEv2)
- since the sec_label bubbling up from the acquire points into a
readonly-ish stack structure it's arguable that it should be a shunk_t

where things break down is with IKEv2's struct traffic_selector (IKEv1
very clearly clones the sec_label into struct state).

My hunch is that IKEv2's struct traffic_selector should be a shunk_t.
It starts out pointing into the pbs_in structure but then, when
selected and saved, is cloned and stored in the same fields as for
IKEv1 with lots of pointers updated.

> This casting is not actually good code:
>
> - we "know" that a shunk_t and a chunk_t have the same layout.  So the
>   cast works.  But it isn't 100% safe because the layout of either
>   could change and nothing would raise an alarm.
>
> - it is possible to cleanly construct a shunk_t object from a chunk_t
>   object but not the reverse: the latter requires stripping const from
>   *ptr.
>
> The real problem is that the logic of C's const is too simple-minded.
> C really does not support the shunk/chunk distinction comfortably.
>
> Do we have other cases where we convert between shunks and chunks?  If
> so, we really should have functions to do this.  That way the
> nastiness can be isolated in one place.
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev