Re: git: 5fc3cc2713ef - main - amd64: make bcmp in libc just call memcmp

On Sat, Mar 12, 2022 at 8:59 AM Mateusz Guzik <mjg@freebsd.org> wrote:
>
> The branch main has been updated by mjg:
>
> URL: https://cgit.FreeBSD.org/src/commit/?id=5fc3cc2713eff8cdabbf6e5d03bf8a799adf808c
>
> commit 5fc3cc2713eff8cdabbf6e5d03bf8a799adf808c
> Author:     Mateusz Guzik <mjg@FreeBSD.org>
> AuthorDate: 2022-03-12 12:27:25 +0000
> Commit:     Mateusz Guzik <mjg@FreeBSD.org>
> CommitDate: 2022-03-12 14:59:14 +0000
>
>     amd64: make bcmp in libc just call memcmp
>
>     Preferably bcmp would just alias memcmp but there is build magic which
>     makes this problematic.
>
>     Reviewed by:    jhb
>     Differential Revision:          https://reviews.freebsd.org/D28846
> ---
>  lib/libc/amd64/string/Makefile.inc |  1 -
>  lib/libc/amd64/string/bcmp.c       | 16 ++++++++++++++++
>  2 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/lib/libc/amd64/string/Makefile.inc b/lib/libc/amd64/string/Makefile.inc
> index cb370bc6be1c..b77079afc933 100644
> --- a/lib/libc/amd64/string/Makefile.inc
> +++ b/lib/libc/amd64/string/Makefile.inc
> @@ -1,7 +1,6 @@
>  # $FreeBSD$
>
>  MDSRCS+= \
> -       bcmp.S \
>         memcmp.S \
>         memcpy.S \
>         memmove.S \

We should probably add a tools/build/depend-cleanup.sh entry for this,
so that non-clean builds pick up the new object, but

> diff --git a/lib/libc/amd64/string/bcmp.c b/lib/libc/amd64/string/bcmp.c
> new file mode 100644
> index 000000000000..b45176dc2d56
> --- /dev/null
> +++ b/lib/libc/amd64/string/bcmp.c
> @@ -0,0 +1,16 @@
> +/*-
> + * Written by Mateusz Guzik <mjg@freebsd.org>
> + * Public domain.
> + */
> +
> +#include <sys/cdefs.h>
> +__FBSDID("$FreeBSD$");
> +
> +#include <string.h>
> +
> +int
> +bcmp(const void *b1, const void *b2, size_t len)
> +{
> +
> +       return (memcmp(b1, b2, len));
> +}

Why do this instead of replacing the previous contents of bcmp.S with either:

#define memcmp bcmp
#include "memcmp.S"

or, restructure memcmp like you did with memcpy/memmove?

Thanks,

Kyle Evans