Re: done digging around test-dprintf-posix2

On Sun, Jan 9, 2011 at 10:44 PM, Bruno Haible wrote: > Bruce Korb wrote: >> SYS_brk(NULL)                                    = 0x00606000 >> SYS_brk(0x00627000)                              = 0x00606000 >> SYS_mmap(0, 0x10, 3, 34, 0x)         = -12 > > I don't understand this. The brk

Re: fnmatch sometimes defined to posix_fnmatch

On 10-Jan-2011, Bruno Haible wrote: | These are simply the old replacement idioms that are not C++ safe. | We introduced the C++ safe idioms for most header files in March 2010, | but the old idioms are still used in a couple of places: | | m4/eaccess.m4:[AC_DEFINE([eaccess], [access], | m4/f

Re: configmake doc?

* Karl Berry wrote on Mon, Jan 10, 2011 at 01:36:51AM CET: > (Eric/Ralf, you can add a specific reference to the new "configmake" > node from the Automake/Autoconf manuals now if you wish.) Done. Thanks, Ralf docs: link to Gnulib configmake documentation. * doc/autoconf.texi (Defini

Re: done digging around test-dprintf-posix2

On 01/09/11 13:15, Bastien ROUCARIES wrote: >> SYS_brk(NULL)= 0x00606000 >> SYS_brk(0x00627000) = 0x00606000 >> SYS_mmap(0, 0x10, 3, 34, 0x) = -12 >> SYS_mmap(0, 0x800, 0, 16418, 0x) = -12 >> SYS_mm

Re: fnmatch sometimes defined to posix_fnmatch

Hi John, > I received a bug report for Octave that was the result of fnmatch > being defined to posix_fnmatch in config.h. I think this is due to > > AC_DEFINE_UNQUOTED([fnmatch], [${gl_fnmatch_required_lowercase}_fnmatch], > [Define to a replacement function name for fnmatch().]) > >

Re: what's a stable release?

On 01/09/11 16:36, Karl Berry wrote: > In gnulib-intro.texi, I noticed some text: > > We also make stable releases every two months, at > @url{http://erislabs.net/ianb/projects/gnulib/}. > > I wasn't aware this was being promulgated as an official release that > "we" make. I do hope we d

Re: what's a stable release?

Hi Karl, About : > Anyway, what's stable about it? It means that these releases are mostly free from occasional regressions. > As far as I was aware, Gnulib did not > promise any stability of anything at any level or

Re: done digging around test-dprintf-posix2

On 01/09/11 13:44, Bruno Haible wrote: > Bruce Korb wrote: >> SYS_brk(NULL)= 0x00606000 >> SYS_brk(0x00627000) = 0x00606000 >> SYS_mmap(0, 0x10, 3, 34, 0x) = -12 > > I don't understand this. The brk area contains

what's a stable release?

In gnulib-intro.texi, I noticed some text: We also make stable releases every two months, at @url{http://erislabs.net/ianb/projects/gnulib/}. I wasn't aware this was being promulgated as an official release that "we" make. Anyway, what's stable about it? As far as I was aware, Gnulib di

Re: configmake doc?

Currently the doc is in the module description (lines 13..25 of modules/configmake), which is an unusual place. Feel free to move it to a new file doc/configmake.texi, I did. Thanks for the specific instructions :). (Eric/Ralf, you can add a specific reference to the new "configmake

fnmatch sometimes defined to posix_fnmatch

I received a bug report for Octave that was the result of fnmatch being defined to posix_fnmatch in config.h. I think this is due to AC_DEFINE_UNQUOTED([fnmatch], [${gl_fnmatch_required_lowercase}_fnmatch], [Define to a replacement function name for fnmatch().]) in gnulib's fnmatch.m4

Re: done digging around test-dprintf-posix2

Bruce Korb wrote: > SYS_brk(NULL)= 0x00606000 > SYS_brk(0x00627000) = 0x00606000 > SYS_mmap(0, 0x10, 3, 34, 0x) = -12 I don't understand this. The brk area contains 132 KiB, and an attempt to mmap 1 MB fails. Wher

Re: done digging around test-dprintf-posix2

On Sun, Jan 9, 2011 at 7:46 PM, Bruce Korb wrote: > Hi Bruno, > > .. > __libc_start_main(0x4009c0, 2, 0x7fff27c151e8, 0x4036d0, 0x403760 ...> > getrlimit(2, 0x7fff27c150e0, 0x7fff27c15200, 0x7f2965bfe4a8, 0x7f2965bff320 > > SYS_getrlimit(2, 0x7fff27c150e0)                 = 0 > <...

Re: uninorm/nfc - Unicode version?

Bruno Haible writes: > I have now updated the Unicode related modules to Unicode 5.2.0. > The process involves more than just regenerating data files. It also > requires to update some functions in gen-uni-tables.c to match the updated > Unicode Standard Annexes. > > There was some significant ch

Re: done digging around test-dprintf-posix2

Hi Bruno, On 01/07/11 21:17, Bruno Haible wrote: > Hi Bruce, > >> I now believe it completely correct to add this: free(malloc(0x88)) >> to the program and put it into the main line until the real cause >> (glibc or kernel) is determined and fixed. > > What is your explanation of why that free(

Re: Unicode version and libidna

Bruno Haible writes: >> Once I have established a good set of self tests, I will run them both >> against libunistring for 5.0.0 and 5.2.0 to see if I can find any string >> that behaves differently. > > I've now pushed an update to Unicode 6.0.0 as well. So, by choosing the > appropriate gnulib

Re: Unicode version and libidna

> Once I have established a good set of self tests, I will run them both > against libunistring for 5.0.0 and 5.2.0 to see if I can find any string > that behaves differently. I've now pushed an update to Unicode 6.0.0 as well. So, by choosing the appropriate gnulib commit when you run ./autogen.s

Re: [PATCH] git-merge-changelog: fix missing space after conflict markers

Bruno Haible writes: > Andreas Schwab wrote: >> >> As required by git. >> > >> > What do you mean by that? >> >> See rerere.c:is_cmarker. > > Please give a "how to reproduce". Enable rerere and cherry-pick a conflicting changelog. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fin

Re: [PATCH] git-merge-changelog: fix missing space after conflict markers

Andreas Schwab wrote: > >> As required by git. > > > > What do you mean by that? > > See rerere.c:is_cmarker. Please give a "how to reproduce". git-merge-changelog fails with an exit code 1 when there is a conflict. This should be enough to alert git about a merge problem and let it hand over th

Re: [PATCH] git-merge-changelog: fix missing space after conflict markers

Bruno Haible writes: > Hello Andreas, > >> As required by git. > > What do you mean by that? See rerere.c:is_cmarker. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."

Re: uninorm/nfc - Unicode version?

Bruno Haible writes: > Hi Simon, > >> There is no hurry, I'm mostly curious about what kind of >> non-trivial changes there would be. I know that between 5.2 and 6.0 >> there were some changes made that would affect a IDNA2008 implementation >> for example. >> >> The best would be if the proces

Re: [PATCH] git-merge-changelog: fix missing space after conflict markers

Hello Andreas, > As required by git. What do you mean by that? The user is expected to resolve the conflict, and this implies removing the <<< and >>> markers, before doing "git add conflicting-file". In other words: Please give a reproducible recipe for experiencing a problem that occur

Re: uninorm/nfc - Unicode version?

Hi Simon, > There is no hurry, I'm mostly curious about what kind of > non-trivial changes there would be. I know that between 5.2 and 6.0 > there were some changes made that would affect a IDNA2008 implementation > for example. > > The best would be if the process to re-generate the files were

[PATCH] git-merge-changelog: fix missing space after conflict markers

As required by git. Andreas. 2011-01-09 Andreas Schwab * lib/git-merge-changelog.c (conflict_write): Add space after conflict marker. --- lib/git-merge-changelog.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/git-merge-changelog.c b/lib/git-

Re: [coreutils] [PATCH] coreutils buglets, useless-if-before-free

Karl Heuer wrote: > `useless-if-before-free --help' prints a literal > NUL character instead of the backslash-zero that > was intended. Also, the "must lie within the > first 8 lines" line is on line 9, and hence not > getting automatically updated. This patch fixes > the former by adding a backs