Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD)

On 10/05/2025 05:46, olcott wrote:

On 5/9/2025 10:12 PM, Richard Damon wrote:

On 5/9/25 10:47 PM, olcott wrote:

On 5/9/2025 9:39 PM, Richard Damon wrote:

On 5/9/25 10:20 PM, olcott wrote:

On 5/9/2025 9:15 PM, Richard Heathfield wrote:

On 10/05/2025 02:48, olcott wrote:

On 5/9/2025 8:32 PM, Richard Heathfield wrote:

On 10/05/2025 02:29, olcott wrote:

On 5/9/2025 8:15 PM, Richard Heathfield wrote:

On 10/05/2025 01:51, olcott wrote:

On 5/9/2025 7:29 PM, Richard Heathfield wrote:

On 10/05/2025 00:02, olcott wrote:

Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.

>
No, it's not. Correct emulation would entail accurately simulating the whole of DDD's behaviour.

>
It is stupidly wrong to require the complete
emulation of a non-terminating input.

>
It is touchingly naive to think you can persuade people to accept incomplete emulation as 'correct'.
>

>
If one instruction is emulated correctly
then is is dishonest to say that zero
instructions were emulated correctly.

>
Which instruction do you think is emulated correctly?

>

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)

>
>
Assumes facts not in evidence. Your HHH function is in a translation unit that contains a syntax error.
>

>
It is a truism that when DDD is emulated by HHH
according to the rules of the x86 language that
the first four instructions of DDD would be emulated
and then HHH would also be required to emulate
itself emulating DDD.
>

>
Nope, because by your definitions HHH can not correctly emulate that DDD, as it doesn't include the code for the HHH that it calls,

>
DDD are HHH are on the same memory space I told you this 50 times
DDD are HHH are on the same memory space I told you this 50 times
DDD are HHH are on the same memory space I told you this 50 times
DDD are HHH are on the same memory space I told you this 50 times
DDD are HHH are on the same memory space I told you this 50 times
>

>
But that doesn't mean that HHH is allowed to access it.
>

 Yes it does mean this.

Any competent C programmer (that /is/ your phrase, I think?) knows different.
When in order to gain access to DDD your code inspects the memory at the address pointed to by ptr P (after first casting to u32), it violates a 'shall' clause.
6.6(9) reads:
"An address constant is a null pointer, a pointer to an lvalue designating an object of static storage duration, or a pointer to a function designator; it shall be created explicitly using
the unary & operator or an integer constant cast to pointer type, or implicitly by the use of an expression of array or function type. The array-subscript [] and member-access . and -> operators, the address & and indirection * unary operators, and pointer casts may be used in the creation of an address constant, but the value of an object shall not be accessed by use of these operators."
In other words, you can't just not touch; you can't even look.
6.6(9) is not a constraint, so your compiler is not obliged to diagnose the flaw, but flaw it remains.
What does that mean?
4(2) reads: "If a ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a constraint is violated, the behavior is undefined."
Putting it another way, the C language standard absolves your compiler of any responsibility for translating your code into the behaviour you intended.
Putting it another nother way, you screwed up.
In programming, details can get terribly tedious. Perhaps you should leave that kind of thing to people who like that kind of thing.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within