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

Groups > comp.lang.c > #154514

Re: Two different Results between C and C++

Show all headers | View raw

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.

-- 
TXR Programming Lanuage: http://nongnu.org/txr
Music DIY Mailing List:  http://www.kylheku.com/diy
ADA MP-1 Mailing List:   http://www.kylheku.com/mp1

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