FreeLists / openbeosstorage / [openbeosstorage] Re: Compatibility Policy

[Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>]

On Mon, 22 Apr 2002, Tyler Dauwalder wrote:

> > 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.

Agreed.

> > * 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?

To give the example I referred to:
BDirectory::Contains(): If the directory is uninitialized, the const char*
version taking a path, returns true, if the entry exists, whereas the
BEntry* version always returns false.
Being a lazy programmer I of course implemented one version using the
other, so that now both versions return true in this case.
I vaguely remember that there where other methods, of which different
versions returned different error codes for the same error.

> > * 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.

Of course. :-)

> 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.

Do I understand you correctly, that you are saying, that if R5 violates
the rule for 1, OBOS has to do it differently (i.e. correctly)?
And that in the case of 2, we don't have to care, what R5 returns, but
return any value of the set that we think fits best?

I guess 3 is a special case anyway, since returning or not returning B_OK
is the border between success and failure, which rather belongs to the bug
section.

> -------------------------
> 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.

Even beyond, I guess most of the return values originate from the file
systems.

> 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.

Yep you're absolutely right.
What I was thinking of are the error values we produce ourselves.
And to standardize those, some questions need to be answered, such as:

* What value to return, if on an uninitialized object a method is invoked 
  that requires the object to be properly initialized? The InitCheck()
  return value, B_NO_INIT or B_FILE_ERROR?

* In which order shall possible errors be checked? First arguments, then
  InitCheck() or the other way around?

* If a method invoked on an object, is supposed to initialize another
  object that is passed as an argument, what happens to the object, if the
  method fails? Unset() it at the end of the method, if an error occured
  or always Unset() it at the beginning of the method and leave it in the
  state it happens to be at the end of the method.

> 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.

Hehe, that's how it usually works -- if you want something to be done
properly, do it yourself. ;-)

> 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... :-)

Let's see, if I find it... :-)

CU, Ingo

PS: I don't know, if I already mentioned it, BEntry doesn't handle too
    long entry names and cyclic links correctly. Please tell me, when you
    have fixed this. Then I can uncomment some of the BDirectory test
    cases.