Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Two different Results between C and C++ Date: Fri, 04 Sep 2020 06:38:02 -0700 Organization: A noiseless patient Spider Lines: 141 Message-ID: <86k0x97jd1.fsf@linuxsc.com> References: <8c6495f9-6139-464e-ac8f-4eac27a92776@googlegroups.com> <60d0f73c-8588-4673-a48d-e5c4cc726196@googlegroups.com> <868sggkepa.fsf@linuxsc.com> <502cecf4-e3eb-4b2d-a1bc-ee8c9965af65o@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="7a5f90e0606212f607690ab7b970a5be"; logging-data="23464"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18fp7Tyt+saJo4o9q6rZQYKm6IJhdSeSmg=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:mYOin9XUwQlsaMA5uWjS9MD/OjM= sha1:CAh3z4a+56Tzu1FHOb/EN9fElXY= Xref: csiph.com comp.lang.c:154485 James Kuyper writes: > On Sunday, June 21, 2020 at 4:26:05 AM UTC-4, Tim Rentsch wrote: > >> James Kuyper writes: >> >>> On 6/2/20 2:39 PM, John Bode wrote: > > ... > >>>> There are an infinite number of programs that are legal C but not >>>> legal C++. There are an infinite number of programs that are legal >>>> in both languages but exhibit different behavior. The two >>>> languages continue to diverge as time goes on. >>> >>> That's true, modulo providing a definition of "legal" (neither >>> standard uses that term). >>> >>> In order to make this more meaningful, I'm going to talk about >>> compatible implementations of C and C++, a term that I need to >>> define. An implementation of C and an implementation of C++ are >>> compatible if, for any given construct, if the meaning or behavior >>> permitted by the C standard for that construct has any overlap >>> with the meaning or behavior permitted by the C++ standard for >>> that same construct, both implementations will give that construct >>> the same meaning or behavior. >>> >>> The fact that both sets are infinite obscures an important point. >>> Rather than looking at infinite sets, lets look at finite ones. >>> Consider sequences of no more than N characters from the basic >>> source character set. >>> >>> A sub-set C(N) of those sequences qualify as having no syntax >>> errors, constraint violations or undefined behavior according to >>> the C standard. This sub-set can be further sub-divided into >>> equivalence classes, every member of which has the same observable >>> behavior under a given implementation of C for all possible >>> inputs. >>> >>> A subset CPP(N) of all sequences of length N or less qualifies as >>> well-formed code having no syntax errors or undefined behavior >>> according to the C++ standard. >>> >>> Note that, in both subsets, I'm including programs with unspecified >>> behavior. >>> >>> I believe that, for the overwhelming majority of the equivalence >>> classes of C(N), there's at least one member of that class that is >>> also in CPP(N), and which has the same observable behavior if >>> compiled using a compatible implementation of C++. Those members >>> might qualify as poorly-written in either language, but they don't >>> have any problems as far as the C standard is concerned. >> >> There are several problems with this argument. >> >> One, there is no evidence at all offered to say the statement of >> belief is true. > > Evidence isn't really relevant. [...] You didn't offer any reasoning either. You simply gave a statement of belief. >> Two, looking at any given C program, there is no way to know with >> certainty that a corresponding equivalent C-and-C++ program >> exists (in the sense of also satisfying the C(N) and CPP(N) >> conditions). > > [...] The overwhelming majority of equivalence classes > in C(N) have many members that are much smaller than N: [...] Certainly that is true of many programs but you haven't given a convincing argument that it is true for an overwhelming majority of programs. Furthermore you haven't said anything about how long a corresponding C++ program would be. >> Three, when looking at a particular C program and a proposed >> candidate C-and-C++ program, there is no way to know with >> certainty that the two programs are equivalent, because testing >> for equivalence is undecidable. So the hypothesis is probably >> impossible to verify. > > You're looking at it wrong. It might be difficult, even impossible, to > confirm that two arbitrary programs have the same required observable > behavior. However, my argument doesn't require that determination to be > made for arbitrary programs. It's trivial to come up with > transformations that take one program and convert it into another > program with the same required observable behavior, and that's all I > need to support my claim. You're wrong that it is trivial. I'm not sure it is even decidable. > It can also be impossible to determine whether any given program has > defined behavior - but I don't need to determine that to support my > claim, either. It's sufficient for what I'm saying that if I take a > program that has defined behavior, there are transformations that can > convert it into another program that has the same defined behavior. You haven't given any reasoning to say such tranformations exist, or that we can find or identify them if they do. > The key point is that there's only a relatively small set of issues that > need to be addressed: Annex C of the C++ standard is only 24 pages long. > For each item in Annex C, there's generally a relatively straightforward > transformation to the code that will address the item. If you feel > otherwise about any particular issue, you should identify it. You seem to think the list in Annex C is complete. You also seem to think that I bear some burden to convince you of some sort of error in your reasoning. That's backwards. You are the one making the claim, and so the burden is on you to provide convincing evidence or reasoning, or both, that your claim is correct. You are in effect offering a proof by assertion. >> Four, the test suggested bears no obvious relationship to any of >> the usual ways that programs are evaluated. More briefly, the >> test looks artificial. Because of that it seems to have little >> conceptual value. > > [...] I'm not claiming that it's a good idea to convert a C > program into [an equivalent C++ program]. [...] > I'm merely pointing out that it is feasible, [...] Your argument is then missing an essential step. Just because it may be possible to transform a C program into an equivalent C program that is also well-formed and equivalent C++ (which has so far not been established), that doesn't mean that C and C++ are necessarily "close" languages. In practice C programs and C++ programs don't look like each other. There are (relatively speaking) very few existing C programs that are also well-formed C++ programs. Furthermore, if an existing C program were to be transformed in a way like you suggest, whoever originally wrote the C program would very likely not continue working on it in the modified form, because "it doesn't look like C". I don't know of even a single counter-example to this rule, and certainly exceptions would be rare if they even exist at all. The metric you propose, even if it does happen to be satisfied, doesn't tell us anything about whether the two languages are closely related in the usual sense of the word. It's an artificial definition, used to support vacuous result.