Re: [hatari-devel] Bug(s) in GEMDOS Dsetpath() emulation

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Mon, 20 Apr 2020 13:16:05 -0400
schrieb "Roger Burrows" <anodyne@xxxxxxxxxxxx>:

> On 20 Apr 2020 at 11:04, Roger Burrows wrote:
> 
> > On 20 Apr 2020 at 16:44, Eero Tamminen wrote:  
> > > 
> > > On 4/19/20 9:57 PM, Roger Burrows wrote:  
> > > > There are some related bugs in Dsetpath() handling:
> > > > 
> > > > 1) Setting the path to '' (the empty string) should be valid,
> > > > and on  
> > Atari  
> > > TOS  
> > > > effectively sets the path to the root of the specified drive;  
> > > 
> > > That seems illogical, if there's no drive root
> > > specified, paths should be relative to current
> > > directory...
> > >   
> > I've just done some more testing and I think my original report was
> > wrong. There is still a bug in there somewhere (perhaps in
> > Dgetpath()), but I need to refine my testing program & test some
> > more before being quite so definite. 
> OK, here is the definitive report :-).  There is a bug in Dsetpath()
> and a bug in Dgetpath().
> 
> (1) Under Atari TOS, attempting to set the empty path on a drive
> (Dsetpath("")) succeeds, and the current path is unchanged.  Under
> Hatari GEMDOS emulation, this fails with an error code of -34 (and
> unsurprisingly the current path is unchanged).
> 
> (2) Under Atari TOS, setting the path to the root (Dsetpath("\"))
> succeeds, and a subsequent Dgetpath() returns the empty string.
> Under Hatari GEMDOS emulation, Dsetpath("\") succeeds, but a
> subsequent Dgetpath() returns "\". [Note: to try to avoid confusion,
> I'm not using C string syntax, i.e. all the strings shown as "\" are
> one byte long containing the backslash character]

Thanks for the report, this should be fixed now.

 Thomas