[Please keep the mailing list in CC.]
Gisle Vanem wrote:
> > What is this clang-cl compiler? Is it disguising itself as _MSC_VER ?
>
> Yes. "clang-cl == clang --driver-mode=cl".
I see. And, like for the GCC disguise, probably this disguise is not perfect
either... Let's hope that it works for th
Hi Marc,
> At least one type in is guaranteed to be
> lock-free, the atomic flag. Since C18, it can be used in signal
> handlers, where Posix locks won't work because they are not
> async-safe. Moreover, provides memory fences, which I
> don't know how to emulate in general and which also seem t
Hi Daiki,
> Here are the two separate commits for this.
The first one is nearly perfect. Only the NEWS entry should go into section
"User visible incompatible changes", not into section "Important general notes".
The second one:
- In fread_file, around line 100, you use a realloc workaround th
Bruno Haible writes:
> The first one is nearly perfect. Only the NEWS entry should go into section
> "User visible incompatible changes", not into section "Important general
> notes".
>
> The second one:
> - In fread_file, around line 100, you use a realloc workaround that appears
> to be
> Here are proposed patches for other modules. Does this look right?
There were no objections. I pushed the changes.
Bruno
The gnulib module 'open' supports O_CLOEXEC since 2017-08-14. We can use it
to make multithreaded application that call fork() and exec() more robust.
Here are proposed patches.
How about module 'fts'? Should the directory fds that it allocates also be
made O_CLOEXEC?
2020-05-27 Bruno Haible
On 2020-05-27 20:43, Bruno Haible wrote:
> How about module 'fts'? Should the directory fds that it allocates also be
> made O_CLOEXEC?
+1
I doubt that passing on those fds to any child is wanted/necessary.
At least that would be a bug for coreutils (rm,du,chmod,chgrp,chcon)
and findutils (find).
On Wed, May 27, 2020, 11:44 Bruno Haible wrote:
> The gnulib module 'open' supports O_CLOEXEC since 2017-08-14. We can use it
> to make multithreaded application that call fork() and exec() more robust.
>
> Here are proposed patches.
>
> How about module 'fts'? Should the directory fds that it al
The getopt.c file generates the following warnings from Apple’s gcc (Apple
clang version 11.0.3 (clang-1103.0.32.62)):
getopt.c:208:21: warning: implicit conversion changes signedness: 'long' to
'size_t' (aka '
On 5/27/20 11:43 AM, Bruno Haible wrote:
> How about module 'fts'? Should the directory fds that it allocates also be
> made O_CLOEXEC?
Yes, I'd say so; I see little reason for a child process to continue an fts
scan.
Hi,
Paul J. Lucas wrote:
> The getopt.c file generates the following warnings from Apple’s gcc (Apple
> clang version 11.0.3 (clang-1103.0.32.62)):
>
>
> getopt.c:208:21: warning: implicit conversion changes signedn
Hi Steve,
> When building for UWP it's particularly important as a lot of APIs may
> be hidden if you use the proper values and they are hidden because you
> shouldn't use them. Forcing to use them when they shouldn't will lead to
> apps that don't run.
Oh, so Microsoft is not only adding new
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 dele
On Wed, May 27, 2020 at 8:43 PM Bruno Haible 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
On 2020-05-28 2:12, Bruno Haible wrote:
Hi Steve,
Hi Bruno,
When building for UWP it's particularly important as a lot of APIs may
be hidden if you use the proper values and they are hidden because you
shouldn't use them. Forcing to use them when they shouldn't will lead to
apps that don't ru
Any update on this patch ?
On Dekstop it's better to use kernel32.dll as it's loaded with every
process, so the LoadLibrary is not loading any new DLL.
On Winstore/UWP apps you cannot use LoadLibrary, only LoadLibraryFromApp
which cannot be used to load system DLLs. Static linking in necessar
Any update on this ?
Just as in gettimeofday, one cannot use LoadLibrary to load system DLLs
in UWP builds. But they are available by static linking with windowsapp
and are guaranteed to be there.
On 2020-05-19 8:26, Steve Lhomme wrote:
LoadLibrary is forbidden in such apps (can only load DL
On Tue, 26 May 2020 21:14:12 -0700
"anton.paras" wrote:
> I posted to Stack Exchange, and they recommended that I file a bug. I'd
> rather not copy+paste it all, so here's the link:
>
>
>
> https://unix.stackexchange.com/questions/579889/why-doesnt-this-sed-command-replace-the-3rd-to-last-a
18 matches
Mail list logo
