Hey,
I write a simple console c++ program on XCODE fro mac.
The code is very simple
#include <iostream>
using namespace std;
int main() {
int a = 0;
cin >> a;
return 0;
}
Then,
1: Press command + R to debug the program.
2: The program is waiting for user input, don't input.
3: Put a breakpoint at "return 0;"
4: The program will continuing running and hit the breakpoint which was put in step.3 without input anything.
As I didn't input anything besides put a breakpoint, the "cin >> a;" should still block the program and waiting for user input. So the actual behavior is not expected.
Have any idea?
Thanks
Lemme explain what’s happening here. When you run this line:
cin >> a;
your process blocks in a read system call. When you set that breakpoint (step 3), the debugging infrastructure causes that read system call to fail with EINTR. It seems that the C++ standard library doesn’t retry in this case, so your program finishes the above-mentioned line and you hit the breakpoint.
Now, I’m no expert on C++ but, from the perspective of C’s <stdio.h> library, this is expected. The equivalent call there is fread. The fread man page doesn’t mention anything about this specifically, and neither does the fgetc man page. However, the Posix spec calls this out in its fgetc [1] discussion:
EINTR … The read operation was terminated due to the receipt of a signal, and no data was transferred.
I expect that the C++ <iostream> has the same semantics. I searched the net for iostream "EINTR" [2] and I’ve found a bunch of other folks similarly confused by this, across a wide range of Unix-y platforms.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] https://pubs.opengroup.org/onlinepubs/000095399/functions/fgetc.html
[2] Make sure to quote EINTR lest your search engine autocorrect it to int or some such silliness.