| olcott <NoOne@NoWhere.com>: May 12 03:45PM -0500 On 5/12/2021 6:46 AM, Richard Damon wrote: > you have some program that creates a 'Turing Complete' environment > taking inputs of Machine Equivalents, and runs them as their Turing > Equivalent. Right now I am only evaluating the software engineering of a partial halt decider written in C that examines x86 machine language execution traces of a simulation of its input on the following basis: Every partial halt decider H that that bases its halting decision on simulating its input P until criteria (1)(2)(3) are met by the execution trace of P correctly decides not halting on input P. If the execution trace of function P() [i.e. the input to H] shows: (1) Partial halt decider H is called twice in sequence from the same machine address of P. (2) with the same machine address parameters to H (3) with no conditional branch or indexed jump instructions in P then H correctly decides not halting on P. The proof that I am correct is the impossibility of creating a counter-example written in C that meets the (1)(2)(3) criteria, halts, and H never stops simulating P. http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Pawel Por <porparek@gmail.com>: May 12 12:56PM -0700 Thank you for an answer. You're right I've posted to comp.lang.c++. |
| Real Troll <real.troll@trolls.com>: May 12 01:04AM +0100 Some of you might be interested in this Microsoft blog: <https://devblogs.microsoft.com/cppblog/finding-bugs-with-addresssanitizer-patterns-from-open-source-projects/> I have copied this to C newsgroup as well just in case they are interested in this. |
| David Brown <david.brown@hesbynett.no>: May 12 10:18AM +0200 On 12/05/2021 02:04, Real Troll wrote: > <https://devblogs.microsoft.com/cppblog/finding-bugs-with-addresssanitizer-patterns-from-open-source-projects/> > I have copied this to C newsgroup as well just in case they are > interested in this. An "Address sanitizer" (or related tool) is great for finding run-time pointer issues. But when problems can be found at compile time, that is always better. Looking at the examples, at least some of them /can/ be found at compile time, and could be avoided by better programming practice. For example, in their "IoT C SDK" (which is apparently C++, not C), the mistake in CopyGlobalBuffer is found as a static error by gcc. It could also be avoided by using sizeof(GLOBAL_BUFFER) instead of BUF_SIZE, or defining GLOBAL_BUFFER with the right size, or using a static assertion to confirm the size, or by using a std::array rather than a C array. The next example with the string and non-matching length should have had the string defined as a "const char[]" rather than a "const unsigned char*" pointer, then the length constant should be got by "constexpr const int twin_len = std::strlen(twin_props)". If they need to check the size matches a numeric constant, that's what static assertions are for. Instrumentation and debugging tools are great - but they are not an alternative to writing decent code in the first place! |
| 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. |
No comments:
Post a Comment