On 2023-07-17 10:12, Pádraig Brady wrote:
Right. In headers though, the traditional "static inline" idiom
Ah, I forgot that it was in system.h. At some point we should have
system.h use _GL_INLINE but that can wait.
On 17/07/2023 18:04, Paul Eggert wrote:
On 2023-07-17 03:31, Pádraig Brady wrote:
static inline void
As a general rule, there's no need for 'static inline' in C, as nowadays
compilers figure out inlining just fine for static functions and plain
'static' should be good enough. There are
On 2023-07-17 03:31, Pádraig Brady wrote:
static inline void
As a general rule, there's no need for 'static inline' in C, as nowadays
compilers figure out inlining just fine for static functions and plain
'static' should be good enough. There are exceptions but 'write_error'
doesn't look
On 17/07/2023 07:35, Bernhard Voelker wrote:
On 7/15/23 23:08, Pádraig Brady wrote:
The attached patch-set addresses two classes of issue:
1. Doubled error messages upon write errors
2. Continued processing upon write errors (the orig problem reported).
Nice work!
Patch 1:
> ---
On 7/15/23 23:08, Pádraig Brady wrote:
The attached patch-set addresses two classes of issue:
1. Doubled error messages upon write errors
2. Continued processing upon write errors (the orig problem reported).
Nice work!
Patch 1:
> --- /dev/null
> +++ b/tests/misc/write-errors.sh
> @@ -0,0
On 09/07/2023 23:54, Pádraig Brady wrote:
On 09/07/2023 20:11, Paul Eggert wrote:
On 2023-07-09 07:11, Pádraig Brady wrote:
Note the patch looks wrong as it would close the input always.
We can fix that up easily enough anyway.
If it's easy and doesn't hurt performance in the usual case,
On 09/07/2023 20:11, Paul Eggert wrote:
On 2023-07-09 07:11, Pádraig Brady wrote:
Note the patch looks wrong as it would close the input always.
We can fix that up easily enough anyway.
If it's easy and doesn't hurt performance in the usual case, that's of
course fine.
For my reference a
On 2023-07-09 07:11, Pádraig Brady wrote:
Note the patch looks wrong as it would close the input always.
We can fix that up easily enough anyway.
If it's easy and doesn't hurt performance in the usual case, that's of
course fine.
For my reference a short list of utils to check (that
On 09/07/2023 10:29, Paul Eggert wrote:
On 2023-07-08 15:43, Josef Bacik wrote:
A very weird bug was uncovered when using fstests with github actions.
In fstests we are doing something like this
od /dev/urandom | dd of=somefile bs=1M count=10
The above works fine, except in the case of github
On Jul 09 2023, Paul Eggert wrote:
> Do you see the same problem if you use 'cat' rather than 'od'? If so, the
> problem isn't with 'od'; it's with the environment, which is somehow set
> up to ignore SIGPIPE. It shouldn't do that, as ignoring SIGPIPE breaks a
> lot of programs, and 'od' would be
On 2023-07-08 15:43, Josef Bacik wrote:
A very weird bug was uncovered when using fstests with github actions.
In fstests we are doing something like this
od /dev/urandom | dd of=somefile bs=1M count=10
The above works fine, except in the case of github actions which runs
this script remotely,
A very weird bug was uncovered when using fstests with github actions.
In fstests we are doing something like this
od /dev/urandom | dd of=somefile bs=1M count=10
The above works fine, except in the case of github actions which runs
this script remotely, capturing the output in a pipe to print
12 matches
Mail list logo
