Function open() sets errno

Applications Programming
1

I am opening a text file using open() system call in O_RDONLY mode.
open() returns me a valid handler but also sets errno to 13 i.e. EACCES(Permission denied).

Question is when open() is returning a valid handler then why does it sets the errno?
Should not errno be set only in case of error and open() failing?

Actually the file I am trying to open is owned by some other user.
In such a case should not open() return -1 instead of returning a valid handler?

2

Well open() returns an integer, which if -1 means errno is set to tell you what you did wrong. It sounds like your access in not good. You can set errno to zero before and test afterward. The nature of errno is that it is only set for errors, not reset on success. I usually:

if ( 0 > ( fd = open( file_name_ptr, O_RDONLY ))){
    perror( file_name_ptr );
    exit( 1 );
  }
1 Like
3

From man 3 errno:

       The  <errno.h> header file defines the integer variable errno, which is
       set by system calls and some library functions in the event of an error
       to  indicate  what  went wrong.  Its value is significant only when the
       return value of the call indicated an error (i.e., -1 from most  system
       calls;  -1  or  NULL from most library functions); a function that suc-
       ceeds is allowed to change errno.

So, errno should never be used to check whether an error happened -- only which error. It's easy to picture more elaborate library calls changing the value of errno many times before they return... You must be exact about when and why you use it for what to get something meaningful.

I'm not sure why a successful system call would be changing errno, but it's allowed to. Perhaps it was a simplification -- "these first 4 cases will all return EACCESS, so set it first, and return immediately if any of them fail". And they never bother to change the error to success when it succeeds.

Another invalid way to use errno is checking the value of errno too late, after they've made another system call. This can give you the strange result 'ERROR: Success'.

1 Like
4

The OP should post the operating system they're using and the code for the shortest program which reproduces the behavior (with a printf or two and the output they generate).

For all we know, the determination of "valid handler" is incorrect.

Regards,
Alister

1 Like
5

If you got a positive number from open(), then the errno was set earlier by some other call, unless your code does something interesting or untoward.... We do need to see some code please.

Note that system calls do not reset errno to zero, so if you do not reliably check returns codes, then it may not be possible to see where the error originated. system calls set errno ONLY when they have an error condition.

1 Like
6

Thanks all for the reply.
I checked and saw errno was set by some other function called earlier.
So I understand that we must not directly check only the errno after a system call.
Instead we must accompany the check with the return value of the function.
For instance:

fd = open(...)
if(fd = -1 &&  errno == ...)
{
  ....
}
7

Kind of, but you seem to just be checking for a specific error. Generally for *NIX system calls:

  • The return value tells you whether there was an error or not, and
  • errno tells you the specific type of error.

Also, be aware that you wrote "fd = -1" not "fd == -1", which is always false - not sure if this is a typo, but make sure you understand why this is an error. I always like to write the constant on the left-hand side of the comparison to try and avoid this sort of thing.

Summing up:

int fd = open(/* ... */);
if (-1 == fd) {
  // There was an error.
  switch (errno) {
  case EACCESS:
    // Access was denied.
    break;
  // ...etc...
  default:
    // Some unknown/other error.
  }
} else {
  // File opened OK.
}
1 Like
8

I'm sure it was just a momentary lapse, but to avoid confusing anyone: assigning -1 is a boolean true.

Regards,
Alister

1 Like
9

[Thanks JohnGraham for the suggestions.
Missing one "=" was a typing mistake.

](JohnGraham's profile and badges)

---------- Post updated at 07:57 PM ---------- Previous update was at 07:56 PM ----------

Thanks JohnGraham for the suggestions.
Missing one "=" was a typing mistake.

10

Of course - d'oh! Apologies if anyone was confused...

11
  • If you are doing simple or poll()/select() driven synchronous blocking I/O, all the errno get the same treatment with different messages.
  • If you do fcntl O_NONBLOCK (O_NDELAY looks like an old mistake) non-blocking, you have to sort out the EAGAIN from would block situations.
  • For some devices and raw I/O, you need to retry on EINTR. (BTW, some situations can also give read() and the like a zero return from an empty framed block, a false EOF that needs to be retried.)
1 Like