On Wed, May 27, 2020 at 8:43 PM Bruno Haible <br...@clisp.org> wrote: > > > The GetProcAddress uses the ANSI version of the API so the proper type for > > the > > string is LPSTR, as found here: > > > > https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfinalpathnamebyhandlea > > --- > > lib/stat-w32.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/lib/stat-w32.c b/lib/stat-w32.c > > index 296ccf18c..106d25120 100644 > > --- a/lib/stat-w32.c > > +++ b/lib/stat-w32.c > > @@ -52,7 +52,7 @@ static GetFileInformationByHandleExFuncType > > GetFileInformationByHandleExFunc = N > > #endif > > /* GetFinalPathNameByHandle was introduced only in Windows Vista. */ > > typedef DWORD (WINAPI * GetFinalPathNameByHandleFuncType) (HANDLE hFile, > > - LPTSTR > > lpFilePath, > > + LPSTR > > lpFilePath, > > DWORD > > lenFilePath, > > DWORD dwFlags); > > static GetFinalPathNameByHandleFuncType GetFinalPathNameByHandleFunc = > > NULL; > > The patch is good. Thanks. But there are more instances of the same problem. > > ... > > 2020-05-27 Bruno Haible <br...@clisp.org> > > Don't assume that UNICODE is not defined. > Some Windows types, such as TCHAR, LPTSTR, LPCTSTR, are defined > differently if the application defines the macro UNICODE. > Reported by Steve Lhomme <rob...@ycbcr.xyz> in > <https://lists.gnu.org/archive/html/bug-gnulib/2020-05/msg00184.html>. > * lib/link.c (CreateHardLinkFuncType): Use LPCSTR, not LPCTSTR. > * lib/localename.c (enum_locales_fn): Use LPSTR, not LPTSTR. > * lib/stat-w32.c (GetFinalPathNameByHandleFuncType): Likewise. > > diff --git a/lib/link.c b/lib/link.c > index fc3eebf..8e079d2 100644 > --- a/lib/link.c > +++ b/lib/link.c > @@ -35,8 +35,8 @@ > (void *) GetProcAddress > > /* CreateHardLink was introduced only in Windows 2000. */ > -typedef BOOL (WINAPI * CreateHardLinkFuncType) (LPCTSTR lpFileName, > - LPCTSTR lpExistingFileName, > +typedef BOOL (WINAPI * CreateHardLinkFuncType) (LPCSTR lpFileName, > + LPCSTR lpExistingFileName, > LPSECURITY_ATTRIBUTES > lpSecurityAttributes); > static CreateHardLinkFuncType CreateHardLinkFunc = NULL; > static BOOL initialized = FALSE; > diff --git a/lib/localename.c b/lib/localename.c > index fe3d168..4046a0b 100644 > --- a/lib/localename.c > +++ b/lib/localename.c > @@ -2564,7 +2564,7 @@ static char lname[LC_MAX * (LOCALE_NAME_MAX_LENGTH + 1) > + 1]; > > /* Callback function for EnumLocales. */ > static BOOL CALLBACK > -enum_locales_fn (LPTSTR locale_num_str) > +enum_locales_fn (LPSTR locale_num_str) > { > char *endp; > char locval[2 * LOCALE_NAME_MAX_LENGTH + 1 + 1]; > diff --git a/lib/stat-w32.c b/lib/stat-w32.c > index c4b5de9..b9163f5 100644 > --- a/lib/stat-w32.c > +++ b/lib/stat-w32.c > @@ -54,7 +54,7 @@ static GetFileInformationByHandleExFuncType > GetFileInformationByHandleExFunc = N > #endif > /* GetFinalPathNameByHandle was introduced only in Windows Vista. */ > typedef DWORD (WINAPI * GetFinalPathNameByHandleFuncType) (HANDLE hFile, > - LPTSTR lpFilePath, > + LPSTR lpFilePath, > DWORD lenFilePath, > DWORD dwFlags); > static GetFinalPathNameByHandleFuncType GetFinalPathNameByHandleFunc = NULL; >
One small comment... For Microsoft platforms, one should also include <tchar.h> when available. The headers is common on many MS platforms, from Windows 95 through about Windows 8. I don't know if modern MS platforms have the header since Microsoft has pushed to Unicode-only API. Maybe an Autotools test would be the best course of action to guard the include. Jeff
