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: Preprocessor Overheads Date: Thu, 02 Feb 2017 12:46:09 -0800 Organization: None to speak of Lines: 39 Message-ID: References: <6f4a3c6f-a81e-4b75-9be6-67e07f6584af@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="523b5027be519a02b651eac1ee0346e8"; logging-data="7421"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18WojRvp3RdppnHvxYy6etW" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:IyQBqrZ3fRJ90Q8Mo4a+X8qsZKM= sha1:oMyOL5ym/q8my2/OGDDU1JPTOfY= Xref: csiph.com comp.lang.c:102980 supercat@casperkitty.com writes: > On Thursday, February 2, 2017 at 3:31:14 AM UTC-6, David Brown wrote: >> Those pesky rules of C, eh? Who would have thought you needed a cast to >> void* just because the standards say so? > > When the Standard was written, a few implementations used different > representations for pointers to different types, but many implementations > used the same representation for void* as for pointers to all kinds of > object. Passing a pointer to a function required casting it to a pointer > type whose passed representation would be compatible with the function was > expecting, *if the existing type's passed representation was already > compatible*. Code which passed an int* to code that expected a char* > without a cast could be expected to work on platforms where the passed > representations of both types were compatible, but potentially fail in > arbitrary fashion on platforms where they were not. > > If the authors of the Standard had intended to preserve that status quo, > would they have written anything other than what they actually wrote? If > not, what reason would there be for not interpreting the Standard as > extending the existing state of affairs? Currently, the standard says that passing a pointer of one type to a function expecting a pointer of a different type has undefined behavior. It could have said that such code has well defined behavior if the two pointer types have the same representation, perhaps with some added wording about alignment. This would relevant only in cases that aren't constraint violations, such as where there's a visible non-variadic prototype for the called function (unless you want to loosen those rules). Of course any implementation can make that guarantee if it chooses to do so. -- 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"