"C: Everyone's favourite programming language isn't a programming language"

[Lynn McGuire]

"C: Everyone's favourite programming language isn't a programming language"
https://www.theregister.com/2022/03/23/c_not_a_language/

"Aria Beingessner, a member of the teams that implemented both Rust and
Swift, has an interesting take on some of those (and other) language's
problems – that C isn't a programming language anymore."

"There are many problems with the C language. To pick just a few: it can
be difficult to parse; there are competing and subtly incompatible
variants; and then there are the complex ways C defines and handles
integers and other variables."

"For instance, after much deliberation, a bunch of companies called the
Aspen Group settled on a programming model for 64-bit Unix and Unix-like
OSes called LP64, also known as "4/8/8". Unfortunately, 64-bit Microsoft
Windows uses a different model, called LLP64 or "4/4/8"."

https://techmonitor.ai/technology/aspen_group_hands_over_specification_proposals_overspill_to_xopen_will_implement_common_64_bit
and
https://wiki.wireshark.org/Development/Win64

"And that's before the issues around intmax_t, which the C99 standard
defines as "a signed integer type capable of representing any value of
any signed integer type." As software engineer JeanHeyd Meneide pointed
out, this gets complicated.
https://thephd.dev/intmax_t-hell-c++-c

Lynn

[Bonita Montero]

C lacks almost anything a modern programming language needs.
Having no fixed size native types is almost no problem.

[Chris M. Thomasson]

Ahhh. Remember way back when C++ was translated into C, then compiled?

[Mark Bluemel]

On Monday, 11 July 2022 at 06:44:31 UTC+1, Lynn McGuire wrote:
> "C: Everyone's favourite programming language isn't a programming language"
> https://www.theregister.com/2022/03/23/c_not_a_language/

As you'd remember if you actually read this newsgroup, we discussed this nearly 4 months ago when the article came out.

I doubt we need to cover the ground again.

[Bonita Montero]

They didn't manage to port exceptions to C and they stopped developing
cfront further.

[Ben Collver]

On 2022-07-11, Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
> Ahhh. Remember way back when C++ was translated into C, then compiled?

I seem to recall using cfront to build gperf to bootstrap GCC using the
extremely limited free-of-charge C compiler that came with HP-UX 9, i
think it was.

[Scott Lurndal]

We used cfront (2.1) to build a distributed operating system, first for the
Motorola 88100, and later for an intel based massivly parallel processor
(MPP) system in the mid 90's.

[Thiago Adams]

How did you debug code using cfront?
Did you debug C or C++ code?

[Lynn McGuire]

Do you have the date and time of the original posting ? I cannot find it.

I sure do not remember the posting but, I have slept since then.

Lynn

[Michael S]

From Mar 24, 2022, 5:36:11 PM to Apr 25, 2022, 9:05:03 PM
Your own post: Mar 28, 2022, 7:54:33 PM
https://groups.google.com/g/comp.lang.c/c/S5ygO3G3Jqg/m/usau9_tqAwAJ

[Scott Lurndal]

How did anyone debug code in 1990? It was an SMP operating system,
using the Chorus Systemes microkernel (written in C++) and a
distributed version of SVR4 (half in C++, half svr4 C code).

Like all good kernels, it had a built-in debugger. Type control-A
at the console serial terminal and the OS dropped into the debugger
(if enabled). Breakpoints, examining memory, stack tracebacks,
instruction disassembly, symbol table compiled into the kernel,
et alia.

Very similar to the kdb in-built kernel debugger I released to the linux mailing
list back in April of 1999. SUSE shipped it as part of the SLES releases and parts
of it still exist in the current linux kernel.

[Albert Arkwright]

On 11/07/2022 11:28, Mark Bluemel wrote:
> As you'd remember if you actually read this newsgroup, we discussed this nearly 4 months ago when the article came out.
>
> I doubt we need to cover the ground again.

Why don't you tell the same thing to that idiot called Olcott? He keeps
posting the same thing every two weeks and there are two guys here who
keep responding to him, instead of kill-filing him.

Olcott comes here because he is getting a response; Olcott won't go
anywhere unless people stop responding to him completely. Just ignore him;

[olcott]

I won't go anywhere until my work is validated whether or not anyone
responds. I just had a very extensive review (23 emails) by a leading
computer scientist.

Because of this review I was able to simplify my presentation so that
everyone here can easily verify that I have correctly refuted the
halting theorem on this pure software engineering basis:

understanding that the simulated P essentially calls simulating halt
decider H in infinite recursion such that the simulated P cannot
possibly terminate normally.

For any program H that might determine if programs
halt, a "pathological" program P, called with some
input, can pass its own source and its input to H
and then specifically do the opposite of what H
predicts P will do. *No H can exist that handles this case*
https://en.wikipedia.org/wiki/Halting_problem

*Any H that does handle this case refutes the halting theorem*

typedef void (*ptr)();
int H(ptr p, ptr i);

void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{
Output("Input_Halts = ", H(P, P));
}

Simulating halt decider H detects that its simulated input is
essentially calling H in infinite recursion. H aborts its simulation on
this basis and rejects this input as non-halting.

*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering


--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

[Lynn McGuire]

Sorry, that posting was not me.

Lynn

[Juha Nieminen]

In comp.lang.c++ Albert Arkwright <Albert.A...@gmail.com> wrote:
> Olcott comes here because he is getting a response; Olcott won't go
> anywhere unless people stop responding to him completely. Just ignore him;

Clearly you don't understand how obsessive compulsion works.

[Mark Bluemel]

I have some hope Lynn may take some notice. It's clear that Olcott won't.

[Vir Campestris]

There are degrees of OCD. By normal standards we've all got it... It's
not normal to be able to spend hours at a time staring at code on a
screen looking for that annoying little error.

But yes, some are worse than others.

Andy

[Bonita Montero]

I don't think he has OCD per se, because people like
that don't have that delusional sense of mission.

[Bonita Montero]

What it has in common with OCD is that Pete only sees details
and is unable to see the big picture. This is also something
that there is in common with circles of thought.

[olcott]

Do you really have to go around and around with all this ad hominen
stuff instead of simply validating that the simulated input to H(P,P)
would never terminate normally ???

typedef void (*ptr)();
int H(ptr p, ptr i);

void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{
Output("Input_Halts = ", H(P, P));
}

Simulating halt decider H detects that its simulated input is

essentially calling H in infinite recursion and would never terminate
normally. H aborts its simulation on this basis and rejects this input
as non-halting.

[olcott]

On 7/12/2022 7:29 AM, Bonita Montero wrote:

[olcott]

For any program H that might determine if programs halt, a
"pathological" program P, called with some input, can pass its own
source and its input to H and then specifically do the opposite of what

H predicts P will do. No *H can exist that handles this case*
https://en.wikipedia.org/wiki/Halting_problem

The big picture is that H(P,P) correctly determines that its input would
never terminate normally and H(P,P) does handle the above "impossible"
case.

[Freethinker]

On 12.07.22 01:14, olcott wrote:
> On 7/11/2022 4:13 PM, Albert Arkwright wrote:
>> On 11/07/2022 11:28, Mark Bluemel wrote:
>>> As you'd remember if you actually read this newsgroup, we discussed
>>> this nearly 4 months ago when the article came out.
>>>
>>> I doubt we need to cover the ground again.
>>
>> Why don't you tell the same thing to that idiot called Olcott? He keeps
>> posting the same thing every two weeks and there are two guys here who
>> keep responding to him, instead of kill-filing him.
>>
>> Olcott comes here because he is getting a response; Olcott won't go
>> anywhere unless people stop responding to him completely. Just ignore
>> him;
>>
>
> I won't go anywhere until my work is validated whether or not anyone
> responds. I just had a very extensive review (23 emails) by a leading
> computer scientist.
>
> Because of this review I was able to simplify my presentation so that
> everyone here can easily verify that I have correctly refuted the
> halting theorem on this pure software engineering basis:
>

OK, so now that we have easily verified that, would you please stop
posting this same thing millions of times?

[Keith Thompson]

Lynn clearly made an honest mistake, posting a relevant link without
realizing that it had been discussed previously.

Olcott is a crank (take a look at comp.theory if you're curious). They
are not comparable.

My personal solution is to killfile olcott in this newsgroup, so I never
see his posts here. What I do see is other posters replying to him.

If you must reply to olcott here, at least don't quote his entire
article and continue arguing with him.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[Lynn McGuire]

On 7/12/2022 1:01 PM, Keith Thompson wrote:
> Mark Bluemel <mark.b...@gmail.com> writes:
>> On Monday, 11 July 2022 at 22:16:29 UTC+1, Albert Arkwright wrote:
>>> On 11/07/2022 11:28, Mark Bluemel wrote:
>>>> As you'd remember if you actually read this newsgroup, we discussed this nearly 4 months ago when the article came out.
>>>>
>>>> I doubt we need to cover the ground again.
>>> Why don't you tell the same thing to that idiot called Olcott? He keeps
>>> posting the same thing every two weeks and there are two guys here who
>>> keep responding to him, instead of kill-filing him.
>>>
>>> Olcott comes here because he is getting a response; Olcott won't go
>>> anywhere unless people stop responding to him completely. Just ignore him;
>>
>> I have some hope Lynn may take some notice. It's clear that Olcott won't.
>
> Lynn clearly made an honest mistake, posting a relevant link without
> realizing that it had been discussed previously.

..
Thank you. I did not realize that the article was old and had already
been posted.

Lynn

[Michael S]

My bad.
Your names sound similar to non--Scotsman like myself.

[Chris M. Thomasson]

Yup! However, you are working toward a goal... To slay the error. A
little OCD can be "useful", from time to time...

> But yes, some are worse than others.

Big time. Some people have to wash their hands 42 times a day. No more,
no less.

[Manu Raju]

On 12/07/2022 21:01, Chris M. Thomasson wrote:
>
> Big time. Some people have to wash their hands 42 times a day. No
> more, no less.
>

At college we had a Muslim woman who cleaned the keyboard and laid blank
papers on chair before sitting down to use a computer. She was just
obsessed with silly things.

[Richard Damon]

And is WRONG, because you have just shown that a call to H(P,P) returns
0 and NOT get into infinite recursion, BECAUSE H is smarter than H gives
it credit for, and know enough to abort its simulation, but isn't smart
enough to know that it will do so.

The ONLY way that H is correct that the call fo H(P,P) inside P(P) leads
to infinite recursion is if H isn't actually a Pure Function, at which
point it fails to be the equivalent of the Turing Machine required by
the proof, or to be a proper decider.

Note, you needed to add the "essentially" to you statment, because it
isn't actually infinite recursion, at least not if H makes the decision
to ever abort its simulation.

H, to be correct, needs to judge P based on the ACTUAL H that exists,
not some close approximation like the essentially tries to let in.

[Richard Damon]

On 7/12/22 8:48 AM, olcott wrote:
> On 7/12/2022 7:46 AM, Bonita Montero wrote:
>> Am 12.07.2022 um 14:29 schrieb Bonita Montero:
>>> Am 12.07.2022 um 11:52 schrieb Juha Nieminen:
>>>> In comp.lang.c++ Albert Arkwright <Albert.A...@gmail.com> wrote:
>>>>> Olcott comes here because he is getting a response; Olcott won't go
>>>>> anywhere unless people stop responding to him completely. Just
>>>>> ignore him;
>>>>
>>>> Clearly you don't understand how obsessive compulsion works.
>>>
>>> I don't think he has OCD per se, because people like
>>> that don't have that delusional sense of mission.
>>
>> What it has in common with OCD is that Pete only sees details
>> and is unable to see the big picture. This is also something
>> that there is in common with circles of thought.
>
> For any program H that might determine if programs halt, a
> "pathological" program P, called with some input, can pass its own
> source and its input to H and then specifically do the opposite of what
> H predicts P will do. No *H can exist that handles this case*
> https://en.wikipedia.org/wiki/Halting_problem
>
> The big picture is that H(P,P) correctly determines that its input would
> never terminate normally and H(P,P) does handle the above "impossible"
> case.
>

Except that it doesn't, at least if it is trying to meet the actual
requirements of the Halting Problem.

Remember the DEFINITION:

H(M,x) accepts its input (returns 1) if M(x) will Halt (return), and
H(M,x) rejects its input (returns 0) if M(x) will NEVER Halt (return).

Thus H(P,P) to correctly return 0, means that P(P) must never return,
but by construction, P(P) WILL return if H(P,P) returns 0.

Your dishonest dodge of saying that the input to H(P,P) somehow doesn't
represent P(P) fails, because that says that P wasn't defined correctly,
as P was defined in the proof to be given an input so P asks H what it
will do when called with its input, and sincd your P(x) calls H(x,x),
athat means that P(P) calls H(P,P) which needs to mean that P is asking
about P(P), and not something else.

Thus, your claim is just an admission that you didn't write P correctly
(or are just lying that H is actually able to do what you claim).

[olcott]

For any program H that might determine if programs halt, a
"pathological" program P, called with some input, can pass its own
source and its input to H and then specifically do the opposite of what
H predicts P will do. *No H can exist that handles this case*
https://en.wikipedia.org/wiki/Halting_problem

It is not verified until it is understood that P and H implement the
classical halting problem "impossible input" template (as shown above)
and refutes this template in that H(P,P) correctly determines that its
input never terminates normally.

*This is the key software engineering that I need validated*
Most anyone here can easily verify that the simulated input to H(P,P)
cannot possibly terminate normally.

The next level of pure software engineering is that H(P,P) correctly
predicts that its simulated input cannot possibly terminate normally. It
may be the case that only the top 5% of software engineers can validate
this point.

typedef void (*ptr)();
int H(ptr p, ptr i);

void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{
Output("Input_Halts = ", H(P, P));
}

Simulating halt decider H detects that its simulated input is
essentially calling H in infinite recursion. H aborts its simulation on
this basis and rejects this input as non-halting.

The execution trace of function P() simulated by function H() shows:
(1) Function H() is called from P().
(2) With the same parameters to H().
(3) With no instructions in P() that could possibly escape this
infinitely recursive simulation.

*That was all of the software engineering that I need validated*

Halting problem proofs refuted on the basis of software engineering

[olcott]

On 7/12/2022 3:01 PM, Chris M. Thomasson wrote:
> On 7/12/2022 3:27 AM, Vir Campestris wrote:
>> On 12/07/2022 10:52, Juha Nieminen wrote:
>>> In comp.lang.c++ Albert Arkwright <Albert.A...@gmail.com> wrote:
>>>> Olcott comes here because he is getting a response; Olcott won't go
>>>> anywhere unless people stop responding to him completely. Just
>>>> ignore him;
>>>
>>> Clearly you don't understand how obsessive compulsion works.
>>
>> There are degrees of OCD. By normal standards we've all got it... It's
>> not normal to be able to spend hours at a time staring at code on a
>> screen looking for that annoying little error.
>
> Yup! However, you are working toward a goal... To slay the error. A
> little OCD can be "useful", from time to time...
>

It works for Elon Musk.

>
>> But yes, some are worse than others.
>
> Big time. Some people have to wash their hands 42 times a day. No more,
> no less.
>

[Richard Damon]

And your property (3) is incorrect the way you use it. The CORRECT
version of (3) looks ALL the way through the loop, which includes in H,
and will find the condtional there.

If you omit that, then (3) is just incorrect, as the fact that P(P)
Halts when H(P,P) returns 0 proves.

You don't want to detect "essentially" in infinite recursion, but need
to detect in ACTUAL infinite recursion.

If the infinite recursion is actual, then H(P,P) is also in infinite
recursion and thus never answers and thus fails to be a decider.

If the infinite recursion isn't actual, then it doesn't matter that it
was close, and only the smarts of H stopped it from being so, as that
smarts in H was PART of the algorithm of P, by the virtual of it calling
H to ask the question, and the P gets "credit" for those smarts too.

If one H has the smarts, but the one called by P doesn't, then H fails
to be the needed Pure Function, so you are shown to be incorrect.

[olcott]

H(P,P) correctly predicts that its input cannot possibly terminate
normally. (I have better words now).

[Richard Damon]

Except that the program represented by the input, P(P) DOES terminate
normally if H(P,P) returns 0.

If H(P,P) isn't asking about the behavior of P(P), then you have defined
your P incorrect and you whole proof is worthless as you aren't working
on the needed case.

Remember, P is defined to as H about what it will do with its input.

THAT is the "impossible" program.

If H(P,P) isn't asking about P(P), then since that is what P is doing,
it was defined wrong.

if that IS what it is asking about, then H is wrong, since P(P) will
halt when H(P,P) returns 0.

IF one H(P,P) returns 0, but the H(P,P) that P(P) calls doesn't, then H
is not a pure function.

If you want to still try to claim it is, what is the first x86
instruction in the ACTUAL EXECTUION of the H(P,P) called by main and in
the ACTUAL EXECUTION of the H(P,P) called by P(P) which have different
results.

Since H is a pure function, and the inputs are the same, the inputs to
the instruction needs to be the same too, or this isn't the first x86
instruction with a difference, and you need to go back to the point
where that difference was created, or admit that they are looking at
something that wasn't part of the input, and thus H isn't a pure function.