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: Tue, 18 Oct 2016 12:03:09 -0700 Organization: None to speak of Lines: 67 Message-ID: References: <58034cbc.2767375@news.xs4all.nl> <003e026c-0fca-40b2-ab84-2197571d165f@googlegroups.com> <3dc49e97-bb93-411f-8fe3-7cdbb6fdb70d@googlegroups.com> <1c6a99e7-93b9-4a27-9201-aa5b6e7985aa@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="c0c8def25655f7556eada2283b8fecd0"; logging-data="15610"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/KN1Z16Gx/rGJUwA3MCHh1" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:Iun2ZAat9ZwN5K4HDQvyHmY2UiE= sha1:qH3/B5lNVrIyRJeVltPjTfL1xT4= Xref: csiph.com comp.lang.c:95074 supercat@casperkitty.com writes: > On Tuesday, October 18, 2016 at 11:14:01 AM UTC-5, Keith Thompson wrote: >> supercat writes: >> >> Consider a hypothetical implementation of memcpy() that checks its >> >> arguments, causing a segfault if either s1 or s2 is a null pointer. >> >> You would assert, I presume, that such an implementation would >> >> be non-conforming? >> >> I see you've decided to ignore that. > > The Standard does not impose any requirements upon how an implementation > processes *any* program, other than the One, which does not contain any > #error directives. So nothing memcpy could do would make an implementation > non-conforming under a literal reading of the Standard if the One Program > did not use memcpy, or did so in a way that happened to behave normally. > > I would say that treating memcpy(any,any,0) as a no-op is a behavior which > programmers should be entitled to expect from any quality implementation > which has not been specifically requested to identify ways in which a > program might fail on inferior implementations, and I would consider that > such requests are generally best handled via non-conforming modes, rendering > the question of conformance for them irrelevant. Let's take another look at the actual wording in the description of memcpy(). N1570 7.24.2.1p2: The memcpy function copies n characters from the object pointed to by s2 into the object pointed to by s1. You claim that memcpy(NULL, NULL, 0) should copy 0 characters, and therefore should not misbehave if the first and/or second argument is a null pointer. But the standard says those characters are copied from "the object" to "the object". From what object, and to what object, are 0 characters copied? The description makes no sense unless there actually are objects pointed to by s2 and by s1. The standard does not describe the behavior of memcpy(NULL, NULL, 0), therefore the behavior is undefined. The current wording suggests that the authors of the standard did *not* intend to define the behavior of memcpy(NULL, NULL, 0). Either they intended to leave the behavior undefined, or they didn't think of that particular case. And again, if you think the behavior *should* be defined, I have no problem with that. If you think that implementations *should* treat memcpy(NULL, NULL, 0) as a no-op, I have no problem with that either (such behavior is of course conforming under either interpretation). If you wish to advocate changing the wording in the next edition of the C standard so that memcpy with n==0 is a well-defined no-op even if either s1 or s2 is a null pointer, I won't object (though I would first ask for a survey of the behavior of existing implementations). But the standard simply does not define the behavior of memcpy(NULL, NULL, 0), so even if we either ignore the "such as" clause in 7.1.4p1 or interpret it in some other way, the behavior is undefined. (I would also have no problem with either leaving the wording as it is, or with adding wording that states more explicitly that the behavior is undefined. Here I'm not disagreeing with you; I'm just not sharing your preference.) -- 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"