Separator issue in KM_fileio.cpp and KM_fileio.h on WIndows

[steveq61]

Hi, In my DCP packaging software, I call functions in libasdcp.lib to do wrapping etc.

Whilst MXF wrapping the subtitle assets I ran into a Windows problem in asdcplib. Many of the functions in KM_fileio.cpp define the path separator as ‘/’, for example:

bool PathIsAbsolute(const std::string& Path, char separator = '/'); // true if path begins with separator

The default separator in Windows is ‘\’ so I have had to modify the file KM_fileio.h and change all the separators to '\' for it to work under Windows:

bool PathIsAbsolute(const std::string& Path, char separator = '\\'); // true if path begins with separator std::string PathMakeAbsolute(const std::string& Path, char separator = '\\'); // compute position of relative path using getcwd()

Whilst Windows does not care about whether the separator is a '/' or '\' character, the code in several functions, tests explicitly for the '/' character only. Here's one example:

bool
Kumu::PathIsAbsolute(const std::string& Path, char separator)
{
  if ( Path.empty() )
    return false;

  if ( Path[0] == separator)  //<--- as defined in the header, separator is '/'
    return true;

  return false;
}

This will most likely fail under Windows. The separator '/' character is explicitly being tested for, but under Windows it will most likely be the default '\' character.

I mentioned this back in 2014, and since then I have just been modifying the header file to fix the issue under Windows. So I thought I'd raise this again in case someone wanted to have a look at it.

@jhursty I emailed you on 21/07/2014 at 3:21 PM and I suggested wrapping this around the define KM_WIN32 in your next release, you replied with:

Steve,

That's unexpected. Windows has always been content to have '/' in the path (i.e., either '\' or '/' will do). What version are you using?

And yes, it seems reasonable enough to have the character selected by KM_WIN32. I'll be interested to know more about your experience before committing to this. There may be unpleasant side-effects (e.g., if PathJoin is used to create a URL the result will be incorrect). I will look around to see what may happen...

-jh

I haven't taken this any further due to the potential side-effects @jhursty mentioned.

Anyhow I'm pretty sure this issue still persists, if someone feels like having a play with it!

Cheers,

Steve Q. :-)

[msheby]

Well, in KM_WIN32-land one probably needs to check that the path starts with drive/volume letter and the colon. See https://docs.microsoft.com/en-us/dotnet/standard/io/file-path-formats.