Re: M4 1.4.14 on AIX 7.1BETA

Hi Rainer, > I now have tested M4 1.4.14 on AIX 7.1BETA. ... The problems you showed may have already been resolved in newer versions of gnulib. For this reason, it would be most helpful if you could use this testdir from today's gnulib: http://www.haible.de/bruno/gnu/gnulib-

Re: regex [was: M4 1.4.14 on AIX 7.1BETA]

On Fri, Jul 30, 2010 at 01:03, Eric Blake wrote: > On 07/29/2010 11:19 AM, Paolo Bonzini wrote: >> On 07/29/2010 07:10 PM, Eric Blake wrote: >>> On 07/29/2010 10:46 AM, Rainer Tammer wrote: *If I use M4 1.4.14.6-ffa0:* # ../src/m4 164.regexp ../src/m4:164.regexp:10: bad regular

[PATCH] strtod: fix replacement bug on AIX.

* lib/strtod.c (strtod): Special case broken "0x" parse in underlying strtod. Reported by Rainer Tammer. Signed-off-by: Eric Blake --- > test-strtod.c:389: assertion failed > > > > { > > const char input[] = "0x"; > > char *ptr; > > double result; > > errno = 0; > > result

Re: regex [was: M4 1.4.14 on AIX 7.1BETA]

On 07/29/2010 11:19 AM, Paolo Bonzini wrote: > On 07/29/2010 07:10 PM, Eric Blake wrote: >> On 07/29/2010 10:46 AM, Rainer Tammer wrote: >>> *If I use M4 1.4.14.6-ffa0:* >>> >>> # ../src/m4 164.regexp >>> ../src/m4:164.regexp:10: bad regular expression: `\<[a-z]\w+': Memory >>> exhausted >> >> ...a

Re: license alteration for chown/lchown

On 07/29/2010 04:47 PM, David Lutterkort wrote: > On Thu, 2010-07-29 at 15:46 -0600, Eric Blake wrote: >> On 07/29/2010 03:42 PM, David Lutterkort wrote: For your request, the following contributors since 2007-10-07 would have to agree: >>> >>> Don't forget Jim, who is cited as the o

Re: license alteration for chown/lchown

On Thu, 2010-07-29 at 15:46 -0600, Eric Blake wrote: > On 07/29/2010 03:42 PM, David Lutterkort wrote: > >> > >> For your request, the following contributors since 2007-10-07 > >> would have to agree: > > > > Don't forget Jim, who is cited as the original author of chown and > > lchown in the sour

Re: license alteration for chown/lchown

David Lutterkort wrote: > > Is it possible to change these modules licenses to LGPLv2+? > > Have you considered releasing your library under LGPLv3+? > > Adam is asking because he's working on porting augeas[1] to mingw; > relicensing augeas under LGPLv3+ is not really an option, since most of > i

Re: license alteration for chown/lchown

David Lutterkort wrote: > Don't forget Jim, who is cited as the original author of chown and > lchown in the source. Yes, you're right. We need Jim's agreement for lib/chown.c and lib/lchown.c, since before 2007-10-07, these files were under GPLv2+, not LGPLv2+. My mistake, sorry. I'm glad you ca

Re: Question about some fields in regex's re_pattern_buffer

On 29 July 2010 23:14, Bruno Haible wrote: > Reuben Thomas wrote: >> Thanks. I guess I should report this documentation bug somewhere, but >> where? (As mentioned in a recent message to this list, I've not had >> much mileage from reporting similar things to glibc in the past.) > > The place to re

Re: Question about some fields in regex's re_pattern_buffer

Reuben Thomas wrote: > Thanks. I guess I should report this documentation bug somewhere, but > where? (As mentioned in a recent message to this list, I've not had > much mileage from reporting similar things to glibc in the past.) The place to report it is glibc bugzilla

Re: license alteration for chown/lchown

On 07/29/2010 03:42 PM, David Lutterkort wrote: >> >> For your request, the following contributors since 2007-10-07 >> would have to agree: > > Don't forget Jim, who is cited as the original author of chown and > lchown in the source. Anything changes made before 2007, including original content,

Re: license alteration for chown/lchown

On 07/29/2010 02:35 PM, Bruno Haible wrote: > Adam Stokes wrote: >> Is it possible to change these modules licenses to LGPLv2+? > > Have you considered releasing your library under LGPLv3+? > > For your request, the following contributors since 2007-10-07 > would have to agree: > > Module

Re: license alteration for chown/lchown

On Thu, 2010-07-29 at 22:35 +0200, Bruno Haible wrote: > Adam Stokes wrote: > > Is it possible to change these modules licenses to LGPLv2+? > > Have you considered releasing your library under LGPLv3+? > > For your request, the following contributors since 2007-10-07 > would have to agree: > >

Re: Tests not being run for some shells

[adding bug-gnulib, since gzip borrows tests/init.sh from there] > Index: tests/init.sh > === > --- tests/init.sh.orig 2010-01-08 18:12:20.0 + > @@ -253,3 +253,7 @@ >&& . "$srcdir/init.cfg" > > setup_ "$@" > +# Thi

Re: license alteration for chown/lchown

Adam Stokes wrote: > Is it possible to change these modules licenses to LGPLv2+? Have you considered releasing your library under LGPLv3+? For your request, the following contributors since 2007-10-07 would have to agree: Module Source file Contributors --

Re: Question about some fields in regex's re_pattern_buffer

On 29 July 2010 20:25, Bruno Haible wrote: > Reuben Thomas wrote: >> /* This data structure represents a compiled pattern.  Before calling >>    the pattern compiler, the fields `buffer', `allocated', `fastmap', >>    `translate', and `no_sub' can be set.  After the pattern has been >>    compiled

license alteration for chown/lchown

Is it possible to change these modules licenses to LGPLv2+? Thank you -Adam

Re: Question about some fields in regex's re_pattern_buffer

Reuben Thomas wrote: > /* This data structure represents a compiled pattern.  Before calling >    the pattern compiler, the fields `buffer', `allocated', `fastmap', >    `translate', and `no_sub' can be set.  After the pattern has been >    compiled, the `re_nsub' field is available.  All other fie

Question about some fields in regex's re_pattern_buffer

(Thanks for helping with my last question; here's another:) re_pattern_buffer contains the following three fields: /* If set, a beginning-of-line anchor doesn't match at the beginning of the string. */ unsigned __REPB_PREFIX(not_bol) : 1; /* Similarly for an end-of-line anchor. */

Re: strtod [was: M4 1.4.14 on AIX 7.1BETA]

Hello Eric, On 29.07.2010 15:17, Eric Blake wrote: > ... cut for clarity ... >> /* Define to 1 if strtod is declared even after undefining macros. */ >> #define HAVE_RAW_DECL_STRTOD 1 > That's not quite what I asked. But thanks for the attachments: looking > at config.log reveals the answers to

Help with openpty

Dear all, I am trying to use the openpty macro, but I encounter a problem: everything works fine on a Mac OS X computer, but the test fails on a Linux one. In particular, the PTY headers are founds #define HAVE_DECL_OPENPTY 1 but I still get no openpty function /* #undef HAVE_OPENPTY */ Looki

Re: regex [was: M4 1.4.14 on AIX 7.1BETA]

On 07/29/2010 07:10 PM, Eric Blake wrote: On 07/29/2010 10:46 AM, Rainer Tammer wrote: *If I use M4 1.4.14.6-ffa0:* # ../src/m4 164.regexp ../src/m4:164.regexp:10: bad regular expression: `\<[a-z]\w+': Memory exhausted ...and has since regressed. Looks like we have a suspect... commit 602e

Re: regex [was: M4 1.4.14 on AIX 7.1BETA]

On 07/29/2010 10:46 AM, Rainer Tammer wrote: >>> + m4:stdin:4: bad regular expression: `^': Memory exhausted >> That's more than just the strtod test failing, > unfortunately yes, the older version was much better (in this way). >> and not the sort of thing >> I like to see. The gnulib regex code

Re: c-stack [was: M4 1.4.14 on AIX 7.1BETA]

On 07/29/2010 10:59 AM, Eric Blake wrote: > On 07/29/2010 10:46 AM, Rainer Tammer wrote: >> >> And test-c-stack also dumps: >> >> # dbx test-c-stack >> Type 'help' for help. >> reading symbolic information ... >> (dbx) where >> __start() at 0x1150 >> (dbx) > > Ouch. Did AIX stack overflow han

Re: c-stack [was: M4 1.4.14 on AIX 7.1BETA]

On 07/29/2010 10:46 AM, Rainer Tammer wrote: > > And test-c-stack also dumps: > > # dbx test-c-stack > Type 'help' for help. > reading symbolic information ... > (dbx) where > __start() at 0x1150 > (dbx) Ouch. Did AIX stack overflow handling change between 6 and 7? Do you have GNU libsigse

Re: strtod [was: M4 1.4.14 on AIX 7.1BETA]

[again, please keep the lists in the loop; and splitting my reply to multiple topics] On 07/29/2010 10:46 AM, Rainer Tammer wrote: > Hello Eric, > source: m4-1.4.14.6-ffa0 >>> 1. The test-strtod is still failing >>> >>> # ./test-strtod (compiled and executet manually) >>> test-strtod.c:389: asser

Re: [PATCH v2 0/5] Speed up uNN_chr and uNN_strchr with Boyer-Moore algorithm

On 07/29/2010 06:00 PM, Pádraig Brady wrote: On 29/07/10 16:29, Paolo Bonzini wrote: if (!needle[0]) return haystack; n = u8_mbtouc(&uc, needle, 4); ^ u8_strmbtouc here as suggested by Bruno. u8_strmbtouc also checks itself for NULL, and returns zero in that cas

guarantees of u8_mbtouc/u8_strmbtouc (was Re: [PATCH v2 0/5] Speed up uNN_chr and uNN_strchr with Boyer-Moore algorithm)

On 07/29/2010 05:36 PM, Bruno Haible wrote: You should better use u8_strmbtouc in this case. Aha, that's true. This function is a better match, but only because it supports CONFIG_UNICODE_SAFETY and is faster in that case (because it can just compare with zero). Still, without safety u8_st

Re: strtod [was: M4 1.4.14 on AIX 7.1BETA]

[let's keep the list in the loop] On 07/29/2010 09:47 AM, Rainer Tammer wrote: > Hello, > > On 29.07.2010 17:26, Eric Blake wrote: >> On 07/29/2010 09:26 AM, Rainer Tammer wrote: >>> Hello Eric, >>> FYI, config.guess is on git (this was really fast). >> Indeed - but it hasn't percolated to gnul

Re: [PATCH v2 0/5] Speed up uNN_chr and uNN_strchr with Boyer-Moore algorithm

On 07/29/2010 05:36 PM, Bruno Haible wrote: Paolo Bonzini wrote: The point is that u8_mbtouc will look only one byte past the end of a (valid or invalid) character This is not guaranteed. If you call u8_mbtouc(&uc, needle, 4) you are asserting that needle[0..3] are valid memory addresses. In

Re: [PATCH v2 0/5] Speed up uNN_chr and uNN_strchr with Boyer-Moore algorithm

Paolo Bonzini wrote: > The point is that > u8_mbtouc will look only one byte past the end of a (valid or invalid) > character This is not guaranteed. If you call u8_mbtouc(&uc, needle, 4) you are asserting that needle[0..3] are valid memory addresses. If it's not the case, u8_mbtouc may crash. Yo

Re: [PATCH v2 0/5] Speed up uNN_chr and uNN_strchr with Boyer-Moore algorithm

On 07/29/2010 04:32 PM, Pádraig Brady wrote: No! You can cheat!:) Just pass 4 to u8_mbtouc. There will be no out-of-bounds access: if the string ends before that, you get either a complete character or an EILSEQ. You don't get EILSEQ for u8_mbtouc(&uc,"aa",6); But you get a complete character

Re: strtod [was: M4 1.4.14 on AIX 7.1BETA]

On 07/29/2010 08:33 AM, Rainer Tammer wrote: >> Which means gnulib _did_ replace strtod on your system. >> > OK, > so the problem is in the replacement function. >> let's diagnose the current state of gnulib on AIX, rather than doing >> post-mortem on old code. It's time for me to release 1.4.15

[PATCH] strtod: aid debugging

* m4/strtod.m4(gl_FUNC_STRTOD): Use distinct exit status to aid understanding why strtod is rejected. Signed-off-by: Eric Blake --- > configure:24715: checking whether strtod obeys C99 > configure:24791: cc -qlanglvl=extc89 -qlanglvl=extc99 -o conftest -g > conftest.c >&5 > configure:24791: $?

Re: strtod [was: M4 1.4.14 on AIX 7.1BETA]

On 07/29/2010 08:33 AM, Rainer Tammer wrote: >> ASSERT (result == 10.0); >> >> Weird - I've never seen that line fail before. If you have a debugger, >> can you put a breakpoint on that line and print the actual value of >> result? > I can do that. > > main(), line 234 in "test-strtod.c" >

false negative in maint.mk

I just updated m4 to the latest gnulib, and it fails 'make syntax-check': doc/m4.texinfo maint.mk: out of date copyright in doc/m4.texi; update it make: *** [sc_copyright_check] Error 1 Two bugs here: First, m4.texinfo contains: Copyright @copyright{} 1989, 1990, 1991, 1992, 1993, 1994, 2004, 2

strtod [was: M4 1.4.14 on AIX 7.1BETA]

On 07/29/2010 06:50 AM, Rainer Tammer wrote: >>> FAIL: test-strtod >>> >>> Is this a know problem ? >> Did configure try to replace AIX' strtod? > According to config.h: > > /* Define to 1 if strtod is declared even after undefining macros. */ > #define HAVE_RAW_DECL_STRTOD 1 That's not quite w

Re: [PATCH v2 0/5] Speed up uNN_chr and uNN_strchr with Boyer-Moore algorithm

On 07/29/2010 12:40 PM, Pádraig Brady wrote: I thought of that but thought it would be too much overhead for the general case since it seemed like it would need strlen, u8_mbsnlen& u8_mbtouc, with conversions back and forth. No! You can cheat! :) Just pass 4 to u8_mbtouc. There will be no o

Re: M4 1.4.14 on AIX 7.1BETA

[Please post to public mailing lists, not to random developers, especially since you have no guarantee whether a random developer's address will still be valid - redirecting to bug-gnulib] On 07/29/2010 05:03 AM, Rainer Tammer wrote: > Hello, > I now have tested M4 1.4.14 on AIX 7.1BETA. I have re

Re: [PATCH v2 0/5] Speed up uNN_chr and uNN_strchr with Boyer-Moore algorithm

On 29/07/10 10:26, Paolo Bonzini wrote: > On 07/29/2010 11:05 AM, Pádraig Brady wrote: >>> I would better recommend to use >>> the u8_strstr function. >> >> I wonder could we speed that up for UTF-8 >> by just deferring to strstr() ? >> I've not tested this so feel free to bin it. > > An alternati

Re: Help with openpty

Hi, > I am trying to use the openpty macro When you use gnulib, you are supposed to use an entire module, in this case the 'openpty' module, not just some .m4 macro without the accompanying source files and dependencies. When you look at modules/openpty, it guarantees you that when you use #inclu

Re: [PATCH v2 0/5] Speed up uNN_chr and uNN_strchr with Boyer-Moore algorithm

On 07/29/2010 11:05 AM, Pádraig Brady wrote: I would better recommend to use the u8_strstr function. I wonder could we speed that up for UTF-8 by just deferring to strstr() ? I've not tested this so feel free to bin it. An alternative idea: check if there is more than 1 character using u8_mb

Re: [PATCH v2 0/5] Speed up uNN_chr and uNN_strchr with Boyer-Moore algorithm

On 28/07/10 22:32, Bruno Haible wrote: > Pádraig Brady wrote: >> I would suggest a new function due to the >> way I see this function called most often. >> >> /* definitely not sure of this name */ >> uint8_t * >> u8_str_u8_chr (const uint8_t *s, const uint8_t *c, size_t size) >> { >> switch (siz

Help with openpty

Dear all, I am trying to use the openpty macro, but I encounter a problem: everything works fine on a Mac OS X computer, but the test fails on a Linux one. In particular, the PTY headers are founds #define HAVE_DECL_OPENPTY 1 but I still get no openpty function /* #undef HAVE_OPENPTY */ Looki