When I comment out the line in pic related, Rust will fail with the error
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" }', libcore/result.rs:1009:5
upon running, but when I let it print, it runs completely fine. What kind of fucking language panics or doesn't based on whether or not something prints?
Hey Rustfag
Other urls found in this thread:
man7.org
stackoverflow.com
man7.org
ecma-international.org
ecma-international.org
docs.oracle.com
ecma-international.org
ecma-international.org
twitter.com
We have dedicated help and consumer stickies you know.
This isn't a help or consumer post, it's a criticism of a language.
I have no idea about Rust, but you're probably invoking undefined behavior, especially since multithreading appears to be involved. Printing likely has a lock that accidentally prevents the bug.
That has nothing to do with Rust. That's EAGAIN, and is returned by the OS. It's a side-effect of you filling up a non-blocking buffer: man7.org
This can happen if you aren't properly interacting with non-blocking sockets or other filehandles. I can't tell, because you aren't showing us all your code, or where you are calling "unwrap".
When you're working with buffered IO and multithreading, any language when you're on the right OS and making the right calls. You're depending on stuff that's difficult to predict. Handle your non-blocking IO. If you want better help, you'll need to present a MCVE so we can reproduce your issue. As is, your question is basically useless: stackoverflow.com
Thanks for admitting that you're shitposting. Reported.
std::thread::spawn uses pthread_create on Unix.
RTFM you fucking faggot.
man7.org
Why are you posting then?
Yes, you have no idea about Rust. It is impossible to invoke UB in safe Rust.
Technically speaking, without a specification the entire Rust language is undefined behavior.
Because 9/10 times, "I have this Rust issue pls halp" turns out to have nothing to do with Rust. As was the case here, even though I didn't guess right this time.
Nice neme, faggot. But you're wrong. UB is a thing only in C/C++ world. Without a spec Rust is technically implementation defined.
So if it isn't C or C++, it magically doesn't have UB even if said behaviour is undefined. Got it.
Aka "we're too lazy to write an actual spec so anything this compiler does is defined behaviour."
You're so fucking retarded. Even more so than C/C++.
Look at any specified language other than C/C++. Does it have UB? Protip: no
"C was originally developed at Bell Labs by Dennis Ritchie between 1972 and 1973 [...]"
"C has been standardized by the American National Standards Institute since 1989 [...]"
"In 1985, the first edition of The C++ Programming Language was released, which became the definitive reference for the language, as there was not yet an official standard."
"The C++ programming language was initially standardized in 1998 [...]"
Kill yourself, you utter retard.
Yes, provided it's an actual language standard rather than "implementation is the standard ecks dee" bullshit. Even Common Lisp has it and there is a good reason for it to exist: It gives the implementation freedom to optimize. C/C++ don't suck because they have undefined behavior; they suck because the specified part is so useless that you can't get around undefined behavior in nontrivial programs.
That's an interesting claim, unfortunately I can't verify it because the standard isn't free. LMAO
So let's take a look at other languages:
C# (ecma-international.org
JavaScript (ecma-international.org
Java (docs.oracle.com
Dart (ecma-international.org
Eiffel (ecma-international.org
UB is peak braindamage.
if only C++ wasn't specified, it wouldn't have undefined behavior, because GCC would define it
I'm just now entering this discussion, but I can give a brief summary of the manner of undefined behaviour Common Lisp has.
Some functions aren't defined to freshly cons (allocate) a result; the result may be reused, so it's undefined what happens if it's modified. Several SEQUENCE manipulating functions accept a :TEST and a :TEST-NOT parameter; the latter is deprecated, but it's undefined what happens if you specify both for a call to such a function. A list can be circular or end improperly, but some functions may or may not detect this; it's undefined what happens if you call LENGTH on a circular list, instead of LIST-LENGTH which specifically detects this case, so an implementation may signal an error or loop indefinitely; a list manipulating function may signal an error if it's used on an improper list, but may not if it gets its result before it reaches the issue. It's undefined what happens if you manipulate a list that's been specified literally, since that may be made constant by the implementation as an optimization.
This is a summary of some of what's in Common Lisp. As you can see, it's nothing particularly unreasonable, unlike C.
I don't understand what you are trying to say.
The absolute state of anti Rust shills.
Cniles are so desperate to argue against their beloved languages deprecation that they praise the worst thing in the history of computer science.
If you aren't programming in straight asm inside a monitor program you're a cuck weenie tbh.
...
Cnile detected. I bet this cuckaroo still uses a MMU lmao.
assuming the implementers did everything correctly protip: they didn't
Without a proper spec, Rust is tied to whatever the fuck its reference compiler does and everyone else has to play catchup.
Yes, you are right. Thanks to LLVM you can invoke UB in safe Rust. C/C++ strikes again.
Correct. Which means Rust is imlementation define, not undefined.
Also nobody cares about a spec.
So is C's standard, that doesn't mean it's difficult to find its draft. Three of the five languages you listed are strongly related and one (JS) errs too much in the other direction, where an implementation must implement completely retarded things (e.g. integers as FP) to stay conformant. I don't know Eiffel, so I'll skip that one.
You already got an answer about some things in Common Lisp, but here you go, see "ยง1.4.2 Error Terminology". Other examples of undefined behavior in CL are wrong type declaration, since those exist for optimization reasons, and assigning to a constant. For some reason I remember that a FORMAT call with too few arguments is undefined too, but I can't seem to find this in the standard. Maybe it was changed before standardization and is somewhere in CLtL. However, a lot of the problems as in C are avoided because the safety level of compilation is adjustable, so implementations will very dutifully check for errors at max safety and let hell break loose if you lower it. Common Lisp, like Ada, is generally a very well-designed language -- unlike the garbage you see nowadays where supposed high-level languages don't even have a fucking rational number type because wah wah that's not in C.
Stop eating my attachments, you big gay.
Rust is correctly panicking instead of going off and fucking everything up in UB land.