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

[Jeffrey Walton]

On Wed, May 27, 2020 at 8:43 PM Bruno Haible <bruno@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  <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;
>

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