[haiku-development] Re: BPath::Append() resets the original path in case of failure.

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 25 Feb 2009 15:51:08 +0100

Fredrik Modéen schrieb:
This code:

        BPath path1 = "/aaa/bbb";
        BPath path2 = "/ccc/ddd";

        path1.Append(path2.Path());

        printf("%s\n", path1.Path());

Will print "(null)". The reason is that path2 must be relative (and not
absolute) so the call to Append fails. I don't have anymore any working
ZETA or BeOS installations here to test but I would be surprised if
this behaviour is expected. IMHO, it should simply not change the
original path.

So, is this really the wanetd behaviour? Can someone test this on BeOS/
ZETA and check if the same happens?

Same Behavor in Zeta 1.5.

BPath path1 = "/aaa/bbb";
BPath path2 = "/ccc/ddd";
path1.Append(path2.Path());
printf("%s\n", path1.Path());
Prints = null

BPath path1 = "/aaa/bbb/";
BPath path2 = "ccc/ddd";
path1.Append(path2.Path());
printf("%s\n", path1.Path());
Prints = null

BPath path1 = "/aaa/bbb";
BPath path2 = "ccc/ddd";
path1.Append(path2.Path());
printf("%s\n", path1.Path());
Prints = /aaa/bbb            (no ccc/ddd added)

BPath path1 = "/aaa/bbb";
//BPath path2 = "/ccc/ddd";
path1.Append("ccc/ddd");
printf("%s\n", path1.Path());
Prints = /aaa/bbb/ccc/ddd/

This all becomes clear when reading through the BeBook documentation for BPath. So both the BeOS and Haiku version perform as documented. Append() is implemented via SetTo(). SetTo() is destructive even in case of error. It becomes a matter of liking (or not) the fact that Append() is destructive... and whether this can even be changed, or if this would break any existing apps.

Best regards,
-Stephan


Other related posts: