Remove 'const' attribute from free_permission_context to prevent
compilation error:
lib/acl-internal.h:300:3: error: 'const' attribute on function
returning 'void' [-Werror=attributes]
Signed-off-by: Carlos Santos
---
lib/acl-internal.h | 6 +-
1 file changed, 1 insertion(+), 5 deleti
On Sun, Jun 24, 2018 at 7:43 PM, Bruno Haible wrote:
> Jim Meyering asks:
>> I presume that by reporting this, you think gcc-4.8.5 is still worth
>> supporting?
>
> Sure. This version of GCC is the default one on RHEL 7.4 / PowerPC, which is a
> mainstream Linux distro that is less than 1 year ol
On 24/06/18 19:32, Bruno Haible wrote:
> This fixes the error message reported by Assaf Gordon on non-seekable
> input.
>
> Four approaches come to mind for fixing this:
> 1) Change the afalg_stream signature, adding an argument where the function
> can store read but not yet processed input.
Jim Meyering asks:
> I presume that by reporting this, you think gcc-4.8.5 is still worth
> supporting?
Sure. This version of GCC is the default one on RHEL 7.4 / PowerPC, which is a
mainstream Linux distro that is less than 1 year old. [1]
In gnulib we support GCC versions down to 3.1. They are
This fixes the error message reported by Assaf Gordon on non-seekable
input.
Four approaches come to mind for fixing this:
1) Change the afalg_stream signature, adding an argument where the function
can store read but not yet processed input.
2) Change the afalg_stream signature, passing it
On Sun, Jun 24, 2018 at 6:36 PM, Bruno Haible wrote:
> Jim Meyering wrote:
>> diff --git a/lib/parse-datetime.y b/lib/parse-datetime.y
>> index f14bb31dc..3d8666a4d 100644
>> --- a/lib/parse-datetime.y
>> +++ b/lib/parse-datetime.y
>> @@ -1766,6 +1766,11 @@ parse_datetime2 (struct timespec *result
Jim Meyering wrote:
> diff --git a/lib/parse-datetime.y b/lib/parse-datetime.y
> index f14bb31dc..3d8666a4d 100644
> --- a/lib/parse-datetime.y
> +++ b/lib/parse-datetime.y
> @@ -1766,6 +1766,11 @@ parse_datetime2 (struct timespec *result, char const
> *p,
>
>timezone_t tz = tzdefault;
>
> +
On 24/06/18 17:58, Bruno Haible wrote:
> afalg_stream is documented as "Read from the current position to the
> end of STREAM." However, the current behaviour after sendfile() succeeds
> is that the stream is in an unusable state (except for fclose): It still
> has buffers allocated, but the underl
afalg_stream is documented as "Read from the current position to the
end of STREAM." However, the current behaviour after sendfile() succeeds
is that the stream is in an unusable state (except for fclose): It still
has buffers allocated, but the underlying file descriptors is at a
different positio
Pádraig Brady wrote:
> I looked into this last night.
> My reading was if &off is specified, the offset remains unchanged.
>
> "If offset is not NULL, then sendfile()
>does not modify the file offset of in_fd;"
>
> So it doesn't look like this is required.
Thanks. I agree.
And since we bo
On Sun, Jun 24, 2018 at 5:00 PM, Bruno Haible wrote:
> Hi Jim, Paul,
>
>> parse-datetime.y: In function 'parse_datetime2':
>> parse-datetime.y:1791:19: error: jump skips variable initialization \
>> [-Werror=jump-misses-init]
Hi Bruno,
Didn't this warning or one very much like it catch real bu
Hi Jim, Paul,
> parse-datetime.y: In function 'parse_datetime2':
> parse-datetime.y:1791:19: error: jump skips variable initialization \
> [-Werror=jump-misses-init]
First this occurred in af_alg.c with pretty standard Linux kernel style
with gotos. [1] Now here.
What is the point of this warn
Fix canon-host.? properly:
>From e86c5da600df51198134e0e9641234bcbaeee852 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sun, 24 Jun 2018 16:54:43 -0700
Subject: [PATCH] canon-host: take GCC9's advice rather than ignoring warning
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Conten
On Sun, Jun 24, 2018 at 4:20 PM, Pádraig Brady wrote:
> On 24/06/18 16:10, Jim Meyering wrote:
>> +/* Without this pragma, gcc version 9.0.0 20180616 suggests that
>> + the canon_* functions might be candidateifor attribute 'malloc' */
>> +#if 9 <= __GNUC__
>> +# pragma GCC diagnostic ignored "
On 24/06/18 16:10, Jim Meyering wrote:
> +/* Without this pragma, gcc version 9.0.0 20180616 suggests that
> + the canon_* functions might be candidateifor attribute 'malloc' */
> +#if 9 <= __GNUC__
> +# pragma GCC diagnostic ignored "-Wsuggest-attribute=malloc"
> +#endif
typo in candidatefor
I tried to build coreutils using recent gcc, built from git, so it
calls itself "gcc version 9.0.0 20180616 (experimental) (GCC)".
There were three gnulib-related build failures. These were errors
solely because I also configured with --enable-gcc-warnings.
With these three changes to gnulib file
2018-06-24 Bruno Haible
af_alg tests: Add another test.
* tests/test-digest.h (test_digest_on_files): Also check a large file
with a skipped header.
* tests/test-md5.c: Include macros.h.
* tests/test-sha1.c: Likewise.
* tests/test-sha256.c: Likewi
On 24/06/18 15:40, Bruno Haible wrote:
> In afalg_stream, if the stream refers to a regular file, and sendfile() fails,
> do we have a guarantee that the offset of the file descriptor remains
> unchanged?
>
> The man page at http://man7.org/linux/man-pages/man2/sendfile.2.html doesn't
> say so.
In afalg_stream, if the stream refers to a regular file, and sendfile() fails,
do we have a guarantee that the offset of the file descriptor remains unchanged?
The man page at http://man7.org/linux/man-pages/man2/sendfile.2.html doesn't
say so.
How about this, then? Does this look right?
2018-0
Mostly comment fixes:
- Clarify that the bug in Linux < 4.9 was discovered in Sept. 2016
but not fixed until Nov. 2016.
- & others.
2018-06-24 Bruno Haible
af_alg: Comment and style improvements.
* lib/af_alg.c (alg_socket): Use 'size_t' as index into a string.
Pádraig Brady wrote:
> I'll push this in a while.
Thanks.
> diff --git a/lib/md5.c b/lib/md5.c
> index ea69a59..2b55cc6 100644
> --- a/lib/md5.c
> +++ b/lib/md5.c
> @@ -172,7 +172,9 @@ md5_stream (FILE *stream, void *resblock)
> {
>/* Either process a partial fread() from thi
On 24/06/18 14:34, Bruno Haible wrote:
> Hi Pádraig,
>
> The patch looks good. Just nitpicking about the comments:
>
>> + /* Either process a partial fread() from this loop,
>> + or the fread() in afalg_stream may have gotten EOF.
>> + We need to avoid a subsequen
Hi Pádraig,
The patch looks good. Just nitpicking about the comments:
> + /* Either process a partial fread() from this loop,
> + or the fread() in afalg_stream may have gotten EOF.
> + We need to avoid a subsequent fread() due to glibc BZ 1190. */
We need to av
Pádraig Brady wrote:
> > All the kernel routines were seen to be significantly slower
> > with these relatively recent components on an i3-2310M system:
> > kernel-4.10.6-200.fc25.x86_64
> > openssl-1.0.2m-1.fc25.x86_64
> > sha1 was nearly twice as slow in the kernel for example.
>
> Assaf Gor
On 24/06/18 12:31, Paul Eggert wrote:
> Pádraig Brady wrote:
>> Assaf Gordon has just detailed more reasons why af_alg
>> should not be enabled by default at:
>> https://lists.gnu.org/archive/html/coreutils/2018-06/msg00034.html
>
> Thanks for the pointer. I was meaning to disable af_alg by defaul
Pádraig Brady wrote:
Assaf Gordon has just detailed more reasons why af_alg
should not be enabled by default at:
https://lists.gnu.org/archive/html/coreutils/2018-06/msg00034.html
Thanks for the pointer. I was meaning to disable af_alg by default myself, as
the arguments against it were pretty
On 24/06/18 02:24, Pádraig Brady wrote:
> All the kernel routines were seen to be significantly slower
> with these relatively recent components on an i3-2310M system:
> kernel-4.10.6-200.fc25.x86_64
> openssl-1.0.2m-1.fc25.x86_64
> sha1 was nearly twice as slow in the kernel for example.
Assa
On 24/06/18 07:24, Bruno Haible wrote:
> Pádraig Brady wrote:
>> I'm going to apply my whar-single module to gnulib to tweak
>> it so the main bottleneck of calling locale_charset repeatedly
>> is removed from wcwidth() and mbrtowc(), in a simple manner,
>> without the need for another API.
>
> Th
Hi Paul,
> I would like to keep Gnulib cdefs.h in sync with glibc as much as
> possible, and installed the attached.
The __nonnull handling here is more risky than my patch. But it works on
FreeBSD 11.
> I hope this sort of thing is a one-off.
>
> I guess you're suggesting two include files? c
Bruno Haible wrote:
IMO the only way to reliably use would be that after
including it, you don't include any system headers any more.
Thanks for checking the port to FreeBSD 11. It appears that the problem is
planned to go away in FreeBSD 12 (they've removed the cdefs.h __inline #define
in t
Pádraig Brady wrote:
> I'm going to apply my whar-single module to gnulib to tweak
> it so the main bottleneck of calling locale_charset repeatedly
> is removed from wcwidth() and mbrtowc(), in a simple manner,
> without the need for another API.
This patch has two problems:
1) It introduces a te
All the kernel routines were seen to be significantly slower
with these relatively recent components on an i3-2310M system:
kernel-4.10.6-200.fc25.x86_64
openssl-1.0.2m-1.fc25.x86_64
sha1 was nearly twice as slow in the kernel for example.
* m4/af_alg.m4: Require --with-linux-crypto to enable.
* lib/af_alg.c (afalg_stream): Don't assume EOF is sticky,
and thus avoid doing a fread() when feof() is set.
* lib/md5.c: Ensure feof() is called before fread().
* lib/sha1.c: Likewise.
* lib/sha256.c: Likewise.
* lib/sha512.c: Likewise.
---
ChangeLog| 10 ++
lib/af_alg.c | 12 +++
* lib/af_alg.c (afalg_stream): Handle the case where we've
successfully written data to the kernel in the read/write loop,
but the kernel doesn't respond with the hash.
---
lib/af_alg.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/lib/af_alg.c b/lib/af_alg.c
index ded4
34 matches
Mail list logo
