regex module breaks distcheck

Hello, The file lib/regex.c includes several files, which are never added to EXTRA_DIST. I propose the following patch: Index: modules/regex === RCS file: /cvsroot/gnulib/gnulib/modules/regex,v retrieving revision 1.12 diff -p -u -r1

Re: regex module breaks distcheck

Paul Eggert <[EMAIL PROTECTED]> wrote: > That shouldn't be needed, since m4/regex.m4's gl_REGEX macro > mentions those files with AC_LIBSOURCES. Yes, indeed. > "make distcheck" works for me, with CVS tar. It was in another project, mailutils. The bug was obviously mine. I've already fixed it.

Re: modules and program name

Eric Blake <[EMAIL PROTECTED]> wrote: > I noticed when compiling tar on cygwin that I got a warning: > if gcc -DHAVE_CONFIG_H -DLIBDIR=\"/usr/local/lib\" -I. -I. -I.. -g2 -Wall > -Werror -MT argp-help.o -MD -MP -MF ".deps/argp-help.Tpo" -c -o argp-help.o > argp-help.c; \ > then mv -f ".deps/

Re: [Bug-tar] argp-help and program name

Eric Blake <[EMAIL PROTECTED]> wrote: > Further looking at the argp-help module shows that tries using > strrchr(program_invocation_name, '/') which is not portable Yes, and yet another function that assumes '/' as the directory separator is argp_parser. While argp-help can be tweaked to use base

Re: argp --help infloop bug

Jim Meyering <[EMAIL PROTECTED]> wrote: > You can make any argp-using program infloop simply by running it > with --help and with something like ARGP_HELP_FMT=rmargin=a in the > environment. Or use a valid (but small) width: ARGP_HELP_FMT=rmargin=2 Yes, indeed. Thanks for reporting. I will fix i

Re: [Bug-tar] argp-help and program name

Eric Blake <[EMAIL PROTECTED]> wrote: > the same thing as what your new __argp_base_name does. Prior to my > dirname patch, the existing base_name does the same as your Thanks for noticing, I'll fix that. > Usually, module owners post their patches to bug-gnulib for review, so I > was a bit sur

Re: argp --help infloop bug

. The following patch is applied (it also fixes a coredump one would get in some cases, e.g. when running ARGP_HELP_FMT=rmargin=39 tar --help). Regards, Sergey 2005-12-10 Sergey Poznyakoff <[EMAIL PROTECTED]> * lib/argp-fmtstream.c (__argp_fmtstream_update): Fix coredump

Re: [Bug-tar] one more warning in argp-help

Eric Blake <[EMAIL PROTECTED]> wrote: > I noticed on cygwin that I was getting a warning for buf being declared at > line argp-help.c:1895 but not used. This patch also fixes a lot of > trailing whitespace; let me know if you don't want whitespace patches. Thank you. Surely the diff will be easi

Re: use of program_name

Paul Eggert <[EMAIL PROTECTED]> wrote: > > -# define program_name program_invocation_name > > Let's omit this '#define', and change all uses of program_name to > program_name in the rest of the code. The other arm of the #if can > then contain > > #define program_invocation_name program_name ()

--avoid with --extract-dependencies

Shouldn't `--avoid' work with `--extract-dependencies'? I propose the following patch: Index: gnulib-tool === RCS file: /cvsroot/gnulib/gnulib/gnulib-tool,v retrieving revision 1.102 diff -p -u -r1.102 gnulib-tool --- gnulib-tool 19 J

Re: warnings in 'argp' module

Bruno Haible <[EMAIL PROTECTED]> wrote: > The argp module has warnings on Linux/glibc: I have installed the following patch: 2006-01-21 Sergey Poznyakoff <[EMAIL PROTECTED]> * lib/argp-help.c (usage_long_opt): Do not print DOC options. (__argp_base

Re: [Bug-tar] tar.c:237: warning: too few arguments for format

Paul Eggert <[EMAIL PROTECTED]> wrote: > Back then, argp-namefrob.h was automatically updated from the latest > version of the file of the same name in glibc. We no longer do that, > since the sources have diverged. It must have been updated by mistake, then. > Shouldn't the glibc and gnulib so

Autoupdate undoing changes (Was Re: [Bug-tar] tar.c:237: warning: too few arguments for format)

After a brief examination I discovered yet another important bugfix to argp library undone on the same date (2005-12-12), namely this: 2005-12-10 Sergey Poznyakoff <[EMAIL PROTECTED]> * argp-fmtstream.c (__argp_fmtstream_update): Fix coredump I have restored it. Karl, please

Re: [Bug-tar] compilation warning in argp-help

Thank you. Regards, Sergey ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: translations

Hi Karl, > I've been telling them to go through the translation project, but now I > wonder if that's the general practice, or whether you-all have accepted > translations "on the fly"? They should all go through TP, certainly. Apart from the reasons, listed by Jim, there are two more: - TP chec

Re: argp.h/argz.h and error_t

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > The hack below fixes that, but I can imagine that it is not an > acceptable fix, given that this is libc code. Should we rather > AC_DEFINE([__error_t_defined], 1, ..)? Yes, I believe we should. Regards, Sergey __

Re: [EMAIL PROTECTED]: [Bug 189545] New: legal argp() arg_option keys (ints) can cause segfaults]

Paul Knowles <[EMAIL PROTECTED]> wrote: > Has the fix been pushed upstream to glibc itself? I could > find no evidence if it via the glibc CVS. The glibc people > informed me that gnu-lib were the maintainers of the argp > code itself. Are updates between the stand alone version > and the inte

exclude_fnmatch function

Hello, I propose to move part of excluded_file_name in the separate function. This will make it possible for an application to use fnmatch-like interface with and without wildcards. In particular, this is needed for GNU tar. The patch is enclosed. Regards, Sergey Index: lib/exclude.c ==

Openat and localcharset issues on Darwin

Hello, The following gnulib-related message was obtained while compiling GNU tar on powerpc-apple-darwin8.6.0 with GCC 4.1.1 and native ld: openat.c: In function 'rpl_openat': openat.c:60: warning: 'mode_t' is promoted to 'int' when passed through '...' openat.c:60: warning: (so you should pass '

Re: create a big test, collect the fallout

Simon Josefsson <[EMAIL PROTECTED]> wrote: > Shishi actually do @include getdate.texi in its manual, so please > don't install this part. And GNU tar does the same. Regards, Sergey

Re: problem importing argp

Gurganus, Brant L <[EMAIL PROTECTED]> wrote: > lib/Makefile.am:18: required file `lib/memcmp.c' not found > lib/Makefile.am:18: required file `lib/malloc.c' not found > lib/Makefile.am:18: required file `lib/lstat.c' not found > lib/Makefile.am:18: required file `lib/stat.c' not found >From these

RE: problem importing argp

Gurganus, Brant L <[EMAIL PROTECTED]> wrote: > Why were those files added to the Makefile when I ran "{path to gnulib > checkout}/gnulib-tool --import argp" then and what is the resolution > for the problem? They cames from a line that use @ALLOCA@ in the > generated Makefile and when I removed AC

Re: new module proposal: split

In mailutils, we use the function argcv_get: int argcv_get (const char *string, const char *delim, const char *cmnt, int *argc, char ***argv); which breaks the `string' according to the delimiters in `delim', eventually ignoring anything after the comment starter `cmnt'. It fills

Fixing argp doc strings

Hello, I have installed the following change: 2006-09-09 Sergey Poznyakoff <[EMAIL PROTECTED]> * argp-help.c (argp_doc): Split the untranslated doc string on '\v', and translate the two parts separately, instead of feeding the whole string to gette

program_name in error.c

Hello, I'd like to install the following change to error.c in order to better cooperate with argp. Any objections? Regards, Sergey Index: error.c === RCS file: /cvsroot/gnulib/gnulib/lib/error.c,v retrieving revision 1.46 diff -p -

Re: [bug-gnulib] program_name in error.c

Bruno Haible <[EMAIL PROTECTED]> wrote: > - Why do you use HAVE_PROGRAM_INVOCATION_NAME here, whereas argp.m4 > defines GNULIB_PROGRAM_INVOCATION_NAME ? Yes, I meant GNULIB_PROGRAM_INVOCATION_NAME, of course. > - If the #ifdef condition is true, you'll be using the > program_invocation_name

Re: [bug-gnulib] Fixing argp doc strings

Bruno Haible <[EMAIL PROTECTED]> wrote: > Additionally, how about documenting this > (non-obvious) convention? Something like this: Thank you. I have applied this change. > Also, one could mention the need of N_(...) in the documentation of > the field 'doc' of struct argp_option as well: No,

Re: [bug-gnulib] Fixing argp doc strings

Bruno Haible <[EMAIL PROTECTED]> wrote: > Sure. But N_(...) does apply to it. One might document this, otherwise > the programmer might think that he needs to fill in the translation himself > into the ->doc field at runtime, not knowing that the argp implementation > does it for him. Ah, yes, in

Re: program_name in error.c

Eric Blake <[EMAIL PROTECTED]> wrote: > Careful. error.c is (mostly) synced upstream with glibc (right now, all > but the comments and a couple of #include order issues), but this would > widen the gap. Yes, I see that the matter is not as simple as it seemed at the first glance. > As it is, er

(no subject)

I have installed the following changes to argp: 2006-09-10 Sergey Poznyakoff <[EMAIL PROTECTED]> * argp-parse.c (__argp_parse) [!_LIBC]: Make sure program_invocation_name and program_invocation_short_name are initialized. * argp-namefrob.h: Move declarati

Re: [bug-gnulib] Fixing argp doc strings

Bruno Haible <[EMAIL PROTECTED]> wrote: > In either case of the 'if' branch, inp_text can end up being NULL. > But it is not allowed to pass a NULL string argument to dgettext. Thank you, I have fixed this. Regards, Sergey 2006-09-12 Sergey Poznyakoff <[EMAIL PR

read_utmp proposition

Hello, I propose the new option for read_utmp: READ_UTMP_USER_PROCESS, which will instruct it to return only entries corresponding to user processes. The patch follows: Index: lib/readutmp.c === RCS file: /cvsroot/gnulib/gnulib/lib/r

read_utmp changes

I have installed the following change to read_utmp: 2006-10-18 Sergey Poznyakoff <[EMAIL PROTECTED]> * lib/readutmp.c (desirable_utmp_entry): Implement new flag: READ_UTMP_USER_PROCESS. * lib/readutmp.h (READ_UTMP_USER_PROCESS): New flag Index: lib/read

Re: read_utmp changes

Jim Meyering <[EMAIL PROTECTED]> wrote: > I've made this additional change: > > 2006-10-18 Jim Meyering <[EMAIL PROTECTED]> > > * lib/readutmp.c (desirable_utmp_entry): Use "bool" as the > type for a local, and rename it: s/up/user_proc/. Thank you. Regards, Sergey

Re: tracking source files for POTFILES.in?

Bruno Haible <[EMAIL PROTECTED]> wrote: > Ad 2) We shouldn't ask the translators to translate the same strings > repeatedly. Some translator groups have a shared translation memory, some > don't. In the long term, I therefore think the right solution is that every > gnulib module with translatable

Re: gnulib localization

Bruno Haible <[EMAIL PROTECTED]> wrote: > What's missing is that gnulib-tool copies the POT & PO files into the > destination project, possibly with measures to avoid collisions with other > versions, and/or arranges to define DEFAULT_TEXT_DOMAIN to "gnulib". I doubt it should. The idea of a com

sysexit_.h fix

I propose the following change to sysexit_.h. Reason: if HAVE_SYSEXITS_H is expanded to 1, then the included header file might be protected by `#ifdef _SYSEXITS_H' (in fact, it is, on GNU/Linux) which will prevent its contents from being included. Index: lib/sysexit_.h

Alan Hourihane: [bug #24687] implicit usage of mbsinit & mbrtowc

Hello, A user of Texinfo reported this: > URL: > > > Summary: implicit usage of mbsinit & mbrtowc > Project: texinfo - GNU documentation system [...] > Details: > > In texinfo 4.13 the files gnulib/lib/mbuiter.h and gnuli

Re: Alan Hourihane: [bug #24687] implicit usage of mbsinit & mbrtowc

Hi Bruno, > The problem is that texinfo's info.h includes mbiter.h unconditionally, > whereas the module description in gnulib specifies this: Ah, that's my fault. > Now I see that you have 9 functions in > texinfo/info/{display.c,session.c,window.c} which use the mbiter > facility unconditiona

Re: Alan Hourihane: [bug #24687] implicit usage of mbsinit & mbrtowc

Bruno Haible ha escrit: > This is done. Thanks, Bruno! Regards, Sergey

set_program_name behavior

Hello, The behavior of set_program_name differs depending on whether argv[0] refers to a libtool script (*/.libs/lt-*) or to a usual binary. In the first case, the function strips off all directory components and the `lt-' prefix, and assigns the result to program_name. In the second case, however

Re: [gnu-prog-discuss] url's in --help output

Karl Berry ha escrit: > However, as far as I know there isn't a gnulib translation domain that > > There actually is, although I admit I don't know how the messages get > integrated into the gnulib-using packages: > http://translationproject.org/domain/gnulib.html It is a "compendium" domai

Re: [gnu-prog-discuss] url's in --help output

Simon Josefsson ha escrit: > Ah, interesting, I wasn't aware of this feature. Do I as maintainer of > projects using gnulib have to do anything special to make this usable > for translators? Nothing special, only make sure the files imported from gnulib are listed in your po/POTFILES.in. Regar

Re: url's in --help output

Ben Asselstine ha escrit: > On Sat, Jan 31, 2009 at 5:22 PM, Karl Berry wrote: > >The <...> markup is helpful when the URL is broken into two lines, > > > > Let's not forget about argp. Here's a patch to sync it to the new > format. That would break too many existing programs. I'd rather

[PATCH] Specify archive suffixes to announce-gen

Hello, The enclosed patch add to announce-gen a new option, --archive-suffix, which allows to specify new archive suffixes. For example: announce-gen --archive-suffix cpio.gz --archive-suffix shar.gz It is useful for such projects as GNU tar, which is distributed in a wider set of archive form

Re: [PATCH] Specify archive suffixes to announce-gen

Jim Meyering ha escrit: > Sure, that looks fine. > But please remove the trailing blanks first. Done. Regards, Sergey

Re: [Translation-team-de] German translations for man-db and gnulib

Colin Watson ha escrit: > Indeed, http://translationproject.org/POT-files/gnulib-1.1.pot is > looking a bit stale. Could somebody on bug-gnulib update the POT file > held by the TP, please? That's my fault. I'll update it today. Regards, Sergey

gnulib.pot versioning scheme

Hello, I am going to submit the updated gnulib.pot to TP. Before this, I'd like to change its versioning scheme so that it coincides with the version reported by `gnilib-tool --version'. E.g. this potfile will be named gnulib-0.0.1991-dbebf.pot. Does it seem a good idea? Regards, Sergey

Re: gnulib.pot versioning scheme

Sergey Poznyakoff wrote: > I am going to submit the updated gnulib.pot to TP. Before this, > I'd like to change its versioning scheme so that it coincides with the > version reported by `gnilib-tool --version'. E.g. this potfile will be > named gnulib-0.0.1991-dbebf.pot.

Re: gnulib.pot versioning scheme

Bruno Haible ha escrit: > How about changing the versioning scheme to > gnulib-1.1.2009.03.26 > or > gnulib-1.1.1836.86a37 It would be better to place "TP version" at the end, as in: gnulib-1836.86a37.1.1 This should work with the TP software. > Could you also generate and publish a

Re: gnulib.pot versioning scheme

Bruno Haible ha escrit: > >gnulib-1836.86a37.1.1 > > If you do this, you can never again switch to a different versioning > scheme. Not quite so. What I meant is that the part between `-' and `1.1' is to be ignored (it cannot be used for ordering anyway). In this case I see no difficulty in

open_safer on amd64

Hello, When trying to compile open-safer.c on amd64 I get: open-safer.c: In function 'open_safer': open-safer.c:46: warning: 'mode_t' is promoted to 'int' when passed through '...' open-safer.c:46: warning: (so you should pass 'int' not 'mode_t' to 'va_arg') open-safer.c:46: note: if this code is

Re: open_safer on amd64

Bruno Haible ha escrit: > You can ignore this warning. The code is fine. Ah, OK. Thank you. Perhaps it merits mentioning in the docs, to avoid further reports of this kind? Regards, Sergey

Re: open_safer on amd64

Eric Blake ha escrit: > In earlier versions of POSIX, the intent was that mode_t could > be narrower than int, and that all programmers had to use only symbolic > constants in that argument. As a side note, on that particular architecture, mode_t is indeed narrower than int. Regards, Sergey

[PATCH] Add optional silent-rules support

Hello, How about the following patch, which adds support for `silent-rules' mode introduced in Automake 1.11: * build-aux/bootstrap (slurp): Add silent rule support to $gnulib_mk, if required by the configure.ac. --- build-aux/bootstrap | 49 + 1

Re: [PATCH] Add optional silent-rules support

Hi Ralf, > Can gnulib-tool create > target1 target2 ... \ > targetN : prereq1 ... \ > prereqN ; rule-command > > rules? Well, quick grep through modules/* shows that so far no module generates such rules. But in theory it is possible. I'll take it into account, then. > Sho

Re: [PATCH] Add optional silent-rules support

Ralf Wildenhues ha escrit: > - the awk script won't detect if there are already $(AM_V_...) variables > present in the rules, Yes, that's intended. It was supposed that silent-rules variables can not appear in the input. Regards, Sergey

Re: [PATCH] Add optional silent-rules support

Ralf Wildenhues ha escrit: > Not as far as I can see. Solaris /bin/awk doesn't have the match and > sub functions, and has several other limitations over POSIX awk. Ah, I see. > On Solaris, you should be able to use nawk or /usr/xpg4/bin/awk. OK, then using ${AWK-awk} should do to help in thi

Re: dropping setuid/setgid privileges

James Youngman ha escrit: > It's possible that one of the process's supplementary groups is > privileged. So we may also need to do something like this: > > #if HAVE_SETGROUPS > /* Use of setgroups() is restricted to root only. */ > if (0 =3D=3D geteuid()) > { > /* We're either r

Re: dropping setuid/setgid privileges

Bruno Haible ha escrit: > What is the use-case that you are considering? A setuid/setgid executable, > or an executable run by root? I was considering an executable run by root. > And what task does it do, related to the user's data and devices? Retaining supplementary is often necessary for t

New module argp-version-etc

functionality requires some minor changes to the existing version-etc module (patch 1). Opinions? Regards, Sergey 2009-06-24 Sergey Poznyakoff Provide additional interfaces for version-etc module. * lib/version-etc.c (version_etc_arn, version_etc_ar): New

Re: New module argp-version-etc

Eric Blake ha escrit: > Why'd you drop the comments describing what the method does? I did not. I simply retained the original comment before version_etc_va. I should have supplied comments before the two new functions, that's true. I'll fix this. > I'd like to see the arguments reversed: > >

Re: New module argp-version-etc

Here's the updated patch. It swaps the n_authors and authors arguments, provides additional comments, removes the year-dependency from the test case and adds a call to va_end in version_etc. Regards, Sergey 2009-06-24 Sergey Poznyakoff Provide additional interfaces for version-etc m

Re: New module argp-version-etc

Eric Blake ha escrit: > One alternative is to massage the actual output through sed to match the > expected output, regardless of the year from version-etc.c. Such as: > > ./test-ave --version | sed 's/(C) [0-9][0-9][0-9][0-9]/(C) 2009/' \ > | diff -c $TMP - || ERR=1 That's exactly what I

Re: New module argp-version-etc

Bruno Haible ha escrit: > - Do you really need *two* array-taking functions? Yes, I believe so. I could remove one of them, but that would make the interface more awkward. E.g. retaining only version_etc_ar would mean extra iteration when called from version_etc_va. On the other hand, retainin

Re: New module argp-version-etc

Hello, I have fixed the issues Bruno pointed out in his posting, and committed the following changes. Regards, Sergey >From 3457fcf5632d0411821c6ca61b09c945da9b1063 Mon Sep 17 00:00:00 2001 From: Sergey Poznyakoff Date: Thu, 25 Jun 2009 10:31:56 +0300 Subject: [PATCH] Provide additio

Re: New module argp-version-etc

Hi Jim, > Another issue: consistency. With Bruno's approach, a public function must > have *no* spec just before its definition, while each private one does. > I think we all agree that duplicating the spec (before definition and in > the .h file) is not maintainable. Unfortunately your mail arr

Re: New module argp-version-etc

Bruno Haible ha escrit: > typo:assumed [..] > A dependency to 'version-etc' is missing. It leads to this error: Thanks, Bruno. I've fixed it. > $ ./gnulib-tool --test argp-version-etc I ran ./gnulib-tool --test --with-tests argp-version-etc, and it pulled the missing dependency via module

Re: New module argp-version-etc

Eric Blake ha escrit: > And introduced a bug to plain version_etc clients in the process, with the > potential to make --version segfault. Sorry for not spotting it before you > committed: Oops, it's me who should apologize for not spotting it! > I will be checking in this patch, if no one e

Re: test-argp-version-etc

Hi Simon, > the self test fails like this when used in a project: Thanks for noticing. > How about this patch? Nice, please push it. Regards, Sergey

[PATCH] Exclude optimization

Hello, The proposed patch considerably speed-ups the exclude module for large exclusion lists of non-wildcard patterns. Ok to push? >From 5421774438de3a67d89f988a0cd735e19a4cafd4 Mon Sep 17 00:00:00 2001 From: Sergey Poznyakoff Date: Mon, 10 Aug 2009 00:14:45 +0300 Subject: [PATCH] Optim

Re: [PATCH] Exclude optimization

Hi Bruno, > 'is_fnmatch_pattern' is probably a misnomer, because its argument is > by definition already an fnmatch pattern. What the function is testing is > whether it contains wildcard characters Yes, indeed. > Btw, this function does not handle multiple adjacent backslashes correctly, > i.e.

Re: [PATCH] Exclude optimization

Bruno Haible ha escrit: > Why does it not fit into two regexes / DFAs? Yes, it would, provided that we translate fnmatch patterns to regexps. > EXCLUDE_WILDCARDS on: 'a?b*' -> 'a.b.*' > EXCLUDE_WILDCARDS off: 'a?b*' -> 'a[?]b[*]' > EXCLUDE_ANCHORED on: 'a?b' -> '^a.b$' >

Re: [PATCH] Exclude optimization

nstant if FNM_NOESCAPE is on. Fixed both. > I would like to see some unit tests committed to this module before the > big optimization. Here they go: >From a83b74985b2226b74e23e9b2d6c32cd8037f3c80 Mon Sep 17 00:00:00 2001 From: Sergey Poznyakoff Date: Tue, 11 Aug 2009 15:47:45 +0300 Su

Re: [PATCH] Exclude optimization

ERR=0 at the beginning, while > test-exclude[167].sh don't? I've forgotten to set it there :) Fixed as well. Here goes the updated patch: >From c531a900bf4e62d0d6675a9133d6ccde972dc29d Mon Sep 17 00:00:00 2001 From: Sergey Poznyakoff Date: Tue, 11 Aug 2009 18:23:23 +0300 Subject

Re: [PATCH] Exclude optimization

Hi Ralf, > This would seem to still mis-characterizes patterns such as 'foo]'. Yes, of course. But this function is by no means thought to correctly catch all possible variations of wildcard patterns (one would have to duplicate fnmatch for that). Its purpose is to give a rough estimate on whethe

Re: [PATCH] Exclude optimization

Sergey Poznyakoff ha escrit: > It may, in same cases, incorrectly recognize the former to be the I wanted to say "in some cases", of course. Regards, Sergey

Minor fix to gitlog-to-changelog

Hello, In the output of gitlog-to-changelog, subject lines are not separated from the body. This fix adds an extra newline and fixes this. Any objections to push it? Regards, Sergey diff --git a/build-aux/gitlog-to-changelog b/build-aux/gitlog-to-changelog index 1cc53eb..a4a0c1d 100755 --- a/bui

Re: Minor fix to gitlog-to-changelog

Jim Meyering ha escrit: > I prefer the existing style, so how about making that format string an > option? That's reasonable. Something like that, then: diff --git a/build-aux/gitlog-to-changelog b/build-aux/gitlog-to-changelog index 1cc53eb..677e5f6 100755 --- a/build-aux/gitlog-to-changelog +

Re: Minor fix to gitlog-to-changelog

Jim Meyering ha escrit: > That's fine, as long as you also add a line or two in --help output. Sure. I have installed the following patch: >From 2ae2a816e734b0332eac67b07e184589e9b5957e Mon Sep 17 00:00:00 2001 From: Sergey Poznyakoff Date: Wed, 12 Aug 2009 19:48:51 +0300 Subj

gl_GETOPT_SUBSTITUTE gone

Bruno, The recent removal of gl_GETOPT_SUBSTITUTE broke argp.m4. Argp depends on GNU getopt internals, so it is safer to always include gnulib's version of getopt even if libc's one behaves identically to GNU. Will it suffice to do this: diff --git a/m4/argp.m4 b/m4/argp.m4 index 7263a56..aeb2aeb

Re: gl_GETOPT_SUBSTITUTE gone

Bruno Haible ha escrit: > Oops, I did not see this dependency. I'm restoring it now, as it's better > if most getopt related stuff stays in the same file getopt.m4. Thank you! Regards, Sergey

Re: [PATCH] progname: also set global program_invocation_name, when possible

Hello, > +#if HAVE_DECL_PROGRAM_INVOCATION_NAME > + program_invocation_name = (char *) argv0; > +#endif In my opinion, that's not correct. Libc (and gnulib's argp, FWIW) uses two variables: program_invocation_name, which points to the full program name as obtained from argv[0], and program_inv

Re: [PATCH] progname: also set global program_invocation_name, when possible

Hi Jim, > I have no control over glibc's error, and it uses program_invocation_name, > not program_invocation_short_name, so in order to make diagnostics appear like > > program_name: > > rather than > > /abs/dir.../.libs/lt-program_name: > > the set_program_name function mus

Re: lib/exclude.c calls towlower() without checking for wideline support

Alan Hourihane ha escrit: > As the subject line says, and I end up with an unresolved symbol. Please try this patch: diff --git a/lib/exclude.c b/lib/exclude.c index 32f2a0a..00f3891 100644 --- a/lib/exclude.c +++ b/lib/exclude.c @@ -31,6 +31,7 @@ #include #include #include +#include

Re: lib/exclude.c calls towlower() without checking for wideline support

Alan Hourihane ha escrit: > Not sure this is right, but it works Surely it is not right. And it does not work, either: it does not correctly lower the case of the input string. Have you tried the patch I sent? Regards, Sergey

Re: lib/exclude.c calls towlower() without checking for wideline support

Alan Hourihane ha escrit: > exclude.c: In function 'string_hasher_ci': > exclude.c:167: warning: implicit declaration of function 'towlower' > exclude.c:167: warning: incompatible implicit declaration of built-in > function 'towlower' These are warnings, not errors. What errors do you get? Pleas

Re: lib/exclude.c calls towlower() without checking for wideline support

Alan Hourihane ha escrit: > Yes, but I get this > > nm exclude.o | grep towlower > U _towlower > > And my libc doesn't define towlower() either. I see. Perhaps it is defined elsewhere? Could you please check? The gnulib's wchar.h does not provide a wrapper for it, unfortunately.

Re: lib/exclude.c calls towlower() without checking for wideline support

Hi Alan, > Sorry to ping again, but because coreutils 7.5 has the newer version of > gnulib it's blocking me from upgrading. Sorry for the delay: I was busy with other projects. I will provide a patch during this weekend. Stay in touch. Regards, Sergey

Re: lib/exclude.c calls towlower() without checking for wideline support

Bruno Haible ha escrit: > Like Solaris 2.5.1 and IRIX 5.3, you mean? This should do it. Thanks, Bruno! Regards, Sergey

getopt broken

Hello, The latest changes to getopt (commit 6471b462, "getopt: fix inclusion guards for cygwin") break compilation of getopt1.c on GNU/Linux: GENconfigmake.h CC getopt1.o getopt1.c:42: error: syntax error before '*' token getopt1.c: In function `getopt_long': getopt1.c:44: error: number o

Re: getopt broken

Eric Blake ha escrit: > Oh, I see. getopt in isolation passes, but getopt in combination with > argp causes the failure you are seeing. I guess it's because the argp > module wants to use lower-level hooks from getopt1.c than what getopt.h > normally exposes. Yes, that's it. Argp uses _getopt_

Re: getopt broken

Eric Blake ha escrit: > Maybe the trick is to check whether _getopt_long_only_r is present to the > linker, in which case we can provide our own declaration of it Yes, but we cannot guarantee our declaration matches the actual function definition. Regards, Sergey

Re: getopt broken

Eric Blake ha escrit: > But I doubt that interface has ever changed signature in glibc, and is not > available anywhere else. There are too many possibilities here. E.g. the function takes as its last argument a struct _getopt_data, which is declared in getopt_int.h This structure in libc may ha

Re: getopt broken

Eric Blake ha escrit: > It turned out there is a much simpler fix. Since glibc #define's > _GETOPT_H, our replacement thought it had already been > included, and short-circuited. If we use a different name, then > everything works out. I'm pushing this: Yes, indeed. Thanks for the fix! Regar

Re: argp warnings

Eric Blake ha escrit: > OK to commit this patch? Sure! Please, do. Regards, Sergey

Re: the signature of getopt, and getopt_long

Hi Lorenzo, > the > > char * const *argv > > libc declaration of getopt_long (which looks wrong, since argv might > be changed during the parsing, right?) Yes, it is wrong because argv might be permuted by getopt_long. And that's why gnulib's implementation uses __getopt_argv_const in the decla

getopt.h broken on FreeBSD

Hi, We've got one more problem with getopt.h. It manifests itself when compiling lex-generated parsers on FreeBSD. What happens is the following: the system getopt.h defines getopt_long, struct option and the accompanying stuff, but does not define __need_getopt. Consequently, gnulib's getopt.h in

Re: getopt.h broken on FreeBSD

Hi Jim, > How about just using flex's %top directive? Hm, I overlooked that. Thanks for the suggestion! Regards, Sergey

Re: [PATCH] argp: fix logic in hol_cluster_cmp

Thank you. I applied this change. Regards, Sergey

  1   2   >