bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] stat: use a CHAR instead of TCHAR with GetFinalPathNameB


From: Bruno Haible
Subject: Re: [PATCH 1/2] stat: use a CHAR instead of TCHAR with GetFinalPathNameByHandleA
Date: Thu, 28 May 2020 02:43:01 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-177-generic; KDE/5.18.0; x86_64; ; )

Hi Steve,

> 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.

When you present a suggestion or report a bug, please try to answer the main
questions:
  * What goes wrong?
  * Under which conditions does it go wrong?

In this case, when the application defines the macro UNICODE, the function types
are defined with wrong parameter types. That's because some types depend on
whether UNICODE is defined or not [1].

Once the problem has been stated like this, it's easy to find all occurrences
of the same problem: grep -rnw '\(TCHAR\|LPTSTR\|LPCTSTR\)' .

[1] https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types


2020-05-27  Bruno Haible  <bruno@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 <robux4@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;




reply via email to

[Prev in Thread] Current Thread [Next in Thread]