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

Groups > comp.lang.c > #152592 > unrolled thread

Two different Results between C and C++

Back to article view | Back to comp.lang.c

Contents

  Two different Results between C and C++ Real Troll <real.troll@trolls.com> - 2020-06-02 04:08 -1000
    Re: Two different Results between C and C++ mark.bluemel@gmail.com - 2020-06-02 07:59 -0700
      Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-02 09:26 -0700
        Re: Two different Results between C and C++ Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-06-02 12:41 -0400
          Re: Two different Results between C and C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-06-02 18:09 +0100
          Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-02 11:51 -0700
            Re: Two different Results between C and C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-06-02 20:44 +0100
              Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-02 12:59 -0700
          Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-02 16:06 -0400
            Re: Two different Results between C and C++ mark.bluemel@gmail.com - 2020-06-03 00:27 -0700
    Re: Two different Results between C and C++ John Bode <jfbode1029@gmail.com> - 2020-06-02 08:41 -0700
      Re: Two different Results between C and C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-06-02 09:20 -0700
      Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-02 12:36 -0400
        Re: Two different Results between C and C++ John Bode <jfbode1029@gmail.com> - 2020-06-02 11:39 -0700
          Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-02 12:06 -0700
            Re: Two different Results between C and C++ Richard Damon <Richard@Damon-Family.org> - 2020-06-02 15:41 -0400
              Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-02 13:50 -0700
            Re: Two different Results between C and C++ John Bode <jfbode1029@gmail.com> - 2020-06-04 13:16 -0700
              Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-04 16:41 -0400
                Re: Two different Results between C and C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-08 16:54 +0200
              Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-04 16:04 -0700
            Re: Two different Results between C and C++ raltbos@xs4all.nl (Richard Bos) - 2020-06-04 20:47 +0000
              Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-04 17:35 -0400
                Re: Two different Results between C and C++ raltbos@xs4all.nl (Richard Bos) - 2020-06-04 22:01 +0000
                  Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-04 20:11 -0400
              Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-04 16:10 -0700
                Re: Two different Results between C and C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-06-05 02:26 -0700
                  Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-05 11:33 -0700
                Re: Two different Results between C and C++ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-06-05 11:28 +0000
            Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-06-21 00:53 -0700
              Re: Two different Results between C and C++ Öö Tiib <ootiib@hot.ee> - 2020-06-21 03:57 -0700
              Re: Two different Results between C and C++ Richard Damon <Richard@Damon-Family.org> - 2020-06-21 08:08 -0400
                Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-06-28 04:59 -0700
              Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-21 10:59 -0700
                Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-04 05:21 -0700
                  Re: Two different Results between C and C++ "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-09-05 13:02 -0700
                    Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-10 06:36 -0700
                      Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-09-10 12:03 -0700
                        Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-12 21:55 -0700
              Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-21 11:40 -0700
                Re: Two different Results between C and C++ Richard Damon <Richard@Damon-Family.org> - 2020-06-21 19:50 -0400
                  Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-02 23:00 -0700
                    Re: Two different Results between C and C++ Öö Tiib <ootiib@hot.ee> - 2020-09-03 09:57 -0700
                      Re: Two different Results between C and C++ David Brown <david.brown@hesbynett.no> - 2020-09-03 20:04 +0200
                      Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-04 06:44 -0700
                        Re: Two different Results between C and C++ Öö Tiib <ootiib@hot.ee> - 2020-09-05 06:51 -0700
                          Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-08 07:34 -0700
                            Re: Two different Results between C and C++ Öö Tiib <ootiib@hot.ee> - 2020-09-10 23:47 -0700
                              Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-09-11 10:17 -0400
                                Re: Two different Results between C and C++ Öö Tiib <ootiib@hot.ee> - 2020-09-11 08:32 -0700
                                  Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-09-11 12:03 -0400
                                    Re: Two different Results between C and C++ Öö Tiib <ootiib@hot.ee> - 2020-09-12 02:49 -0700
                              Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-12 22:24 -0700
                                Re: Two different Results between C and C++ Öö Tiib <ootiib@hot.ee> - 2020-09-13 06:25 -0700
                                  Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-15 05:01 -0700
                                    Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-09-15 10:59 -0700
                                    Re: Two different Results between C and C++ Öö Tiib <ootiib@hot.ee> - 2020-09-15 15:58 -0700
                                      Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-28 21:38 -0800
                                        Re: Two different Results between C and C++ Öö Tiib <ootiib@hot.ee> - 2020-12-30 05:39 -0800
                    Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-09-03 12:46 -0700
                      Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-10 06:20 -0700
                        Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-09-10 07:37 -0700
                        Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-09-10 10:44 -0400
                Re: Two different Results between C and C++ raltbos@xs4all.nl (Richard Bos) - 2020-06-29 16:20 +0000
                  Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-29 11:18 -0700
                    Re: Two different Results between C and C++ raltbos@xs4all.nl (Richard Bos) - 2020-06-29 21:46 +0000
                      Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-29 14:59 -0700
                      Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-29 18:53 -0400
                        Re: Two different Results between C and C++ Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2020-06-30 01:40 +0200
                          Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-29 17:48 -0700
                          Re: Two different Results between C and C++ David Brown <david.brown@hesbynett.no> - 2020-06-30 07:45 +0200
                          Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-30 15:11 -0400
                        Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-29 17:45 -0700
                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
                        Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 16:49 -0800
          Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-02 15:51 -0400
            Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-06-21 01:25 -0700
              Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-21 10:34 -0700
                Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-04 06:38 -0700
                  Re: Two different Results between C and C++ "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-09-06 05:52 -0700
                    Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-10 06:37 -0700
          Re: Two different Results between C and C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-08 16:54 +0200
      Re: Two different Results between C and C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-08 16:52 +0200
    Re: Two different Results between C and C++ Juha Nieminen <nospam@thanks.invalid> - 2020-06-02 18:45 +0000
      Re: Two different Results between C and C++ Bart <bc@freeuk.com> - 2020-06-02 19:55 +0100
        Re: Two different Results between C and C++ Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-06-02 15:11 -0400
          Re: Two different Results between C and C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-06-02 20:14 +0000
            Re: Two different Results between C and C++ Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-06-02 16:19 -0400
      Re: Two different Results between C and C++ Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-06-02 15:06 -0400
      Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-02 16:20 -0400
    Re: Two different Results between C and C++ Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2020-06-06 00:07 -0400

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#152874

On 6/21/20 2:40 PM, Keith Thompson wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> [...]
>>> All these statements are true, but none are particularly relevant.
>>> You can construct an infinite number of valid C or C++ programs by
>>> playing games with the grammar.  There are an infinite number of
>>> legal C programs that use conditional operators nested 10,000 levels
>>> deep, but I doubt that any such programs exist in the wild (except
>>> *maybe* as compiler capacity tests).  I think it's more useful to
>>> look at actual code rather than contrived infinite sets of programs.
>>>
>>> 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.
>>
>> This claim sounds like an article of faith, being offered without
>> either proof or evidence.  If meant as just an empirical statement
>> then of course there is no way anyone can know that.
> 
> 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 statement was not an "article of faith".  It was somewhat
> speculative.  I think it was correct, but it's not worth the effort
> to perform a major research project to verify it.
> 
> [...]
> 

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.

It actually comes down to the malloc call style used. Perhaps older code
that wanted to protect from a lack of prototype will leave the return
value uncast, another style (that will generate code that will compile
as C++) is to cast it to a pointer to the type mentioned in the sizeof
operator used as the parameter to malloc. This doesn't protect against
lack of prototype (unless you turn on the requirement for a prototype)
but does protect against the pointer being of the wrong type, which the
first method didn't protect from.

[toc] | [prev] | [next] | [standalone]

#154416

Richard Damon <Richard@Damon-Family.org> writes:

> On 6/21/20 2:40 PM, Keith Thompson wrote:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>> [...]
>>
>>>> All these statements are true, but none are particularly relevant.
>>>> You can construct an infinite number of valid C or C++ programs by
>>>> playing games with the grammar.  There are an infinite number of
>>>> legal C programs that use conditional operators nested 10,000
>>>> levels deep, but I doubt that any such programs exist in the wild
>>>> (except *maybe* as compiler capacity tests).  I think it's more
>>>> useful to look at actual code rather than contrived infinite sets
>>>> of programs.
>>>>
>>>> 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.
>>>
>>> This claim sounds like an article of faith, being offered without
>>> either proof or evidence.  If meant as just an empirical statement
>>> then of course there is no way anyone can know that.
>>
>> 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 statement was not an "article of faith".  It was somewhat
>> speculative.  I think it was correct, but it's not worth the effort
>> to perform a major research project to verify it.
>>
>> [...]
>
> 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.

[toc] | [prev] | [next] | [standalone]

#154428

On Thursday, 3 September 2020 09:00:54 UTC+3, Tim Rentsch  wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
> 
> > On 6/21/20 2:40 PM, Keith Thompson wrote:
> >
> >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> >>
> >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> >>
> >> [...]
> >>
> >>>> All these statements are true, but none are particularly relevant.
> >>>> You can construct an infinite number of valid C or C++ programs by
> >>>> playing games with the grammar.  There are an infinite number of
> >>>> legal C programs that use conditional operators nested 10,000
> >>>> levels deep, but I doubt that any such programs exist in the wild
> >>>> (except *maybe* as compiler capacity tests).  I think it's more
> >>>> useful to look at actual code rather than contrived infinite sets
> >>>> of programs.
> >>>>
> >>>> 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.
> >>>
> >>> This claim sounds like an article of faith, being offered without
> >>> either proof or evidence.  If meant as just an empirical statement
> >>> then of course there is no way anyone can know that.
> >>
> >> 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 statement was not an "article of faith".  It was somewhat
> >> speculative.  I think it was correct, but it's not worth the effort
> >> to perform a major research project to verify it.
> >>
> >> [...]
> >
> > 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.  

James Kuyper already said somewhere in this thread that C++ standard
lists such differences in Annex C [diff.iso]. It is quite exhaustive
list, may be few obscure cases are missing.

> 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.

[toc] | [prev] | [next] | [standalone]

#154443

On 03/09/2020 18:57, Öö Tiib wrote:
> On Thursday, 3 September 2020 09:00:54 UTC+3, Tim Rentsch  wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 6/21/20 2:40 PM, Keith Thompson wrote:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>> [...]
>>>>
>>>>>> All these statements are true, but none are particularly relevant.
>>>>>> You can construct an infinite number of valid C or C++ programs by
>>>>>> playing games with the grammar.  There are an infinite number of
>>>>>> legal C programs that use conditional operators nested 10,000
>>>>>> levels deep, but I doubt that any such programs exist in the wild
>>>>>> (except *maybe* as compiler capacity tests).  I think it's more
>>>>>> useful to look at actual code rather than contrived infinite sets
>>>>>> of programs.
>>>>>>
>>>>>> 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.
>>>>>
>>>>> This claim sounds like an article of faith, being offered without
>>>>> either proof or evidence.  If meant as just an empirical statement
>>>>> then of course there is no way anyone can know that.
>>>>
>>>> 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 statement was not an "article of faith".  It was somewhat
>>>> speculative.  I think it was correct, but it's not worth the effort
>>>> to perform a major research project to verify it.
>>>>
>>>> [...]
>>>
>>> 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.  
> 
> James Kuyper already said somewhere in this thread that C++ standard
> lists such differences in Annex C [diff.iso]. It is quite exhaustive
> list, may be few obscure cases are missing.
> 
>> 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.
> 

I'd say that if you write good, clear C code, and that code is also
valid as C++ (as a rough check, it compiles with "-pedantic errors" in
gcc with, for example, both std=c11 and std=c++11), then it is highly
unlikely that it would silently have different semantics in the two
languages.  To get different meanings, you have to use features like
declaring C functions without prototypes, or relying on the size of
character constants.  For a developer who has a care for the quality of
their code, it should not be at all difficult to write their C code in a
way that is fully C++ compatible and has identical semantics.  I
certainly have had no problem doing that on the few occasions I have
been required to write code that is compatible with both languages.

That does not mean, however, that I can look at a piece of C code and be
confident that the code has no silent differences between the languages
- not everyone writes their code in a clear and logical manner, and some
people seem to take pride in writing in a style that pushes boundaries.

Compiler warnings (or other static analysis tools) could presumably help
here too.

I would expect that overall your risks of C code having silently
different semantics in C++, after using warning checks from gcc, clang
or another good tool, are a good deal less than your risks of silently
having different semantics between different C++ versions.

[toc] | [prev] | [next] | [standalone]

#154487

Tiib <ootiib@hot.ee> writes:

> On Thursday, 3 September 2020 09:00:54 UTC+3, Tim Rentsch  wrote:
>
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 6/21/20 2:40 PM, Keith Thompson wrote:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>> [...]
>>>>
>>>>>> All these statements are true, but none are particularly relevant.
>>>>>> You can construct an infinite number of valid C or C++ programs by
>>>>>> playing games with the grammar.  There are an infinite number of
>>>>>> legal C programs that use conditional operators nested 10,000
>>>>>> levels deep, but I doubt that any such programs exist in the wild
>>>>>> (except *maybe* as compiler capacity tests).  I think it's more
>>>>>> useful to look at actual code rather than contrived infinite sets
>>>>>> of programs.
>>>>>>
>>>>>> 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.
>>>>>
>>>>> This claim sounds like an article of faith, being offered without
>>>>> either proof or evidence.  If meant as just an empirical statement
>>>>> then of course there is no way anyone can know that.
>>>>
>>>> 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 statement was not an "article of faith".  It was somewhat
>>>> speculative.  I think it was correct, but it's not worth the effort
>>>> to perform a major research project to verify it.
>>>>
>>>> [...]
>>>
>>> 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.
>
> James Kuyper already said somewhere in this thread that C++ standard
> lists such differences in Annex C [diff.iso]. It is quite exhaustive
> list, may be few obscure cases are missing.

The list is not complete.  AFAICT it doesn't even try to be
complete, or current.

>> 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.

[toc] | [prev] | [next] | [standalone]

#154553

On Friday, 4 September 2020 16:45:16 UTC+3, Tim Rentsch  wrote:
> Tiib <ootiib@hot.ee> writes:
> 
> > On Thursday, 3 September 2020 09:00:54 UTC+3, Tim Rentsch  wrote:
> >
> >> Richard Damon <Richard@Damon-Family.org> writes:
> >>
> >>> On 6/21/20 2:40 PM, Keith Thompson wrote:
> >>>
> >>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> >>>>
> >>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> >>>>
> >>>> [...]
> >>>>
> >>>>>> All these statements are true, but none are particularly relevant.
> >>>>>> You can construct an infinite number of valid C or C++ programs by
> >>>>>> playing games with the grammar.  There are an infinite number of
> >>>>>> legal C programs that use conditional operators nested 10,000
> >>>>>> levels deep, but I doubt that any such programs exist in the wild
> >>>>>> (except *maybe* as compiler capacity tests).  I think it's more
> >>>>>> useful to look at actual code rather than contrived infinite sets
> >>>>>> of programs.
> >>>>>>
> >>>>>> 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.
> >>>>>
> >>>>> This claim sounds like an article of faith, being offered without
> >>>>> either proof or evidence.  If meant as just an empirical statement
> >>>>> then of course there is no way anyone can know that.
> >>>>
> >>>> 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 statement was not an "article of faith".  It was somewhat
> >>>> speculative.  I think it was correct, but it's not worth the effort
> >>>> to perform a major research project to verify it.
> >>>>
> >>>> [...]
> >>>
> >>> 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.
> >
> > James Kuyper already said somewhere in this thread that C++ standard
> > lists such differences in Annex C [diff.iso]. It is quite exhaustive
> > list, may be few obscure cases are missing.
> 
> The list is not complete.  AFAICT it doesn't even try to be
> complete, or current.
> 
> >> 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.

[toc] | [prev] | [next] | [standalone]

#154701

Tiib <ootiib@hot.ee> writes:

> On Friday, 4 September 2020 16:45:16 UTC+3, Tim Rentsch  wrote:
>> Tiib <ootiib@hot.ee> writes:
>>> On Thursday, 3 September 2020 09:00:54 UTC+3, Tim Rentsch  wrote:
>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>> On 6/21/20 2:40 PM, Keith Thompson wrote:
>>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> 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.
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?

[toc] | [prev] | [next] | [standalone]

#154853

On Tuesday, 8 September 2020 17:34:58 UTC+3, Tim Rentsch  wrote:
> Tiib <ootiib@hot.ee> writes:
> 
> > On Friday, 4 September 2020 16:45:16 UTC+3, Tim Rentsch  wrote:
> >> Tiib <ootiib@hot.ee> writes:
> >>> On Thursday, 3 September 2020 09:00:54 UTC+3, Tim Rentsch  wrote:
> >>>> Richard Damon <Richard@Damon-Family.org> writes:
> >>>>> On 6/21/20 2:40 PM, Keith Thompson wrote:
> >>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> >>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> 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.
Instead "equivalent" means "as useful for its usages".

I said it is not more difficult in practice than to get C++ program
compiled on gcc on Windows ported to C++ program that is compiled
both on gcc and msvc for same platform. Actually that kind of
transformations typically result with program that is less defective
in both C and C++ (or both gcc and msvc). So result isn't usually
equivalent but bit better. I've participated in works of both kinds on
several occasions. But I may be mistaken about what was discussed.

[toc] | [prev] | [next] | [standalone]

#154866

On 9/11/20 2:47 AM, Öö Tiib wrote:
...
> ... Actually that kind of
> transformations typically result with program that is less defective
> in both C and C++ (or both gcc and msvc).

Not really. For example, code that must compile in both C and C++ has to
use something like (T*)malloc(size_expression) to allocate memory
dynamically, which is sub-optimal C because of the cast, and also
sub-optimal C++ because it uses malloc() rather than "new".

[toc] | [prev] | [next] | [standalone]

#154867

On Friday, 11 September 2020 17:17:22 UTC+3, James Kuyper  wrote:
> On 9/11/20 2:47 AM, Öö Tiib wrote:
> ...
> > ... Actually that kind of
> > transformations typically result with program that is less defective
> > in both C and C++ (or both gcc and msvc).
> 
> Not really. For example, code that must compile in both C and C++ has to
> use something like (T*)malloc(size_expression) to allocate memory
> dynamically, which is sub-optimal C because of the cast, and also
> sub-optimal C++ because it uses malloc() rather than "new".

Do you really mean sub-optimal or that it is unsafe or
error prone? I just said about my experience with amount of defects
in resulting software. Questionable places in code are the places
where the transformation is potentially not entirely mechanical.
That drags attention to such places during transformation. That
attention usually results with those places being unit-tested
better and also typically rewritten into less questionable. 

[toc] | [prev] | [next] | [standalone]

#154868

On 9/11/20 11:32 AM, Öö Tiib wrote:
> On Friday, 11 September 2020 17:17:22 UTC+3, James Kuyper  wrote:
>> On 9/11/20 2:47 AM, Öö Tiib wrote:
>> ...
>>> ... Actually that kind of
>>> transformations typically result with program that is less defective
>>> in both C and C++ (or both gcc and msvc).
>>
>> Not really. For example, code that must compile in both C and C++ has to
>> use something like (T*)malloc(size_expression) to allocate memory
>> dynamically, which is sub-optimal C because of the cast, and also
>> sub-optimal C++ because it uses malloc() rather than "new".
> 
> Do you really mean sub-optimal or that it is unsafe or
> error prone? ...

I meant sub-optimal. Being unsafe or error prone are two different ways
code can be sub-optimal - there are many others. In this case, the code
is unsafe only if compiling for C90, in that you get no error message if
you forget to #include <stdlib.h>. This could cause your program to
malfunction if int and void* are passed by different methods.

However, if you're using a more modern version of C, a warning is
guaranteed in that case. In that case, all that's sub-optimal about that
code is something much more subtle, and controversial: it's an
unnecessary cast that pointlessly solves the wrong problem (the type
returned by malloc()) rather than the right one (the size passed to
malloc()). It draws the attention of everyone who's properly paranoid
about casts. If such unnecessary casts are common, they also encourage
people to become less paranoid about casts, which is another kind of harm.

[toc] | [prev] | [next] | [standalone]

#154885

On Friday, 11 September 2020 19:03:25 UTC+3, James Kuyper  wrote:
> On 9/11/20 11:32 AM, Öö Tiib wrote:
> > On Friday, 11 September 2020 17:17:22 UTC+3, James Kuyper  wrote:
> >> On 9/11/20 2:47 AM, Öö Tiib wrote:
> >> ...
> >>> ... Actually that kind of
> >>> transformations typically result with program that is less defective
> >>> in both C and C++ (or both gcc and msvc).
> >>
> >> Not really. For example, code that must compile in both C and C++ has to
> >> use something like (T*)malloc(size_expression) to allocate memory
> >> dynamically, which is sub-optimal C because of the cast, and also
> >> sub-optimal C++ because it uses malloc() rather than "new".
> > 
> > Do you really mean sub-optimal or that it is unsafe or
> > error prone? ...
> 
> I meant sub-optimal. Being unsafe or error prone are two different ways
> code can be sub-optimal - there are many others. In this case, the code
> is unsafe only if compiling for C90, in that you get no error message if
> you forget to #include <stdlib.h>. This could cause your program to
> malfunction if int and void* are passed by different methods.
> 
> However, if you're using a more modern version of C, a warning is
> guaranteed in that case. In that case, all that's sub-optimal about that
> code is something much more subtle, and controversial: it's an
> unnecessary cast that pointlessly solves the wrong problem (the type
> returned by malloc()) rather than the right one (the size passed to
> malloc()). It draws the attention of everyone who's properly paranoid
> about casts. If such unnecessary casts are common, they also encourage
> people to become less paranoid about casts, which is another kind of harm.


Generally I support removing superfluous constructs where those
add no value. 

Cast from void* to some other pointer are in places worth
double attention. Even casts between arithmetic types are
often in places worth double attention.
If explicit cast now shows that attention was paid or just
shows that people sprinkle casts carelessly all over the code
to silence warnings is more matter-of-taste-philosophical I
think as I haven't heard of any actual studies made about it.

Matter-of-taste-philosophically I like the C++ casts more as
they feel like something worth to be paranoid about, easier to
notice, easier to search and as what one (like me) would not
add without reason. But when we have that common subset as
goal (it is not very usual goal) then few superfluous C style
casts hurt nothing and certainly won't add defects.

[toc] | [prev] | [next] | [standalone]

#154924

Tiib <ootiib@hot.ee> writes:

> On Tuesday, 8 September 2020 17:34:58 UTC+3, Tim Rentsch  wrote:
>
>> Tiib <ootiib@hot.ee> writes:
>>
>>> On Friday, 4 September 2020 16:45:16 UTC+3, Tim Rentsch  wrote:
>>>
>>>> Tiib <ootiib@hot.ee> writes:
>>>>
>>>>> On Thursday, 3 September 2020 09:00:54 UTC+3, Tim Rentsch  wrote:
>>>>>
>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>
>>>>>>> On 6/21/20 2:40 PM, Keith Thompson wrote:
>>>>>>>
>>>>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>>>>>
>>>>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

#154939

On Sunday, 13 September 2020 08:24:59 UTC+3, Tim Rentsch  wrote:
> Tiib <ootiib@hot.ee> writes:
> 
> > On Tuesday, 8 September 2020 17:34:58 UTC+3, Tim Rentsch  wrote:
> >
> >> Tiib <ootiib@hot.ee> writes:
> >>
> >>> On Friday, 4 September 2020 16:45:16 UTC+3, Tim Rentsch  wrote:
> >>>
> >>>> Tiib <ootiib@hot.ee> writes:
> >>>>
> >>>>> On Thursday, 3 September 2020 09:00:54 UTC+3, Tim Rentsch  wrote:
> >>>>>
> >>>>>> Richard Damon <Richard@Damon-Family.org> writes:
> >>>>>>
> >>>>>>> On 6/21/20 2:40 PM, Keith Thompson wrote:
> >>>>>>>
> >>>>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> >>>>>>>>
> >>>>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> 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.

Is that real world program? For me real world program has (at
least) 3 mandatory behavioral components ... input, processing
and output. Otherwise what is its real world usage? Also it 
isn't defective (that real world programs are as rule). ;)

> 
> 
> > 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.

OK but it is indeed usually trivial. All trouble that I have met was
with undefined behaviors manifesting differently. Is there some real
example of difficulties of translating semantics of C into semantics
of common subset between C and C++? 

My experience is that C++ compiler will lament about most places and
additionally warn lot more. The differences that I would search for
manually (and if needed correct or made more explicit) are const 
variables linkage, inline functions linkage and usage of names of
structs, unions and enums. Then I would remove any pointless usage
of size of character literals, logical operators, trues, falses and
enums. Finally if there is time then ... I would refactor away type
punning with union despite  all C++ compilers seem to support it.
What else? Sure it is work if we talk about lot of lines of code
but easy work.

[toc] | [prev] | [next] | [standalone]

#155015

Tiib <ootiib@hot.ee> writes:

> On Sunday, 13 September 2020 08:24:59 UTC+3, Tim Rentsch  wrote:
>> Tiib <ootiib@hot.ee> writes:

[..pruning..]

>>> 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.
>
> Is that real world program?  For me real world program has (at
> least) 3 mandatory behavioral components ... input, processing
> and output.  Otherwise what is its real world usage?  Also it
> isn't defective (that real world programs are as rule). ;)

It was only an example of a semantics-preserving transformation.
Of course it was meant as only one part of a program, not an
entire program.  Other parts of the program could do I/O,
have possible undefined behavior, etc.


>>> 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.
>
> OK but it is indeed usually trivial.

So people keep saying, more or less, but I haven't seen any kind
of supporting argument except proof by assertion.

> All trouble that I have met was with undefined behaviors
> manifesting differently.

What I think you mean is the only trouble that you know you have
met was undefined behavior manifesting differently.  But, since
you aren't sure about all the ways that semantics can vary
between C and C++, you don't know if there were other troubles.

> Is there some real example of difficulties of translating
> semantics of C into semantics of common subset between C and
> C++?

The question here is not whether some conversions are incredibly
difficult but whether most programs can be transformed with a
small effort.  If converting a program takes two months of full
time, even if the work is easy, that is not a small effort.


> My experience is that C++ compiler will lament about most places
> and additionally warn lot more.  The differences that I would
> search for manually (and if needed correct or made more explicit)
> are const variables linkage, inline functions linkage and usage of
> names of structs, unions and enums.  Then I would remove any
> pointless usage of size of character literals, logical operators,
> trues, falses and enums.  Finally if there is time then ... I
> would refactor away type punning with union despite all C++
> compilers seem to support it.  What else?  Sure it is work if we
> talk about lot of lines of code but easy work.

What experience do you have actually trying to convert C code
into C++?  What can you say about the programs and types of
programs that were converted?  How long did it take in each case?
What evidence can you offer, if any, that the results you saw
would apply to all types of real-world programs and not just the
programs that you happened to work on?

[toc] | [prev] | [next] | [standalone]

#155040

On Tuesday, September 15, 2020 at 8:01:22 AM UTC-4, Tim Rentsch wrote:
> Tiib <ootiib@hot.ee> writes:
...
> > OK but it is indeed usually trivial.
> 
> So people keep saying, more or less, but I haven't seen any kind
> of supporting argument except proof by assertion.

What kind of supporting argument would you like to see?

If I were to say it's not difficult to dress myself in the morning, you
could say that I'm just providing an argument by assertion. How would
you want me to prove that it's not difficult to dress myself?

You've rejected the most obvious argument: "I've done it many times
before, without running into any serious problems" by suggesting that we
were mistaken when we thought we'd actually done it.

Do you want a complete rundown of what needs to be done? I see that
they've changed the numbering in n4860.pdf, and the relevant section is
now Annex C.5. The first item in that list is:

"Change: New Keywords
Rationale: These keywords were added in order to implement the new
semantics of C ++ .
Effect on original feature: Change to semantics of well-defined feature.
Any ISO C programs that used any of these keywords as identifiers are
not valid C ++ programs.
Difficulty of converting: Syntactic transformation. Converting one
specific program is easy. Converting a large collection of related
programs takes more work."

Procedure: make a list of all of the new keywords in C++. Search for all
occurrences of those keywords in the C program. For each declaration or
definition of a C identifier matching one of those keywords, determine
which other uses of that identifier refer back to that declaration or
definition. Then change that declaration or definition, and all uses
that refer to it, to use a new identifier that is neither a C keyword or
a C++ keyword and doesn't conflict with any other identifiers used in
the same program (nor with any of the other reserved identifiers).
In practice, most occurrences of this problem will cause syntax errors
if compiled as C++ code, so you can get most of the way to identifying
all such problems just by trying to compile the code and dealing with
any resulting diagnostics.

Now, would you consider it helpful for me to systematically go through
every entry in Annex C.5 of n4860.pdf and explain what needs to be done
to deal with the problem? 
I wouldn't expect it to be helpful, since what I've written above seems
so obvious that you shouldn't need me to explain it. Also, you've
suggested that the key problem is not that the items in Annex C.5 can't
be dealt with, but that the list is incomplete. However, if you think it
would help, I'm willing to continue - particularly if doing so would
make you willing to identify what you think is missing from Annex C.5.

> What experience do you have actually trying to convert C code
> into C++?  What can you say about the programs and types of
> programs that were converted?  How long did it take in each case?

It would be much easier for you to identify the features a C program
might possess that cause you to think it might be difficult.

[toc] | [prev] | [next] | [standalone]

#155041

On Tuesday, 15 September 2020 15:01:22 UTC+3, Tim Rentsch  wrote:
> Tiib <ootiib@hot.ee> writes:
> 
> 
> > All trouble that I have met was with undefined behaviors
> > manifesting differently.
> 
> What I think you mean is the only trouble that you know you have
> met was undefined behavior manifesting differently.  But, since
> you aren't sure about all the ways that semantics can vary
> between C and C++, you don't know if there were other troubles.

Yes. I only know of my experience. I can not know of experiences
of someone else. Defects are preferred to be discovered with
testing but sometimes reach users. 

> > Is there some real example of difficulties of translating
> > semantics of C into semantics of common subset between C and
> > C++?
> 
> The question here is not whether some conversions are incredibly
> difficult but whether most programs can be transformed with a
> small effort.  If converting a program takes two months of full
> time, even if the work is easy, that is not a small effort.

Porting it has to provide benefits above alternatives and so it
is important to predict it correctly. Two man-months is certainly
effort but relatively low effort in typical software projects. 
 
> > My experience is that C++ compiler will lament about most places
> > and additionally warn lot more.  The differences that I would
> > search for manually (and if needed correct or made more explicit)
> > are const variables linkage, inline functions linkage and usage of
> > names of structs, unions and enums.  Then I would remove any
> > pointless usage of size of character literals, logical operators,
> > trues, falses and enums.  Finally if there is time then ... I
> > would refactor away type punning with union despite all C++
> > compilers seem to support it.  What else?  Sure it is work if we
> > talk about lot of lines of code but easy work.
> 
> What experience do you have actually trying to convert C code
> into C++?  What can you say about the programs and types of
> programs that were converted?  How long did it take in each case?
> What evidence can you offer, if any, that the results you saw
> would apply to all types of real-world programs and not just the
> programs that you happened to work on?

Sure I can talk about it but it is unsure how it helps as these
are still just mine experiences. There were different reasons in
different projects.

For example couple times there was desire to use certain C99 code
bases of significant size on Windows, compiled with MSVC to
integrate into larger Visual Studio project but to keep using
same code on original equipment as well for not to fork code
base into branches. Microsoft's C compiler however was kind of
C90 with some extensions. Decided was that instead of back-porting
C99 into that weird C90 it will be translated into common subset
to be compilable with Visual C++. Low amount of effort between
other works. Very common issues ... like that Visual C++
did not yet support variadic macros so some tricks were loaned
from Boost.Preprocessor that worked on both. Or that some C++
keyword like "new" was used as name.

Whatever amount of experience can not show that it is guaranteed
to be simple but I don't have any idea what major difficulties
there are supposed to be. Common subset is only slightly crippled
but fully useful as programming language and in those projects
it was preferred to C90. 

[toc] | [prev] | [next] | [standalone]

#157860

Tiib <ootiib@hot.ee> writes:

I am sorry to have taken so long to respond to this posting.  My
apologies. 

> On Tuesday, 15 September 2020 15:01:22 UTC+3, Tim Rentsch  wrote:
>
>> Tiib <ootiib@hot.ee> writes:
>>
>>> All trouble that I have met was with undefined behaviors
>>> manifesting differently.
>>
>> What I think you mean is the only trouble that you know you have
>> met was undefined behavior manifesting differently.  But, since
>> you aren't sure about all the ways that semantics can vary
>> between C and C++, you don't know if there were other troubles.
>
> Yes.  I only know of my experience.  I can not know of experiences
> of someone else.  Defects are preferred to be discovered with
> testing but sometimes reach users.

My point is you don't know if the transformations tried resulted
in the same programs.  The last sentence there suggests that they
did not.

>>> Is there some real example of difficulties of translating
>>> semantics of C into semantics of common subset between C and
>>> C++?
>>
>> The question here is not whether some conversions are incredibly
>> difficult but whether most programs can be transformed with a
>> small effort.  If converting a program takes two months of full
>> time, even if the work is easy, that is not a small effort.
>
> Porting it has to provide benefits above alternatives and so it
> is important to predict it correctly.  Two man-months is certainly
> effort but relatively low effort in typical software projects.

I'm willing to take it for granted that a transformation is being
done because it is thought that some benefits will result.  The
question is not do the benefits justify the effort involved but
only how large an effort is needed.  Two months of full time is
not what I would call a small effort, regardless of how much
effort was needed on other parts of the project.

>>> My experience is that C++ compiler will lament about most places
>>> and additionally warn lot more.  The differences that I would
>>> search for manually (and if needed correct or made more explicit)
>>> are const variables linkage, inline functions linkage and usage of
>>> names of structs, unions and enums.  Then I would remove any
>>> pointless usage of size of character literals, logical operators,
>>> trues, falses and enums.  Finally if there is time then ... I
>>> would refactor away type punning with union despite all C++
>>> compilers seem to support it.  What else?  Sure it is work if we
>>> talk about lot of lines of code but easy work.
>>
>> What experience do you have actually trying to convert C code
>> into C++?  What can you say about the programs and types of
>> programs that were converted?  How long did it take in each case?
>> What evidence can you offer, if any, that the results you saw
>> would apply to all types of real-world programs and not just the
>> programs that you happened to work on?
>
> Sure I can talk about it but it is unsure how it helps as these
> are still just mine experiences.  There were different reasons in
> different projects.
>
> For example couple times there was desire to use certain C99 code
> bases of significant size on Windows, compiled with MSVC to
> integrate into larger Visual Studio project but to keep using
> same code on original equipment as well for not to fork code
> base into branches.  Microsoft's C compiler however was kind of
> C90 with some extensions.  Decided was that instead of back-porting
> C99 into that weird C90 it will be translated into common subset
> to be compilable with Visual C++.  Low amount of effort between
> other works.  Very common issues ... like that Visual C++
> did not yet support variadic macros so some tricks were loaned
> from Boost.Preprocessor that worked on both.  Or that some C++
> keyword like "new" was used as name.

This summary isn't very informative.  No quantitative statements
of how many projects, how much code was involved, or how long
each of the efforts took.  No indication of what kind of code was
being transformed, except that it used some C99 constructs, but
not which ones or how lightly/heavily.  (I should note that
variadic macros were given a specific mention.)

In reporting what the transformation entailed, you mention some
of the problems you found but not what was done (if anything)
to discover if there might have been other problems that did
not cause compilation errors.

> Whatever amount of experience can not show that it is guaranteed
> to be simple

Note that I am not looking for a guarantee, just some kind of
empirical evidence.

> but I don't have any idea what major difficulties there are
> supposed to be.

A key point.  If we don't know what all the problems are, we
can't say how large an effort is needed to address them.

> Common subset is only slightly crippled but fully useful as
> programming language and in those projects it was preferred to
> C90.

Point one:  preferred to C90 for those code bases.  Other code
bases may have reached different conclusions.

Point two:  whether the C++ version is preferred is irrelevant
to the question of how much effort is needed to accomplish the
transformation.

Point three:  because you don't know whether the conversion
efforts faithfully preserved program semantics, you actually
don't know if the "common subset" is indeed truly a common
subset.

[toc] | [prev] | [next] | [standalone]

#157902

On Tuesday, 29 December 2020 at 07:38:42 UTC+2, Tim Rentsch wrote:
> Tiib <oot...@hot.ee> writes: 
> 
> I am sorry to have taken so long to respond to this posting. My 
> apologies. 

No problems. I am not in hurry. :D
 
> > On Tuesday, 15 September 2020 15:01:22 UTC+3, Tim Rentsch wrote: 
> > 
> >> Tiib <oot...@hot.ee> writes: 
> >> 
> >>> All trouble that I have met was with undefined behaviors 
> >>> manifesting differently. 
> >> 
> >> What I think you mean is the only trouble that you know you have 
> >> met was undefined behavior manifesting differently. But, since 
> >> you aren't sure about all the ways that semantics can vary 
> >> between C and C++, you don't know if there were other troubles. 
> > 
> > Yes. I only know of my experience. I can not know of experiences 
> > of someone else. Defects are preferred to be discovered with 
> > testing but sometimes reach users. 
> 
> My point is you don't know if the transformations tried resulted 
> in the same programs. The last sentence there suggests that they 
> did not. 

Any work is done for the product to become useful for something
else than it was before. IOW not to be same is the whole point.
Perhaps I formed the sentence too dimly. Programs are released
with issues. Sometimes with known (won't fix) issues and sometimes
with unknown yet issues. I know of *no* case that such issue was
because of usage of common subset between C and C++. 
Do you know any?

> >>> Is there some real example of difficulties of translating 
> >>> semantics of C into semantics of common subset between C and 
> >>> C++? 
> >> 
> >> The question here is not whether some conversions are incredibly 
> >> difficult but whether most programs can be transformed with a 
> >> small effort. If converting a program takes two months of full 
> >> time, even if the work is easy, that is not a small effort. 
> > 
> > Porting it has to provide benefits above alternatives and so it 
> > is important to predict it correctly. Two man-months is certainly 
> > effort but relatively low effort in typical software projects. 
> 
> I'm willing to take it for granted that a transformation is being 
> done because it is thought that some benefits will result. The 
> question is not do the benefits justify the effort involved but 
> only how large an effort is needed. Two months of full time is 
> not what I would call a small effort, regardless of how much 
> effort was needed on other parts of the project. 

By my experience it is that porting POSIX to Windows or
translating C99 to C90 are bigger work than translating C99
to  C99/C++03. 

> >>> My experience is that C++ compiler will lament about most places 
> >>> and additionally warn lot more. The differences that I would 
> >>> search for manually (and if needed correct or made more explicit) 
> >>> are const variables linkage, inline functions linkage and usage of 
> >>> names of structs, unions and enums. Then I would remove any 
> >>> pointless usage of size of character literals, logical operators, 
> >>> trues, falses and enums. Finally if there is time then ... I 
> >>> would refactor away type punning with union despite all C++ 
> >>> compilers seem to support it. What else? Sure it is work if we 
> >>> talk about lot of lines of code but easy work. 
> >> 
> >> What experience do you have actually trying to convert C code 
> >> into C++? What can you say about the programs and types of 
> >> programs that were converted? How long did it take in each case? 
> >> What evidence can you offer, if any, that the results you saw 
> >> would apply to all types of real-world programs and not just the 
> >> programs that you happened to work on? 
> > 
> > Sure I can talk about it but it is unsure how it helps as these 
> > are still just mine experiences. There were different reasons in 
> > different projects. 
> > 
> > For example couple times there was desire to use certain C99 code 
> > bases of significant size on Windows, compiled with MSVC to 
> > integrate into larger Visual Studio project but to keep using 
> > same code on original equipment as well for not to fork code 
> > base into branches. Microsoft's C compiler however was kind of 
> > C90 with some extensions. Decided was that instead of back-porting 
> > C99 into that weird C90 it will be translated into common subset 
> > to be compilable with Visual C++. Low amount of effort between 
> > other works. Very common issues ... like that Visual C++ 
> > did not yet support variadic macros so some tricks were loaned 
> > from Boost.Preprocessor that worked on both. Or that some C++ 
> > keyword like "new" was used as name. 
> 
> This summary isn't very informative. No quantitative statements 
> of how many projects, how much code was involved, or how long 
> each of the efforts took.

Different works are done at same time or for to make other work
possible nothing is done pointlessly. I can not imagine project where
whatever transformation is just standalone goal. Are you asking for
quantitive data about precise hours spent for one or other task and
how many tens of thousands lines of code was  in what code base?

> No indication of what kind of code was 
> being transformed, except that it used some C99 constructs, but 
> not which ones or how lightly/heavily. (I should note that 
> variadic macros were given a specific mention.) 

Problem domain was processing and passing ISO8583 messages
between certain devices and financial institutions. All was later also
certified by EMV. The macros I mentioned because that was sole
important thing about C99 that MSVC C compiler supported but
MSVC C++ compiler did not.

> In reporting what the transformation entailed, you mention some 
> of the problems you found but not what was done (if anything) 
> to discover if there might have been other problems that did 
> not cause compilation errors. 

Most typically things did not compile for quite obvious reasons.
Far more rarely the things did compile but tests did fail and that
was always obvious why, like that bit width were assumed differently.
I already posted list of problems that can on some lucky corner case
compile and give different results. What else you expect there to be
done?

> > Whatever amount of experience can not show that it is guaranteed 
> > to be simple 
> 
> Note that I am not looking for a guarantee, just some kind of 
> empirical evidence. 

These were concrete cases in concrete problem domain in some
concrete projects more than 10 years ago. What more evidence?

> > but I don't have any idea what major difficulties there are 
> > supposed to be. 
> 
> A key point. If we don't know what all the problems are, we 
> can't say how large an effort is needed to address them. 

I have posted list of problems that I know of in this very thread
and can copy-paste again for convenience:
| I can try to list from top of my head.
| * const variables implicitly static/extern
| * C++ typedefs structs, unions and enums implicitly C does not
| * inline functions different
| * size difference of character literals
| * size difference of results of logical operators
| * size difference of true and false
| * size difference of enums

You have mentioned no reasoning why you consider any of
these or any other you refuse to identify hard to resolve nor
have posted any concrete issues yourself.

> > Common subset is only slightly crippled but fully useful as 
> > programming language and in those projects it was preferred to 
> > C90. 
> 
> Point one: preferred to C90 for those code bases. Other code 
> bases may have reached different conclusions. 

"Maybe there have" ... it isn't any way convincing argument? No
one can prove negative about unidentified places. I was expecting
you to identify problems with that common subset wherever else.
Otherwise anywhere else may be was major uproar of wrath
of God but here wasn't and as no one reported any there was
none to my knowledge.


> Point two: whether the C++ version is preferred is irrelevant 
> to the question of how much effort is needed to accomplish the 
> transformation.

Are you claiming that people involved estimated what costs
how lot of effort wrongly?  

> Point three: because you don't know whether the conversion 
> efforts faithfully preserved program semantics, you actually 
> don't know if the "common subset" is indeed truly a common 
> subset.

For that there are tests and testing and certifying. There never
are much more. What else can be expected?

[toc] | [prev] | [next] | [standalone]

#154449

On Thursday, September 3, 2020 at 2:00:54 AM UTC-4, Tim Rentsch wrote:
...
> 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. ...

Those ways are listed in Annex C.1 of the C++ standard. It is 9 pages
long in the latest version of the C++ standard that I have available.
The C++ standard is itself 1608 pages long, and incorporates essentially
the entire description of the C standard library by reference (with 2
pages of modifications), for another 278 pages. That's a total of 1886
pages of specification. The total of 11 pages that describe those
differences is pretty small by comparison.

Looking at those differences in detail, most of them will rarely if ever
be a significant problem, for one reason or another. While, by
definition, those differences do not involve syntax errors or constraint
violations, many of them would never cause any actual problems except in
code where the difference between the two languages would result in a
mandatory diagnostic for one reason or another in some other part of the
code.

A lot of the differences involve code that has defined behavior in one
language, and not in the other. In many cases a fully conforming C
compiler developed in coordination with a fully conforming C++ compiler
could in principle even have the undefined behavior in one language be
the same as the behavior required by the other language.

There's only a few significant differences between the languages that
involve strictly conforming C code which is also well-formed C++ code
with different behavior in each language - most of them having to do
with the differences in how the two languages handle scopes and name
spaces (not namespaces, which is a different concept, and C++ specific)
and the fact that in C, "struct", "union" and "enum" are mandatory in
contexts where they can be left out in C++.

Constructing code where those differences cause problems without
triggering mandatory diagnostics is possible, but, in general, quite
difficult. I know that because I once put together a program intended to
demonstrate every single such case.

I claim to be completely familiar with those differences, and I don't
think it's particularly difficult to achieve that level of familiarity -
at least, not by comparison with how difficult it is to achieve that
same level of familiarity with C itself. I won't dispute that many
people are unaware of those differences - but that's something that can
also be said about a great many features of either of those languages.

[toc] | [prev] | [next] | [standalone]

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web