Project Home
Project Home
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - chdir and errno on failure (correctness question): (6 Items)
   
chdir and errno on failure (correctness question)  
Looking at Sean's patch, I glanced through chdir implementation. It ends with:

return MsgSendv(PATHMGR_COID, iov, 2, 0, 0);

If MsgSendv fails, errno will be set to whatever MsgSendv sets it to (e.g. EBADF). However in our docs there are 
different errno values for MsgSendv and chdir (i.e. chdir does not set it to EBADF according to docs).

What is wrong: our implementation or our docs? 

RE: chdir and errno on failure (correctness question)  
If you get EBADF on PATHMGR_COID that's the least of your problems.

-seanb

-----Original Message-----
From: Aleksandar Ristovski [mailto:aristovski@qnx.com]
Sent: Fri 6/20/2008 4:56 PM
To: ostech-core_os
Subject: chdir and errno on failure (correctness question)
 
Looking at Sean's patch, I glanced through chdir implementation. It ends with:

return MsgSendv(PATHMGR_COID, iov, 2, 0, 0);

If MsgSendv fails, errno will be set to whatever MsgSendv sets it to (e.g. EBADF). However in our docs there are 
different errno values for MsgSendv and chdir (i.e. chdir does not set it to EBADF according to docs).

What is wrong: our implementation or our docs? 



_______________________________________________
OSTech
http://community.qnx.com/sf/go/post9494


Attachment: Text winmail.dat 2.79 KB
Re: RE: chdir and errno on failure (correctness question)  
> 
> If you get EBADF on PATHMGR_COID that's the least of your problems.
> 
> -seanb

Well, my question was not precise. It is not about EBADF in particular (I gave it as an example) but a general question.
 There is a list of errno that MsgSendv can set on failure, but chdir doc does not document that (and I believe there 
are other libc functions doing the same).

So my question is still - should chdir documentation list all possible errno values on failure, or should chdir get the 
return value and return one of the listed ones?

Or are you saying that any failure of MsgSendv can be considered fatal and the errno value would be "the least of my 
problems" (what about EINTR and ETIMEDOUT - can they happen and would they still be unrecoverable)?  

Re: RE: chdir and errno on failure (correctness question)  
We had this discussion many years ago about the return of access().  The problem was specifically that access() returned
 EINTR, even though that return value wasn't documented.  RnD's view at the time was "POSIX says that a function will 
return _at least_ the documented values, maybe more", so the EINTR was still within POSIX.

Looking at access(), it can still return errno values outside of it's documented range, so chdir() doing the same isn't 
anything new.

Personal opinion?  chdir() (and access(), etc.) should be checking the return from calls like MsgSend(), and doing their
 own error handing. (if EINTR is returned, the call should be re-started inside of chdir()).  As a side-effect, the 
chdir() call only returns its documented errno values.
Re: RE: chdir and errno on failure (correctness question)  
> Personal opinion?  chdir() (and access(), etc.) should be checking the return 
> from calls like MsgSend(), and doing their own error handing. (if EINTR is 
> returned, the call should be re-started inside of chdir()).

Wouldn't that be real bad, since it would make the function possibly loop forever if for whatever reason it would keep 
getting EINTR.


RE: RE: chdir and errno on failure (correctness question)  
 

> -----Original Message-----
> From: Mario Charest [mailto:mcharest@zinformatic.com] 
> Sent: July 8, 2008 10:53 AM
> To: ostech-core_os
> Subject: Re: RE: chdir and errno on failure (correctness question)
> 
> > Personal opinion?  chdir() (and access(), etc.) should be 
> checking the 
> > return from calls like MsgSend(), and doing their own error 
> handing. 
> > (if EINTR is returned, the call should be re-started inside 
> of chdir()).
> 
> Wouldn't that be real bad, since it would make the function 
> possibly loop forever if for whatever reason it would keep 
> getting EINTR.


Okay, so I should have said "intelligent error handling".  I agree that
an infinite loop because of EINTR is bad.  I also think the library
calls should be making some effort to deal with errors/translate errno
values.  The alternative is to add all the possible errno values to the
docs for each function.

> 
> 
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post10156
> 
>