Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #154705

Re: Two different Results between C and C++

Show all headers | View raw

Kaz Kylheku <793-849-0957@kylheku.com> writes:

> On 2020-09-04, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> I think it was correct, but it's not worth the effort to
>>> perform a major research project to verify it.
>>
>> Let's think about what you're saying.  How many C programs have
>> actually been written?  A hundred thousand?  A million?  Of those,
>> how many have you actually looked at?  Probably a few hundred, but
>> let's guess a thousand.  Of the C programs you've seen, how many
>> have you actually tried to convert to C++?  Five?  Ten?  Twenty?
>
> Most C programs I have ever looked at would likely present
> difficulties simply being ported to a different compiler/environment.
>
> A highly portable C program written in the C90 dialect is easy to
> convert to C++, with overwhelming confidence that it's still the
> same program.  C++ has pretty much all features of C90, going as
> far back as C++98 or even earlier to draft C++ dialects.  A
> program using some later C features, like mixed declarations and
> statements, // comments, variables defined in for(;;) or inline
> functions might also still be fairly easy to port to C++.
>
> I'm not very confident on C99 or later code being easily
> convertible to C++, compared to C90, what with all the designated
> initializers, VLA's, type generic math and whatever not that can
> be used.  (Newer C++ revisions have probably picked up some newer
> C features;  I don't keep up with that.)  In any case, code using
> C features that are not in the target C++ dialect could require
> substantial refactoring.
>
> Reagarding the "same program" topic:  if we had to make changes
> for C++, then of course it's not literally the same program as the
> one without the changes;  so first we have to convince ourselves
> that those changes have not altered the program, when regarded as
> a C program.  Then we consider whether the C++ interpretation
> evokes the same meaning.
>
> In that, we can have approximately the same confidence as that the
> program is well-defined.
>
> So that is to say, suppose we have edited the program so it builds
> as C++, while remaining C at the same time.  Having that program,
> suppose we then face two activities:  port the program to a
> different C compiler, and port the program to a C++ compiler.
>
> There is a concern that the program won't be "the same" when
> ported to the C compiler, due to the risk that it has hidden
> nonportabilities that do not affect its ability to be translated
> and executed.  Now the concern with regard to the C++ port is
> about of the same magnitude.  The concerns regarding C++
> constructs behaving differently from C constructs are dwarfed by
> the threat that the program contains hidden misuses of the
> language.  The program could have serious stability and security
> bugs that are reproducible in the original port, not only ones
> that show up under porting.  If there is a reproducible buffer
> overflow in it somewhere, then the C++ port will have it too, and
> so will the parallel port to the new C compiler.
>
> According to this reasoning, also, I would be more confident about
> a C program that built and tested with GNU C program ported to GNU
> C++, than about the same program ported to Intel C or what have
> you, because at least the compiler back end is staying the same.
> I would be more confident, even if it requires no changes to build
> with the other C compiler, while requiring some changes to become
> C++.
>
> Porting to C++ can help uncover bugs in C (either during the
> initial port, or later as the C++ port is maintained going
> forward).  So at the end of the exercise, we may end up with more
> certainties about the behavior of the resulting C program than we
> had before.
>
> In order to have absolutely no concern other that the C++ changes
> are introducing bugs, what we need to start with is a maximally
> portable C program that has been proven correct.  The changes
> needed to make it C++ then give us, firstly, a C program which is
> no longer proven correct.  We must re-do the proof for that
> program as a C program to recover the confidence that it's still
> the same program.  Secondly, we don't have a C++ program proven
> correct.  We must adjust our proof tools to recognize C++
> semantics of C features, and re-do the proof that way.

I'm not sure you understand the question being discussed.  The
set of programs under discussion is real-world C programs, to
use Keith Thompson's phrase, and there is a tacit assumption
that the programs are well-formed (meaning no syntax errors or
constraint violations).  They might or might not be either
highly portable or well defined (ie, they might have undefined
behavior under certain circumstances).  Porting the code to a
different C compiler is not a consideration:  there is a second
tacit assumption that the transformed code targets the same
implementation of C as the original.  Furthermore there is no
concern about the C++ implementation being "non-compatible":
there is a third tacit assumption that implementation-defined
behaviors in C++ such as size and representation of int, etc,
are chosen in the C++ implementation to match those of the
specified C implementation.

Given all that, we don't care if the transformed code is
"correct".  What we do care about is whether the transformed code
is equivalent to the original, in the sense that the resultant C
program, and also the (identical source) C++ program, has the
same semantics as the original program.  Assuming that condition
is met, the question is:  Can such transformations be effected,
with only a small effort in each case, for almost all real-world
C programs?

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-04 03:13 -0700
  Re: Two different Results between C and C++ Kaz Kylheku <793-849-0957@kylheku.com> - 2020-09-04 18:44 +0000
    Re: Two different Results between C and C++ David Brown <david.brown@hesbynett.no> - 2020-09-05 15:57 +0200
    Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-08 08:27 -0700
      Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-09-08 17:50 -0700
        Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-09-08 21:07 -0400
        Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-09-08 18:28 -0700
          Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-09-08 22:14 -0400
        Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-10 06:35 -0700
  Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-09-04 11:46 -0700
    Re: Two different Results between C and C++ Kaz Kylheku <793-849-0957@kylheku.com> - 2020-09-04 19:07 +0000
    Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-10 04:15 -0700
      Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-09-10 12:46 -0700

csiph-web