Re: Why does this work on Xcode ???

From	David Brown <david.brown@hesbynett.no>
Newsgroups	comp.lang.c++
Subject	Re: Why does this work on Xcode ???
Date	2019-08-25 11:36 +0200
Organization	A noiseless patient Spider
Message-ID	<qjtkrh$gd1$1@dont-email.me> (permalink)
References	(10 earlier) <87pnkwakex.fsf@bsb.me.uk> <qjnt6f$e14$1@dont-email.me> <qjoplk$ep$1@dont-email.me> <qjotnh$p13$1@dont-email.me> <qjpki9$vhs$1@dont-email.me>

Show all headers | View raw

On 23/08/2019 23:07, Alf P. Steinbach wrote:
> On 23.08.2019 16:37, David Brown wrote:
>> On 23/08/2019 15:28, James Kuyper wrote:
>>> On 8/23/19 1:22 AM, Alf P. Steinbach wrote:
>>>> On 23.08.2019 00:45, Ben Bacarisse wrote:
>>>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>>>>> <cut>
>>>>>> And I don't think you think you're smarter than everybody else in
>>>>>> this
>>>>>> group just for holding an opinion on UB that nobody else here shares.
>>>>>
>>>>> Why do you think no one else shares Tim's opinion?
>>>>
>>>> Because he's been arguing his view for a very long time and nobody's
>>>> supported him.
>>>
>>> I normally try (and often fail) to avoid paying attention to his posts,
>>> because I've found discussions with him to be unproductive - when I
>>> discuss my disagreements with him, we usually both end up wasting a lot
>>> of time failing to convince each other. He's a lot like you in that
>>> regard.
>>>
>>> He has a strong tendency to elevate what he believes to be the
>>> committee's intent to play a larger role in the interpretation of the
>>> standard than I think appropriate. This can be particularly annoying if
>>> I disagree with him about what that intent was.
>>> If the standard's wording is in conflict with (or even simply fails to
>>> clearly express) the committee's intent, then that wording should be
>>> corrected to clearly express that intent - but that discrepancy doesn't
>>> change the meaning of the words that they actually wrote.
>>>
>>> However, he is very knowledgeable about the standard, and he is correct
>>> about the pre-eminence of a program's observable behavior. The
>>> standard's definition of "observable behavior" is not "behavior which
>>> can be observed" - it's far more specific than that:
>>>
>>> "The least requirements on a conforming implementation are:
>>> — Accesses through volatile glvalues are evaluated strictly according to
>>> the rules of the abstract machine.
>>> — At program termination, all data written into files shall be identical
>>> to one of the possible results that
>>> execution of the program according to the abstract semantics would have
>>> produced.
>>> — The input and output dynamics of interactive devices shall take place
>>> in such a fashion that prompting
>>> output is actually delivered before a program waits for input. What
>>> constitutes an interactive device is
>>> implementation-defined.
>>> These collectively are referred to as the observable behavior of the
>>> program. ..." (4.6p7).
>>>
>>> The term "observable behavior" is in italics, an ISO convention
>>> indicating that this sentence is the official definition of that term.
>>> In the context of the C++ standard, that definition overrides any
>>> alternative interpretation that might otherwise seem appropriate.
>>>
>>> Note that the amount of stack space taken up by a program does not
>>> qualify as "observable behavior".
>>>
>>> The standard very explicitly says "The semantic descriptions in this
>>> International Standard define a parameterized nondeterministic abstract
>>> machine. This International Standard places no requirement on the
>>> structure of conforming implementations. In particular, they need not
>>> copy or emulate the structure of the abstract machine. Rather,
>>> conforming implementations are required to emulate (only) the observable
>>> behavior of the abstract machine as explained below." (4.6p1).
>>>
>>> So if the same observable behavior can be achieved by using either an
>>> iterative or a recursive algorithm, an implementation is free to use
>>> either of those algorithms to achieve it, regardless of which algorithm
>>> you actually expressed in your code. The fact that one algorithm runs a
>>> higher risk of running out of stack space than the other imposes no
>>> requirement on the implementation to avoid that risk (or to embrace it,
>>> for that matter).
>>>
>>
>> Since we are expressing opinions - regardless of how much or little they
>> may be worth - I agree with James here.  And as far as I can see, it is
>> the same as Tim has been saying in this regard.
>>
>> Usually, changing an iterative algorithm into a recursive one will be a
>> pessimisation, taking more space and run-time.  So it is highly unlikely
>> for a compiler to do this sort of thing - it would quickly become an
>> unpopular tool.  But it is allowed to do so.
> 
> As an example, rewriting a function with loop that uses a fixed size
> storage known at compile time, to a recursive function that uses storage
> proportional to the function argument, changes the behavior.
> 

Not as far as the language is concerned, no.

For the programmer, many things are important that are not covered by
the language itself.  The same therefore applies to compilers.

But as far as language conformance goes - and that is what we are
discussing, /nothing/ else matters.  It doesn't matter if the compiler
takes 15 years to finish compiling "Hello, world".  It doesn't matter if
it uses 26 MB of ram for that program.  It doesn't matter if it
generates the code as a Turing program and includes a simulator in the
exe file.

> With the original code one is guaranteed that it will complete.
> 

Nonsense.

The C++ standards only describe how the language is interpreted and
certain aspects of the behaviour.  They don't give guarantees about the
environment, resources, timings, etc.

The /compiler/ might give you more guarantees.  The compiler distributor
might guarantee that the compiler will generate sane code or you get
your money back.  (gcc guarantees that if the compiler breaks, you get
to keep both halves.)

But the C++ standards - the only things relevant for conformance - give
no such guarantees.


> With the recursive one one is not guaranteed completion, because for
> large enough values of the parameter it will run out of stack space, an
> implementation limit.
> 
>   * * *
> 
> Essentially the argument about observable behavior is therefore that a
> compiler is formally permitted to change a program that guarantees a
> result if it compiles and loads, into a program that almost guaranteed
> does not produce a correct result.

No.  (You seem to be totally misunderstanding the concepts of observable
behaviour, C++ conformance, and the role of the language standard in
this post.)

The compiler can manipulate the code in any way, preserving the
observable behaviour, without affecting conformity.  Resources don't
come into it - usually the compiler doesn't know the resources either.

It is not unknown, for real, quality compilers, for different choices of
compiler flags to result in programs that work in their target
environment or don't work - while the observable behaviour of the code
on a target with enough resources is unaffected.  This can happen in
many ways in resource-constrained embedded systems - optimisation flag
choices can make the program too big for flash, use too much ram, too
much stack, take too long to run.  But these aspects are usually beyond
the knowledge of the compiler, and are certainly well beyond the scope
of the standards - and therefore irrelevant for conformity.

> 
> That's a perpetuum mobile construction argument. One doesn't necessarily
> know where someone's logic went astray so that they ended up with a
> perpetuum mobile design, but the end result is just not reality: it's
> absurd. Somewhere in that argument there's necessarily something wrong,
> and that's not a QoI issue.
> 
> 
>> In the same way, between "int a = b + c;" and "int d = a * 2;", the
>> compiler is allowed to insert code calculating the first hundred digits
>> of pi - including the stack space needed for the job.
> 
> No, that's not the same way.
> 
> In this example a fixed storage requirement is not changed to a
> requirement of storage depending on a parameter.

I am sure it would not stretch your imagination to adapt the example to
your liking.  The compiler can insert code to calculate "a" digits of pi
between these two statements.  Happy?

> 
> 
>>  It would be an
>> unpopular tool, but this would not affect the observable behaviour and
>> thus it would not affect the conformance of the compiler.
> 
> It would affect observable behavior. One would get wrong results or
> crashes. Instead of with a conforming compiler, correct results.

No.  Please re-read the part of the C++ standard explaining what
"observable behaviour" is in regards to the standards.  It does /not/
mean "behaviour observed by the user".

> 
> 
>> The standards do not impose any requirements on quality of
>> implementation (though they have a few hints here and there) - that is
>> up to the user.
> 
> That's right, but this isn't QoI, it's about correctness.
> 

Yes - I'm correct, and you're wrong :-)

Thread

Why does this work on Xcode ??? Bob Langelaan <bobl0456@gmail.com> - 2019-07-16 22:03 -0700
  Re: Why does this work on Xcode ??? Paavo Helde <myfirstname@osa.pri.ee> - 2019-07-17 08:46 +0300
  Re: Why does this work on Xcode ??? Öö Tiib <ootiib@hot.ee> - 2019-07-17 00:06 -0700
    Re: Why does this work on Xcode ??? Öö Tiib <ootiib@hot.ee> - 2019-07-17 01:44 -0700
  Re: Why does this work on Xcode ??? Juha Nieminen <nospam@thanks.invalid> - 2019-07-17 07:46 +0000
  Re: Why does this work on Xcode ??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-07-17 09:12 -0400
  Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-07-17 17:01 +0200
    Re: Why does this work on Xcode ??? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-07-17 22:15 +0100
      Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-07-17 23:29 +0200
        Re: Why does this work on Xcode ??? Christian Gollwitzer <auriocus@gmx.de> - 2019-07-19 08:27 +0200
          Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-07-19 09:09 +0200
            Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-07-19 09:24 +0200
            Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-10 11:18 -0700
              Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-10 21:05 +0200
                Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-22 10:28 -0700
                Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-22 19:50 +0200
                Re: Why does this work on Xcode ??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-08-22 23:45 +0100
                Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-23 07:22 +0200
                Re: Why does this work on Xcode ??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-08-23 13:12 +0100
                Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-23 16:02 +0200
                Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-09-18 08:50 -0700
                Re: Why does this work on Xcode ??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-23 09:28 -0400
                Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-23 16:37 +0200
                Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-23 23:07 +0200
                Re: Why does this work on Xcode ??? Richard Damon <Richard@Damon-Family.org> - 2019-08-23 19:10 -0400
                Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-24 06:49 +0200
                Re: Why does this work on Xcode ??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-23 19:49 -0400
                Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-24 06:45 +0200
                Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-25 12:06 +0200
                Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-25 13:25 +0200
                Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-25 15:11 +0200
                Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-25 17:12 +0200
                Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-25 23:32 +0200
                Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-26 11:51 +0200
                Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-26 13:26 +0200
                Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-25 11:36 +0200
                Re: Why does this work on Xcode ??? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-25 13:27 +0200
                Re: Why does this work on Xcode ??? David Brown <david.brown@hesbynett.no> - 2019-08-25 15:15 +0200
                Re: Why does this work on Xcode ??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-26 00:43 -0400
                Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-24 04:58 -0700
                Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-26 09:53 -0700
                Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-28 18:03 -0700
          Re: Why does this work on Xcode ??? Öö Tiib <ootiib@hot.ee> - 2019-07-19 00:20 -0700
          Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-09 07:41 -0700
      Re: Why does this work on Xcode ??? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-24 19:49 +0200
    Re: Why does this work on Xcode ??? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-07-21 11:41 +0000
      Re: Why does this work on Xcode ??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-10 09:29 -0700

csiph-web