Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: memcpy with NULL pointer
Date: Fri, 29 Oct 2021 03:40:53 -0700
Organization: A noiseless patient Spider
Lines: 40
Message-ID: <86ee84f70q.fsf@linuxsc.com>
References: <slgdn2$1v7q$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="b7f56eff5ad6c7d9130605d054ce58ef"; logging-data="21911"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19j0BVsjtaJgsUCSDBgtPJh4xpvm6RN6p0="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:QxivDQL+ekYLYUvzVsk0FwVS79I= sha1:DNkXD76jMGRNANa13e78xNvtzxA=
Xref: csiph.com comp.lang.c:163230

Steve Keller <keller.steve@gmx.de> writes:

> I wonder whether calling the mem* and str* functions with a NULL
> pointer has defined bahavior if the count parameter is also 0,
> like in this call
>
>         #include <string.h>
>
>         ...
>         memcpy(NULL, NULL, 0);
>
> The same for memmove(NULL, NULL, 0), memcmp(NULL, NULL, 0),
> strncpy(dst, NULL, 0), strncat(dst, NULL, 0), strncmp(NULL, NULL, 0).

They are all undefined behavior.

> It seems the standard doesn't say anything about this.

It does.  Paragraph 2 of 7.24.1, "String function conventions", says
this:

    Where an argument declared as size_t n specifies the length
    of the array for a function, n can have the value zero on a
    call to that function.  Unless explicitly stated otherwise in
    the description of a particular function in this subclause,
    pointer arguments on such a call shall still have valid
    values, as described in 7.1.4.  [...]

A null pointer is not among the set of valid values.  Refer to
section 7.1.4, paragraph 1, for details.  (I did a quick check of
the six functions you mentioned and did not see any indication
that they are exceptions to the above rule.  Of course, I cannot
promise that such quick checks are 100% reliable, so please feel
free to double check me on that.)

> Since no memory access via the NULL pointer is done I'd assume
> this should not result in undefined behavior.

That's a plausible assumption but not one that the C standard
supports.