Re: Bad faith and dishonesty

On 5/25/25 4:48 PM, olcott wrote:

On 5/25/2025 3:28 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 5/25/2025 11:59 AM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 5/25/2025 10:49 AM, Fred. Zwarts wrote:

Op 25.mei.2025 om 16:36 schreef olcott:

On 5/25/2025 1:21 AM, Mikko wrote:

On 2025-05-24 01:20:18 +0000, Mr Flibble said:

>

So much bad faith and dishonesty shown in this forum that myself and
Peter
Olcott have to fight against.

>

Everything here seems to be dishonesty and protests against dishonesty.
If you could remove all dishonesty the protests woud stop, too, and
nothing would be left.

>
>

_DDD()
[00002192] 55             push ebp
[00002193] 8bec           mov ebp,esp
[00002195] 6892210000     push 00002192
[0000219a] e833f4ffff     call 000015d2  // call HHH
[0000219f] 83c404         add esp,+04
[000021a2] 5d             pop ebp
[000021a3] c3             ret
Size in bytes:(0018) [000021a3]

>

Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.

Why repeating this bug in HHH?

>

That everyone that understands these things
sees that there is no bug ....

>

That is untrue.  The bug is clear to anybody who understands C code.

>
>

OK then to prove that you are not a damned liar
(you won't do this because you know that you are a liar)
show how DDD simulated by HHH according to the rules
of the x86 language reaches its own "ret" instruction
final halt state.

>
You've got a wierd notion of what it means to be a liar.
>

FIND THE BUG ASSHOLE !!!

>
You're not a nice person.  The bug in question has been pointed out many
times, in particular by Fred.
>

 I am not going to be a nice person to those that
are lying about my work. Being a nice person in
this case is weakness and invitation to more abuse.

But since you have been proven to be a liar, nice was never in the picture.

 _DDD()
[00002192] 55             push ebp
[00002193] 8bec           mov ebp,esp
[00002195] 6892210000     push 00002192
[0000219a] e833f4ffff     call 000015d2  // call HHH
[0000219f] 83c404         add esp,+04
[000021a2] 5d             pop ebp
[000021a3] c3             ret
Size in bytes:(0018) [000021a3]

Which can't be the input to a program decider, because it isn't a program.
Your repeated xlaims that you can make it an input, just proves that you are just a pathological liar that doesn't know what he is talking about, and doesn't care. The fact you haven't replied to this fact in all this time shows that you know you are wrong here, but haven't thought of a dishonest dodge to get around the problem, because you have just burned down all the bridges trying to handle the other problems pointed out.

 Alluded to is not the same as pointing the
exact machine address where DDD emulated by
HHH breaks the rules of the x86 language
such that DDD emulated by HHH reaches its
own "ret" instruction.
 

Every time HHH doesn't continue with the HHH that is in the input when it encounders the call HHH code in the input.
THis is hard to do since the code for HHH isn't in the input.
Claiming to look as something else in memory just says you are lying about HHH emulating the DDD given as the input,
Sorry, you just don't understand the meaning of the words, and create wrong definitions to try to get around your problems, which just shows you are a stupid liar.