- SIGSEGV in stl_iterator.h - 4 Updates
- Pass by rvalue reference - 1 Update
- Simulating Halt Decider (SHD) Copyright (c) 2022 Mr Flibble - 4 Updates
- "C++ on the Move" by Darryl K. Taft - 4 Updates
| Paavo Helde <eesnimi@osa.pri.ee>: Mar 10 07:09PM +0200 10.03.2023 17:54 Jivanmukta kirjutas: > what == 1 and "after identifiers[what]" are TRACEd. Then SIGSEGV. > Why .size() causes SIGSEGV? Does it means there's something wrong with > identifiers[1] object? Most probably, yes. The first suspicion is that identifiers[1] does not even exist. So you should TRACE the number of objects in the identifiers, to see if identifiers[1] exists. Oh wait, you cannot do that, because you do not have that information, because you have decided to use some error-prone C-style array which doesn't know its own length. So throw it out and replace by proper std::vector. See my other post. |
| Andrey Tarasevich <andreytarasevich@hotmail.com>: Mar 10 12:15PM -0800 On 03/10/23 2:41 AM, Jivanmukta wrote: > puste i wtedy SIGV > } > what == 1 is TRACEd. Then SIGSEGV. size is not TRACEd. What does it mean? Er... Why are you trying to TRACE `identifiers[what].size()`? Nobody cares about `identifiers[what].size()`. We need `identifiers.size()`. What does `identifiers.size()` equal to? -- Best regards, Andrey |
| Andrey Tarasevich <andreytarasevich@hotmail.com>: Mar 10 12:17PM -0800 On 03/10/23 7:54 AM, Jivanmukta wrote: > TRACE("size == " << identifiers[what].size()); > what == 1 and "after identifiers[what]" are TRACEd. Then SIGSEGV. > Why .size() causes SIGSEGV? Because, as I have already stated above, `what` is out of bounds. Why are you trying to TRACE `identifiers[what].size()`? You need `identifiers.size()`. > Does it means there's something wrong with > identifiers[1] object? Most likely, it does. `identifiers[1]` simply does not exist. -- Best regards, Andrey |
| usenet@stegropa.de (Stefan Große Pawig): Mar 10 11:50PM +0100 > dir=L"/home/robert/Projekty/laravel-lodash/vendor/laravel", > result_dir=L"/", options="", delim="~#@%_", cached=@0x7fffffffdd00: > true, identifiers=0x0, strings=0x0) at src/cache.cpp:97 Here: identifiers=0x0, so any dereferening is likely to result in a segfault. > framework_dir=L"/home/robert/Projekty/laravel-lodash/vendor/laravel", > delim="~#@%_", framework_identifiers=0x0) > at src/cache.cpp:133 Here: framework_identifiers=0x0 > third_party_identifiers=std::__debug::unordered_map with 48 elements = > {...}) at src/cache.cpp:189 > [...] You may want to check what you pass as 'framework_identifiers' argument to cache::load_framework_cache(). Regards, Stefan |
| Pawel Por <porparek@gmail.com>: Mar 10 02:19PM -0800 >Everything else is a completely separate consequence of that, which >happens later, _after_ `std::move`. Overload resolution sees an xvalue >argument and chooses move constructor for this initialization. I think this is what I do here, "unname" a reference via std::move. Am I correct ? ml.push_front(std::move(dog)); That's why I expect the move constructor to be called while passing an argument to MyList<T>::push_front(T&&). |
| olcott <polcott2@gmail.com>: Mar 10 10:48AM -0600 On 3/10/2023 6:46 AM, Mr Flibble wrote: > Flibble Simulating Halt Decider is the *first* SHD that solves the > halting problem. > /Flibble I came up with the idea that the Peter Linz halting problem proof is decidable as non-halting six years ago in this forum. On 3/11/2017 3:13 PM [Infinitely Recursive input on HP Proofs] Message-ID: <918df253-d4f0-4370-8f73-88e6690380a1@googlegroups.com> All of the conventional halting theorem proofs have this same issue. Instead of merely detecting the pathological relationship and rejecting this input, the otherwise "impossible" input is correctly determined to be non-halting. -- Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Mr Flibble <flibble2@reddwarf.jmc.corp>: Mar 10 07:05PM On 10/03/2023 16:48, olcott wrote: > Instead of merely detecting the pathological relationship and rejecting > this input, the otherwise "impossible" input is correctly determined to > be non-halting. A halt decider MUST give a ternary result that includes "invalid input"; the traditional binary result of halting/non-halting is not sufficient to solve the halting problem as it doesn't recognize the category error present in the definition of the problem. Your SHD is invalid and worthless; Mr Flibble SHD is perfect and correct. /Flibble |
| olcott <polcott2@gmail.com>: Mar 10 01:29PM -0600 On 3/10/2023 1:05 PM, Mr Flibble wrote: > present in the definition of the problem. Your SHD is invalid and > worthless; Mr Flibble SHD is perfect and correct. > /Flibble You can't even provide the criterion measure that you use in the conditional statements that recognizes pathological self-reference (Olcott 2004). 01 int D(int (*x)()) 02 { 03 int Halt_Status = H(x, x); 04 if (Halt_Status) 05 HERE: goto HERE; 06 return Halt_Status; 07 } 08 09 void main() 10 { 11 H(D,D); 12 } I provide fully operational software that does correctly determine that D correctly simulated by H cannot possibly reach its own "return" instruction and halt whether or not this simulation is ever aborted. H(D,D) is fully operational in the x86utm operating system: https://github.com/plolcott/x86utm -- Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Mr Flibble <flibble2@reddwarf.jmc.corp>: Mar 10 07:41PM On 10/03/2023 19:29, olcott wrote: > instruction and halt whether or not this simulation is ever aborted. > H(D,D) is fully operational in the x86utm operating system: > https://github.com/plolcott/x86utm Software that is fully operational and wrong is still wrong, and worthless. A SHD *must* return a ternary result that includes "invalid program" in order to solve the halting problem as the SHD *must* correctly recognize the category error present in the definition of the problem itself. /Flibble |
| kalevi@kolttonen.fi (Kalevi Kolttonen): Mar 10 04:48PM > Typical case is that programmer did invoke undefined behavior but > program appears to work like he wanted ... until it does not. Who > benefits from that? Apologies for mentioning UB in C in a C++ newsgroup, but everybody needs to realize that it is very important to avoid UB at all costs. The following is a true horror story and much worse things than this could happen. When I was working as a system administrator, we used Cyrus IMAPD as email storage. I guess the Cyrus version was 2.4.17 and if I remember right, at the time it was running on Red Hat Enterprise Linux 7. This Cyrus version had worked flawlessly for years, but unfortunately the C code had UB. In the code handling mailboxes database, I think I remember there was an incorrect invocation of strcpy, a well-known C standard library function. The strcpy manual page clearly states: The strings may not overlap, and the destination string dest must be large enough to receive the copy The strings did overlap, but nobody ever noticed it, since glibc implementation of strcpy guarded against this mistake. As we know, with UB, anything could happen, including producing the correct behavior as intended by the programmer. Then one day glibc maintainers decided to optimize their AMD64 implementation of strcpy, and the guards for detecting overlapping strings were removed. Next thing we knew was that the mailboxes database was getting more and more corrupted, ending up in such a bad state that Cyrus IMAPD would no longer start. It was not a fun task to restore the mailboxes database into working order. Lesson: Never rely on UB! br, KK |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Mar 10 11:08AM -0800 >> Read this: >> https://mega.nz/file/ehcR1S5B#5YcRMdcJ0WArshD0szI2bckaqVmk2jC59XmOZh_GXgM > No freaking way. Looks like a ransomware file to me. I opened the link in a manner that is unlikely to allow any malware to affect me. The browser reports it as "cppMoveBook.zip", 5.9 MB. I'm not going to download it. I wonder if it's a copy of "C++ Move Semantics The Complete Guide" by Nicolai M. Josuttis (which is available legally as an ebook from leanpub.com). -- 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 */ |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Mar 10 11:14AM -0800 Öö Tiib <ootiib@hot.ee> writes: [...] [...] > are no reason why something that hardware does not handle (despite > its cost to performance if handled is hard to notice) should be left > undefined behavior. [...] You say there's "no reason", and then you explain in the same sentence what the reason is: performance. I don't see how the distinction between "portable assemblers" (which pretty much do not exist) and programming languages is relevant. -- 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 */ |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Mar 10 11:33AM -0800 David Brown <david.brown@hesbynett.no> writes: [...] > It would be a terrible idea for an efficient language to try to define > what happens here, forcing compilers to generate pointless extra > run-time checks just because some people have bugs in their code. [...] > that". Why someone would then want the language to say what will > happen when you do something contrary to the rules of the language, is > beyond my understanding. [...] Let me offer Ada as a counterexample (and I'm not suggesting that C++ should follow Ada's example). Signed numeric overflow and division by zero, along with a number of other conditions like out of bounds array access and dereferencing a null pointer, are defined in Ada to raise the predefined Constraint_Error exception. If I write code that divides by zero and then handles the exception, the behavior is well defined. If I don't handle the exception, the program (or task, similar to a thread) is aborted. The result of a division is either a well defined numeric result or a well defined exception. Since exceptions and the conditions that raise them are defined in the language, optimizing compilers can omit a lot of checks if they can prove that they'll never be triggered. There are also language mechanisms to suppress checks. If a check would have been triggered but is suppressed, the behavior is undefined. There is certainly a non-zero cost to this -- a cost that you can avoid by suppressing checks -- but the cost is not all that great, certainly less than the cost of using an interpreted language rather than a compiled language. -- 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 */ |
| 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