Re: [bug-gnulib] Re: getopt and Solaris 10

On Mon, May 09, 2005, Paul Eggert wrote: > Derek Price <[EMAIL PROTECTED]> writes: > > > > + myargv[[0]] = "conftest"; > > + myargv[[1]] = "-+"; > > This doesn't null-terminate myargv. D'oh ! > But I still don't get why the change is needed. It sounds like you're > assuming S

Re: [bug-gnulib] Re: getopt and Solaris 10

On Mon, May 09, 2005, Derek Price wrote: [...] > I did read this correctly in your report. If anyone else sees a need > for an actual test for correct optind=0 behavior, then they are welcome > to write one, but I decided the point was moot at the moment since > detecting the "+" bug, just as val

Re: [bug-gnulib] Re: getopt and Solaris 10

Hi. One more clarification. Maybe one or the other missed my last comments on . It was me, who introduced the "'+' myth". I "analysed" the problem wrong in the beginning. It is not exactly the "+" that makes the problem, but the fact, that the

Re: [bug-gnulib] Re: getopt and Solaris 10

On Mon, May 09, 2005, Derek Price wrote: [...] > Okay, one more revision, to actually check if the -+ registers as an > option or not. This fits the autoconf paradigm of testing for the bug, > even if it is using AC_TRY_RUN. This way, if Sun fixes the problem in a > later Solaris release, we sho

Re: [bug-gnulib] Re: getopt and Solaris 10

Derek Price <[EMAIL PROTECTED]> writes: > + myargv[[0]] = "conftest"; > + myargv[[1]] = "-+"; This doesn't null-terminate myargv. But I still don't get why the change is needed. It sounds like you're assuming Solaris 11 getopt might get fixed? But even in that case, the curren

[bug-gnulib] Re: timegm license incompatibility

Bruno Haible <[EMAIL PROTECTED]> writes: > time_r is even more in the "library" camp, because it's more important > for a library to be MT-safe than for an application. Thanks for the advice. I changed time_r to be LGPL too. ___ bug-gnulib mailing li

Re: [bug-gnulib] [bug-gnulib] fts portability fix for hosts with unusual pointer semantics

Bruno Haible <[EMAIL PROTECTED]> writes: > (I have not yet seen any platform where the ABI treats 'void *' pointers > differently than any data pointers. The basic reason that 'void *' exists > at all in C is to permit this kind of cast.) The basic problem, as I understand it, is that some archit

Re: [bug-gnulib] [bug-gnulib] fts portability fix for hosts with unusual pointer semantics

On Mon, May 09, 2005 at 10:04:34PM +0200, Bruno Haible wrote: Bruno> Paul Eggert wrote: [...] Paul> I installed this patch into coreutils. Paul> Paul> +static int Paul> +fts_compar (void const *a, void const *b) Paul> +{ Paul>/* ... */ Paul> + return pa[0]->fts_fts->fts_compar (pa, pb); Paul>

[bug-gnulib] [PATCH]: getaddrinfo module broken

Hi, Here is a patch that address several issues in the getaddrinfo GnuLib module implementation: - getaddrinfo might be available from -lnls or -lsocket. Look that up. - Don't fail when SOCK_STREAM or SOCK_DGRAM are specified in ai_socktype (most getaddrinfo usage involve using it, this was maki

Re: [bug-gnulib] [bug-gnulib] fts portability fix for hosts with unusual pointer semantics

Paul Eggert wrote: > That reminds me; fts.c violates C89 in a couple of places, which could > lead to core dumps on unusual hosts where void * and FTSENT const ** > have differing runtime representations. I installed this patch into > coreutils. > > +static int > +fts_compar (void const *a, void c

Re: [bug-gnulib] Re: timegm license incompatibility

# Copyright (C) 2003 Free Software Foundation, Inc. # This file is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, # with or without modifications, as long as this notice is preserved. "preserve-notice" sounds fine.

Re: [bug-gnulib] Re: getopt and Solaris 10

Derek Price wrote: >>>2005-05-05 Paul Eggert <[EMAIL PROTECTED]> >>> >>> * lib/getopt.m4 (gl_GETOPT): Check for Solaris 10 getopt, and >>> avoid needless checks. >>> >>> >>Yes, this also works for me. >> >> > >Okay, one more revision, to actually check if the -+ registers as

[bug-gnulib] Re: timegm license incompatibility

Paul Eggert wrote: > On the other hand, it's meant as a replacement for > glibc code that is LGPLed. Fellow gnulibers, do we have a general > policy for this sort of thing? If not, I'm inclined to LGPL it. My guideline for deciding whether something can be LGPLed is: 1) Does the GNU project al

[bug-gnulib] Re: timegm license incompatibility

Yoann Vandoorselaere <[EMAIL PROTECTED]> writes: > I noticed that the GnuLib timegm module is marked as LGPL but some of > it's dependencies (time_r and extensions), are marked as GPL. Thus > gnulib-import --lgpl fail. > > Would it be possible to move the time_r and extensions module license to >

[bug-gnulib] regex.h w/ mingw g++ 3.4

regex does not compile with mingw g++ 3.4: ./regex.h:535: error: expected primary-expression before "__restrict__" ./regex.h:535: error: expected `]' before "__restrict__" ./regex.h:535: error: expected `,' or `...' before "__restrict__" -- Sam Steingold (http://www.podval.org/~sds) running w2k

Re: [bug-gnulib] stat-macros module depends on itself

Thanks for catching that; I installed the fix. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib

[bug-gnulib] fts portability fix for hosts with unusual pointer semantics

Jim Meyering <[EMAIL PROTECTED]> writes: > I've hesitated to add coreutils' fts.c to gnulib partly because > I didn't know of any other package that used it. Also, in order > to remove some of those limitations, I had to change numerous types > of fts.h's struct members. That means packages that

Re: [bug-gnulib] fts modules submission

Henry Culver wrote: > I would like to contribute an fts module for inclusion into gnulib. > Systems that are not based on glibc may not have fts_open, fts_close, > fts_read, fts_children or fts_set. I have extracted the fts.c and > fts.h from glibc-2.3.5/io and modified them (providing a few #defi

Re: [bug-gnulib] Re: getopt and Solaris 10

Regardless, since using an optind = 0 is not specified as supported by POSIX, whereas optind = 1 is, and since using optind = 1 in place of optind = 0 in CVS would avoid this problem on all platforms and with all versions of getopt (supporting optind = 0 provides no additional functionality that I

Re: [bug-gnulib] Re: getopt and Solaris 10

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ...I know you already agreed... ...I just thought this was interesting... In fact, Solaris 10 is the one actually sticking to the letter of the POSIX spec here, not that I think that assuming argv[0] should not be processed is going to hurt the GNU v

[bug-gnulib] timegm module license incompatibility

Hi, The GnuLib "timegm" module is marked as LGPL but some of its dependencies (time_r and extensions namely), are marked as GPL. Thus gnulib-import --lgpl on the timegm module will fail. Would it be possible to move the time_r and extensions module license to LGPL ? Thanks, -- Yoann Vandoorsel

Re: [bug-gnulib] [bug-gnulib] [PATCH]: inet_ntop module for GnuLib

On Mon, 2005-05-09 at 17:05 +0200, Bruno Haible wrote: > Yoann Vandoorselaere wrote: > > Attached is a patch adding an inet_ntop module to GnuLib. The code has > > been adapted from the inet_ntop glibc code. > > Thanks. I've added this module with minor tweaks: [...] Thanks! > The following hav

Re: [bug-gnulib] Re: getopt and Solaris 10

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthias Kurz wrote: >Hi. > >One more clarification. Maybe one or the other missed my last comments >on . It was me, >who introduced the "'+' myth". Well, it is not a myth. I studied the test pro

[bug-gnulib] Re: fts modules submission

Henry Culver <[EMAIL PROTECTED]> wrote: > I would like to contribute an fts module for inclusion into gnulib. ... Thank you. There are unnecessary limitations and a few bugs in the glibc's fts. Most of those have been fixed in the version used by coreutils. For more details, see the 24 log entrie

Re: [bug-gnulib] Re: getopt and Solaris 10

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthias Kurz wrote: >I do not think that this is a Solaris _bug_. - From the point of view of the GNULIB getopt.m4 tests, if it doesn't behave like GNU getopt, that is a bug. :) >I'd bet that every system that does not use GNU getopt will suffer

[bug-gnulib] fts modules submission

I would like to contribute an fts module for inclusion into gnulib. Systems that are not based on glibc may not have fts_open, fts_close, fts_read, fts_children or fts_set. I have extracted the fts.c and fts.h from glibc-2.3.5/io and modified them (providing a few #defines and removing __ from cal

Re: [bug-gnulib] Re: getopt and Solaris 10

Matthias Kurz wrote: >On Thu, May 05, 2005, Paul Eggert wrote: > > > >>Derek Price <[EMAIL PROTECTED]> writes: >> >> >> >>>I prefer door #2. Trivial patch attached: >>> >>> >>Thanks, but I'd rather use AC_CHECK_DECL, so I installed this instead, >>into both coreutils and gnulib. Does

Re: [bug-gnulib] [bug-gnulib] [PATCH]: inet_ntop module for GnuLib

Yoann Vandoorselaere wrote: > Attached is a patch adding an inet_ntop module to GnuLib. The code has > been adapted from the inet_ntop glibc code. Thanks. I've added this module with minor tweaks: - modules/inet_ntop: Add a description. - modules/inet_ntop: Add 'glibc' to maintainers, so that

[bug-gnulib] [PATCH]: inet_ntop module for GnuLib

Hi, Attached is a patch adding an inet_ntop module to GnuLib. The code has been adapted from the inet_ntop glibc code. Regards, -- Yoann Vandoorselaere | Responsable R&D / CTO | PreludeIDS Technologies Tel: +33 (0)8 70 70 21 58 Fax: +33(0)4 78 42 21 58 http://www.prelude-ids.co

[bug-gnulib] stat-macros module depends on itself

I noticed this, though it didn't seem to confuse gnulib-tool when it got used. --- moodules/stat-macros.~1.1.~ Tue Mar 22 07:43:56 2005 +++ moodules/stat-macrosMon May 9 11:21:01 2005 @@ -6,7 +6,6 @@ m4/stat-macros.m4 Depends-on: -stat-macros configure.ac: gl_STAT_MACROS ___

Re: [bug-gnulib] dirname module should depend on stdbool

Paul Eggert <[EMAIL PROTECTED]> writes: > I omitted stdbool on the theory that packages that to assume C99 don't > need to use the stdbool module, since stdbool.h comes with C99. For what it's worth, this wasn't a package assuming c99. I think it was a result of including something that autoscan

[bug-gnulib] Re: xmalloc should depend on xalloc-die

Dave Love <[EMAIL PROTECTED]> wrote: > gnulib-tool sucked in xmalloc from something else and that failed to > build because xalloc-die was missing. This fixed it: > > --- xalloc.~1.15.~Sat Apr 16 22:19:07 2005 > +++ xallocMon May 9 10:50:13 2005 > @@ -7,6 +7,7 @@ > m4/xalloc.m4 > > Depe

[bug-gnulib] xmalloc should depend on xalloc-die

gnulib-tool sucked in xmalloc from something else and that failed to build because xalloc-die was missing. This fixed it: --- xalloc.~1.15.~ Sat Apr 16 22:19:07 2005 +++ xalloc Mon May 9 10:50:13 2005 @@ -7,6 +7,7 @@ m4/xalloc.m4 Depends-on: +xalloc-die configure.ac: gl_XALLOC