Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: UB of memcpy(NULL, NULL, 0) Date: Sun, 16 Oct 2016 11:23:17 -0700 Organization: None to speak of Lines: 30 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: mx02.eternal-september.org; posting-host="47375d5ce36f0082b94983afe63eb3b3"; logging-data="7366"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX184eI3KdosbZomd2T2FNtnH" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:/tSTdlDQGuOfZms0gTMYAySN6BY= sha1:5IhmC8juS3kylNh0aDCJNU1BOgQ= Xref: csiph.com comp.lang.c:94931 Lőrinczy Zsigmond writes: >> As a programmer, how much of a burden is it to avoid calling memcpy() >> with a null pointer? I wrote the above. Please don't delete attribution lines when you post a followup. > It would add a redundant 'if' to the code, increasing complexity > > - memcpy (to, from, len) > + if (len) memcpy (to, from, len) That's only necessary when you don't already know that `to` and `from` are non-null. Copying zero bytes between actual objects might be reasonably common. Copying zero bytes from one nonexistent object to another *might* be valid, depending on the program's logic, but it's likely to indicate a bug. I have no strong opinion on whether memcpy(NULL, NULL, 0) *should* have defined behavior. The fact is that it doesn't. I don't think I've ever seen real-world code where it matters. If it does, adding an `if` is trivial. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"