Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: C pointer semantics with dynamically allocated struct Date: Fri, 09 Oct 2015 09:02:12 -0700 Organization: None to speak of Lines: 57 Message-ID: References: <995425d1-0f9f-4086-b02c-9a48910336b4@googlegroups.com> <5861f87d-0660-44af-ba33-3b5f00a76508@googlegroups.com> <81267d1a-e9c6-4831-87f2-f6cf5248a7c5@googlegroups.com> <212091ef-f3a2-4aa2-816c-6eb76428ca8e@googlegroups.com> <13aee181-00df-4fb3-bff6-9ee5c7481a7a@googlegroups.com> <7af02bf3-0b39-41ed-b6f0-a901ccbd6baa@googlegroups.com> <57951b68-dbfb-4f16-8ed9-fad2a970ad19@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="23009"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX182JZWaVEoXBpKCCYuhUKBB" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:trd1YTcuo9ZROJjwZHVBwsdOzPI= sha1:IwVRJ6kHLY95vgoK3CsNid1QblE= Xref: csiph.com comp.lang.c:72269 supercat@casperkitty.com writes: > On Thursday, October 8, 2015 at 7:24:08 PM UTC-5, Keith Thompson wrote: >> The standard doesn't say much about extensions, so the boundary >> between extensions and non-extensions is vague. I suppose >> if a compiler implements a feature that's relevant only for >> constructs whose behavior is not defined by the standard, it can >> avoid documenting it simply by not describing it as an extension. >> For example, if a shift with a negative right operand always happens >> to yield 42, that satisfies the requirements of the standard and >> needn't be documented. > > My interpretation of the Standard would be that if a compiler says nothing > about the effect of x>>(-1), then even if the the current version of the > compiler would always yield 42, that would not constitute an extension and > future versions would be under no obligation to keep doing the same thing. Agreed. > If, however, an implementation does document that for all x, x>>(-1) will > always yield 42, then I would interpret such a statement as documenting an > extension in the absence of language explicitly specifying otherwise (e.g. > saying that such an expression is expected to yield 42 under typical > conditions, but it's not possible to list all the factors that might cause > it to do something else). > > Do you know anything in the Standard which would contradict such a reading? I know of nothing in the standard that would either contradict or support such a reading. The standard says a few things about extensions, but it never defines the word. It requires extensions to be documented; it doesn't say exactly what an "extension" is. I'm not aware that this vagueness has ever caused an actual problem. > Would you agree that it would create the possibility of an implementation > requirements specification... [BIG SNIP] I'm not going to answer these questions in detail, partly because you haven't answered mine. But to summarize: The standard requires *some* things to be documented by each implementation. Implementations are free to document other things, beyond what the standard requires. The dividing line between those two things is not 100% clear. Just as a matter of common sense, we expect each implementation's documentation to be accurate. In some cases, inaccurate documentation would violate the standard; in other cases, it would not. As a practical matter, if an implementation doesn't follow its own documentation that's a problem, and *it doesn't really matter* whether that problem is a violation of the standard. -- 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"