On Thu, 1 Sept 2022 at 18:51, D. Hugh Redelmeier <[email protected]> wrote: > > | From: Andrew Cagney <[email protected]> > | > | New commits: > | commit ba30451878021e304e510cfc3adc1493bd41a31d > | Author: Andrew Cagney <[email protected]> > | 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 > [email protected] > https://lists.libreswan.org/mailman/listinfo/swan-dev _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
