| Deutsch English Français Italiano |
|
<v57155$onl3$10@i2pn2.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: Can you please verify that the analysis of these C functions is
correct?
Date: Sat, 22 Jun 2024 13:20:37 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v57155$onl3$10@i2pn2.org>
References: <v4obkj$f9p5$2@dont-email.me>
<v4pg5p$morv$1@raubtier-asyl.eternal-september.org>
<v54s1p$3boc5$1@dont-email.me> <v5684p$3n50u$1@dont-email.me>
<v56gs1$3olbi$3@dont-email.me> <v56lar$onl4$7@i2pn2.org>
<v56uij$3rako$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 22 Jun 2024 17:20:37 -0000 (UTC)
Injection-Info: i2pn2.org;
logging-data="810659"; mail-complaints-to="usenet@i2pn2.org";
posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <v56uij$3rako$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 4487
Lines: 94
On 6/22/24 12:36 PM, olcott wrote:
> On 6/22/2024 8:58 AM, Richard Damon wrote:
>> On 6/22/24 8:42 AM, olcott wrote:
>>> On 6/22/2024 5:13 AM, Richard Harnden wrote:
>>>> On 21/06/2024 22:41, olcott wrote:
>>>>> On 6/17/2024 9:11 AM, Bonita Montero wrote:
>>>>>> Am 17.06.2024 um 05:47 schrieb olcott:
>>>>>>> To understand this analysis requires a sufficient knowledge of
>>>>>>> the C programming language and what an x86 emulator does.
>>>>>>>
>>>>>>> typedef void (*ptr)();
>>>>>>> int H0(ptr P);
>>>>>>>
>>>>>>> void Infinite_Loop()
>>>>>>> {
>>>>>>> HERE: goto HERE;
>>>>>>> }
>>>>>>>
>>>>>>> void Infinite_Recursion()
>>>>>>> {
>>>>>>> Infinite_Recursion();
>>>>>>> }
>>>>>>>
>>>>>>> void DDD()
>>>>>>> {
>>>>>>> H0(DDD);
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> H0(Infinite_Loop);
>>>>>>> H0(Infinite_Recursion);
>>>>>>> H0(DDD);
>>>>>>> }
>>>>>>>
>>>>>>> Every C programmer that knows what an x86 emulator is knows that
>>>>>>> when H0
>>>>>>> emulates the machine language of Infinite_Loop,
>>>>>>> Infinite_Recursion, and
>>>>>>> DDD that it must abort these emulations so that itself can terminate
>>>>>>> normally.
>>>>>>>
>>>>>>> When this is construed as non-halting criteria then simulating
>>>>>>> termination analyzer H0 is correct to reject these inputs as non-
>>>>>>> halting.
>>>>>>>
>>>>>>> *My POD24 diagnosis is reducing the time I have left to work on
>>>>>>> this*
>>>>>>> Validation of POD24 as a robust early clinical end point of poor
>>>>>>> survival in FL from 5225 patients on 13 clinical trials
>>>>>>> https://pubmed.ncbi.nlm.nih.gov/34614146/
>>>>>>>
>>>>>>
>>>>>> Everything correct, no further questions allowed.
>>>>>>
>>>>>
>>>>> Thanks for your help on this. The Liars on comp.theory are
>>>>> even lying about what you actually said.
>>>>>
>>>>
>>>> Pretty sure that Bonita was taking the piss.
>>>>
>>> I would say that this would indicate that you are insufficiently
>>> competent with the C programming language.
>>>
>>
>> It seems you are the one that doesn't know the C programing language.
>> After all, you didn't know about the unordering of sub-expressions, or
>> that this can lead to undefined behavior.
>
> It seems pretty stupid to allow gaps in the semantics of C++ programs.
> Simply specify that the order of evaluation is left to right unless:
> (a) Otherwise specified such as operator precedence rules.
> (b) Derives the same result as left to right ordering.
>
Nope. The problem is that such a rule breaks the fundamental design
decisions that the goal is to make it possible to create as efficient
machine code as possible.
If you need the left to right evaluation order, there are ways to write
the code to make that happen.
One of the fundamental design decisions in the language is that it
trusts the programmer to know the rules, and will strive for the fastest
code possible.
C++ made a special rule for the << operator because the gain for its use
as an output was high enough, and the cost as a normal shift operator
was rarely high (and normally hidden by the "as if" rule) so it was done
there.
There are too many cases for the more general arguement that causes
measurable speed differences.