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: pointers Date: Tue, 25 Oct 2016 12:17:01 -0700 Organization: None to speak of Lines: 60 Message-ID: References: <18d7b7b9-ea72-49d3-9535-df13d560473c@googlegroups.com> <726d78eb-47b3-1b92-0203-e2f63bb740ae@verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="0a5b782d68e23f17f10cdd6bfe85a146"; logging-data="10775"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX187DV645vNJisdL8I9Gmsms" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:kQG6+K38BE1pb2heOslp8NXutno= sha1:1dTFVSnzkoVgHpiKpLXN8iF5Fes= Xref: csiph.com comp.lang.c:95308 Tim Rentsch writes: > Keith Thompson writes: >> Tim Rentsch writes: >>> supercat@casperkitty.com writes: >>>> The Standard does [say] that no conforming extension should alter >>>> the effect of a strictly-conforming program, but many of the >>>> "Common Extensions" listed in the annex would do precisely that. >>> >>> That depends on how the extension is implemented, doesn't it? Or >>> are you saying that some of the listed common extensions would be >>> impossible to implement without changing some strictly conforming >>> programs? If so, which of the listed extensions fall into that >>> category? >> >> The "fortran" and "asm" keywords, if they're treated as keywords in >> all contexts, would clearly break strictly conforming programs that >> use them as identifiers (J.5.9, J.5.10). > > Sure. If treated as keywords in the same way that regular C > keywords are treated, then yes. If instead they were treated as > some form of optional, context-dependent keywords, then they > wouldn't necessarily intrude on the strictly-conformingness > property - right? Of course, but that's not what I was referring to -- which is why I wrote "*if* they're treated as keywords in all contexts". My point is that J.5 lists "common extensions"; it does not limit itself to *conforming* extensions. And non-conforming extensions are in fact common. For example, gcc with default options (which is known to be non-conforming) reports a syntax error on `int asm;`. That's clearly the kind of thing J.5p1 is talking about, extensions that "render an implementation nonconforming". >> Likewise for predefined >> macro names using unreserved identifers (J.5.12). > > In this case too I believe it is possible to implement some form > of "weak" macro definitions that would not intrude on the > strictly-conformingness property. I admit that it's harder to do > that with macros than the previous case. But there is another > point worth mentioning here: the offending macro definitions may > be in force only when the compilation is already in some sort of > non-conforming mode. In gcc, for example, there are predefined > macros such as 'unix', but these predefined macros go away when > an option like -std=c99 or -ansi is used. So the objection is > very likely not strictly correct, but even in cases where it > applies it seems to be vastly overblown. Annex J is not normative anyway, and J.5 in particular veers into discussing non-conforming implementations (which, to be overly pedantic, aren't really C implementations at all). I'm not sure what's being "vastly oveblown", or who is overblowing it. -- 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"