Daiki Ueno wrote:
> Afterwards, I realized a
> compilation error in the test code on FreeBSD, so I've added the
> follow-up patch attached.
Indeed, octal and hexadecimal escape sequences are not limited to 3 or 2
digits. ISO C 11 section 6.4.4.4 says:
"The hexadecimal digits that follow the
Bruno Haible writes:
>> + ASSERT (fwrite (DATA, 1, sizeof(DATA)-1, f) == sizeof(DATA)-1);
> ...
>> + ASSERT (fread (buf, 1, sizeof(buf), f) == sizeof(DATA)-1);
>
> GNU coding style wants a space between 'sizeof' and the opening parenthesis.
> Other than that, your patch is perfect.
Thank you
Hi Daiki,
Thank you for noticing this, and the rapid fix.
> Sorry, attached an old patch; this would be simpler (and also supports
> other platforms that need O_BINARY).
> + ASSERT (fwrite (DATA, 1, sizeof(DATA)-1, f) == sizeof(DATA)-1);
...
> + ASSERT (fread (buf, 1, sizeof(buf), f) ==
Daiki Ueno writes:
> Bruno Haible writes:
>
>>> Here are proposed patches for other modules. Does this look right?
>>
>> There were no objections. I pushed the changes.
>
> Thank you for this. I have rebased GnuTLS on top of it, but noticed a
> strange test failures on Windows CI, which
Bruno Haible writes:
>> Here are proposed patches for other modules. Does this look right?
>
> There were no objections. I pushed the changes.
Thank you for this. I have rebased GnuTLS on top of it, but noticed a
strange test failures on Windows CI, which involve reading binary files
(OCSP
> Here are proposed patches for other modules. Does this look right?
There were no objections. I pushed the changes.
Bruno
Hi Daiki,
> > Thank you for this; would it make sense to use it in the modules that do
> > one-shot fopen/fclose, such as read-file?
Here are proposed patches for other modules. Does this look right?
Note: The patch to sethostname.c is only relevant for Minix. Minix does not
have multithreading
Hi Daiki,
> Thank you for this; would it make sense to use it in the modules that do
> one-shot fopen/fclose, such as read-file?
This would improve things for multithreaded programs that call exec or
posix_spawn. There are not that many programs of this kind. But on the other
hand,
Hello Bruno,
Bruno Haible writes:
> Additionally, gnulib is the right place to do this because - as Eric said -
> the 'e' flag is already scheduled for being added to the next POSIX version:
> https://www.austingroupbugs.net/view.php?id=411
>
> My evaluation of current platform support was
Tim Rühsen wrote on 2020-05-12:
> > How about using open() with O_CLOEXEC, and then fdopen()?
>
> Thanks. Sure, this is possible. Doing so at dozens of places (or more)
> asks for an implementation in gnulib :)
Additionally, gnulib is the right place to do this because - as Eric said -
the 'e'
Hi Bruno,
On 11.05.20 18:37, Bruno Haible wrote:
> Hi Tim,
>
>> i would like to ask for your expert knowledge.
>>
>> How to prevent file descriptor leaks in a multi-threaded application
>> that fork+exec. Quick answer is surely "use O_CLOEXEC" to close those
>> file descriptors on exec.
>>
>>
On 5/11/20 11:37 AM, Bruno Haible wrote:
POSIX [2][3], macOS [4], FreeBSD [5], Solaris [6] don't support this 'e' flag.
Although it _is_ slated to be added in a future revision of POSIX:
https://www.austingroupbugs.net/view.php?id=411
How about using open() with O_CLOEXEC, and then
Hi Tim,
> i would like to ask for your expert knowledge.
>
> How to prevent file descriptor leaks in a multi-threaded application
> that fork+exec. Quick answer is surely "use O_CLOEXEC" to close those
> file descriptors on exec.
>
> But how does this work with fopen in a portable way ?
> GNU
13 matches
Mail list logo
