FreeLists / openbeosstorage / [openbeosstorage] Re: Compatibility Policy

[Tyler Dauwalder <tyler@xxxxxxxxxxxxx>]

> I wonder, if there is a guideline, how to deal with R5 compatiblity
> issues. I don't mean general binary compatibility, but kind of behavioral
> compatibility, concerning e.g.:

Not really/sort of (I've pursued this before with the powers that be :-).

> * R5 bugs:
>   Shall R5 bugs be reproduced by OBOS? Some applications rely on bugs.

This is handled on a case by case basis. If it makes sense and won't break
anything (or too much), fix it. For example, BNode::RenameAttr() doesn't
work with R5, but ours does.

> * R5 inconsistencies:
>   Shall inconsistencies of R5 be reproduced? I don't have the code at
>   hand, so I can't give an example, but I remember, that I had two
>   versions of a method, that returned different results for the same
>   input. Boolean methods, btw...

If one's returning true and the other false on the same input, that could
be bad. I'd consider something like that to be similar to a bug, and handle
it as such. Am I interpreting you correctly?

> * error codes:
>   Could probably be subsumed under inconsistencies as well.
>   For instance the return value, when invoking a method on an
>   uninitialized object (a method that requires it to be initialized, of
>   course) varies from B_NO_INIT over B_FILE_ERROR, B_BAD_VALUE to crashs
>   (if we consider those return values ;-). Or passing a NULL value for a
>   required parameter might result in B_BAD_VALUE, B_BAD_ADDRESS,
>   B_NO_INIT or, again, a crash.
>
> Personally I would like to have each of these items fixed (bugs might be
> worth a second thought though).
> Especially for the error codes I would like to have some standardization;
> like what to return on what error and in which order to check for errors.

The crashing on NULL parameters I'm strongly against. IMO, that's stupid
and should be fixed.

As far as return codes go otherwise, here's the official word:

-------------------------
Begin official word
-------------------------

There are three types of values that can be returned:

1. Error codes with a functional meaning. An example of this would be
BEntry::GetParent() returning B_ENTRY_NOT_FOUND when the entry is "/".
B_ENTRY_NOT_FOUND *needs* to be returned in this instance. Further, any
other error *needs* to return something *other* than B_ENTRY_NOT_FOUND.

2. Error codes with no significant functional meaning. These are the bulk
of errors returned, and most people will likely just check for (result <
B_OK). Sure they have specific meaning (B_NO_MEMORY, B_BAD_VALUE, etc.),
but they'll generally be handled identically.

3. B_OK (or otherwise meaningful positive values)

Error codes of types 1 and 3 are to have no inconsistencies. Error codes of
type 2 pretty much just have to be an error code (i.e. < B_OK). They can
always be B_DEV_DOOR_OPEN for all anyone cares.

-------------------------
End official word
-------------------------

Personally, I would also prefer these inconsistencies to be standardized  
but I don't know that we're the ones (at the moment) to be making the
standards.

The difficult thing from our point of view is that many of our return
values are just handed back from kernel_interface calls. So the real
standardization needs to occur in the kernel.

There are certainly cases where we could just check if the kernel returns
an error, and then return our own, standardized, error instead of blindly
passing on what the kernel gives us. I haven't actually looked, so I don't
know what percentage of the cases this would actually comprise. The
downside of this is that I wouldn't want to filter out B_NO_MEMORY (and
possibly a handful of other errors), so we'd end up needing a function like

status_t filterError(status_t error, status_t standardizedError) {
=09if (error =3D=3D B_NO_MEMORY || error =3D=3D ...)
=09=09return error;
=09else
=09=09return standardizedError;
}

It's not much overhead, but it *is* overhead. Is it worth it? I don't know;
it seems like a hack to me. I'd rather see the standardization occur at the
source, in the kernel.

So really, my personal stance is: follow the official rules and when the
time comes, push for standardization in the kernel. My guess is the latter
will only happen if someone who cares (me, you, someone else who agrees)
takes it upon themselves to make it happen. I could be wrong though.

Thoughts?

-Tyler

p.s. Despite my current personal stance, I know there's at least one case 
in BNode where I went out of my way to return the weird value the R5 
version returned; I've just never gotten back to taking it out. Perhaps if 
you come across it... X-P... :-)