Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Two different Results between C and C++ Date: Sat, 12 Sep 2020 22:24:37 -0700 Organization: A noiseless patient Spider Lines: 139 Message-ID: <86pn6q2qqy.fsf@linuxsc.com> References: <8c6495f9-6139-464e-ac8f-4eac27a92776@googlegroups.com> <60d0f73c-8588-4673-a48d-e5c4cc726196@googlegroups.com> <87blm1wam0.fsf@nosuchdomain.example.com> <86d05skg6z.fsf@linuxsc.com> <87tuz4gt4c.fsf@nosuchdomain.example.com> <861rjj8kmz.fsf@linuxsc.com> <86ft7x7j1h.fsf@linuxsc.com> <7abdc18a-78b6-4fb5-a7f7-82e6b220b389o@googlegroups.com> <86tuw85ocl.fsf@linuxsc.com> <83c9cb00-6c52-4837-95a2-6cfe31eb5d88o@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="94c20496801271c42e84b298ad5f3672"; logging-data="28970"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+x2STuWLIeVaUkWm/Egpo7nIDHWnJs2yE=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:gOMcFw3bQIlF1QD4ZjT0kdWjqUM= sha1:z52atVMM2l+Probq9BfdoPd2Krs= Xref: csiph.com comp.lang.c:154924 Tiib writes: > On Tuesday, 8 September 2020 17:34:58 UTC+3, Tim Rentsch wrote: > >> Tiib writes: >> >>> On Friday, 4 September 2020 16:45:16 UTC+3, Tim Rentsch wrote: >>> >>>> Tiib writes: >>>> >>>>> On Thursday, 3 September 2020 09:00:54 UTC+3, Tim Rentsch wrote: >>>>> >>>>>> Richard Damon writes: >>>>>> >>>>>>> On 6/21/20 2:40 PM, Keith Thompson wrote: >>>>>>> >>>>>>>> Tim Rentsch writes: >>>>>>>> >>>>>>>>> Keith Thompson writes: >> >> [..snipped for brevity.. blank lines may indicate snipping..] >> >>>>>>>>>> There are *some* programs that are legal C but not legal C++. >>>>>>>>>> The most common causes of this are probably C++'s tighter >>>>>>>>>> restrictions on implicit conversions involving void*, C code >>>>>>>>>> that uses C++ keywords as identifiers, and C features that >>>>>>>>>> haven't been incorporated into C++, such as VLAs, _Generic, >>>>>>>>>> and compound literals. But almost all programs that are >>>>>>>>>> legal C but not legal C++ can be made into legal C++ with a >>>>>>>>>> small effort. >>>>>>>> >>>>>>>> When I wrote "almost all programs that are legal C but not >>>>>>>> legal C++", I was referring to real-world programs, not the >>>>>>>> infinite set of all possible programs. I probably could have >>>>>>>> made that clearer. >>>>>>> >>>>>>> My experiance would be a bit different, most C programs from the >>>>>>> 'wild' would likely fail as C++ precisely because of the >>>>>>> implicit conversion from void* that does not happen in C++. >>>>>>> These programs can trivially be converted to programs which are >>>>>>> valid in both C and C++ by adding the explicit cast. [...] >>>>>> >>>>>> Lots of C programs fail as C++ because of constraint violations >>>>>> or syntax errors. The problems are (obviously) easy to find, >>>>>> and mostly I think easy to fix. >>>>>> >>>>>> The bigger problem is C code that is legal C++ but has different >>>>>> semantics in C++ than in C. There are more of these than most >>>>>> C or C++ developers think there are. I don't know anyone, >>>>>> including myself, who can say with confidence that they know >>>>>> all the different ways that source code can have a different >>>>>> meaning in C++ compared to C. >>>>>> >>>>>> Clearly if someone doesn't know >>>>>> what all the potential discrepancies are there is no way they >>>>>> could find and fix them. >>>>> >>>>> In practice even developer who has never read neither standards >>>>> nor that [diff.iso] can do it. There always are at least some >>>>> tests. If test fails there is capability to figure it out why >>>>> it fails. Once that capability has been applied to fix an issue >>>>> also knowledge is obtained how to search for similar from >>>>> untested parts of code. >>>> >>>> Testing can be used to show the presence of errors, but >>>> never their absence. The code may seem to work even >>>> when bugs are still lurking. >>>> >>>> Also, if a test fails, there is no guarantee we can track >>>> down what caused the failure in any reasonably limited >>>> amount of time. This is especially true when we don't >>>> know what it is we're looking for. >>> >>> Yes, but so what? Writing code that can be compiled to produce >>> close enough to be useful result on both C and C++ compilers is >>> in practice about as difficult as to write code that produces >>> close enough to be useful result on both clang and msvc. >>> >>> All programmers are usual humans and therefore fallible and so >>> absence of errors in programs (including said compilers) >>> is about as expensive (and about as unneeded) to achieve as >>> collecting all berries of certain type from forest. >>> >>> It is just fact ... and that fact is easy to verify by looking at >>> issue management systems of every large open source project that >>> is happily used by millions of people. Lot of defects manifest as >>> errors long time after these were introduced into code since these >>> affect only tiny subset of users and even them very rarely. >>> >>> The idea of software development is to produce programs that >>> are useful and help some people in something, not defect-free >>> programs. That is also written so in license agreement of >>> majority of software. >> >> The claim under discussion is two-fold (my wording, but I am >> trying to be consistent with what Keith Thompson said above): >> >> (1) Any well-formed C program can be transformed into an >> equivalent well-formed C program that is also a >> well-formed, and equivalent, C++ program; and >> >> (2) For almost all "real-world" programs, to use Keith's >> phrasing, such transformations can be effected with >> a small effort. >> >> AFAICT your comments don't speak to either of these criteria. > > That depends on interpretation of these words. It is possible > that I misinterpreted something there. > >> You seem to be arguing that it is possible, with some unspecified >> amount of effort, to produce useful (even if not necessarily >> equivalent) programs. What I'm talking about is only the >> question of producing equivalent programs, and whether they can >> be produced with a small effort. Do you see the difference >> between that question and your comments above? > > You seem to ignore fact that very close to all "real world" programs > are defective and so the equivalence isn't (and can't be) mathematical. Of course it can be. There are lots of ways to transform a program into a different program that has identical semantics, whether or not the original program has defects. The transformed program will then have exactly the same defects as the original. Example: this declaration int x = 1; has exactly the same semantics as the transformed declaration int x = (int) 1; assuming of course there is no preprocessor funny business. > Instead "equivalent" means "as useful for its usages". I am using "equivalent" to mean "having exactly the same semantics", which is also what I think Keith Thompson meant.