Monday, November 14, 2022

Digest for comp.lang.c++@googlegroups.com - 25 updates in 4 topics

Bonita Montero <Bonita.Montero@gmail.com>: Nov 14 10:03PM +0100

To dispel the doubts that Windows Stacks is overcommitted, I wrote a
small program that creates threads recursively and outputs every second
how many threads have been created so far. Unless you set something else
in the linker, Windows reserves one megabyte of address space for each
new stack. I can easily create 250,000 threads on my machine with this
program, which then consumes 250 gigabytes of address space. If all this
were committed without being physically assigned, then I would need at
least a lot of swap, which would keep the available swap in case the
committed pages were also written.
 
Here's the code:
 
#include <iostream>
#include <vector>
#include <thread>
#include <functional>
#include <semaphore>
#include <chrono>
#include <syncstream>
 
using namespace std;
using namespace chrono;
 
int main()
{
vector<jthread> threads;
threads.reserve( 1'000'000 );
function<void ()> threadFn;
atomic_uint32_t n;
counting_semaphore semFinish( 0 );
steady_clock::time_point start = steady_clock::now();
atomic_uint lastElapsed = 0;
auto create = [&]()
{
try
{
threads.emplace_back( threadFn );
++n;
unsigned elapsed = (unsigned)duration_cast<seconds>(
steady_clock::now() - start ).count();
if( elapsed > lastElapsed )
osyncstream( cout ) << n << endl,
lastElapsed = elapsed;
semFinish.acquire();
}
catch( system_error const & )
{
semFinish.release( n );
}
};
(threadFn = create)();
threads.resize( 0 );
cout << n << endl;
}
T <T@invalid.invalid>: Nov 14 12:39AM -0800

Hi All,
 
I am trying to write an interface to wit Raku.
I do have a time understanding C++.
 

https://learn.microsoft.com/en-us/windows/win32/api/vds/nf-vds-ivdspack-queryvolumes
 
What is `[out] IEnumVdsObject **ppEnum`.
 
C++
 
HRESULT QueryVolumes(
[out] IEnumVdsObject **ppEnum
);
 
 
Is this an array of 32 bit Integers? Where is
this length?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 14 01:29AM -0800

On 11/14/2022 12:39 AM, T wrote:
 
> Is this an array of 32 bit Integers?  Where is
> this length?
 
Afaict, it means the function can store a resulting pointer in ppEnum,
perhaps depending on HRESULT, don't know off hand.
"Öö Tiib" <ootiib@hot.ee>: Nov 14 01:39AM -0800

On Monday, 14 November 2022 at 10:39:38 UTC+2, T wrote:
> I do have a time understanding C++.
 
> https://learn.microsoft.com/en-us/windows/win32/api/vds/nf-vds-ivdspack-queryvolumes
 
> What is `[out] IEnumVdsObject **ppEnum`.
 
Not standard C++. The [out] is simply MS extension/notation that ppEnum is
pointer to output parameter that is pointer of interface. So pointer of pointer.
 
> );
 
> Is this an array of 32 bit Integers? Where is
> this length?
 
No arrays there. Pointer of pointer to single interface.
It is typical MS COM interface calling concept so you use it like that:
 
IVdsPack* pVp = get_that_interface_from_somewhere();
IEnumVdsObject* pEvo;
HRESULT res = pVp->QueryVolumes(&pEvo);
// check if res was good and handle issues
// if good then use pEvo->methods documented there:
// <https://learn.microsoft.com/en-us/windows/win32/api/vdshwprv/nn-vdshwprv-ienumvdsobject>
T <T@invalid.invalid>: Nov 14 01:46AM -0800

On 11/14/22 01:29, Chris M. Thomasson wrote:
>> this length?
 
> Afaict, it means the function can store a resulting pointer in ppEnum,
> perhaps depending on HRESULT, don't know off handHi Chris,
 
 
I get it now. **ppEnum is a C style pointer
to a structure defined by HSRESULT.
 
Now to figure out what HSRESULT is.
 
Thank you!
 
-T
T <T@invalid.invalid>: Nov 14 01:48AM -0800

On 11/14/22 01:39, Öö Tiib wrote:
> // check if res was good and handle issues
> // if good then use pEvo->methods documented there:
> // <https://learn.microsoft.com/en-us/windows/win32/api/vdshwprv/nn-vdshwprv-ienumvdsobject>
 
I am confused. :'(
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 14 01:52AM -0800

On 11/14/2022 1:46 AM, T wrote:
>> perhaps depending on HRESULT, don't know off handHi Chris,
 
> I get it now.  **ppEnum is a C style pointer
> to a structure defined by HSRESULT.
 
take:
 
IEnumVdsObject **ppEnum
 
Well, that is pointer to a pointer.
 
So, think of: typing, please try to forgive any typos:
 
int a = 0;
int* p_a = &a;
 
int* p_b = nullptr;
 
int** foo = nullptr;
 
foo = &p_b;
*foo = &p_a;
 
Now p_a == p_b, the both point at a ala (&a)...
 
;^)
 
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 14 01:55AM -0800

On 11/14/2022 1:52 AM, Chris M. Thomasson wrote:
 
> int** foo = nullptr;
 
> foo = &p_b;
> *foo = &p_a;
^^^^^^^^^^^^^^^
 
GOD DAMN IT!!
 
That should be *foo = p_a, shit. That's what I get wrt typing code into
a damn newsreader!
 
So sorry for that boneheaded mistake. ;^o
 
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 14 02:01AM -0800

On 11/14/2022 1:48 AM, T wrote:
>> //
>> <https://learn.microsoft.com/en-us/windows/win32/api/vdshwprv/nn-vdshwprv-ienumvdsobject>
 
> I am confused.  :'(
 
int a = 0;
int* p_a = &a;
int* p_b = nullptr;
 
int** pp = &p_b;
*pp = p_a;
 
p_b == p_a
 
I think I got it right typing directly in the newsreader. :^)
"Öö Tiib" <ootiib@hot.ee>: Nov 14 02:30AM -0800

On Monday, 14 November 2022 at 11:48:27 UTC+2, T wrote:
 
> I get it now. **ppEnum is a C style pointer
> to a structure defined by HSRESULT.
 
> Now to figure out what HSRESULT is.
 
No "HSRESULT" there. It is HRESULT. 32-bit signed integer encoding
long list of values ... for that method the potential values are mentioned
in the very page you gave. E_INVALIDARG, E_OUTOFMEMORY,
S_OK, VDS_E_PROVIDER_CACHE_CORRUPT.
"Öö Tiib" <ootiib@hot.ee>: Nov 14 02:33AM -0800

On Monday, 14 November 2022 at 11:49:12 UTC+2, T wrote:
> > // if good then use pEvo->methods documented there:
> > // <https://learn.microsoft.com/en-us/windows/win32/api/vdshwprv/nn-vdshwprv-ienumvdsobject>
 
> I am confused. :'(
 
I am not psychic. Elaborate what you understand, what you do
not. Default is nothing ... but that takes about half a year of
teaching to compensate ... that we can't do in Usenet thread.
T <T@invalid.invalid>: Nov 14 02:38AM -0800

On 11/14/22 02:30, Öö Tiib wrote:
> long list of values ... for that method the potential values are mentioned
> in the very page you gave. E_INVALIDARG, E_OUTOFMEMORY,
> S_OK, VDS_E_PROVIDER_CACHE_CORRUPT.
 
 
This is their list of return codes:
 
https://learn.microsoft.com/en-us/windows/win32/vds/virtual-disk-service-common-return-codes
 
I am not wrapping my head around how one crams all
those codes into one 32 bit integer.
 
By "32-bit signed integer", do you mean it can
have a negative value (as opposed to a cardinal)?
"Öö Tiib" <ootiib@hot.ee>: Nov 14 02:48AM -0800

On Monday, 14 November 2022 at 12:39:50 UTC+2, T wrote:
> > S_OK, VDS_E_PROVIDER_CACHE_CORRUPT.
> This is their list of return codes:
 
> https://learn.microsoft.com/en-us/windows/win32/vds/virtual-disk-service-common-return-codes
 
Those are special values for whole subsystem. The methods return
still usually S_OK for when all is good.
 
> I am not wrapping my head around how one crams all
> those codes into one 32 bit integer.
 
One at time. It is return value of method. So each method
call produces only one value of HRESULT.
 
> By "32-bit signed integer", do you mean it can
> have a negative value (as opposed to a cardinal)?
 
Yes. Basically zero is full success named S_OK, positive values are
indicating generally positive outcome and negative values are errors.
Maybe that is simpler explanation:
<https://en.wikipedia.org/wiki/HRESULT>
T <T@invalid.invalid>: Nov 14 02:59AM -0800

On 11/14/22 02:33, Öö Tiib wrote:
 
> I am not psychic. Elaborate what you understand, what you do
> not. Default is nothing ... but that takes about half a year of
> teaching to compensate ... that we can't do in Usenet thread.
 
 
This is what I think I understand and do not.
 
`*` is a C pointer
 
`**` is a C pointer that points to another
C pointer (AAAHHH!)
 
`HRESULT QueryVolume` is not `HRESULT = QueryVolume(...)`.
It is not a return value from a function.
 
`HRESULT` is telling me that is the structure of what
the pointer to a pointer (**ppEnum) points to.
 
I have no idea what `HRESULT` is. I am not sure
how this applies:
https://en.wikipedia.org/wiki/HRESULT#Data_Structure
 
I am after both
VDS_E_VOLUME_NOT_HEALTHY (0x8004243EL), and
VDS_E_VOLUME_NOT_A_MIRROR (0x80042445L)
 
Does the "L" stand from 32 bit integer? (To me,
64 bits is "Long".)
 
And is bit 31 is used for "Severity" it look a
lot and unsigned integer (cardinal) to me.
"Öö Tiib" <ootiib@hot.ee>: Nov 14 03:33AM -0800

On Monday, 14 November 2022 at 13:00:13 UTC+2, T wrote:
 
> `*` is a C pointer
 
> `**` is a C pointer that points to another
> C pointer (AAAHHH!)
 
Correct.
 
 
> `HRESULT QueryVolume` is not `HRESULT = QueryVolume(...)`.
> It is not a return value from a function.
 
It is, QueryVolume is method of IVdsPack interface.
 
 
> `HRESULT` is telling me that is the structure of what
> the pointer to a pointer (**ppEnum) points to.
 
No.
You get the value like I posted:
 
HRESULT res = pVp->QueryVolumes(&pEvo);
 
Where pVp is pointer to IVdsPack interface.
 
 
> I have no idea what `HRESULT` is.
 
It is 32 bit signed integer.
 
> I am not sure
> how this applies:
> https://en.wikipedia.org/wiki/HRESULT#Data_Structure
 
It is just meaning of individual bits in HRESULT value.
Those bits do not generally matter unless you want to
make some kind of very generic handling of HRESULT
value space.
 
> VDS_E_VOLUME_NOT_A_MIRROR (0x80042445L)
 
> Does the "L" stand from 32 bit integer? (To me,
> 64 bits is "Long".)
 
The L means signed long. MS is not caring what rest of
the world thinks, as it is very rich and powerful company.
For MS signed long is 32 bits until MS decides otherwise,
and the C++ standard allows that freedom.
 
> And is bit 31 is used for "Severity" it look a
> lot and unsigned integer (cardinal) to me.
 
As result of QueryVolumes you should perhaps just check
that if res == S_OK then you use gained IEnumVdsObject
interface, if not then refuse to continue with error
message.
"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Nov 14 02:34PM +0100

On 14 Nov 2022 09:39, T wrote:
 
> HRESULT QueryVolumes(
>   [out] IEnumVdsObject **ppEnum
> );
 
What does a deprecated Microsoft interface for disk management have to
do with writing an "interface to wit Raku"?
 
(As I understand it Raku is sort of Perl 2, <url:
https://en.wikipedia.org/wiki/Raku_(programming_language)>).
 
For that matter what does "wit" stand for, and what exactly do you mean
by that?
 
Are you trying to write some Windows-specific library to be called from
Raku?
 
If so what?
 
 
> Is this an array of 32 bit Integers?  Where is this length?
 
As an ordinary C++ function you would have had something like
(considering that this is a member function of IVdsPack)
 
auto create_volumes_iterator() const
-> unique_ptr<IEnumVdsObject>;
 
But while the COM technology is /based/ on early C++, all the COM stuff
offered by the Windows API must be C compatible. They solved the problem
of calling C++ member functions from C, by specifying a binary level
memory layout (ABI) for COM objects, which is what COM is most about: a
known ABI. But C can't consume things like smart pointers, and though C
has `const` it isn't comfortable with C++ style `const`, so for C
compatibility one would have to express the function like this:
 
auto create_volumes_iterator() -> IEnumVdsObject* ;
 
Or with old C syntax:
 
IEnumVdsObject* create_volumes_iterator();
 
But this still has a hidden C++ specific dependency, namely that any
error is communicated via exception throwing. That won't do for COM.
It's not only that C lacks exceptions: COM was designed for use via any
programming language, and these languages don't do C++ exceptions.
 
So, COM communicates failure via the function result type, which must
always be an `HRESULT`, a structured 32-bit failure reporting value sort
of like the one used (as I recall) in VMS:
 
HRESULT create_volumes_iterator( IEnumVdsObject*& p_iterator );
 
But oh I forgot, C has no references to use for out parameters. So you
need to express that as a pointer to a pointer:
 
HRESULT create_volumes_iterator( IEnumVdsObject** pp_iterator );
 
And, I also forgot, to adhere to the COM spirit you need to Microsoftify
the function name:
 
HRESULT QueryVolumes( IEnumVdsObject** pp_iterator );
 
Now instead of the name signifying what this function does, it signifies
what you intend to do with the result, or perhaps a part of what the
function does on the inside (e.g. a side effect such as perhaps waiting
ten to fifteen seconds for the spinning up of disks, expressed subtly
via the name instead of documented). Smart. If one is into Microsoft-ish
obfuscation of things, e.g., if one works for Microsoft.
 
Anyway, an HRESULT is a not a simple error code, in particular 0 denotes
success not failure (it's the value S_OK), so in order to check the
HRESULT for success or failure you can and should preferentially use
macros like SUCCEEDED and FAILED, so a call can look like this:
 
void foo( IVdsPack* p_vds_pack )
{
IEnumVdsObject* p_iterator;
const HRESULT hr = p_vds_pack->QueryVolumes( &p_iterator );
if( not SUCCEEDED( hr ) ) {
throw "Alabama!"; // Ref. movie "Crimson Tide", 1995.
}
// Use p_iterator to iterate over volumes. Then:
p_iterator->Release();
}
 
However, throwing exceptions is not very compatible with manual release
calls like the last statement above; you risk memory and resource
leakage. Instead of such risky raw interface pointer and manual release
calls you can use a COM /smart pointer/ that guarantees proper release
calls. There is an abundance of such smart pointer classes, including
one supplied with Visual C++, <url:
https://learn.microsoft.com/en-us/cpp/cpp/com-ptr-t-class?view=msvc-170>.
 
All this said, do heed the statements in the documentation that say that
something (e.g. this disk management functionality) is deprecated and
directs you to newer stuff; use the newer stuff instead.
 
- Alf
"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Nov 14 02:44PM +0100

On 14 Nov 2022 14:34, Alf P. Steinbach wrote:
> in particular 0 denotes success not failure (it's the value S_OK)
 
I /meant/ to write, ❝in particular 1 denotes success not failure (it's
the value S_FALSE)❞
 
It's like the most common typo, namely transposition of characters, just
that this is the most common thinko, transposition of facts/thoughts.
 
Hm!
 
- Alf (possibly unclear in ze head b/c can't take my diabetes medicine
due to upcoming invasive heart/blood vessel check).
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Nov 14 09:12AM -0800

"Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
[...]
> (As I understand it Raku is sort of Perl 2, <url:
> https://en.wikipedia.org/wiki/Raku_(programming_language)>).
[...]
 
The current version of Perl is Perl 5 (the latest release is 5.36).
 
The language now called Raku was originally called Perl 6. It was
intended to be the next version of Perl, but it diverged enough that it
was decided to rename it. (There's more to the history, but this isn't
the place to discuss it.)
 
(There was a Perl 2, released in 1988.)
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
T <T@invalid.invalid>: Nov 14 11:02AM -0800

On 11/14/22 05:34, Alf P. Steinbach wrote:
> do with writing an "interface to wit Raku"?
 
> (As I understand it Raku is sort of Perl 2, <url:
> https://en.wikipedia.org/wiki/Raku_(programming_language)>).
 
Perl 6 was renamed Raku
 
> For that matter what does "wit" stand for, and what exactly do you mean
> by that?
 
"Wit" was a typo. I should have been "with"
 
> Are you trying to write some Windows-specific library to be called from
> Raku?
 
Yes. I am using the nightmare "Native Call".
They could not have made it more difficult, but I
usually make it work.
 
https://docs.perl6.org/language/nativecall
 
I am trying to avoid having to run as administrator
when calling Diskpart --> list volume
 
"Listing" should not require administrator privileges,
but Windows is not as smart as Linux ("dnf" lets
query without being root, etc.).
 
 
> If so what?
 
 
https://learn.microsoft.com/en-us/windows/win32/api/vds/nf-vds-ivdspack-queryvolumes
 
And I just found out that I have to also
be administrator to call IEnumVdsObject,
so poop (not my exact word). Meaning that
I am going to have to run as administrator
anyway, so I do not need to have this
question answered anymore, other that
for leaning for the future.
 
So everyone can stop trying to teach me
now. And thank you for all your gracious
effort!
 
A pointer to a pointer. Geez! I am going
to write that up in my C notes that I use
with native call.
T <T@invalid.invalid>: Nov 14 11:10AM -0800

On 11/14/22 03:33, Öö Tiib wrote:
> that if res == S_OK then you use gained IEnumVdsObject
> interface, if not then refuse to continue with error
> message.
 
 
I just found out that `IVdsPack` also has
to be run as an administrator. I was trying
to get Diskpart --> list volume without
being an administrator. (Diskpart is
the only call that will give you a mirrored
volume's status.)
 
So I will have to run as administrator
anyway and I do not need this question
answered anymore. I will just call Diskpart.
Poop!
 
Thank you all for your gracious assistance!
 
-T
 
Queries should not have to be run as administrator.
Windows is what it is. I would not have a job
without with poor quality.
David Brown <david.brown@hesbynett.no>: Nov 14 10:09AM +0100

On 13/11/2022 03:00, Keith Thompson wrote:
 
> An unsigned time_t makes it impossible to represent times before 1970.
> Not all software is going to care about that, but in my opinion it's
> an unacceptable price.
 
For the solid majority of programs that use Unix epoch times, unsigned
would be fine. There can't be many programs that need dates before 1970
but are happy to think the world started in late 1901 - Unix epoch times
are almost always considered as time after 01.01.1970. However, as long
as there are /some/ programs that need negative epoch times, you can't
break that functionality.
 
 
> There are still 32-bit systems and environments. On my 64-bit Ubuntu
> system I can compile with `gcc -m32` and get 32-bit pointers and time_t.
 
I think I heard that the next Ubuntu would not have 32-bit libraries in
its normal repositories any more. That won't stop them being available
for those that need them. (I think I only need 32-bit libraries on
Linux in connection with Wine and 32-bit Windows programs.)
 
More modern Linux (since kernel 5.6, according to Wikipedia) systems
have 64-bit time_t even on 32-bit builds.
 
> But since C and C++ require support for 64-bit integers anyway, it
> should be practical to require 64-bit time_t even on 32-bit systems.
 
Yes.
 
> (Not sure about Fortran.)
 
(That's better than me - I haven't a clue about Fortran!)
 
 
> The real problem is going to be 32-bit (or smaller) embedded systems
> whose software can't be updated. On the other hand, a lot of such
> systems probably don't care what time it is.
 
Pretty much any non-trivial embedded system will care a bit about time,
but usually only relative time - blink every second, send a message
every hour, or whatever. These might have a 32-bit second counter, but
are more likely to have millisecond counters or higher resolution. And
they generally take overflow into account by simply subtracting start
times and current times (generally assuming two's complement wrapping
overflow...). Millisecond 32-bit counters overflow after 49 days, so it
is something you think about more than 69 year overflows.
 
Small embedded systems which also track the date will generally not do
so using Unix epoch timestamps - it's a lot easier to hold a structure
with second, minute, hour, day, month, year fields and update it. That
avoids all the mess of locales and time and date conversions.
 
Bigger embedded systems are more likely to be updatable - though that
does not mean they /will/ be updated. Manufacturers might provide
updates for a few years or while the product is still being made and
sold, but after that they may not bother.
 
There will be some systems that are a problem - but I do not expect it
to be a widespread issue.
gazelle@shell.xmission.com (Kenny McCormack): Nov 14 09:14AM

In article <tkrao1$1ghql$1@redfloyd.dont-email.me>,
>> On the other hand, a lot of such
>> systems probably don't care what time it is.
 
>Why am I thinking of Chicago now?
 
03:35, 03;34, whatever...
 
--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Voltaire
Klaus Wacker <klaus.w.wacker@t-online.de>: Nov 14 01:47PM

In comp.lang.fortran Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
[...]
 
> An unsigned time_t makes it impossible to represent times before 1970.
> Not all software is going to care about that, but in my opinion it's
> an unacceptable price.
 
I read somewhere that the reason for a signed time_t was mainly that
this type was nor just used for time stamps, but also for time
differences.
 
--
Klaus Wacker klaus.w.wacker@t-online.de
51°29'7"N 7°25'7"E
Thomas Koenig <tkoenig@netcologne.de>: Nov 14 02:09PM


> Yes.
 
>> (Not sure about Fortran.)
 
> (That's better than me - I haven't a clue about Fortran!)
 
Fortran has the DATE_AND_TIME inrinsic, which returns the the date
and time in calendar format, either as YYYYMMDD and HHMMSS.SSS and
[+/-] HHMM for the zoneif you chose character arguments, or as an
array of integer with the same info.
 
The library is supposed to take care of how to get the value
from the operating system, user programs need not bother.
 
There are also non-standard extensions which mimic system
behavior, but those should be avoided, at least in new code.
olcott <polcott2@gmail.com>: Nov 13 10:55PM -0600

Every rebuttal of my work in the last two years only has rejecting the
notion of a simulating halt decider as its basis.
 
Once a simulating halt decider is accepted then ordinary software
engineering proves that H correctly determines the halt status of D.
 
MIT Professor Michael Sipser (author of the best selling book on the
theory of computation) has agreed that the following verbatim paragraph
is correct (he has not agreed to anything else):
 
If simulating halt decider H correctly simulates its input
D until H correctly determines that its simulated D would
never stop running unless aborted then H can abort its
simulation of D and correctly report that D specifies a
non-halting sequence of configurations.
 
void D(void (*x)())
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}
 
int main()
{
Output("Input_Halts = ", H(D, D));
}
 
(A) The definition of a UTM proves that the behavior of a correctly
simulated input is a correct halt deciding basis for a simulating halt
decider.
 
(B) The line-by-line execution trace of D simulated by H exactly matches
what the line-by-line x86 source code of D specifies conclusively proves
that the simulation of D by H is correct.
 
(C) D correctly simulated by H would never reach its final state and
terminate normally.
 
(X) A&B&C form the necessary and sufficient conditions for H to reject D
as non-halting.
 
*My reviewers don't seem to be able to grasp this essential detail*
When A&B&C entails X and A&B&C then X is entailed no matter what or who
disagrees. My reviewers know this this logic is correct yet have failed
to notice that A&B&C entails X.
 
*A&B&C also meets the Sipser approved criteria*
H correctly simulates its input D until H correctly determines
that its simulated D would never stop running unless aborted.
 
*Simulating Halt Decider Applied to the Halting Theorem*
https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
 
--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)