Bruno Haible wrote:
What would be the benefit of doing so in gnulib? That some, but not all,
programs of a Linux distro can claim Y2038-proof-ness before all the rest?
Basically that, yes, though the benefit is not limited to Linux kernels. It
should work for FreeBSD too. (FreeBSD i386 still h
[Dropping libc-alpha from CC]
Hi Paul,
> I was thinking of something more ambitious: having Gnulib support 64-bit
> time_t on
> 32-bit glibc now, even before the Glibc support is in. In doing this, it
> would
> emulate the planned Glibc behavior by defining the Glibc macro's name (even
> tho
* config/srclist.txt: Gnulib and glibc regex code
are synchronized again.
---
ChangeLog | 6
config/srclist.txt | 86 --
2 files changed, 12 insertions(+), 80 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index c670b3962..a9e237899 1006
Albert ARIBAUD wrote:
Do code syncs from glibc to gnulib happen on new glibc releases?
It depends. Some of Gnulib syncs soon after a commit to glibc master. Other
parts of Gnulib sync more lackadasically. Glibc release boundaries don't matter
much.
Conversely, sometimes Glibc syncs files fr
Bruno Haible wrote:
3) During the next source-code sync from glibc to gnulib, involving mktime.c
etc., the gnulib people (likely Paul) make sure that this source code can
still be used on non-glibc platforms with either 32-bit time_t or 64-bit
time_t. Usually this involves a
Albert ARIBAUD wrote:
Although true for now, in the long run year2038 could be changed to enable
macros that will cause the implementation to use 64- instead of 32-bit time_t.
This is a plausible thing to do once glibc has such a macro.
Now I'm confused. I was under the impression that you wan
Albert ARIBAUD wrote:
I was thinking about the whole series branch that you requested for the
patch series in glibc. Won't you require a similar whole series branch
for gnulib?
Yes, that's the idea. It shouldn't be that big a deal, for Gnulib, as Gnulib
already works on both 32- and 64-bit tim
A note for when gnulib will add a 'renameat2' module:
- The glibc function is being introduced in 2.28.
- Cygwin has this function as well, but it "only supports the
RENAME_NOREPLACE flag". [1]
- Android might get the function in the future.
Bruno
[1] https://cygwin.com/cygwin-api/std-n
Bruno Haible wrote:
I agree only because 'coreutils' is the only user of 'renameat2', and Pádraig
is surely aware of the issue.
I already fixed Coreutils:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=439741053256618eb651e6d43919df29625b8714
* More generally, an incompatible cha
Paul Eggert wrote:
> > I would add a placeholder for the old module name,
> > for a period of transition. ...
>
> In the past, we've often avoided such placeholders, as Gnulib is a
> source-code
> module and people can upgrade at their leisure.
I disagree with the "can upgrade at their leisure"
Bonjour Paul,
Le Thu, 5 Jul 2018 12:45:30 -0700, Paul Eggert a
écrit :
> Albert ARIBAUD wrote:
>
> > Since gnulib is on Savannah, not Sourceware, I assume I will need to be
> > given some level of write access to the Savannah gnulib repository in
> > order to provide branches there too, similar
11 matches
Mail list logo
