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

2005-05-05 Thread Paul Eggert
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 it work? 2005-05-05 Paul Eggert [EMAIL PROTECTED] * lib/getopt.m4 (gl_GETOPT): Check

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

2005-05-06 Thread Paul Eggert
, so (to save everyone some time) I've added that dependency as follows. In the long run stdbool will go away, since C99 will become universal, but that will be several years from now I guess. 2005-05-06 Paul Eggert [EMAIL PROTECTED] * modules/argmatch (Depends-on): Add stdbool

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

2005-05-09 Thread Paul Eggert
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] Re: timegm license incompatibility

2005-05-09 Thread Paul Eggert
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 list

Re: [bug-gnulib] New GNULIB glob module?

2005-05-13 Thread Paul Eggert
Derek Price [EMAIL PROTECTED] writes: We've been removing those sort of constructs from CVS as part of the move away from KR support. IIRC, I was told that typecasts to and from (void *) were necessary on some really old systems, but that I could be confident that we wouldn't encounter any

[bug-gnulib] changing comments from LGPL to GPL in gnulib files that can be either

2005-05-14 Thread Paul Eggert
I installed this change, to adjust recently-added gnulib files to the gnulib tradition that the CVS version says GPL and gnulib-tool turns this into the LGPL as needed. 2005-05-13 Paul Eggert [EMAIL PROTECTED] * byteswap_.h, getsubopt.h, iconvme.h, strsep.c, strsep.h: Change

[bug-gnulib] sync gnulib from coreutils (yesno, makepath fixes)

2005-05-15 Thread Paul Eggert
I installed the following: 2005-05-14 Paul Eggert [EMAIL PROTECTED] Sync from coreutils. * lib/gethrxtime.c, lib/gethrxtime.h, lib/getpass.h, lib/mountlist.h, lib/path-concat.c, lib/regex.h, lib/strtoll.c, lib/unlocked-io.h, lib/xtime.h: White space changes only

Re: [bug-gnulib] New GNULIB glob module?

2005-05-15 Thread Paul Eggert
One other remark about glob.c. You should remove this comment, as it's obsolete now: /* Comment out all this code if we are using the GNU C Library, and are not actually compiling the library itself. This code is part of the GNU C Library, but also included in many other GNU

Re: [bug-gnulib] gcc -Wall warning for minmax.h

2005-05-17 Thread Paul Eggert
Derek Price [EMAIL PROTECTED] writes: +#ifdef LIMITS_H_HAS_MINMAX +# include limits.h +#elif SYS_PARAM_H_HAS_MINMAX +# include sys/param.h +#endif This doesn't work if limits.h and sys/param.h both define MIN. + AC_CHECK_HEADERS_ONCE([sys/param.h], +[gl_have_sys_param_h=:],

Re: [bug-gnulib] New GNULIB glob module?

2005-05-18 Thread Paul Eggert
Derek Price [EMAIL PROTECTED] writes: But let's step back a second. Why are we worried about building gnulib glob.c under glibc? It will never happen, right? So perhaps we needn't worry about this problem at all. Won't it? I thought the idea was that when you and I settled on something that

Re: [bug-gnulib] gcc -Wall warning for minmax.h

2005-05-18 Thread Paul Eggert
Derek Price [EMAIL PROTECTED] writes: Corrected patch attached. Thanks. A couple more things. (Sorry I didn't catch it earlier.) First, the $gl_* variables should be cached, with AC_CACHE_CHECK. Second, suppose limits.h and sys/param.h have conflicting definitions of MIN and MAX? To work

Re: [bug-gnulib] New GNULIB glob module?

2005-05-18 Thread Paul Eggert
Derek Price [EMAIL PROTECTED] writes: +# define GETPW_R_SIZE_MAX() (-1); There shouldn't be a semicolon here. # ifndef __USE_GNU # define __USE_GNU 1 # endif This shouldn't be needed once the sys/cdefs.h change is needed, because sys/cdefs.h should define __USE_GNU. No, because we

[bug-gnulib] sync from coreutils for fts, gettimeofday, canonicalize

2005-05-18 Thread Paul Eggert
I installed this into gnulib. This is just an internal cleanup; it shouldn't affect behavior. 2005-05-18 Paul Eggert [EMAIL PROTECTED] * lib/canonicalize.c: Include canonicalize.h first, to test interface. Include stddef.h unconditionally, since we assume C89 now. All

Re: [bug-gnulib] Re: coreutils FTS inclusion

2005-05-18 Thread Paul Eggert
Yoann Vandoorselaere [EMAIL PROTECTED] writes: There is also a problem with the 'intprops.h' dependency. When gnulib-tool is run, the file is included, but it doesn't seem to be listed as part of the generated Makefile.am, leading to 'dist' trouble. I have removed this dependency; fts no

[bug-gnulib] Re: same, utimecmp should depend on minmax

2005-05-23 Thread Paul Eggert
Bruno Haible [EMAIL PROTECTED] writes: The following heuristics works very well in practice: - First comes the #include ... specifying the module being implemented. - Then come all the #include ... of system or system-replacement headers, in arbitrary order. - Then come all the

Re: [bug-gnulib] New getlogin_r module

2005-05-25 Thread Paul Eggert
: /cvsroot/gnulib/gnulib/lib/getlogin_r.c,v retrieving revision 1.1 diff -p -u -r1.1 getlogin_r.c --- lib/getlogin_r.c25 May 2005 14:21:20 - 1.1 +++ lib/getlogin_r.c25 May 2005 19:12:57 - @@ -18,7 +18,9 @@ /* written by Paul Eggert and Derek Price */ -#include config.h

Re: [bug-gnulib] Re: references to POSIX

2005-05-27 Thread Paul Eggert
Jim Meyering [EMAIL PROTECTED] writes: Besides, isn't it worth a tiny sacrifice to avoid systematically including meaningless (and long) strings like onlinepubs/009695399/ in our code and documentation? I'm reluctant to put URLs like that in the code or documentation, since they mutate too

[bug-gnulib] Re: stat and lstat should define their replacements

2005-05-27 Thread Paul Eggert
Bruno Haible [EMAIL PROTECTED] writes: The crucial trick here is the ability to compile lstat.c so that it uses the original lstat function (be it #defined to lstat64 or not). This idea looks good to me. But: ! static int ! rpl_lstat (const char *file, struct stat *sbuf) Surely the static

Re: [bug-gnulib] ullong_max vs. stdint.h/inttypes.h

2005-05-27 Thread Paul Eggert
sense, yes. But it's not needed any more for this particular case, now that I installed this patch (in both gnulib and coreutils) to fix the problems mentioned above: 2005-05-27 Paul Eggert [EMAIL PROTECTED] * modules/fts (Files): Remove m4/inttypes-pri.m4. * modules/fts-lgpl

Re: [bug-gnulib] Re: comparison_fn_t

2005-05-27 Thread Paul Eggert
Oskar Liljeblad [EMAIL PROTECTED] writes: Sure, but assume you're passing strcmp for the comparison function, wouldn't you want to cast it to avoid the warning? I should warn you that the C Standard does not allow that sort of cast. This is for portability to hosts that use different

[bug-gnulib] Re: New getlogin_r module

2005-05-28 Thread Paul Eggert
to stick to the C convention for errno. (Sorry, I'd forgotten that rule.) On the other hand, there's no need to restore errno, and apps shouldn't depend on its being preserved. I installed this. It should be enough to conform to the C convention, right? 2005-05-27 Paul Eggert [EMAIL PROTECTED

Re: [bug-gnulib] New GNULIB glob module?

2005-05-28 Thread Paul Eggert
Derek Price [EMAIL PROTECTED] writes: Fair enough, but why undo the change to glob.m4? Shouldn't I just change the target of the AC_DEFINE from MISSING_SYS_CDEFS_H to _SYS_CDEFS_H? Yes, you're right. Sorry, I'd forgotten the trick that I had suggested. (This suggests that it deserves a nice

Re: [bug-gnulib] quote(arg) module usage?

2005-05-29 Thread Paul Eggert
[EMAIL PROTECTED] (Karl Berry) writes: Can someone point me at an example of using the quote(arg) modules? rms wants to know. gnulib/lib/makepath.c is an example. Here's how it works: #include quote.h ... error (0, errno, _(cannot change owner and/or group of %s),

Re: [bug-gnulib] getopt depending on gettext

2005-05-30 Thread Paul Eggert
Werner LEMBERG [EMAIL PROTECTED] writes: I think it is a *bad* idea to make getopt depend on gettext unconditionally. Is this because groff uses getopt but not gettext? What about the other gnulib modules that depend on gettext? Here is a list. Shouldn't they be in the same category as

Re: [bug-gnulib] New GNULIB glob module?

2005-05-31 Thread Paul Eggert
Derek Price [EMAIL PROTECTED] writes: 1. Corrects an incorrect check for a successful return from getlogin_r to assume only 0 means success, per the POSIX2 spec: http://www.opengroup.org/onlinepubs/009695399/functions/getlogin_r.html. 2. Moves the check for GLOB_MARK

[bug-gnulib] inadvertent bison.m4 patch to gnulib?

2005-06-02 Thread Paul Eggert
The following patch was installed on gnulib but it looks inadvertent. I assume it's OK for me to revert it? Or perhaps you could revert it. Index: bison.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/bison.m4,v retrieving revision 1.4

Re: [bug-gnulib] New GNULIB glob module?

2005-06-02 Thread Paul Eggert
Derek Price [EMAIL PROTECTED] writes: It may be. It looks like the change was intentional (http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/generic/glob.c?rev=1.52content-type=text/x-cvsweb-markupcvsroot=glibc), but I still disagree. I agree with you. Historically, the * pattern in

Re: [bug-gnulib] Handling of invalid multibyte character sequences in fnmatch()

2005-06-07 Thread Paul Eggert
James Youngman [EMAIL PROTECTED] writes: Any ideas/suggestions? Does the following untested patch fix things? It attempts to mimic what Bash does. *** fnmatch.c Fri May 13 23:03:58 2005 --- /tmp/fnmatch.c Tue Jun 7 00:02:03 2005 *** fnmatch (const char *pattern, const char

Re: [bug-gnulib] quote characters in stds

2005-06-08 Thread Paul Eggert
Bruno Haible [EMAIL PROTECTED] writes: Five years ago, people made up lists of programs that _do_ work with UTF-8 encoded text files. Today, these programs are uncountable. Instead, people make up lists of programs that _don't_ work with Unicode:

Re: gcc -Wall warning for minmax.h

2005-06-10 Thread Paul Eggert
Derek Price [EMAIL PROTECTED] writes: + [test ${$1+set} = set], + [{ as_var=$1; eval test \\${$as_var+set}\ = set; }])]) That change looks like it can do only good, so I installed it into Autoconf. Thanks. I'm not sure about the documentation change. It's not yet clear to me that we

Re: [bug-gnulib] Handling of invalid multibyte character sequences in fnmatch()

2005-06-10 Thread Paul Eggert
of the glibc version? But in any event, the .c fix should go in, so I installed this into gnulib: 2005-06-10 Paul Eggert [EMAIL PROTECTED] * fnmatch.c (fnmatch): If there is an encoding error in a multibyte string or pattern, fall back on unibyte matching. Problem reported

Re: xmalloc.c's xcalloc performs unnecessary test for N*S overflow

2005-06-16 Thread Paul Eggert
is being called. How about the following (untested) change instead? It omits the tests when they're unnecessary, but it doesn't establish a dependency of xalloc on calloc. I'd rather leave out dependencies like that if it's easy. 2005-06-16 Paul Eggert [EMAIL PROTECTED] * xmalloc

Re: xmalloc.c's xcalloc performs unnecessary test for N*S overflow

2005-06-17 Thread Paul Eggert
to reverse the sense and call it HAVE_GNU_CALLOC or something like that. How about the following (also untested) patch? 2005-06-17 Paul Eggert [EMAIL PROTECTED] * xmalloc (HAVE_GNU_CALLOC): New macro. (xcalloc): Omit needless tests if ! HAVE_GNU_CALLOC. --- xmalloc.c 2005-05-13 23

Re: warning: comparison is always false due to limited range of data type

2005-06-22 Thread Paul Eggert
Jim Meyering [EMAIL PROTECTED] writes: Oskar Liljeblad [EMAIL PROTECTED] wrote: What's the proper way to fix these warnings? quotearg.c: In function `quotearg_n_options': quotearg.c:586: warning: comparison is always false due to limited range of data type Paul, if you don't find a way to

Re: xmalloc.c's xcalloc performs unnecessary test for N*S overflow

2005-06-22 Thread Paul Eggert
I installed the following (slightly different) patch for that problem, into gnulib. It's tested with GNU tar. 2005-06-22 Paul Eggert [EMAIL PROTECTED] * xmalloc.c (HAVE_GNU_CALLOC): New constant. (xcalloc): Use it to avoid needless tests. Problem reported by Jim

Re: [patch] who and stale utmp entries

2005-06-22 Thread Paul Eggert
Tim Waugh [EMAIL PROTECTED] writes: I had a bug report that 'who -b' and 'who -r' fail to give output with this patch. This fixes it: Thanks for reporting that. IS_USER_PROCESS is already defined in readutmp.h, so I installed this simpler patch in both coreutils and gnulib. 2005-06-22 Paul

Re: new warnings in mktime.c

2005-06-22 Thread Paul Eggert
please try it with your GCC? If it pacifies your GCC I'll propagate it into gnulib and glibc. 2005-06-22 Paul Eggert [EMAIL PROTECTED] * mktime.c: Include string.h even if !DEBUG. (From glibc.) (ranged_convert): Don't save conversion in a temporary struct. This causes

Re: warning: comparison is always false due to limited range of data type

2005-06-22 Thread Paul Eggert
simply fix GCC instead? Something like the following. (-Wextra is the new name for -W.) (Also I'd have to document this.) 2005-06-22 Paul Eggert [EMAIL PROTECTED] * c-common.c (shorten_compare): Unless -Wextra is used, do not warn against comparisons always being false due

Re: new warnings in mktime.c

2005-06-23 Thread Paul Eggert
Jim Meyering [EMAIL PROTECTED] writes: Anyway, I installed this patch into coreutils. Can you please try it with your GCC? If it pacifies your GCC I'll propagate it into gnulib and glibc. It does. Thanks! OK, I installed it. I also started the ball rolling on propagating the changes

canon-host.c disagreement (gnulib vs coreutils); zero initializers

2005-06-23 Thread Paul Eggert
be used for any object in C89, e.g.: mbstate_t initial_state = { 0, }; where we don't know whether mbstate_t is a structure, or an integer, and the code works either way. So, I propose that we make the following patch to gnulib, and propagate this to coreutils: 2005-06-23 Paul Eggert

Re: FYI: Minor patch to glob_.h

2005-06-23 Thread Paul Eggert
Derek Price [EMAIL PROTECTED] writes: Do you want me to keep sending FYI's to this list for this sort of minor change? Yes, please. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [EMAIL PROTECTED]: Re: quotation characters]

2005-06-23 Thread Paul Eggert
[EMAIL PROTECTED] (Karl Berry) writes: Here are rms's comments on our draft about the quote character stuff. 1) I don't know how to address his problem with domain at hand, please help? How about changing this: Sticking to the ASCII character set (plain text, 7-bit characters) is

Re: canon-host.c disagreement (gnulib vs coreutils); zero initializers

2005-06-24 Thread Paul Eggert
Simon Josefsson [EMAIL PROTECTED] writes: I recall some compilers complaining about a trailing ','s. Is it really OK by C89? I'm just curious. Yes, it is allowed in C89. Perhaps you're thinking of enumeration specifiers. The declaration: enum { zero, }; is not allowed in C89. (C99

Re: size_max

2005-06-24 Thread Paul Eggert
a proposed patch. 2005-06-24 Paul Eggert [EMAIL PROTECTED] * size_max.m4 (gl_SIZE_MAX): ~(size_t)0 - (size_t) -1, since the latter works even if size_t is narrower than int. --- size_max.m4 2005-01-18 05:07:56 -0800 +++ /tmp/size_max.m42005-06-24 11:01:41 -0700 @@ -26,9

Re: [EMAIL PROTECTED]: Re: quotation characters]

2005-06-24 Thread Paul Eggert
[EMAIL PROTECTED] (Karl Berry) writes: Maybe we should just drop the text about '...' and ..., as it's kind of implied. Thus: In the C locale, GNU programs should stick to plain ASCII for quotation characters in messages to users: preferably 0x60 (`) for left quotes and 0x27 (') for

Re: proposal: lib/verify.h

2005-06-30 Thread Paul Eggert
Jim Meyering [EMAIL PROTECTED] writes: #define GL_CONCAT... #define VERIFY(assertion) \ struct GL_CONCAT (compile_time_assert_, __LINE__) \ { char a[(assertion) ? 1 : -1]; } This trick won't work if VERIFY is used in two different files with the same line number. Typically the

xnanosleep.c port to OpenBSD 3.4

2005-07-01 Thread Paul Eggert
I installed the following to fix a porting problem with OpenBSD 3.4. Its time.h declares 'struct timespec' but does not define it, i.e., it says only struct timespec;. (That's pretty usesless, hun?) 2005-07-01 Paul Eggert [EMAIL PROTECTED] * xnanosleep.c: Include timespec.h, since

Re: lgpl compatible files archive?

2005-07-03 Thread Paul Eggert
Patrice Dumas [EMAIL PROTECTED] writes: I am currently packaging a library under the LGPL, so I cannot use the files of the gnulib that are under the GPL. Is there somewhere a project similar with the gnulib but with files with LGPL compatible licences? Not that I know of. Note that many of

Re: strftime LGPL depends on GPL modules

2005-07-03 Thread Paul Eggert
to prereq.m4 to require the tzset module). 2005-07-03 Paul Eggert [EMAIL PROTECTED] Remove the dependency of the strftime module on the tzset module. * lib/strftime.c (my_strftime) [! defined _LIBC ! HAVE_RUN_TZSET_TEST]: Copy the input structure, to work around some

Re: lgpl compatible files archive?

2005-07-04 Thread Paul Eggert
Patrice Dumas [EMAIL PROTECTED] writes: alloca malloc realloc strtod atexit dup2 getcwd getpagesize memmove memset strerror regex These are mostly equivalent to existing and widely used LGPLed code, so I'd say they should be LGPLed. I would say the one exception is getcwd, where the code to

Re: Use of the m4 macros and standard package

2005-07-04 Thread Paul Eggert
Patrice Dumas [EMAIL PROTECTED] writes: Imagine someone doing coding at 6 places (5 labs and a home) No, let's not imagine that. (You should be simplifying your life! :-) Seriously, though, I regularly do something like this: * Check out a the latest Tar CVS. * Run ./bootstrap. This

Re: mbrtowc.m4 on mingw32

2005-07-04 Thread Paul Eggert
Stepan Kasal [EMAIL PROTECTED] writes: A copy of the macro is attached below; does it work for you? Thanks for suggesting that. Yes, if the current Autoconf macro works for Bruno, we should simply use a copy of it in gnulib. ___ bug-gnulib mailing

Re: proposal: lib/verify.h

2005-07-04 Thread Paul Eggert
do. Similarly, we shouldn't need to #undef verify. I installed this patch into coreutils. Comments? 2005-07-04 Paul Eggert [EMAIL PROTECTED] * lib/verify.h (GL_CONCAT0, GL_CONCAT): Define unconditionally; don't depend on whether verify_decl is defined. (verify

Re: no rpl_mktime in mktime.c

2005-07-07 Thread Paul Eggert
Patrice Dumas [EMAIL PROTECTED] writes: There is no rpl_mktime defined in mktime.c, although in gl_FUNC_MKTIME there is AC_DEFUN([gl_FUNC_MKTIME], [ AC_REQUIRE([AC_FUNC_MKTIME]) if test $ac_cv_func_working_mktime = no; then AC_DEFINE(mktime, rpl_mktime, Doesn't this cause the

Re: same.c:78: error: `HAVE_LONG_FILE_NAMES' undeclared (first use in this function)

2005-07-08 Thread Paul Eggert
is adding AC_REQUIRE([AC_SYS_LONG_FILE_NAMES]) to the same prerequisites like it is in backupfile.m4. Thanks; I installed this patch in both gnulib and coreutils: 2005-07-07 Paul Eggert [EMAIL PROTECTED] * backupfile.m4 (gl_BACKUPFILE): Use AC_CHECK_FUNCS_ONCE on pathconf

Re: no rpl_mktime in mktime.c

2005-07-08 Thread Paul Eggert
Patrice Dumas [EMAIL PROTECTED] writes: Yes, but if in the standard headers something odd is done with the mktime symbol and mktime is redefined then it could end up with a build error. Yes; that's a problem with all the rpl_* symbols. It might be better than a runtime error (but not

Re: no rpl_mktime in mktime.c

2005-07-09 Thread Paul Eggert
Patrice Dumas [EMAIL PROTECTED] writes: So maybe there shouldn't be AC_DEFINE(mktime, rpl_mktime, in gl_FUNC_MKTIME in m4/mktime.m4? Yes, because otherwise mktime.c would attempt to define an external function mktime. The C Standard doesn't allow that, and some hosts don't permit it. The

Re: {base,dir}name // semantics

2005-07-09 Thread Paul Eggert
[EMAIL PROTECTED] (Eric Blake) writes: I take it a simple autoconf test is in order (how about just testing to see if 'ls -di / //' produces 2 different inodes?) Sounds reasonable. Why doesn't gnulib use the platform's basename(3) and dirname(3), They're too often buggy.

Re: [bug-gnulib] Re: no rpl_mktime in mktime.c

2005-07-11 Thread Paul Eggert
Bruno Haible [EMAIL PROTECTED] writes: - Which header files are included by the program, in which order? That I don't know, but it's pretty easy to see how the problem would arise by looking at the header (see the pattern below). - Which C++ header undefines mktime? On my Debian GNU/Linux

Re: lgpl compatible files archive?

2005-07-11 Thread Paul Eggert
Stepan Kasal [EMAIL PROTECTED] writes: does this mean that the arbitrarily-deep nesting code is not going to be contributed back to glibc? No. I don't think anybody is working on it though, and in the meantime let's let sleeping dogs lie. ___

Re: [bug-gnulib] Re: should argp depend on unlocked-io?

2005-07-11 Thread Paul Eggert
Bruno Haible [EMAIL PROTECTED] writes: What about this patch, then? Add the dependency to the module description. It's then unnecessary to mention it in the autoconf macro. Both patches look a bit off to me, since argp should be usable in multithreaded code. (This is a problem with the

Re: [bug-gnulib] Re: proposal: lib/verify.h

2005-07-11 Thread Paul Eggert
Bruno Haible [EMAIL PROTECTED] writes: However, Jim's first version with the NULL pointer works in C++ too: #define verify_expr(R) (void) ((verify_type__ (R) *) 0) I'd therefore suggest to use this one. Thanks for catching that; I followed your suggestion in coreutils. 2005-07-11 Paul

Re: [bug-gnulib] new module gettext-h for programs that don't use i18n

2005-07-11 Thread Paul Eggert
Bruno Haible [EMAIL PROTECTED] writes: I would therefore now suggest to undo the earlier commodity hacks and return to a state where the modules/* files represent the real dependencies. Namely, add back 'xalloc-die' as dependency to those modules need it. Not sure about 'unlocked-io'. Thanks

Re: UTF-8 support

2005-07-11 Thread Paul Eggert
Bruno Haible [EMAIL PROTECTED] writes: Paul Eggert wrote: I read your email containing accented letters with GNU Emacs 21.4 and Gnus 5.10.6, a combination that supports UTF-8. The UTF-8 support in Emacs 21.4 is minimal. Some people recommend the emacs-unicode-2 branch of the Emacs CVS

Re: copyright message with(out) directives

2005-07-12 Thread Paul Eggert
[EMAIL PROTECTED] (Karl Berry) writes: +the GNU General Public License http://www.gnu.org/licenses/gpl.html.\n\ I've never seen a url in this message before, for any program. Not that I object, I guess it makes sense, but it seems new? Yes, it is new. You said you found this in the

Re: Test for glob symlink bug

2005-07-13 Thread Paul Eggert
Derek Price [EMAIL PROTECTED] writes: +AC_CACHE_CHECK([GNU glob interface version], [gl_cv_glob_interface], +[ AC_COMPILE_IFELSE( ... [[#include gnu-versions.h char a[_GNU_GLOB_INTERFACE_VERSION == 1 ? 1 : -1];]], - [], [GLOB_H=glob.h]) +

Re: [bug-gnulib] Re: quoting in gnulib

2005-07-15 Thread Paul Eggert
Bruno Haible [EMAIL PROTECTED] writes: Hey, how about using this as a help for the translators. Thanks. I installed that, with a minor change to the URL and its associated text, as follows: --- quotearg.c 14 May 2005 06:03:58 - 1.44 +++ quotearg.c 15 Jul 2005 21:01:41 -

Re: [bug-gnulib] new module gettext-h for programs that don't use i18n

2005-07-15 Thread Paul Eggert
Bruno Haible [EMAIL PROTECTED] writes: The way it's implemented in gnulib-tool, the --avoid acts _during_ the computation of the transitive closure, not afterwards. Which means, --avoid=xalloc-die prevents the xalloc-die module from being included AND also prevents the error, gettext-h,

Re: support for multithread-safe libraries

2005-07-15 Thread Paul Eggert
Bruno Haible [EMAIL PROTECTED] writes: So I still think the name lock is fine. Here's a little bit more evidence. I just checked Debian stable, and it has an /usr/include/lock.h, installed by an AFS development package. See:

Re: getline

2005-07-17 Thread Paul Eggert
Simon Josefsson [EMAIL PROTECTED] writes: 1) Port the libc LGPL getdelim into a gnulib module. 2a) Port the libc LGPL getline into a gnulib module. 2b) Write a gnulib LGPL getline module that use the gnulib LGPL getdelim. 3) Keep the current getndelim2 as a GPL module. The libc getline seem

Re: [bug-gnulib] Re: quoting in gnulib

2005-07-18 Thread Paul Eggert
[EMAIL PROTECTED] (Bob Proulx) writes that http://en.wikipedia.org/wiki/Quotation_mark#Quotation_marks_in_English: looks fine to me too on my stock Debian GNU/Linux 3.1 sarge system running Firefox 1.0.4. (I am saying this only so that readers of the archive later won't think this is

Re: patch for regex.m4

2005-07-25 Thread Paul Eggert
the underlying problem is first, before removing this from regex.m4. 2005-07-25 Paul Eggert [EMAIL PROTECTED] * regex.m4 (gl_INCLUDED_REGEX): Use AC_RUN_ELSE instead of the obsolescent AC_TRY_RUN. Include the default includes files, for 'exit'. --- regex.m47 Jul 2005 08:08:39

Re: patch for regex.m4

2005-07-25 Thread Paul Eggert
I removed m4_syscmd, ..., because they were not working on either Mac OS/X or RHEL3. Hmm, why not? Shouldn't they be working? What versions of m4 and Autoconf were you using? Let's try to see what the underlying problem is first, before removing this from regex.m4. Well, I have to

Re: tempfailure: adding TEMP_FAILURE_RETRY

2005-07-25 Thread Paul Eggert
Oskar Liljeblad [EMAIL PROTECTED] writes: It backports the TEMP_FAILURE_RETRY macro from GNU Libc to Gnulib. The proposed implementation isn't portable; it assumes GCC syntax. And it should probably defer to the unistd.h implementation if available. My kneejerk reaction is that it's a bit

getopt.m4 changes for Emacs

2005-07-26 Thread Paul Eggert
I installed this change for the benefit of GNU Emacs. Other packages shouldn't be affected. 2005-07-26 Paul Eggert [EMAIL PROTECTED] Add support to getopt for Emacs, which doesn't use LIBOBJS in the normal way. * m4/getopt.m4 (gl_GETOPT_SUBSTITUTE_HEADER): New macro

Re: getline

2005-07-26 Thread Paul Eggert
That patch (in http://lists.gnu.org/archive/html/bug-gnulib/2005-07/msg00172.html) looks reasonable to me, though I haven't had time to test it myself. Please install it, and we can deal with any porting problems later. ___ bug-gnulib mailing list

Re: [bug-gnulib] some headers prevent later code from using __attribute__

2005-08-15 Thread Paul Eggert
Ben Pfaff [EMAIL PROTECTED] writes: Do you know anybody still seriously using a GCC version 2.95 ? I do not. Is this a serious argument against doing the right thing? I think the problem is that we cannot seriously test any changes here. Also, there are probably some backward-compatibility

Re: [bug-gnulib] regex problems

2005-08-15 Thread Paul Eggert
filed a glibc bug report so that it gets put into glibc. Here's what I installed. 2005-08-15 Paul Eggert [EMAIL PROTECTED] * config/srclist.txt: Comment out $LIBCSRC/posix/regex.h. Add comments for each pending glibc patch. 2005-08-15 Bruno Haible [EMAIL PROTECTED

getopt patch for GNU tar

2005-08-16 Thread Paul Eggert
for the substitute getopt.h but getopt then overrode the result. I installed this fix: 2005-08-16 Paul Eggert [EMAIL PROTECTED] * getopt.m4 (gl_GETOPT_CHECK_HEADERS): Do not override the results of gl_GETOPT_SUBSTITUTE. That way, if both gl_GETOPT_SUBSTITUTE and gl_GETOPT are both

regex_internal.c patch to avoid warnings with gcc -Wshadow

2005-08-19 Thread Paul Eggert
I installed this, adapted from coreutils. I also filed glibc bug 1215 to merge it back into glibc. 2005-08-19 Paul Eggert [EMAIL PROTECTED] * config/srclist.txt: Comment out $LIBCSRC/posix/regex_internal.c. * lib/regex_internal.c (re_string_realloc_buffers, re_node_set_insert

lib/regexec.c patch to avoid shadowing warning

2005-08-19 Thread Paul Eggert
I installed this patch, taken from coreutils. I also filed a glibc bug report. 2005-08-19 Jim Meyering [EMAIL PROTECTED] * lib/regexec.c (proceed_next_node): Redo local variables to avoid GCC shadowing warnings. 2005-08-19 Paul Eggert [EMAIL PROTECTED] * config

patch for regex_internal.c bogus warnings

2005-08-19 Thread Paul Eggert
I installed this, imported from coreutils. I filed glibc bug 1218. 2005-08-19 Paul Eggert [EMAIL PROTECTED] * lib/regex_internal.c (re_acquire_state, re_acquire_state_context) [defined lint]: Suppress bogus uninitialized-variable warnings. * config/srclist.text: Add

removed duplicate decl from regcomp.c

2005-08-20 Thread Paul Eggert
I installed this, and filed a glibc bug report. 2005-08-20 Paul Eggert [EMAIL PROTECTED] * srclist.txt: Add glibc bug 1223. * lib/regcomp.c (create_initial_state): Remove duplicate decl. Index: config/srclist.txt

remove no-longer-needed forward decls from regcomp.c

2005-08-20 Thread Paul Eggert
I installed this and filed glibc bug 1224. 2005-08-20 Paul Eggert [EMAIL PROTECTED] * srclist.txt: Add glibc bug 1224. * lib/regcomp.c: (init_word_char, create_initial_state, duplicate_node_closure): (fetch_token, peek_token_bracket, build_range_exp

regexec.c patch imported from coreutils to avoid uninit var warning

2005-08-20 Thread Paul Eggert
I installed this and filed glibc bug 1225: 2005-08-20 Paul Eggert [EMAIL PROTECTED] * config/srclist.txt: Add glibc bug 1225. 2005-08-20 Jim Meyering [EMAIL PROTECTED] * lib/regexec.c (regexec, re_search_stub) [!_LIBC]: Omit declaration of unused local, dfa

Re: regex problems

2005-08-20 Thread Paul Eggert
Sam Steingold [EMAIL PROTECTED] writes: Would you please also consider the 2 patches in http://article.gmane.org/gmane.comp.lib.gnulib.bugs:3996 OK, I installed the first patch, as follows: 2005-08-20 Paul Eggert [EMAIL PROTECTED] * config/srclist.txt: Add glibc bug 1226

Re: regex problems

2005-08-20 Thread Paul Eggert
the following instead (and reported the bug to glibc): 2005-08-20 Paul Eggert [EMAIL PROTECTED] * config/srclist.txt: Add glibc bug 1227. * lib/regexec.c (sift_states_bkref): Fix portability bug: the code assumed that reg_errcode_t is a signed type, which is not necessarily

Re: regexp regressions

2005-08-21 Thread Paul Eggert
Sam Steingold [EMAIL PROTECTED] writes: the latest and greatest gnulib regexp has the following regressions vs the previous (monolithic) version: Sorry, I didn't understand the notation that you used in http://lists.gnu.org/archive/html/bug-gnulib/2005-08/msg8.html. I tried to reproduce

Re: error: possibly undefined macro: AC_CHECK_HEADERS_ONCE

2005-08-23 Thread Paul Eggert
Bruno Haible [EMAIL PROTECTED] writes: That appears to be obsolete. As far as I see, there are no users of this macro which don't also bundle regex.c. Yes, that sounds right. I installed this patch into gnulib, and then reindented. 2005-08-23 Paul Eggert [EMAIL PROTECTED] * m4

regex.h REG_ENOSYS patch for POSIX and portability

2005-08-23 Thread Paul Eggert
It looks like I spoke too soon and that we still have some regex problems. Among other things, there seem to be several problems with the POSIX name space restrictions in regex.h. To get the ball rolling I installed this: 2005-08-23 Paul Eggert [EMAIL PROTECTED] * config/srclist.txt

Re: regex g++

2005-08-23 Thread Paul Eggert
Sam Steingold [EMAIL PROTECTED] writes: c++ is stricter, so if the code can be compiled with c++ it is probably safer. That doesn't match my experience. To make C code work with C++, I often have to introduce casts (e.g., to convert void * to char *, or to convert one integer type to

Re: ISO C 99 versus POSIX 2001

2005-08-24 Thread Paul Eggert
Bruno Haible [EMAIL PROTECTED] writes: Gnulib's purpose is to provide portability across the mainstream systems, _regardless_ whether they implement the standards correctly. I agree with most of the other points you made, but I'd like to demur on this point. Gnulib is part of the GNU

Re: Possible spurious cycle detection with fts

2005-08-24 Thread Paul Eggert
Jim Meyering [EMAIL PROTECTED] writes: I'll hold off on the commit until Paul signs off on it. That looks good to me. Thanks for doing the merge. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: getpass: use of termios.h problematic

2005-08-24 Thread Paul Eggert
Simon Josefsson [EMAIL PROTECTED] writes: + * getpass.c: Add WIN32 implementation. Conditionalize use of + termios.h, tcgetattr, tcsetattr and __fsetlocking. Remove some + GLIBC specific code. Why remove the GLIBC specific code? I'd rather keep gnulib in sync with glibc as much

modify regex implementation to use POSIX-compliant names

2005-08-24 Thread Paul Eggert
I installed this as a followup to the regex.h POSIX-compliance fixes, and filed glibc bug 1237. 2005-08-24 Paul Eggert [EMAIL PROTECTED] * config/srclist.txt: Add glibc bug 1237. * lib/regcomp.c, lib/regex_internal.c, lib/regex_internal.h: * lib/regexec.c: All

'restrict' fixes for regex.h, regcomp.c

2005-08-24 Thread Paul Eggert
I installed this to patch another POSIX incompatibility with regex, and filed glibc bug 1240. 2005-08-24 Paul Eggert [EMAIL PROTECTED] * config/srclist.txt: Add glibc bug 1240. * lib/regcomp.c (regerror): 2nd arg is 'restrict', as per POSIX. * lib/regex.h (regerror

Re: sysexits.h: Define EX_OK

2005-08-24 Thread Paul Eggert
Ben Pfaff [EMAIL PROTECTED] writes: Is there an advantage to defining EX_OK to EXIT_SUCCESS over defining it to 0? I can't think of any. Let's please just define it to 0; it's simpler and less likely to cause trouble. I also like Simon's suggestion of defining EXIT_SUCCESS and EXIT_FAILURE

Re: getpass: use of termios.h problematic

2005-08-24 Thread Paul Eggert
Simon Josefsson [EMAIL PROTECTED] writes: The resulting code would look awful, and I think it would be weird to have plenty of non-glibc specific hacks inside glibc. But keeping things in sync is a good idea, and I can work toward that goal for this module if you want. If it's too much

Re: sysexits.h: Define EX_OK

2005-08-25 Thread Paul Eggert
Stepan Kasal [EMAIL PROTECTED] writes: something like the attached patch (not tested)? Yes, something like that. For sanity's sake, I'd use the string exitcodes uniformly, though (e.g., modules/exitcodes, m4/exitcodes.m4, gl_EXITCODES). And I'd move the #include stdlib.h next to the other

Re: getpass: use of termios.h problematic

2005-08-25 Thread Paul Eggert
Simon Josefsson [EMAIL PROTECTED] writes: Ok to install? OK, with the following caveats: * Please put the standard implementation first, and the Windows implementation second. That'll make it easier to read. * Please use standard GNU indenting style, e.g., char * getpass (const char

  1   2   3   4   5   6   7   8   9   10   >