Re: Fix memleak in getdelim.m4
Hi Tim, > > rm -rf ../testdir-all; ./gnulib-tool --create-testdir > > --dir=../testdir-all --single-configure > > This results in: > > executing autopoint --force > autopoint: *** The AM_GNU_GETTEXT_VERSION declaration in your configure.ac >file requires the infrastructure from gettext-0.20 but > this version >is older. Please upgrade to gettext-0.20 or newer. > autopoint: *** Stop. You may try to pass '--avoid=gettext' to overcome this. > As Debian unstable is at gettext 0.19.8.1, I tried to build gettext from > git master. This results in > > make[7]: Entering directory > '/home/tim/src/gettext/gettext-tools/examples/tmp-hello-pascal' > make[7]: warning: jobserver unavailable: using -j1. Add '+' to parent > make rule. > LOCALEDIR='/usr/local/share/locale' /usr/bin/ppcx64 -o./hello ./hello.pas > Free Pascal Compiler version 3.0.4+dfsg-23 [2019/11/25] for x86_64 > Copyright (c) 1993-2017 by Florian Klaempfl and others > Target OS: Linux for x86-64 > Compiling ./hello.pas > hello.pas(9,6) Fatal: Can't find unit gettext used by hello > Fatal: Compilation aborted > make[7]: *** [Makefile:798: hello.rsj] Error 1 > > > Is it really needed to fail the whole build just because a *PASCAL* > example doesn't compile ? I may sound a bit old-fashioned when I recommend tarballs over building from git checkouts. But sometimes it has its advantages. gettext 0.20.2 is not that old. [1] Bruno [1] https://ftp.gnu.org/gnu/gettext/gettext-0.20.2.tar.gz
Re: Easy Accurate Reading and Writing of Floating-Point Numbers
Marc Nieper-Wißkirchen wrote: > for output, the shortest rounded > representation that still reads back accurately has to be selected. > ... > A simple algorithm is given by Aubrey Jaffer in [1]. > > [1] http://people.csail.mit.edu/jaffer/III/EZFPRW There are several other algorithms for this purpose. There is an overview by RyanJuckett at http://www.ryanjuckett.com/programming/printing-floating-point-numbers/ The papers I know of are: * Guy L. Steele Jr, Jon L White "How to Print Floating-Point Numbers Accurately" 1990 * Robert G. Burger, R. Kent Dybvig "Printing Floating-Point Numbers Quickly and Accurately" 1996 * Florian Loitsch "Printing Floating-Point Numbers Quickly and Accurately with Integers" 2010 * Marc Andrysco, Ranjit Jhala, Sorin Lerner "Printing Floating-Point Numbers" 2016 Then there's also the algorithm, by Michael Stoll and me (1990), in GNU clisp and CLN (based on multiprecision arithmetic, not hardware floats). Bruno
Re: copyright in Germany
Marc Nieper-Wißkirchen wrote: > > "copyright" here means more "Nutzungsrecht" which you can transfer also > > in Germany. You still stay the "Urheber". > > If transferring the "Nutzungsrecht" is enough, everything should be fine. You need to verify, though, that no employer of yours has a legal basis for claiming the "Nutzungsrechte" on the code that you want to contribute. If the code you write is not related to your job, that is, if you are not being paid to write it, then the "Nutzungsrechte" belong to you - regardless whether your employment contract says otherwise. This is guaranteed by Art. 2.(1) Grundgesetz. (*) Often it is clear whether something is related to your job. For example, if you have a manager that tells you what to develop. (*) If your employer is a university [1], things are less clear. In the past, some universities have been strict and claimed that the works of their professors and researchers belong to them. This has changed somewhat around 2000-2005: The slogan "public money - public code" has convinced at least some universities to allow the code that came out of research projects to be released under Open Source licenses. In any case, this topic is subject to negotiation between the professors/researchers and the university. (*) Disclaimer: I got this infos from a lawyer. But I am not a lawyer. Consult your own lawyer. Bruno [1] https://www.uni-augsburg.de/de/fakultaet/mntf/math/prof/alg/arbeitsgruppe/nieper-wisskirchen/
Re: Fix memleak in getdelim.m4
On 18.05.20 21:44, Bruno Haible wrote: > Hi Tim, > >>> The way to determine the answer is: >>> 1. Create a test dir of all gnulib modules. >>> 2. Configure it with --config-cache. >>> 3. Configure it with --config-cache and your sanitizer options. >>> 4. Compare the generated config.cache and config.status files. >> >> I am short on time and would like to prevent being distracted too much > > Everyone here is probably in the same situation... > >> If you could give me a quick instruction on how to do 1. > > I typically use this command: > > rm -rf ../testdir-all; ./gnulib-tool --create-testdir --dir=../testdir-all > --single-configure This results in: executing autopoint --force autopoint: *** The AM_GNU_GETTEXT_VERSION declaration in your configure.ac file requires the infrastructure from gettext-0.20 but this version is older. Please upgrade to gettext-0.20 or newer. autopoint: *** Stop. As Debian unstable is at gettext 0.19.8.1, I tried to build gettext from git master. This results in make[7]: Entering directory '/home/tim/src/gettext/gettext-tools/examples/tmp-hello-pascal' make[7]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. LOCALEDIR='/usr/local/share/locale' /usr/bin/ppcx64 -o./hello ./hello.pas Free Pascal Compiler version 3.0.4+dfsg-23 [2019/11/25] for x86_64 Copyright (c) 1993-2017 by Florian Klaempfl and others Target OS: Linux for x86-64 Compiling ./hello.pas hello.pas(9,6) Fatal: Can't find unit gettext used by hello Fatal: Compilation aborted make[7]: *** [Makefile:798: hello.rsj] Error 1 Is it really needed to fail the whole build just because a *PASCAL* example doesn't compile ? Wow, I used Pascal in the 1980s the last time, didn't know it is still used except for fun projects :) Regards, Tim signature.asc Description: OpenPGP digital signature
Re: Easy Accurate Reading and Writing of Floating-Point Numbers
On 19.05.20 21:10, Marc Nieper-Wißkirchen wrote: > Am Di., 19. Mai 2020 um 19:23 Uhr schrieb Tim Rühsen : > >> "copyright" here means more "Nutzungsrecht" which you can transfer also >> in Germany. You still stay the "Urheber". > > If transferring the "Nutzungsrecht" is enough, everything should be fine. The first step is to follow ./doc/Copyright/request-assign.future. That is Please email the following information to ass...@gnu.org, and we will send you the assignment form for your past and future changes. Please use your full legal name (in ASCII characters) as the subject line of the message. -- REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES [What is the name of the program or package you're contributing to?] [Did you copy any files or text written by someone else in these changes? Even if that material is free software, we need to know about it.] [Do you have an employer who might have a basis to claim to own your changes? Do you attend a school which might make such a claim?] [For the copyright registration, what country are you a citizen of?] [What year were you born?] [Please write your email address here.] [Please write your postal address here.] [Which files have you changed so far, and which new files have you written so far?] signature.asc Description: OpenPGP digital signature
Re: ftoastr.h: Include guard incomplete
On 5/19/20 12:27 PM, Marc Nieper-Wißkirchen wrote: ftoastr.h tests for _GL_FTOASTR_H, but does not define it. Thanks, I installed the attached. >From b3c04ecec58ea687423f5c709410e6ecee4abd9b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 19 May 2020 13:45:46 -0700 Subject: [PATCH] ftoastr: fix ifndef typo * lib/ftoastr.h (_GL_FTOASTR_H): Define. --- ChangeLog | 5 + lib/ftoastr.h | 1 + 2 files changed, 6 insertions(+) diff --git a/ChangeLog b/ChangeLog index 9ff7c69ca..1c39b92e6 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2020-05-19 Paul Eggert + + ftoastr: fix ifndef typo + * lib/ftoastr.h (_GL_FTOASTR_H): Define. + 2020-05-19 Bruno Haible havelib: Tweak documentation. diff --git a/lib/ftoastr.h b/lib/ftoastr.h index d945cc064..852e4000d 100644 --- a/lib/ftoastr.h +++ b/lib/ftoastr.h @@ -18,6 +18,7 @@ /* Written by Paul Eggert. */ #ifndef _GL_FTOASTR_H +#define _GL_FTOASTR_H #include "intprops.h" #include -- 2.17.1
ftoastr.h: Include guard incomplete
ftoastr.h tests for _GL_FTOASTR_H, but does not define it.
Re: Easy Accurate Reading and Writing of Floating-Point Numbers
Am Di., 19. Mai 2020 um 19:23 Uhr schrieb Tim Rühsen : > "copyright" here means more "Nutzungsrecht" which you can transfer also > in Germany. You still stay the "Urheber". If transferring the "Nutzungsrecht" is enough, everything should be fine. Marc
Re: Easy Accurate Reading and Writing of Floating-Point Numbers
On 19.05.20 18:11, Marc Nieper-Wißkirchen wrote: > Am Di., 19. Mai 2020 um 17:51 Uhr schrieb Paul Eggert : >> >> On 5/19/20 8:35 AM, Marc Nieper-Wißkirchen wrote: It is, however, locale-dependent, and there is no "c_dtoastr" version as there is a "c_strtod". (Could we get such a wrapper?) >>> Or a version "c_dtoastr" that uses "c_snprintf" and "c_strtod" internally. >> >> Yes, that'd be good to have. Could you write that? > > I should be able to. But please note that I haven't filled out an > assignment form for copyright transfer yet (which is, by the copyright > law of Germany, where I live, technically not possible, by the way). I > hope this is not a major problem. > > Marc Hi Marc, "copyright" here means more "Nutzungsrecht" which you can transfer also in Germany. You still stay the "Urheber". The german Urheberrecht has been changed a few years ago to be pretty much in sync with international laws. I am not an expert in this area and can't give you any advice here :-) Regards, Tim signature.asc Description: OpenPGP digital signature
Re: Easy Accurate Reading and Writing of Floating-Point Numbers
Am Di., 19. Mai 2020 um 17:51 Uhr schrieb Paul Eggert : > > On 5/19/20 8:35 AM, Marc Nieper-Wißkirchen wrote: > >> It is, however, locale-dependent, and there is no "c_dtoastr" > >> version as there is a "c_strtod". (Could we get such a wrapper?) > > Or a version "c_dtoastr" that uses "c_snprintf" and "c_strtod" internally. > > Yes, that'd be good to have. Could you write that? I should be able to. But please note that I haven't filled out an assignment form for copyright transfer yet (which is, by the copyright law of Germany, where I live, technically not possible, by the way). I hope this is not a major problem. Marc
Re: Easy Accurate Reading and Writing of Floating-Point Numbers
On 5/19/20 8:35 AM, Marc Nieper-Wißkirchen wrote: It is, however, locale-dependent, and there is no "c_dtoastr" version as there is a "c_strtod". (Could we get such a wrapper?) Or a version "c_dtoastr" that uses "c_snprintf" and "c_strtod" internally. Yes, that'd be good to have. Could you write that?
Re: Easy Accurate Reading and Writing of Floating-Point Numbers
Am Di., 19. Mai 2020 um 17:10 Uhr schrieb Marc Nieper-Wißkirchen : > I have just discovered the "dtoastr" module, which seems to do what I > want. It is, however, locale-dependent, and there is no "c_dtoastr" > version as there is a "c_strtod". (Could we get such a wrapper?) Or a version "c_dtoastr" that uses "c_snprintf" and "c_strtod" internally. Marc P.S. Could we also get a flag for "(c_)strtod", with which one can choose the %e or %f format explicitly? At the moment, it always uses "%g".
Re: Easy Accurate Reading and Writing of Floating-Point Numbers
Am Di., 19. Mai 2020 um 09:44 Uhr schrieb Marc Nieper-Wißkirchen : > Such input and output routines for floats and doubles would also be > very helpful in the C language. Do you think this could become a > Gnulib module? I have just discovered the "dtoastr" module, which seems to do what I want. It is, however, locale-dependent, and there is no "c_dtoastr" version as there is a "c_strtod". (Could we get such a wrapper?) Marc
[PATCH] stat: implement GetFileInformationByHandle with Winstore apps restrictions
GetFileInformationByHandle() cannot be called. But the same information can be
gathered via calls to GetFileInformationByHandleEx() which is allowed.
A function pointer is used to pick between the local version using
GetFileInformationByHandleEx() and the system one.
If WINSTORECOMPAT is defined that means the app is built with mingw including
the compatibility library which also includes an GetFileInformationByHandle()
implementation, so no need to redefine it.
---
lib/stat-w32.c | 44 +++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/lib/stat-w32.c b/lib/stat-w32.c
index 6900dfcf5..6699b9560 100644
--- a/lib/stat-w32.c
+++ b/lib/stat-w32.c
@@ -58,6 +58,48 @@ typedef DWORD (WINAPI * GetFinalPathNameByHandleFuncType)
(HANDLE hFile,
static GetFinalPathNameByHandleFuncType GetFinalPathNameByHandleFunc = NULL;
static BOOL initialized = FALSE;
+#if !WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP) &&
!defined(WINSTORECOMPAT)
+WINBOOL _GetFileInformationByHandle(HANDLE hFile, LPBY_HANDLE_FILE_INFORMATION
lpInfo)
+{
+FILE_ID_INFO id_info;
+FILE_STANDARD_INFO standard_info;
+FILE_BASIC_INFO basic_info;
+if (!GetFileInformationByHandleEx(hFile, FileIdInfo, _info, sizeof
(id_info)) ||
+!GetFileInformationByHandleEx(hFile, FileStandardInfo, _info,
sizeof (standard_info)) ||
+!GetFileInformationByHandleEx(hFile, FileBasicInfo, _info,
sizeof (basic_info)))
+{
+return FALSE;
+}
+
+lpInfo->dwFileAttributes = basic_info.FileAttributes;
+
+lpInfo->ftCreationTime.dwHighDateTime = basic_info.CreationTime.HighPart;
+lpInfo->ftCreationTime.dwLowDateTime= basic_info.CreationTime.LowPart;
+lpInfo->ftLastAccessTime.dwHighDateTime =
basic_info.LastAccessTime.HighPart;
+lpInfo->ftLastAccessTime.dwLowDateTime =
basic_info.LastAccessTime.LowPart;
+lpInfo->ftLastWriteTime.dwHighDateTime =
basic_info.LastWriteTime.HighPart;
+lpInfo->ftLastWriteTime.dwLowDateTime = basic_info.LastWriteTime.LowPart;
+
+lpInfo->dwVolumeSerialNumber = id_info.VolumeSerialNumber;
+
+lpInfo->nFileSizeHigh = standard_info.EndOfFile.HighPart;
+lpInfo->nFileSizeLow = standard_info.EndOfFile.LowPart;
+
+lpInfo->nNumberOfLinks = standard_info.NumberOfLinks;
+
+/* The nFileIndex from GetFileInformationByHandle is equal to the low
+ 64 bits of the 128-bit FileId from GetFileInformationByHandleEx,
+ and the high 64 bits of this 128-bit FileId are zero. */
+lpInfo->nFileIndexLow = (id_info.FileId.Identifier[12] << 24) |
(id_info.FileId.Identifier[13] << 16) | (id_info.FileId.Identifier[14] << 8) |
id_info.FileId.Identifier[15];
+lpInfo->nFileIndexHigh = (id_info.FileId.Identifier[ 8] << 24) |
(id_info.FileId.Identifier[ 9] << 16) | (id_info.FileId.Identifier[10] << 8) |
id_info.FileId.Identifier[11];
+
+return TRUE;
+}
+static WINBOOL (*GetFileInformationByHandleFunc)(HANDLE hFile,
LPBY_HANDLE_FILE_INFORMATION lpInfo) = _GetFileInformationByHandle;
+#else /* WINAPI_PARTITION_DESKTOP */
+static WINBOOL (WINAPI *GetFileInformationByHandleFunc)(HANDLE hFile,
LPBY_HANDLE_FILE_INFORMATION lpInfo) = GetFileInformationByHandle;
+#endif /* WINAPI_PARTITION_DESKTOP */
+
static void
initialize (void)
{
@@ -159,7 +201,7 @@ _gl_fstat_by_handle (HANDLE h, const char *path, struct
stat *buf)
The latter requires -D_WIN32_WINNT=_WIN32_WINNT_VISTA or higher. */
BY_HANDLE_FILE_INFORMATION info;
- if (! GetFileInformationByHandle (h, ))
+ if (! GetFileInformationByHandleFunc (h, ))
goto failed;
/* Test for error conditions before starting to fill *buf. */
--
2.26.2
Easy Accurate Reading and Writing of Floating-Point Numbers
It is often important to be able to read back a written floating-point number accurately so it has to be output with high enough precision. The Scheme standard even demands this for the number->string and string->number procedures. Moreover, for output, the shortest rounded representation that still reads back accurately has to be selected. Such input and output routines for floats and doubles would also be very helpful in the C language. Do you think this could become a Gnulib module? A simple algorithm is given by Aubrey Jaffer in [1]. Marc [1] http://people.csail.mit.edu/jaffer/III/EZFPRW
[PATCH] stat: remove _GL_WINDOWS_STAT_INODES == 2 support
It may be outdated code, the value is never 2.
sys_types_h.m4 sets it to 0 or via gl_WINDOWS_STAT_INODES.
gl_WINDOWS_STAT_INODES sets it to 1 if compiled via mingw* and 0 otherwise.
---
lib/stat-w32.c | 107 +++--
lib/stat.c | 9
lib/sys_types.in.h | 25 ---
3 files changed, 6 insertions(+), 135 deletions(-)
diff --git a/lib/stat-w32.c b/lib/stat-w32.c
index 6900dfcf5..2cbcdca8b 100644
--- a/lib/stat-w32.c
+++ b/lib/stat-w32.c
@@ -42,14 +42,6 @@
#define GetProcAddress \
(void *) GetProcAddress
-#if _GL_WINDOWS_STAT_INODES == 2
-/* GetFileInformationByHandleEx was introduced only in Windows Vista. */
-typedef DWORD (WINAPI * GetFileInformationByHandleExFuncType) (HANDLE hFile,
-
FILE_INFO_BY_HANDLE_CLASS fiClass,
- LPVOID lpBuffer,
- DWORD
dwBufferSize);
-static GetFileInformationByHandleExFuncType GetFileInformationByHandleExFunc =
NULL;
-#endif
/* GetFinalPathNameByHandle was introduced only in Windows Vista. */
typedef DWORD (WINAPI * GetFinalPathNameByHandleFuncType) (HANDLE hFile,
LPSTR lpFilePath,
@@ -63,9 +55,6 @@ initialize (void)
{
#if !WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
/* LoadLibrary not allowed but the functions are available with the windows
runtime */
-#if _GL_WINDOWS_STAT_INODES == 2
- GetFileInformationByHandleExFunc = GetFileInformationByHandleEx;
-#endif
#if _WIN32_WINNT >= 0x0A00 /* _WIN32_WINNT_WIN10 */
GetFinalPathNameByHandleFunc = GetFinalPathNameByHandleA;
#endif
@@ -73,10 +62,6 @@ initialize (void)
HMODULE kernel32 = LoadLibrary ("kernel32.dll");
if (kernel32 != NULL)
{
-#if _GL_WINDOWS_STAT_INODES == 2
- GetFileInformationByHandleExFunc =
-(GetFileInformationByHandleExFuncType) GetProcAddress (kernel32,
"GetFileInformationByHandleEx");
-#endif
GetFinalPathNameByHandleFunc =
(GetFinalPathNameByHandleFuncType) GetProcAddress (kernel32,
"GetFinalPathNameByHandleA");
}
@@ -152,12 +137,7 @@ _gl_fstat_by_handle (HANDLE h, const char *path, struct
stat *buf)
or through
GetFileInformationByHandle
-
- or through
- GetFileInformationByHandleEx with argument FileBasicInfo
-
-
- The latter requires -D_WIN32_WINNT=_WIN32_WINNT_VISTA or higher. */
+
*/
BY_HANDLE_FILE_INFORMATION info;
if (! GetFileInformationByHandle (h, ))
goto failed;
@@ -174,60 +154,9 @@ _gl_fstat_by_handle (HANDLE h, const char *path, struct
stat *buf)
GetFileInformationByHandle
- as 64 bits, or through
- GetFileInformationByHandleEx with argument FileIdInfo
-
-
- as 128 bits.
- The latter requires -D_WIN32_WINNT=_WIN32_WINNT_WIN8 or higher. */
- /* Experiments show that GetFileInformationByHandleEx does not provide
- much more information than GetFileInformationByHandle:
- * The dwVolumeSerialNumber from GetFileInformationByHandle is equal
- to the low 32 bits of the 64-bit VolumeSerialNumber from
- GetFileInformationByHandleEx, and is apparently sufficient for
- identifying the device.
- * The nFileIndex from GetFileInformationByHandle is equal to the low
- 64 bits of the 128-bit FileId from GetFileInformationByHandleEx,
- and the high 64 bits of this 128-bit FileId are zero.
- * On a FAT file system, GetFileInformationByHandleEx fails with
error
- ERROR_INVALID_PARAMETER, whereas GetFileInformationByHandle
- succeeds.
- * On a CIFS/SMB file system, GetFileInformationByHandleEx fails with
- error ERROR_INVALID_LEVEL, whereas GetFileInformationByHandle
- succeeds. */
-# if
[PATCH] gettimeofday: do not use LoadLibrary when built for Windows Store apps
LoadLibrary is forbidden in such apps (can only load DLLs from within the app
package).
The API entries are available to all apps linking with the Windows API as found
here:
https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis
windowsapp.lib (and mincore.lib for Windows 8) are both available in MinGW as
well.
GetSystemTimePreciseAsFileTime is only allowed in Win10 UWP apps.
---
lib/gettimeofday.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/lib/gettimeofday.c b/lib/gettimeofday.c
index 19804793a..087f7eada 100644
--- a/lib/gettimeofday.c
+++ b/lib/gettimeofday.c
@@ -45,12 +45,17 @@ static BOOL initialized = FALSE;
static void
initialize (void)
{
+#if !WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP) && _WIN32_WINNT >=
0x0A00 /* _WIN32_WINNT_WIN10 */
+ /* LoadLibrary not allowed but the functions are available with the windows
runtime */
+ GetSystemTimePreciseAsFileTimeFunc = GetSystemTimePreciseAsFileTime;
+#else /* WINAPI_PARTITION_DESKTOP */
HMODULE kernel32 = LoadLibrary ("kernel32.dll");
if (kernel32 != NULL)
{
GetSystemTimePreciseAsFileTimeFunc =
(GetSystemTimePreciseAsFileTimeFuncType) GetProcAddress (kernel32,
"GetSystemTimePreciseAsFileTime");
}
+#endif /* WINAPI_PARTITION_DESKTOP */
initialized = TRUE;
}
--
2.26.2
[PATCH 2/2] stat: do not use LoadLibrary when built for Windows Store apps
LoadLibrary is forbidden in such apps (can only load DLLs from within the app
package).
The API entries are available to all apps linking with the Windows API as found
here:
https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis
windowsapp.lib (and mincore.lib for Windows 8) are both available in MinGW as
well.
GetFinalPathNameByHandleA is only allowed in Win10 UWP apps
GetFileInformationByHandleEx is allowed in Win8 and Win10 UWP apps.
---
lib/stat-w32.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/lib/stat-w32.c b/lib/stat-w32.c
index 106d25120..6900dfcf5 100644
--- a/lib/stat-w32.c
+++ b/lib/stat-w32.c
@@ -61,6 +61,15 @@ static BOOL initialized = FALSE;
static void
initialize (void)
{
+#if !WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
+ /* LoadLibrary not allowed but the functions are available with the windows
runtime */
+#if _GL_WINDOWS_STAT_INODES == 2
+ GetFileInformationByHandleExFunc = GetFileInformationByHandleEx;
+#endif
+#if _WIN32_WINNT >= 0x0A00 /* _WIN32_WINNT_WIN10 */
+ GetFinalPathNameByHandleFunc = GetFinalPathNameByHandleA;
+#endif
+#else /* WINAPI_PARTITION_DESKTOP */
HMODULE kernel32 = LoadLibrary ("kernel32.dll");
if (kernel32 != NULL)
{
@@ -71,6 +80,7 @@ initialize (void)
GetFinalPathNameByHandleFunc =
(GetFinalPathNameByHandleFuncType) GetProcAddress (kernel32,
"GetFinalPathNameByHandleA");
}
+#endif /* WINAPI_PARTITION_DESKTOP */
initialized = TRUE;
}
--
2.26.2
[PATCH 1/2] stat: use a CHAR instead of TCHAR with GetFinalPathNameByHandleA
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; -- 2.26.2
