On Mon, 2015-10-19 at 23:05 +0200, Jiri Svoboda wrote: > Hi, > > (sorry for sending a little bit late) Note that since > changeset:mainline, > 2397 there is a change to how I/O functions return error. If you are > working > on a project that works with files, you may be affected. > > Before the change, the 'native' I/O functions (open(), read(), > write(),close > (), etc.) returned >=0 on success (in some cases a meaningful value, > such as > fd, number of records transferred). On failure they would return > negative > error code. After this change, on error they return -1 and set errno. > > This means any code that actually distinguishes between different > error > codes will be impacted. What's worse, if your code uses file > functions, it > will still compile, it just won't handle the errors properly. There > is no > easy way to check for this, except to audit all uses of file > functions (I > did this in mainline). > > The main motivation for this change: I consider functions that return > >=0 on > success and negative error code on error bad interface design because > the > return value mixes two unrelated things. It makes code checking the > error > value sensitive to the sign of Exxx constants. (As you know these are > negative in HelenOS and positive in UNIX). The file functions in > HelenOS are > named like the UNIX functions, they have *almost* the same signatures > and > they behave *almost* the same. This led to a lot of cases where the > caller > errorneously assumed the functions behave like their UNIX > counterparts (e.g. > in Bdsh - since it was ported from Linux). > > While nothing precludes HelenOS having a file API completely distict > from > the UNIX-like one (which should have nonconflicting function names), > in this > case the easiest immediate fix was to just align the functions with > the UNIX > -like ones.
I looked through the changes when they landed, and it's not clear to me how you handle multiple threads/fibrils. Traditional errno has the disadvantage of making all the functions non-reentrant (if you want trust the errno value upon return). Introducing such restriction seems like a step back, as there are other solutions to the problem (like having a error output parameter, that would also change the signature to find all uses at compile time). Jan > > Please let me know if you have any questions or concerns or if you > need help > with updating your code. > Best regards, > Jiri > (http://trac.helenos.org/changeset/mainline%2C2397) > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/listinfo/helenos-devel
signature.asc
Description: This is a digitally signed message part
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
