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 09:14:03 -0700 Organization: None to speak of Lines: 70 Message-ID: References: <58034cbc.2767375@news.xs4all.nl> <003e026c-0fca-40b2-ab84-2197571d165f@googlegroups.com> <3dc49e97-bb93-411f-8fe3-7cdbb6fdb70d@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="c0c8def25655f7556eada2283b8fecd0"; logging-data="4826"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19cOhuYXwx1MyrS5dUZPz5s" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:hUf0AN3p8BvJ1G4X4H0i+4FEzto= sha1:sC7n0qYpCzAe95TIgeFfxBYEsUo= Xref: csiph.com comp.lang.c:95068 supercat@casperkitty.com writes: > On Monday, October 17, 2016 at 6:43:23 PM UTC-5, Keith Thompson wrote: >> I believe the intent is that all the cases following "such as" are meant >> to be invalid unless explicitly stated otherwise in the detailed >> descriptions. All the cases other than "a null pointer" are clearly >> invalid. I find it implausible that that's the only exception, >> especially given that there are cases where null pointers are stated >> explicitly to be valid. (Usually such a statement is needed because the >> behavior would be unclear otherwise.) > > The term "such as" in English prose does not imply that the author has > endeavored to call out every possible exception, much less gone through > any effort to ensure that all possible exceptions were listed. I'll acknowledge that the wording is ambiguous. >> 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. > Consider a not-so-hypothetical C compiler which requires functions to be > written out as: > > int foo(bar) > int bar; > { > printf("%d", bar); > } > > rather than what is now the more fashionable > > int foo(int bar) > { > printf("%d", bar); > } > > There were a lot of implementations like that in 1988. Would you brand > them all as non-conforming? Of course they're non-conforming. They conformed to the language as it existed at the time (though even in 1988 support for prototypes was becoming widespread), but not to any language definition pubished since 1989. No doubt there's some connection between that and what I was talking about, but you haven't chosen to share your reasoning. > There is nothing wrong with a standard > requiring implementations to do something they wouldn't otherwise do-- > that's part of the *point* of standards. Even on your hypothetical > implementation, do you think that the usefulness would be in any way > impaired by requiring that it check for a size of zero before validating > the pointers? Probably not, but that's beside the point. As I've said, it would have been reasonable for the standard to state that memcpy(NULL, NULL, 0) has well defined behavior. But that's not what the standard says, at least not explicitly. There's probably a case to be made that it's implied, but given the actual wording, in my opinion there's a stronger case that the behavior is undefined (even if every existing implementation happens to have the same behavior, which may or may not be the case). -- 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"