[Swan-dev] memory: in clone_bytes() don't call memcpy(,,0)

[Andrew Cagney]

On Thu, 1 Sept 2022 at 18:51, D. Hugh Redelmeier <hugh at mimosa.com> wrote:
>
> | From: Andrew Cagney <cagney at vault.libreswan.fi>
> |
> | New commits:
> | commit ba30451878021e304e510cfc3adc1493bd41a31d
> | Author: Andrew Cagney <cagney at gnu.org>
> | Date:   Thu Sep 1 14:24:46 2022 -0400
> |
> |     memory: in clone_bytes() don't call memcpy(,,0)
> |
> |     undefined; fix github #836
>
> I don't understand this change.  It prevents calling memcpy when
> the size would be 0.

Libreswan was calling:
   memcpy(pointer, NULL, 0)
per Riastradh's comment on #pkgsrc: 7.1.4 Use of library functions
`Each of the following statements applies unless explicitly stated
otherwise in the descriptions that follow: If an argument to a
function has an invalid value (such as...a null pointer, or...), ...
the behavior is undefined.'

Based on past experience, testing .len>0 is more robust than
.ptr!=NULL and, as a bonus, eliminates the pointless:
  memcpy(pointer, "", 0);
which can happen when dealing with hunks pointing into strings.

> It is perfectly legal to call memcpy with a size of 0.
>
> What's slightly surprising is that the C standard requires that the source
> and destination pointers must not have invalid values even when the size
> is 0.  NULL is an invalid value (but the code prevents that).  Beyond
> that, the standard isn't clear what an invalid value is.
>
> Before this change, did we call memcpy with an invalid value?  For the
> source?  For the destination?
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev