[Swan-dev] memory: in clone_bytes() don't call memcpy(,,0)
andrew.cagney at gmail.com
Fri Sep 2 03:22:01 EEST 2022
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
More information about the Swan-dev