Re: [PATCH 1/4] localename: -Wtautological-pointer-compare

2023-01-15 Thread Paul Eggert
On 2023-01-15 14:03, Bruno Haible wrote: My confusion arose partly because I am accustomed to languages where the distinction between null and non-null pointers is checked statically ... Oh, now I understand. May I guess the language: Haskell, OCaml, TypeScript, Rust? These days OCaml and ma

Re: [PATCH v2] Define alignof_slot using _Alignof when using C11 or newer

2023-01-15 Thread Khem Raj
On Sun, Jan 15, 2023 at 11:52 AM Paul Eggert wrote: > On 2023-01-14 17:51, Paul Eggert wrote: > > > We already have two copies of that stuff elsewhere (in lib/stdalign.in.h > > and m4/stdalign.m4), for reasons that currently escape me. > > To try to address that in an upward-compatible way, I ins

Re: RFC: git-commit based mtime-reproducible tarballs

2023-01-15 Thread Bruno Haible
Paul Eggert wrote: > some users want to "trust but verify" and a reproducible > tarball is easier to audit than a non-reproducible one, so for these > users it can be a win to omit the irrelevant data from the tarball. Reproducibility can be implemented in different ways: - by omitting irrelev

Re: [PATCH 1/4] localename: -Wtautological-pointer-compare

2023-01-15 Thread Bruno Haible
Hi Paul, > My confusion arose partly because I am accustomed to languages where the > distinction between null and non-null pointers is checked statically and > reliably, and I keep forgetting that with C, GCC and Clang are only poor > approximations to that Oh, now I understand. May I guess t

Re: [PATCH v2] Define alignof_slot using _Alignof when using C11 or newer

2023-01-15 Thread Paul Eggert
Oh, that patch had a misspelling "alignasf"; fixed by installing the attached further patch. From 784f8c776223ba3234c7673664f1fd2a9629bcda Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 15 Jan 2023 11:53:40 -0800 Subject: [PATCH] sys_socket: fix typo Fix typo in previous change. --- mo

Re: [PATCH v2] Define alignof_slot using _Alignof when using C11 or newer

2023-01-15 Thread Paul Eggert
On 2023-01-14 17:51, Paul Eggert wrote: We already have two copies of that stuff elsewhere (in lib/stdalign.in.h and m4/stdalign.m4), for reasons that currently escape me. To try to address that in an upward-compatible way, I installed the attached. This shrinks the number of copies of that c

Re: RFC: git-commit based mtime-reproducible tarballs

2023-01-15 Thread Paul Eggert
On 2023-01-15 05:21, Bruno Haible wrote: Reproducibility is about verifying that an artifact A was generated from a source S. Quite true. However, there's something else going on: when I do an 'ls -l' of a source directory that I got from a distribution tarball, it's useful to see the last ti

Re: RFC: git-commit based mtime-reproducible tarballs

2023-01-15 Thread Bruno Haible
Hi Simon, > > This attempts to make > > reproducible tarballs by sorting the files and passing the > > "--mtime=" option to tar. ... > Having the same mtime on all files in a tarball First question: What is the point of doing that? Reproducibility is about verifying that an artifact A was

Re: fpending Android bug

2023-01-15 Thread Po Lu
Bruno Haible writes: > Ah, now that makes sense: When they moved 'struct __sFILE' out of > into , they also removed its named fields. > > In other words, looking at the timeline of the Android API level 19 support: > - They added this support in NDK r10e, > - In NDK r13b the elements of a FI

RFC: git-commit based mtime-reproducible tarballs

2023-01-15 Thread Simon Josefsson via Gnulib discussion list
Hi. Quoting the recent binutils announcement: > As an experiment these tarballs were made with the new "-r " > option supported by the src-release.sh script. This attempts to make > reproducible tarballs by sorting the files and passing the > "--mtime=" option to tar. The date used for

Re: fpending Android bug

2023-01-15 Thread Bruno Haible
Po Lu wrote: > It doesn't compile because ->_p and ->_base are undefined in FILE *. > ... > I'm using the NDK r25b; however, bits/struct_file.h in the NDK r25b only > includes: > > __BEGIN_DECLS > > /** The opaque structure implementing `FILE`. Do not make any assumptions > about its content. */