Here comes the second part: Use of 'restrict' in non-POSIX function
declarations, excluding libunistring code.
2020-02-23 Bruno Haible
crypto/gc: Use 'restrict'.
* lib/gc.h (gc_pbkdf2_hmac, gc_pbkdf2_sha1): Use 'restrict'.
* m4/gc.m4 (gl_GC): Require AC_C_RESTRICT.
Paul improved the definitions of '_Restrict_' and '_Restrict_arr_' on
2018-06-28:
* lib/regex.h: Fix a problem with glibc installed-header checking,
as follows:
(_Restrict_): Prefer __restrict if defined or if GCC 2.95 or later.
(_Restrict_arr_): Prefer __restrict_arr if defined,
This patch, finally, makes use of 'restrict' also in the libunistring header
files.
2020-02-23 Bruno Haible
uni*/base: Use 'restrict'.
* lib/unitypes.in.h (_UC_RESTRICT): New macro, based on '_Restrict_'
from lib/regex.h.
* lib/unistr.in.h (u8_cpy, u16_cpy,
Hello,
I propose the following small addition to users.txt .
-assaf
>From b3bf948d4179ef144a87568ecd282e960f6bf293 Mon Sep 17 00:00:00 2001
From: Assaf Gordon
Date: Sun, 23 Feb 2020 23:07:42 -0700
Subject: [PATCH] users.txt: Add datamash, time
* users.txt: Add datamash, time.
---
ChangeLog
On 2/23/20 6:27 PM, Bruno Haible wrote:
Therefore I think we need to do two things:
* For those functions that may be stubs in glibc, define HAVE_FUNC to 1
instead of 0 if glibc implements it as a stub.
This sounds like it could lead to trouble, as it runs afoul of longstanding
On 2/22/20 3:46 PM, Bruno Haible wrote:
Oops, this change is broken: It causes a link error on Solaris 10:
I ran into that problem independently, and found that I had trouble reading the
code and there were some other obvious glitches in it. It seems that my original
patch was too
Hi Paul,
> found that I had trouble reading the code
That's probably because I prefer the "one code for each platform" approach when
suitable - because when debugging problems I don't like to rely to
$CC ... -E file.c > file.i
to tell me which code is actually enabled -, whereas you seem to
Paul Eggert wrote:
> On 2/23/20 2:58 AM, Bruno Haible wrote:
> > the file doc/glibc-functions/lchmod.texi still says
> >
> >...
> >This function always fails with @code{errno} set to @code{ENOSYS},
> >even when the file is not a symbolic link:
> >GNU/Linux with glibc 2.31.
> >
>
On 2/23/20 2:58 AM, Bruno Haible wrote:
the file doc/glibc-functions/lchmod.texi still says
...
This function always fails with @code{errno} set to @code{ENOSYS},
even when the file is not a symbolic link:
GNU/Linux with glibc 2.31.
Overriding the system's lchmod function requires
[Not related to gnulib, but of general interest anyway.]
You find in the Gnow-How wiki a writeup about profiling tools, how to use
them, and their respective advantages and drawbacks:
https://gitlab.com/ghwiki/gnow-how/-/wikis/Profiling/with_call_graph
If you would like to contribute to this
10 matches
Mail list logo