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: usecases of void foo(char **b) {} Date: Tue, 01 Nov 2016 08:31:05 -0700 Organization: None to speak of Lines: 47 Message-ID: References: <5a9aae7f-eb86-4c7b-bc93-142504b1d0a9@googlegroups.com> <53f08403-90c0-4850-9d2a-734c7735cf2e@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="3c9491fcd50349ea336243ee8772beaa"; logging-data="20139"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ck16BhbRapfJmwea8I93a" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:U2tB0YKczWCbkyAfzXgBXY6EnIQ= sha1:AkHNDViegsaCB5NE6X62onoCHJs= Xref: csiph.com comp.lang.c:95518 supercat@casperkitty.com writes: > On Monday, October 31, 2016 at 12:04:58 PM UTC-5, Richard Heathfield wrote: >> In fact, they are required not to. See 6.3.2.3(3): An integer constant >> expression with the value 0, or such an expression cast to type >> void *, is called a null pointer constant. 66) If a null pointer >> constant is converted to a pointer type, the resulting pointer, called a >> null pointer, is guaranteed to compare unequal to a pointer to any >> object or function. > > It compares unequal to any object or function *that would be recognized by > the Standard*. The Standard does not recognize the existence of an I/O > port control register located at address zero, nor does it specify anything > about what happens if code tries to dereference a pointer that compares > equal to null. On the other hand, if a piece of hardware does happen to > have a port at address zero, the simplest and most practical way for a > quality implementation targeting that platform to support access to that > port is to simply treat zero like any other address. The Standard does > not require such behavior, but nothing in the Standard would prohibit it > either. A conforming implementation for that platform could make address > zero inaccessible, but from the point of view of the Standard it could just > as well deny access to all hardware addresses that aren't used to hold > Standard-recognized C objects. A freestanding implementation that did that > wouldn't be very useful, of course, but would be allowable under the > Standard nonetheless. All that is covered by the fact that the behavior of dereferencing a null pointer is undefined. A null pointer does not point to an object or function, because the standard defines what a pointer, a null pointer, an object, and function are. If an implementation chooses to define for itself the behavior of dereferencing a null pointer, then of course it can do so. If it's important to be able to access something at address 0, then an implementation also has the option of using a representation other than all-bits-zero for null pointers. (In practice, I suspect that hardware designers tend to avoid putting anything useful at address zero, precisely so that C null pointers are unambiguous.) -- 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"