Re: Portability issues with scractch_buffer

My guess is that the preprocessor expands __has_attribute (__fallthrough__) to 1 but the attribute does not actually work. Is that the case? has_attribute is indeed 1. Looking at the Clang 3.4 source code, I don't see how that could be, as clang-3.4/include/clang/Basic/Attr.td lists the clan

Re: ptsname_r on Cygwin

On 1/21/2021 3:26 PM, Bruno Haible wrote: Ken Brown wrote: Thanks for the report. I've submitted a patch that fixes this: https://cygwin.com/pipermail/cygwin-patches/2021q1/010995.html Thanks. EBADF is the more "proper" errno value here, for fd < 0. But glibc produces errno ENOTTY in thi

Re: canonicalize test failures on Cygwin

Ken Brown wrote: > Thanks for confirming. I've submitted a patch that fixes this: > >https://cygwin.com/pipermail/cygwin-patches/2021q1/010985.html Thanks. > This fixes a failing gnulib test of realpath(3). More importantly, it fixes a POSIX compliance issue: https://pubs.opengroup.org/onl

Re: ptsname_r on Cygwin

Ken Brown wrote: > Thanks for the report. I've submitted a patch that fixes this: > >https://cygwin.com/pipermail/cygwin-patches/2021q1/010995.html Thanks. EBADF is the more "proper" errno value here, for fd < 0. But glibc produces errno ENOTTY in this case; so it should be acceptable too.

Re: canonicalize test failures on Cygwin

On 1/20/2021 3:31 AM, Bruno Haible wrote: Ken Brown wrote: I took a quick look, and it appears that this is a Cygwin bug in which realpath() fails with ENOENT instead of ENOTDIR. Yes, I confirm. POSIX says that when one

Re: ptsname_r on Cygwin

Hi Bruno, On 1/20/2021 1:31 AM, Bruno Haible wrote: Hi Ken, On Cygwin 2.9 (64-bit) I see a test failure in test-ptsname_r.c, here: { char buffer[256]; int result; result = ptsname_r (-1, buffer, sizeof buffer); ASSERT (result != 0); // < HERE

Re: link dependencies

> The 'Link' section in the module description is only informative. > > Originally, we thought that it would be good to note, in the 'Link' > section, > only the immediate link dependencies of the module, and let the user > use > ./gnulib-tool --extract-recursive-link-directive MODULE > for the

Re: link dependencies

Simon Josefsson wrote: > > > > +Link: > > +$(LIB_GETRANDOM) > > + > > License: > > LGPLv2+ > > Is this part needed? The module depends on getrandom. Is it because > that is only a conditional dependency? > > > diff --git a/modules/crypto/gc-tests b/modules/crypto/gc-tests > > index 7b153d1.

Re: [PATCH] gc-random: Replace implementation with call to getrandom.

Bruno Haible writes: > Hi Simon, > >> Hi. I re-read the discussion around getrandom vs gc-random and didn't >> see any point in keeping the duplicated code. I believe the >> getrandom-approach is better than what was in gc-gnulib.c today, so this >> patch make it use that function. I have push