[prev in list] [next in list] [prev in thread] [next in thread]
List: gnulib-bug
Subject: Re: [PATCH 1/2] stat: use a CHAR instead of TCHAR with GetFinalPathNameByHandleA
From: Jeffrey Walton <noloader () gmail ! com>
Date: 2020-05-28 1:07:25
Message-ID: CAH8yC8=NYgpxOykRRZNnQRttBr+dqBi854w1C6Ri1HGv+TeExw () mail ! gmail ! com
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic