long long double on interix

Hi! While porting glib to interix, i stumbled over a problem i didn't hit for a while (and in fact forgot that it existed on interix): long long double is broken. this bites me in the gnulib vasnprintf implementation, which calls snprintf from libc which immediately crashes ... :( i fixed this

Re: Download gnulib tarball

clovis MPassy writes: > How can I downloading GNULIB without using git, cvs, etc. >   > I wish get the GNULIB tarball. The web viewer for the Git repository has links for downloading tarballs. -- Ben Pfaff http://benpfaff.org

Re: Download gnulib tarball

On 06/09/11 12:53, clovis MPassy wrote: > I wish get the GNULIB tarball. The Google query "GNULIB tarball" pointed me immediately to .

Re: porting code

On 06/09/11 13:52, Steven Abner wrote: > I wish to know how to link in the current system locale data > into your strftime() code. I am on a Mac, 10.6.somethin'. I can't use %a, %b > etc Hmm, it should "just work". Perhaps you could show an example program that illustrates the problem, and expla

porting code

Hi I was just turned on to your library from another developer group in reference to testing. It was great! Normally I spend hours, sometimes giving up, on trying to get glibc code. Took me about 10 mins to start using your code! Well, as said I use for testing. I wish to know how to link in t

Download gnulib tarball

Hi; How can I downloading GNULIB without using git, cvs, etc. I wish get the GNULIB tarball. Thanks for your response

Re: glob-libc.h not installed

On 26 May 2011 00:26, Bruce Korb wrote: > On 05/25/11 14:44, Reuben Thomas wrote: >> >> On 9 May 2011 17:19, Bruce Korb  wrote: >>> >>> On 05/08/11 15:24, Reuben Thomas wrote: Still missing a header: >>> >>> ... In file included from lposix.c:25:0: /usr/local/include/libpo

Re: Dealing with character ranges in grep

On Thu, Jun 9, 2011 at 19:14, Paul Eggert wrote: > On 06/08/2011 10:14 PM, Aharon Robbins wrote: > >> So, for the upcoming gawk 4.0, I decided (as Karl put it) to cut the >> Gordian knot and make ranges behave like the C locale, the way it's long >> been documented, and as most people expect.  Tho

Re: Dealing with character ranges in grep

On 06/08/2011 10:14 PM, Aharon Robbins wrote: > So, for the upcoming gawk 4.0, I decided (as Karl put it) to cut the > Gordian knot and make ranges behave like the C locale, the way it's long > been documented, and as most people expect. Those who want the POSIX > behavior can still get it using

Re: test-lock compilation failure on mingw

On 06/09/2011 04:44 AM, Bruno Haible wrote: > Hi Eric, > >> the new cygwin cross-compiler for mingw: >> >> i686-pc-mingw32-gcc (GCC) 4.5.2 > > Ah, interesting. > > There is also a new cross-compiler i686-w64-mingw32-gcc. And a new x86_64-w64-mingw32-gcc, as well! > It also produces > native Wi

Re: implementing extended bracket expressions in gnulib [was Re: Dealing with character ranges in grep]

On 06/09/2011 01:53 PM, Bruno Haible wrote: Paolo, My proposal wouldn't change defaults, which is why I believe that this is a separate topic. But at the same time you are pushing for the use of --with-included-regex. We found out that by doing this, the equivalence classes feature gets lost,

fclose/fflush and GNU RCS

According to Hydra: http://hydra.nixos.org/build/1114029 gnulib has something to do with the GNU RCS build breaking (actually, failing "make check"). The particular change is: http://git.savannah.gnu.org/cgit/gnulib.git/diff/?id=3606b9&id2=122987 I think this is related to the thread begin

Re: implementing extended bracket expressions in gnulib [was Re: Dealing with character ranges in grep]

Paolo, > My proposal wouldn't change defaults, which is why I believe that this > is a separate topic. But at the same time you are pushing for the use of --with-included-regex. We found out that by doing this, the equivalence classes feature gets lost, and the divergence between glibc and gnuli

implementing extended bracket expressions in gnulib [was Re: Dealing with character ranges in grep]

On 06/09/2011 01:12 PM, Bruno Haible wrote: What would it take to let distros/people use --with-included-regex and get understandable semantics for ranges + working equivalence classes? I would prefer that to your proposal, because it cannot be seen as a regression by people who care about equiv

Re: test-lock compilation failure on mingw

Paul Eggert wrote: > isn't there another problem here?  thread.h assumes > that NULL is an 'int', which surely isn't a portable assumption. > Here's a proposed patch: > > diff --git a/lib/glthread/thread.h b/lib/glthread/thread.h > index 5d72040..b52646d 100644 > --- a/lib/glthread/thread.h > +++

Re: Support of SOCK_CLOEXEC

Any news of this ? Bastien On Mon, Mar 28, 2011 at 7:07 PM, Bastien ROUCARIES wrote: > On Mon, Mar 28, 2011 at 7:02 PM, Eric Blake wrote: >> On 03/28/2011 10:51 AM, Bastien ROUCARIES wrote: >>> Hi, >>> >>> A mail for getting the status of SOCK_CLOEXEC flags and particularly for >>> socket and

Re: Dealing with character ranges in grep

Paolo, > With my proposal, distros/people that use --with-included-regex would > get understandable semantics + no equivalence classes > ... > locale behavior of regex are irremediably > broken. For example, when you have a collation element, you can match > it using ranges (e.g. [d-i] matches

Re: Dealing with character ranges in grep

On 06/09/2011 11:58 AM, Bruno Haible wrote: Paolo, [=e=] to match "e" as well as accented versions like é, è and ê). That is the one feature that you get with glibc, and that you would sacrifice when building --with-included-regex. I agree. It's up to distros to choose, of course. If you a

Re: test-lock compilation failure on mingw

Paul Eggert wrote: > POSIX doesn't guarantee that pthread_t is a pointer type, so > test-lock.c shouldn't be trying to print gl_thread_self () > with %p; that's not portable. Perhaps all instances of > code like this: > > dbgprintf ("Mutator %p before lock\n", gl_thread_self ()); > > shoul

Re: test-lock compilation failure on mingw

Hi Eric, > the new cygwin cross-compiler for mingw: > > i686-pc-mingw32-gcc (GCC) 4.5.2 Ah, interesting. There is also a new cross-compiler i686-w64-mingw32-gcc. It also produces native Win32 executables. Do you know what's the difference between i686-pc-mingw32 and i686-w64-mingw32? Bruno --

Re: Dealing with character ranges in grep

Paolo, > > [=e=] to match "e" as well as accented versions like é, è and ê). > > That is the one feature that you get with glibc, and that you would > > sacrifice when building --with-included-regex. > > I agree.  It's up to distros to choose, of course. If you are on the point of sacrificing a

Re: STDERR_FILENO on HP-UX

Bruno Haible wrote: > On HP-UX 11.31, I'm seeing this test failure: > > test-spawn-pipe-child.c:99: assertion failed > test-spawn-pipe.sh: iteration 4 failed > test-spawn-pipe-child.c:99: assertion failed > test-spawn-pipe.sh: iteration 5 failed > test-spawn-pipe-child.c:99: assertion fai

Re: STDERR_FILENO on HP-UX

On Thu, Jun 9, 2011 at 11:44 AM, Bruno Haible wrote: > On HP-UX 11.31, I'm seeing this test failure: > >  test-spawn-pipe-child.c:99: assertion failed >  test-spawn-pipe.sh: iteration 4 failed >  test-spawn-pipe-child.c:99: assertion failed >  test-spawn-pipe.sh: iteration 5 failed >  test-spawn-p

STDERR_FILENO on HP-UX

On HP-UX 11.31, I'm seeing this test failure: test-spawn-pipe-child.c:99: assertion failed test-spawn-pipe.sh: iteration 4 failed test-spawn-pipe-child.c:99: assertion failed test-spawn-pipe.sh: iteration 5 failed test-spawn-pipe-child.c:99: assertion failed test-spawn-pipe.sh: iterati

acl tests on HP-UX

On HP-UX 11, the ACL tests fail to compile: cc: "test-sameacls.c", line 389: error 1594: The sizeof operator cannot be applied to types with unknown size. This fixes it. 2011-06-09 Bruno Haible acl tests: Fix compilation error on HP-UX 11. * tests/test-sameacls.c: Include

Re: Dealing with character ranges in grep

On 06/09/2011 11:33 AM, Jim Meyering wrote: I like the idea. However a potential sticking point is the equivalence class (e.g., using [=e=] to match "e" as well as accented versions like é, è and ê). That is the one feature that you get with glibc, and that you would sacrifice when building --wit

Re: Dealing with character ranges in grep

Paolo Bonzini wrote: > [making this public, there should be no reason not to] > > On 06/08/2011 10:14 PM, Aharon Robbins wrote: >> Hi. As we've discussed a little previously, I finally got tired of >> trying to explain to users why the character range [a-z] was matching >> most uppercase letters a

Re: fileblocks: missing declaration of st_blocks?

James Youngman wrote: > I notice that the fileblocks module defines st_blocks, but there's no > declaration for it. Is that deliberate? Hi James, I doubt that it was deliberate. It is likely that that code is effectively dead. It is used only on systems that lack stat.st_blocks, etc. This is th

Re: Dealing with character ranges in grep

[making this public, there should be no reason not to] On 06/08/2011 10:14 PM, Aharon Robbins wrote: Hi. As we've discussed a little previously, I finally got tired of trying to explain to users why the character range [a-z] was matching most uppercase letters also. ("I've found a bug in gawk!