Re: [PATCH 2/2] gitlog-to-changelog: support 'tiny change' commits.

Can we just take the difference between lines added and lines removed per patch, and automatically add the (tiny change) annotation to the generated ChangeLog if that turns out to be 5 or less? I tend to think not, I tend to agree with you, for the reasons you state. (Unfortunat

Re: gl_FUNC_FSTATAT doesn’t support cross-compilation

Hi, Bruno Haible skribis: > + [case "$host_os" in > +linux*) gl_cv_func_fstatat_zero_flag="guessing yes";; > +*) gl_cv_func_fstatat_zero_flag="guessing no";; I’m actually interested in cross-compilation to GNU/Hurd, which doesn’t have the problem I suppose.

Re: [PATCH 2/4] ptsname_r-tests: new test module

On 11/10/2011 06:02 AM, Eric Blake wrote: Not necessarily. On many of the existing standardized *_r functions, and more particularly on ptsname_r, POSIX requires that the function returns ^ Correction - the closest existing standardized function I had in mind is

Re: [PATCH 2/4] ptsname_r-tests: new test module

Eric Blake wrote: > I'd expect > a POSIX standardization of ptsname_r to require the return value to be > ERANGE, and leave errno unspecified. Sounds plausible. Thanks for explaining. Bruno -- In memoriam Cornstalk

Re: [PATCH 2/4] ptsname_r-tests: new test module

On 11/10/2011 05:57 AM, Bruno Haible wrote: * tests/test-ptsname_r.c: New file. You are testing that the return value in case of failure is == errno. This is not documented, neither in the glibc documentation, nor in the Linux man page. Why should people write if (result == EINVAL) when

Re: [PATCH 2/4] ptsname_r-tests: new test module

> * tests/test-ptsname_r.c: New file. You are testing that the return value in case of failure is == errno. This is not documented, neither in the glibc documentation, nor in the Linux man page. Why should people write if (result == EINVAL) when they can just as well write if (errno ==

Re: [PATCH 2/4] ptsname_r-tests: new test module

Eric Blake wrote: > + result = ptsname_r (fd, NULL, 0); On glibc 2.11, with CPPFLAGS=-Wall, this code gives a warning: test-ptsname_r.c: In function 'test_errors': test-ptsname_r.c:88:3: warning: null argument where non-null required (argument 2) I'm copying the trick from test-memmem.c: 201

Re: ptsname_r on OSF/1

Let's try to deal with the compilation error first: > * OSF/1 5.1: > > Compilation error > > cc -O -DHAVE_CONFIG_H -I. -I.. -DGNULIB_STRICT_CHECKING=1 > -DIN_GNULIB_TESTS=1 -I. -I. -I.. -I./.. -I../gllib -I./../gllib -c > test-ptsname_r.c > cc: Error: test-ptsname_r.c, line 22: In the

Re: gl_FUNC_FSTATAT doesn’t support cross-compilation

Paul Eggert wrote: > >> > One possibility is to assume that AIX 7.1 is the only > >> > target platform with that bug -- that would be easier > >> > to maintain > > Yes, this appears to be the case. > > OK, let's go with that then. Or perhaps, a bit more > conservatively, we can assume that AIX is

Re: [PATCH 1/4] ptsname_r: new module

Paul Eggert wrote: > From my point of view, we shouldn't design manuals that are hard to > read under Emacs. The default choice of the "face" 'nobreak-space' is apparently intentional. In my opinion it makes sense for editable buffers, but is not the right thing for presentation modes (like Info-m

ptsname_r testing

Eric Blake wrote: > Now we get to work on addressing the platform fallout Here are my findings, with a testdir built for --avoid=pt_chown openpty ptsname_r * Linux/glibc 2.11: All tests passed. * MacOS X 10.5: All tests passed. * FreeBSD 6.4: PASS: test-ptsname test-ptsname_r.c:187: assertio

Re: [PATCH 1/4] ptsname_r: new module

Jim Meyering wrote: > They tend to cause confusion (at least with me) > because they look like a space in many contexts, yet when you search > for the explicit space, you will not find those as matches. Good point, yes. Things like that can drive people crazy. Bruno -- In memoriam Cornstalk