Get File Extension
-
Jim, When you are working with paths on the windows platform I would recommend using the Shell Path Handling Functions[^]. You are probably looking for the PathFindExtension function[^]. Best Wishes, -David Delaune
-
Jim, When you are working with paths on the windows platform I would recommend using the Shell Path Handling Functions[^]. You are probably looking for the PathFindExtension function[^]. Best Wishes, -David Delaune
That works great. Thanks But I don't get it. I'm not sure if the wcsncpy_s bombed, or if I have some kind of buffer error, that never got flagged. I have a registry function that's doing the same thing, but just the 1, so far, all others work fine. I'm going to post it in a new post.
-
That works great. Thanks But I don't get it. I'm not sure if the wcsncpy_s bombed, or if I have some kind of buffer error, that never got flagged. I have a registry function that's doing the same thing, but just the 1, so far, all others work fine. I'm going to post it in a new post.
jkirkerx wrote:
I have a registry function that's doing the same thing, but just the 1, so far, all others work fine.
Not sure but if you post the contents of the function and the calling function I might be able to pinpoint your problem. Because I am somewhat familiar with the project you are working on... last comment about path handling: In the future I would recommend that you use the Shell Path Handling Functions[^] when working on the windows platform rather than attempting to implement your own path parser. Over the past 20 years or so there have been hundreds of vulnerabilities associated with path handling/parsing... because many software engineers attempted to implement an algorithm of their own. Best Wishes, -David Delaune
-
You kidding me, there's an app for that! So PathFinderExtension trumps the sample function posted earlier? Thanks Dave, spent way too much time on it last night.
There's also a CRT function for this -
_splitpath_s/_wsplitpath_s«_Superman_» _I love work. It gives me something to do between weekends.
-
jkirkerx wrote:
I have a registry function that's doing the same thing, but just the 1, so far, all others work fine.
Not sure but if you post the contents of the function and the calling function I might be able to pinpoint your problem. Because I am somewhat familiar with the project you are working on... last comment about path handling: In the future I would recommend that you use the Shell Path Handling Functions[^] when working on the windows platform rather than attempting to implement your own path parser. Over the past 20 years or so there have been hundreds of vulnerabilities associated with path handling/parsing... because many software engineers attempted to implement an algorithm of their own. Best Wishes, -David Delaune
Dear Mr. David Delaune, I have received your feedback. Thank you so much. please give me your email! Best Regards, L.Q.LONG
-
Dear Mr. David Delaune, I have received your feedback. Thank you so much. please give me your email! Best Regards, L.Q.LONG
-
I copied this off the internet without fully understanding how it works, and now it's not working when I compile as Release version. In Debug it works fine. Not sure if I should dump it and reinvent the wheel, or if there is just a slight mistake in the code. The part I don't understand is in bold.
WCHAR extension [32];
WCHAR* peek = szFileName + szFileName [ wcslen( szFileName ) - 1 ];
while ( peek >= szFileName )
{
if (*peek == L'.') {
wcsncpy_s ( extension, peek, wcslen( peek ) ); // stuck here
break;
}
peek--;
}
swprintf_s( szFileExtension, L"%s", extension );Edit: The peek gets stuck with a 2 dot extension, and won't progress forward like project.config.user And then all file extensions are .user after that. But just in Release
THe code snippet assumes UNICODE is being used. I would suggest to use generic mapping that will work for both: ANSII and UNICODE: As for retrieving parts of the path why not to let CRT do it for you using generic (_tsplitpath_s)? For example:
LPTSTR lpszPath = \_T("project.config.user"); TCHAR szFilename\[MAX\_PATH\] = {0}; TCHAR szExt\[MAX\_PATH\] = {0}; \_tsplitpath\_s(lpszPath, NULL, NULL, NULL, NULL, szFilename, \_MAX\_FNAME, szExt, \_MAX\_EXT);JohnCz
-
Further to Flaviu2 said, if you're not using MFC, this will work: Code:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>int main()
{
wchar_t *wszFilename = L"project.config.user";
wchar_t *extension;
wchar_t *dotPosition;
size_t extensionLength;dotPosition = wcsrchr(wszFilename, '.'); extensionLength = wcslen(dotPosition); extension = (wchar\_t\*) malloc(extensionLength \* sizeof(wchar\_t)); wcscpy(extension, dotPosition + 1); // add 1 to point to char following the . wprintf(extension);}
Output:
user
What if the path is \\server\share\path.path\file?
-
THe code snippet assumes UNICODE is being used. I would suggest to use generic mapping that will work for both: ANSII and UNICODE: As for retrieving parts of the path why not to let CRT do it for you using generic (_tsplitpath_s)? For example:
LPTSTR lpszPath = \_T("project.config.user"); TCHAR szFilename\[MAX\_PATH\] = {0}; TCHAR szExt\[MAX\_PATH\] = {0}; \_tsplitpath\_s(lpszPath, NULL, NULL, NULL, NULL, szFilename, \_MAX\_FNAME, szExt, \_MAX\_EXT);JohnCz
I implemented the PathFinderExtension from Dave's Suggestion, but your suggestion looks quite interesting. hmm. I didn't know about that function and how to implement it. The PathFinderExtension is working quite well now, but let me fix my errors first before making any more changes.
