You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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. :-)
The text was updated successfully, but these errors were encountered:
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:
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:
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. :-)
The text was updated successfully, but these errors were encountered: