Return indicates failure , errno indicates status?
-
This is NOT question, just asking - to whom do I trust ? perror posts “operation now in progress “ which is great to know BUT connect return “status “ is -1 . To whom do I trust ? This implies that "“operation now in progress “ is an error or checking return value is bogus. Simple "connect" function description quoted from documentation: "The normal return value from connect is 0. If an error occurs, connect returns -1. The following errno error conditions are defined for this function:" Please notice how "errno" is used. status = connect(s, (struct sockaddr*) &server_addr, sizeof(server_addr)); if (errno != 0 | status != 0) { // redundant and wrong ....
-
This is NOT question, just asking - to whom do I trust ? perror posts “operation now in progress “ which is great to know BUT connect return “status “ is -1 . To whom do I trust ? This implies that "“operation now in progress “ is an error or checking return value is bogus. Simple "connect" function description quoted from documentation: "The normal return value from connect is 0. If an error occurs, connect returns -1. The following errno error conditions are defined for this function:" Please notice how "errno" is used. status = connect(s, (struct sockaddr*) &server_addr, sizeof(server_addr)); if (errno != 0 | status != 0) { // redundant and wrong ....
Both. From the man page:
Quote:
RETURN VALUE If the connection or binding succeeds, zero is returned. On error, -1 is returned, and errno is set appropriately. ERRORS The following are general socket errors only. There may be other domain-specific error codes. EACCES For UNIX domain sockets, which are identified by pathname: Write permission is denied on the socket file, or search permission is denied for one of the directories in the path prefix. (See also path_resolution(7).) EACCES, EPERM The user tried to connect to a broadcast address without having the socket broadcast flag enabled or the connec‐ tion request failed because of a local firewall rule. EADDRINUSE Local address is already in use. ... etc ...
So you know that the call to
connect()did not succeed, because it returned -1. There's a lot of reasons thatconnect()might fail, and you can examineerrnoto find out why. In many cases, depending on context, an unsuccessful connect might be expected, or recoverable (e.g. if you've run out of resources, you might be able to either wait for other connections to close, or be able to clean up/close old connections). In your case errno is EINPROGRESS "The socket is nonblocking and the connection cannot be completed immediately". See the man page for further information. If this is a bluetooth, then consult any relevant bluetooth docs to see if EINPROGRESS is mentioned and why you might get that error code. Note thatperror()will always print "operation now in progress" any time errno == EINPROGRESS. Some library calls might set EINPROGRESS to indicate a condition that does not directly translate to "operation now in progress", but the resource is temporarily busy, and you should try again later, and EAGAIN already is used for some other retry condition. -
Both. From the man page:
Quote:
RETURN VALUE If the connection or binding succeeds, zero is returned. On error, -1 is returned, and errno is set appropriately. ERRORS The following are general socket errors only. There may be other domain-specific error codes. EACCES For UNIX domain sockets, which are identified by pathname: Write permission is denied on the socket file, or search permission is denied for one of the directories in the path prefix. (See also path_resolution(7).) EACCES, EPERM The user tried to connect to a broadcast address without having the socket broadcast flag enabled or the connec‐ tion request failed because of a local firewall rule. EADDRINUSE Local address is already in use. ... etc ...
So you know that the call to
connect()did not succeed, because it returned -1. There's a lot of reasons thatconnect()might fail, and you can examineerrnoto find out why. In many cases, depending on context, an unsuccessful connect might be expected, or recoverable (e.g. if you've run out of resources, you might be able to either wait for other connections to close, or be able to clean up/close old connections). In your case errno is EINPROGRESS "The socket is nonblocking and the connection cannot be completed immediately". See the man page for further information. If this is a bluetooth, then consult any relevant bluetooth docs to see if EINPROGRESS is mentioned and why you might get that error code. Note thatperror()will always print "operation now in progress" any time errno == EINPROGRESS. Some library calls might set EINPROGRESS to indicate a condition that does not directly translate to "operation now in progress", but the resource is temporarily busy, and you should try again later, and EAGAIN already is used for some other retry condition."So you know that the call to connect() did not succeed, because it returned -1. There's a lot of reasons that connect() might fail, and you can examine errno to find out why." That is what I though I was doing - looking at status and expected 0 and then errno to get some more info. I think the connect is failing due to remote end not responding in - for now unknown - time, but that is where the "in progress" is somewhat telling me that. Also the actual response is delayed by this , yet unspecified time. Interestingly - after first call fails with "in progress..." next call returns immediately with "device busy..". Question is - which device ? Must be the local which is busy - doing what ? It did not connect... Remote ? If it did not "connect" in first place how it can be the remote which is busy? ( At present rebooting local sort of works, and I am working on something faster using code ...) "Note that perror() will always print "operation now in progress" any time errno == EINPROGRESS" I don't think there is an easy way to correlate actual message to its symbol. I am sure I can find the source code , but why ? In my view that woudl defeat the function of perror - translating the errno # to text without showing the symbols.
-
"So you know that the call to connect() did not succeed, because it returned -1. There's a lot of reasons that connect() might fail, and you can examine errno to find out why." That is what I though I was doing - looking at status and expected 0 and then errno to get some more info. I think the connect is failing due to remote end not responding in - for now unknown - time, but that is where the "in progress" is somewhat telling me that. Also the actual response is delayed by this , yet unspecified time. Interestingly - after first call fails with "in progress..." next call returns immediately with "device busy..". Question is - which device ? Must be the local which is busy - doing what ? It did not connect... Remote ? If it did not "connect" in first place how it can be the remote which is busy? ( At present rebooting local sort of works, and I am working on something faster using code ...) "Note that perror() will always print "operation now in progress" any time errno == EINPROGRESS" I don't think there is an easy way to correlate actual message to its symbol. I am sure I can find the source code , but why ? In my view that woudl defeat the function of perror - translating the errno # to text without showing the symbols.
The "in progress" status is telling you that the local device is trying to complete some operation. If you then try to use it again it may well be returning "busy" because it is unable to accept your request. The
perror()function has been around for years and has always been fairly succinct in its output. The important information is the actualerrnovalue. It is a fairly simple matter to write your own function to display the value and the error message (see strerror(3) - Linux manual page[^]). What you really should do is get hold of the RFC documents for TCP/IP and Bluetooth, and study the protocol details. They should give you the exact sequence of events that are supposed to happen when the two endpoints try to communicate. -
The "in progress" status is telling you that the local device is trying to complete some operation. If you then try to use it again it may well be returning "busy" because it is unable to accept your request. The
perror()function has been around for years and has always been fairly succinct in its output. The important information is the actualerrnovalue. It is a fairly simple matter to write your own function to display the value and the error message (see strerror(3) - Linux manual page[^]). What you really should do is get hold of the RFC documents for TCP/IP and Bluetooth, and study the protocol details. They should give you the exact sequence of events that are supposed to happen when the two endpoints try to communicate.Richard MacCutchan wrote:
The
perror()function has been around for years and has always been fairly succinct in its output. The important information is the actualerrnovalue. It is a fairly simple matter to write your own function to display the value and the error message (see strerror(3) - Linux manual page[^]).Even old dogs learn something new occasionally. I was certain that
perror()would be locale aware, but it seems not (which could be an issue if you are depending on exact text matches in your output). While researching that, I came across the GNUerror()function, which might help the OP. See about half-way down this page: [Error Messages (The GNU C Library)](https://www.gnu.org/software/libc/manual/html\_node/Error-Messages.html) -
Richard MacCutchan wrote:
The
perror()function has been around for years and has always been fairly succinct in its output. The important information is the actualerrnovalue. It is a fairly simple matter to write your own function to display the value and the error message (see strerror(3) - Linux manual page[^]).Even old dogs learn something new occasionally. I was certain that
perror()would be locale aware, but it seems not (which could be an issue if you are depending on exact text matches in your output). While researching that, I came across the GNUerror()function, which might help the OP. See about half-way down this page: [Error Messages (The GNU C Library)](https://www.gnu.org/software/libc/manual/html\_node/Error-Messages.html)Thanks, this is very good reference. Error Messages (The GNU C Library)[^] So far I am getting used to perror , it mostly gives good description of the state. I am still unsure how to recover from some of those related to socket and bluetooth. The moral of the story check the return value first , then let perror describe the state. perror does not always tells error, but state. BTW the original error was due to my mistake not checking the remote bluetooth device address. I was passing the device name and not the address! Live and learn... Cheers
-
Thanks, this is very good reference. Error Messages (The GNU C Library)[^] So far I am getting used to perror , it mostly gives good description of the state. I am still unsure how to recover from some of those related to socket and bluetooth. The moral of the story check the return value first , then let perror describe the state. perror does not always tells error, but state. BTW the original error was due to my mistake not checking the remote bluetooth device address. I was passing the device name and not the address! Live and learn... Cheers
Vaclav_ wrote:
check the return value first , then let perror describe the state.
No, don't rely on perror alone. The most important piece of information is the actual error code. And, as I already suggested, you should study the RFC documents to get a thorough understanding of the protocols you are trying to use.
-
This is NOT question, just asking - to whom do I trust ? perror posts “operation now in progress “ which is great to know BUT connect return “status “ is -1 . To whom do I trust ? This implies that "“operation now in progress “ is an error or checking return value is bogus. Simple "connect" function description quoted from documentation: "The normal return value from connect is 0. If an error occurs, connect returns -1. The following errno error conditions are defined for this function:" Please notice how "errno" is used. status = connect(s, (struct sockaddr*) &server_addr, sizeof(server_addr)); if (errno != 0 | status != 0) { // redundant and wrong ....
Quote:
perror posts “operation now in progress “ which is great to know BUT connect return “status “ is -1 . To whom do I trust ?
They're both saying the same thing. Why are you confused? The return from connect() means "Unable to connect, check errno for why". The errno you are getting for "why I can't connect" is "operation in progress (EINPROGRESS)". Seems pretty clear.
-
The "in progress" status is telling you that the local device is trying to complete some operation. If you then try to use it again it may well be returning "busy" because it is unable to accept your request. The
perror()function has been around for years and has always been fairly succinct in its output. The important information is the actualerrnovalue. It is a fairly simple matter to write your own function to display the value and the error message (see strerror(3) - Linux manual page[^]). What you really should do is get hold of the RFC documents for TCP/IP and Bluetooth, and study the protocol details. They should give you the exact sequence of events that are supposed to happen when the two endpoints try to communicate.Quote:
The important information is the actual errno value. It is a fairly simple matter to write your own function to display the value and the error message (see strerror(3) - Linux manual page[^]).
You don't need to, on GNU systems simply use '%m' in the printf format string. The '%m' is replaced with the actual error message in the language that the system is set to.
-
Quote:
The important information is the actual errno value. It is a fairly simple matter to write your own function to display the value and the error message (see strerror(3) - Linux manual page[^]).
You don't need to, on GNU systems simply use '%m' in the printf format string. The '%m' is replaced with the actual error message in the language that the system is set to.