search

tomas-nestorovic / RIDE

Windows tool for low-level access to any floppy disks, and comfortable high-level access to some legacy filesystems (ZX Spectrum, MS-DOS, etc.).
https://nestorovic.hyperlink.cz/ride/html/index.html
56 stars 0 forks source link

All DOSes: File name+extension retrieval may be erroneous and unsafe #43

Closed tomas-nestorovic closed 3 years ago

tomas-nestorovic commented 4 years ago

Methods that serve as "interface" to DOS file name and/or extension retrieval and modification cannot contain DOS-specific characters - Windows native C-style strings are a too weak means to represent them (see the below CDos class declaration snippet).

class CDos
{
    typedef TStdWinError (CDos::*TFnCreateSubdirectory)(LPCTSTR name,DWORD winAttr,PFile &rCreatedSubdir);
    typedef TStdWinError (CDos::*TFnMoveFileToCurrDir)(PFile file,LPCTSTR fileNameAndExt,PFile &rMovedFile);

    virtual bool GetFileNameOrExt(PCFile file,PTCHAR bufName,PTCHAR bufExt) const=0;
    PTCHAR GetFileNameWithAppendedExt(PCFile file,PTCHAR bufNameExt) const;
    bool HasFileNameAndExt(PCFile file,LPCTSTR fileName,LPCTSTR fileExt) const;
    virtual TStdWinError ChangeFileNameAndExt(PFile file,LPCTSTR newName,LPCTSTR newExt,PFile &rRenamedFile)=0;
    PFile FindFileInCurrentDir(LPCTSTR fileName,LPCTSTR fileExt,PCFile ignoreThisFile) const;
};

A more robust way to represent, for instance, null-character (0x00), valid in all Spectrum platforms, should be created. Moreover, the C-style character arrays are unsafe - buffer overrun at stake!

It's thus suggested to create a new data type encapsulating both C-style character array (big enough to accommodate a valid Windows long name) along with the count of valid characters in it. To indicate the constrained usage, it's further suggested to name this data type CPathString.

tomas-nestorovic commented 3 years ago

With almost fifteen months with no reported bug, this issue can be closed.