Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: More physical source files Date: Wed, 01 Jul 2015 11:08:02 -0700 Organization: None to speak of Lines: 59 Message-ID: References: <36e79c40-a86d-416d-b290-b2de49560c61@googlegroups.com> <7cf2be57-a46a-454a-a6cb-0c81d77ed7fb@googlegroups.com> <56d054c6-5316-46eb-b7b4-686bd405149d@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="5285"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Nb6xISqZRFzrKzLhHYlKA" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:yD+ihvOPandxYEwIaVPZMntIgRM= sha1:NNQqw7kccQx4Ic9l6gQcOe4fY30= Xref: csiph.com comp.lang.c:64597 David Kleinecke writes: > On Tuesday, June 30, 2015 at 3:14:19 PM UTC-7, Keith Thompson wrote: >> David Kleinecke writes: [...] >> > To what extent would an error-corecting compiler be conforming? >> >> That depends on just how the "error-correcting" works. If it accepts >> valid programs and generates correctly behaving code for them, and >> diagnoses all syntax errors and constraint violations (and handles the >> #error directive correctly), then it's conforming. If not, it's not. > > I'm just poking the standard around the edges to get comfortable with > it. > > The error I had in maind is using "a.b" instead of "a->b" when a is a > pointer to a struct/union. Easy to detect and correct. The error IMO > makes for a prettier source code. A conforming C compiler must diagnose the constraint violation of using `a.b` where `a` is a pointer. The diagnostic message can be a non-fatal warning. Once it's done that, it can do anything it likes, including generating the same code it would have generated for `a->b`. The behavior is not defined by the standard, but a compiler is free to define it. It could be a documented extension, explicitly permitted by section 4 of the standard. A non-conforming compiler (perhaps obtained by passing, or not passing, some command line option to an otherwise conforming compiler) could behave as above except that it doesn't issue the warning. Of course a non-conforming compiler can do anything it likes; the standard says exactly nothing about how it must behave. Personally I think an extension permitting `a->b` to be written as `a.b` would be more trouble than it's worth. It would encourage programmers to write code that cannot be compiled on any compiler that doesn't implement that particular extension. Some extensions are worth that cost, but I don't think this one is. But that's just my opinion; don't let me discourage you from thinking about this stuff. > I gather that error correcting would be possible in a conforming > compiler. It is strictly compiling where that is not possible. I don't know what you mean by "strictly compiling". There is a concept of "strictly conforming", but it applies to programs, not to compilers. A compiler (more precisely an implementation) is either conforming or not. A program using an extension is not strictly conforming, but it may be conforming ("conforming" is a very loose criterion for programs). > Hum. I need to think what other errors (besides the "a.b" error) I am > seriously interested in correcting. The colon idea, which was not a > serious suggestion, perhaps. -- 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"