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

2005-05-09 Thread Jim Meyering
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 Depends-on:

[bug-gnulib] Re: stdint_.h update

2005-05-14 Thread Jim Meyering
Hi Bruno, 2005-05-13 Bruno Haible [EMAIL PROTECTED] * stdint_.h (int64_t, uint64_t, int_least64_t, uint_least64_t, int_fast64_t, uint_fast64_t, intmax_t, uintmax_t, INT64_MIN, INT64_MAX, UINT64_MAX, INT_LEAST64_MIN, INT_LEAST64_MAX, UINT_LEAST64_MAX,

[bug-gnulib] Re: coreutils FTS inclusion

2005-05-17 Thread Jim Meyering
). Maintainer: Jim Meyering, Paul Eggert ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib

[bug-gnulib] Re: coreutils FTS inclusion

2005-05-17 Thread Jim Meyering
Yoann Vandoorselaere [EMAIL PROTECTED] wrote: ... The other files are not hidden :) They're part of coreutils. I will try by using these. Note that coreutils contain no fts.m4. I will You'll find it in the CVS repository for the project on Savannah: savannah.gnu.org/projects/coreutils

[bug-gnulib] Re: coreutils FTS inclusion

2005-05-17 Thread Jim Meyering
Yoann Vandoorselaere [EMAIL PROTECTED] wrote: On Mon, 2005-05-16 at 13:04 +0200, Yoann Vandoorselaere wrote: On Mon, 2005-05-16 at 12:57 +0200, Jim Meyering wrote: Yoann Vandoorselaere [EMAIL PROTECTED] wrote: From a first look, the fts module file is lacking lstat, realloc and malloc

[bug-gnulib] Re: [PATCH]: fix warning in the hash module

2005-05-17 Thread Jim Meyering
Yoann Vandoorselaere [EMAIL PROTECTED] wrote: This patch fix constness warning in the GnuLib hash module. I'm all for avoiding warnings, but not when it detracts from what I think of as the correctness of an interface, as it would in this case. Those `const void *entry' parameters constitute a

[bug-gnulib] Re: coreutils FTS inclusion

2005-05-17 Thread Jim Meyering
Yoann Vandoorselaere [EMAIL PROTECTED] wrote: Another things is that including the fts module trigger a missing dependency: ../src/.libs/libprelude.so: undefined reference to `xalloc_die' That's because the hash module uses xalloc. You must tell gnulib-tool that you want to use xalloc-die, or

[bug-gnulib] Re: [PATCH]: fix warning in the hash module

2005-05-17 Thread Jim Meyering
Yoann Vandoorselaere [EMAIL PROTECTED] wrote: On Tue, 2005-05-17 at 14:21 +0200, Jim Meyering wrote: Yoann Vandoorselaere [EMAIL PROTECTED] wrote: ... This requirement is technically wrong since you allow modification of the input argument through the user provided callback. I am well

[bug-gnulib] Re: references to POSIX

2005-05-27 Thread Jim Meyering
Bruno Haible [EMAIL PROTECTED] wrote: For those modules which implement some functionality specified by POSIX, I propose to add a reference to the POSIX spec as an URL. This is a handy reference. See attached patch. Files affected: getaddrinfo.h (Simon Josefsson) getcwd.h (all)

[bug-gnulib] Re: references to POSIX

2005-05-27 Thread Jim Meyering
Bruno Haible [EMAIL PROTECTED] wrote: Jim Meyering wrote: ... use shortened URLs. E.g., this http://www.opengroup.org/susv3xsh/gai_strerror.html redirects to this: http://www.opengroup.org/onlinepubs/009695399/functions/gai_strerror.html ... Interesting :-) However, some users (like

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

2005-05-28 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: Also, while we're on the subject of lstat, what operating systems have the bug caught by AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK? If they are sufficiently old, perhaps we can simply remove the lstat module as well. That would be nice. It's going to be a few

Re: quote characters in stds

2005-06-07 Thread Jim Meyering
Hi Karl, Here's a nit: [EMAIL PROTECTED] (Karl Berry) wrote: ... The @uref{http://www.gnu.org/software/gnulib/, Gnulib} @code{quote} and @code{quotearg} modules provide a reasonably straightforward way support locale-specific quote characters, as well as taking care of s/support/to support/

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

2005-06-16 Thread Jim Meyering
Currently, the xalloc module doesn't depend on any other. I think it should depend at least on the calloc module. If it did so, the test for overflow /* Test for overflow, since some calloc implementations don't have proper overflow checks. */ if (xalloc_oversized (n, s) || (! (p =

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

2005-06-17 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: ... 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. Looks fine to me. Thanks!

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

2005-06-21 Thread Jim Meyering
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 eliminate the warning by changing

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

2005-06-22 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: 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

new warnings in mktime.c

2005-06-22 Thread Jim Meyering
in this function mktime.c:244: warning: 'tm.tm_sec' may be used uninitialized in this function make[1]: *** [mktime.o] Error 1 There is no real problem, but it's best to provide a way to suppress such warnings. So here's one approach, but I'm hoping there's a better way... 2005-06-22 Jim Meyering

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

2005-06-22 Thread Jim Meyering
Oskar Liljeblad [EMAIL PROTECTED] wrote: On Wednesday, June 22, 2005 at 11:50, Jim Meyering wrote: ... These days, I rarely use -W (and never use it with -Werror), for precisely that reason. I get that warning without both -W and -Wall, I think. (gcc 3.3.6) I've tried with the following

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

2005-06-22 Thread Jim Meyering
Oskar Liljeblad [EMAIL PROTECTED] wrote: On Wednesday, June 22, 2005 at 13:47, Jim Meyering wrote: I get that warning without both -W and -Wall, I think. (gcc 3.3.6) I've tried with the following versions of gcc on x86_64-unknown-linux-gnu: gcc-3.3 (GCC) 3.3.6 (Debian 1:3.3.6-6) gcc

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

2005-06-22 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: Oskar Liljeblad [EMAIL PROTECTED] wrote: ... quotearg.c: In function `quotearg_n_options': quotearg.c:586: warning: comparison is always false due to limited range of data type ... My own experience is that that particular warning is more trouble than

Re: new warnings in mktime.c

2005-06-22 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: With gcc-4.0 -O -Wall, I get these new warnings: Odd; I don't get those warnings with gcc 4.0.0 -O -Wall: $ gcc -DHAVE_CONFIG_H -I. -I.. -O -Wall -c mktime.c $ gcc --version | sed 1q gcc (GCC) 4.0.0 I'm using

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

2005-06-23 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: It will take a while for this fix to propagate, though. In the meantime, why not modify the definition of xalloc_oversized(n,s) to always return 0 if if s is a constant and if the size of n is such that the comparison cannot possibly fail. Something like

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

2005-06-24 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: I noticed the following disagreement between gnulib and coreutils: --- gnulib/lib/canon-host.c 2005-05-13 23:03:57 -0700 +++ cu/lib/canon-host.c 2005-05-14 00:58:06 -0700 ... I assume that this was due to a warning from gcc -W about a missing

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

2005-06-24 Thread Jim Meyering
Simon Josefsson [EMAIL PROTECTED] wrote: Paul Eggert [EMAIL PROTECTED] writes: The extra comma is an indication to the reader that we know there are missing zeros, and don't care. This style can be used for any object in C89, e.g.: mbstate_t initial_state = { 0, }; where we don't

Re: check_version

2005-06-25 Thread Jim Meyering
Simon Josefsson [EMAIL PROTECTED] wrote: I'm using this module in all of my GNU packages. One complication might be that it depends on VERSION being defined. Feedback appreciated. Looks useful, but sounds like a job better implemented in a higher level language. But maybe you have

Re: check_version

2005-06-25 Thread Jim Meyering
Simon Josefsson [EMAIL PROTECTED] wrote: Not sure I follow the higher-level language part... Perhaps I should explain more what I use this for. I use it in my libraries, which are all written in C. The source code Thanks for explaining. That's what I suspected. What do you think about

Re: check_version

2005-06-28 Thread Jim Meyering
Simon Josefsson [EMAIL PROTECTED] wrote: Paul Eggert [EMAIL PROTECTED] writes: Simon Josefsson [EMAIL PROTECTED] writes: /* Check version of libgcrypt. */ if (!gcry_check_version (GCRYPT_VERSION)) die (version mismatch\n); Can't you use strverscmp for this? E.g.:

Re: check_version

2005-06-28 Thread Jim Meyering
Simon Josefsson [EMAIL PROTECTED] wrote: Ah, right. I accidentally installed the m4 file. Ok to install the rest too? Sure. It looks fine to me. Thanks. ___ bug-gnulib mailing list bug-gnulib@gnu.org

proposal: lib/verify.h

2005-06-29 Thread Jim Meyering
-alloc); But then I realized that while the above changes made things a little more concise and maybe even a little cleaner, they also added a potential risk. So I added an intermediate X2REALLOC macro, and made all of the above use that instead of using x2realloc directly. 2005-06-29 Jim Meyering

FYI: minor mkdir-p.c and idcache.c clean-up

2005-06-29 Thread Jim Meyering
I've just checked in these changes in both gnulib and coreutils: 2005-06-29 Jim Meyering [EMAIL PROTECTED] * mkdir-p.c (make_dir_parents): Don't apply sizeof to a hard-coded type name. Use the variable name instead. * idcache.c (getuser, getuidbyname, getgroup

Re: proposal: lib/verify.h

2005-06-30 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: 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

FYI: removing HAVE_FCNTL_H tests

2005-07-01 Thread Jim Meyering
I've just removed all tests for HAVE_FCNTL_H from coreutils. It's been gone in at least one place since coreutils-5.0 (2004-04-02) and no one has complained, so I think it's safe to say every system we care about has fcntl.h, now. If you know of a system (reasonable portability target) that lacks

Re: FYI: removing HAVE_FCNTL_H tests

2005-07-01 Thread Jim Meyering
Jim Meyering [EMAIL PROTECTED] wrote: I've just removed all tests for HAVE_FCNTL_H from coreutils. It's been gone in at least one place since coreutils-5.0 (2004-04-02) The same applies to HAVE_UNISTD_H and unistd.h, but I haven't yet made the change in coreutils. I'll do it over the weekend

Re: FYI: removing HAVE_FCNTL_H tests

2005-07-02 Thread Jim Meyering
Jim Meyering [EMAIL PROTECTED] wrote: I've just removed all tests for HAVE_FCNTL_H from coreutils. It's been gone in at least one place since coreutils-5.0 (2004-04-02) and no one has complained, so I think it's safe to say every system we care about has fcntl.h, now. FYI, that date should

Re: FYI: removing HAVE_FCNTL_H tests

2005-07-02 Thread Jim Meyering
target) that lacks fcntl.h, speak now. Tomorrow I plan to remove all #if HAVE_FCNTL_H tests, retaining only the `if' branch. Likewise, there is no need to check for fcntl.h in .m4 macros. I've just done the same for gnulib: [lib] 2005-07-01 Jim Meyering [EMAIL PROTECTED] * chown.c

Re: lgpl compatible files archive?

2005-07-04 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: 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

Re: Possible spurious cycle detection with fts

2005-08-09 Thread Jim Meyering
false positives with FTS_NOSTAT|FTS_LOGICAL. Here's a barely-tested fix (tested only with an instrumented chown-core.c via `chown -RL' since I don't have the latest find sources here): Barring negative feedback, I'll check it in to gnulib in a day or two. 2005-08-09 Jim Meyering [EMAIL PROTECTED

Re: Possible spurious cycle detection with fts

2005-08-10 Thread Jim Meyering
James Youngman [EMAIL PROTECTED] wrote: This patch resolves my problem; thanks. Might I suggest though that you enhance the ChangeLog entry to describe the problem as well as the solution? This change requires some comment changes, too. I'll do both.

Re: Possible spurious cycle detection with fts

2005-08-14 Thread Jim Meyering
Jim Meyering [EMAIL PROTECTED] wrote: James Youngman [EMAIL PROTECTED] wrote: This patch resolves my problem; thanks. Might I suggest though that you enhance the ChangeLog entry to describe the problem as well as the solution? This change requires some comment changes, too. I'll do both

FYI: strftime.c fix obscure %s formatting bug

2005-08-19 Thread Jim Meyering
FYI, I've just checked in this change: 2005-08-17 Jim Meyering [EMAIL PROTECTED] Make the %s format (seconds since the epoch) work for a negative number and when used with a zero-padded field width, e.g. %015s. * strftime.c (my_strftime): Move

Re: getdelim doesn't set errno on failure?

2005-08-24 Thread Jim Meyering
Bruno Haible [EMAIL PROTECTED] wrote: You cannot assume that malloc() and realloc() set errno upon failure. - In ISO C 99, the description of malloc() and realloc() does not mention errno. Also, errno.h is not required to declare a macro 'ENOMEM'. - Windows (mingw) malloc() and

Re: getdelim doesn't set errno on failure?

2005-08-24 Thread Jim Meyering
Bruno Haible [EMAIL PROTECTED] wrote: Jim Meyering wrote: Note that POSIX *does* require a failed malloc call to set errno to ENOMEM, albeit with CX shading (meaning IEEE Std 1003.1-2001). http://www.opengroup.org/susv3xsh/malloc.html Let's try not to let substandard systems dictate

Re: Possible spurious cycle detection with fts

2005-08-24 Thread Jim Meyering
I've just committed that patch. Jim Meyering [EMAIL PROTECTED] wrote: ... Thanks for reporting that. With the following changes, ./gnulib-tool --test fts once again passes. 2005-08-24 Jim Meyering [EMAIL PROTECTED] * modules/fcntl-safer: New module. * modules/fts (Depends

cvs coreutils was broken wrt LARGEFILE support

2005-08-25 Thread Jim Meyering
Today I tried to use `cp' to copy a file larger than 2GB and was surprised to get a `File too large' error. Here's the patch I've applied to both coreutils and gnulib: 2005-08-25 Jim Meyering [EMAIL PROTECTED] * open-safer.c: Include config.h. Otherwise, we'd lose LARGEFILE

Re: patch ping

2005-08-29 Thread Jim Meyering
Stepan Kasal [EMAIL PROTECTED] wrote: could you please look at my patch submitted in http://lists.gnu.org/archive/html/bug-gnulib/2005-07/msg00084.html That looks fine. Thanks for doing that. Please apply. ___ bug-gnulib mailing list

Re: pathmax module license

2005-08-31 Thread Jim Meyering
Yoann Vandoorselaere [EMAIL PROTECTED] wrote: Hi Jim, Would it be possible to change the pathmax license from GPL to LGPL ? I would like to use the module from the prelude library, which require external code to be LGPL. Regards, That's fine with me, and it's certainly small enough, but

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

2005-08-31 Thread Jim Meyering
Jim Meyering [EMAIL PROTECTED] wrote: Paul Eggert [EMAIL PROTECTED] wrote: It will take a while for this [gcc] fix to propagate, though. In the Is there a patch yet to make gcc suppress that warning? FYI, here is the warning again [line 586 referred to the test in the expansion

Re: fts broken again

2005-08-31 Thread Jim Meyering
[EMAIL PROTECTED] (Eric Blake) wrote: The following patch was needed to make 'gnulib-tool --test fts' pass again. Is there some way to improve new file creation to ensure that all files are claimed by a module? 2005-08-31 Eric Blake [EMAIL PROTECTED] * modules/unistd-safer (Files):

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

2005-08-31 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: Is there a patch yet to make gcc suppress that warning? Sorry, not yet. Other things are on my plate - unsigned int n1 = n0 + 1; + /* FIXME: technically, the type of n1 should be `unsigned int

const-correctness fixes for regex

2005-08-31 Thread Jim Meyering
A week or so ago, I stumbled across one interface that was missing a `const' attribute on a parameter, then dug up a few more. Paul, let me know when you reach a point at which my checking this in won't interfere. Index: regcomp.c

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

2005-09-01 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: Is it really permitted to have sizeof (size_t) sizeof (unsigned int)? ... The offending warning breaks coreutils' `make distcheck' rule. Would it make sense to rewrite coreutils 'make distcheck' to filter out

Re: const-correctness fixes for regex

2005-09-01 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: A week or so ago, I stumbled across one interface that was missing a `const' attribute on a parameter, then dug up a few more. Paul, let me know when you reach a point at which my checking this in won't interfere

Re: AC_LIBSOURCES considered harmful

2005-09-02 Thread Jim Meyering
Bruno Haible [EMAIL PROTECTED] wrote: Hi Paul, Jim, Alexandre, gnulib-tool now supports multiple gnulib directories with a single configure.ac. Simon needs this in GnuTLS. I need this in libglocale. But half of gnulib doesn't work with gnulib-tool. Due to AC_LIBSOURCES. Hi Bruno, There is

Re: AC_LIBSOURCES considered harmful

2005-09-02 Thread Jim Meyering
Bruno Haible [EMAIL PROTECTED] wrote: The problem you describe was more of an automake limitation, and it has been resolved by automake's addition of AC_CONFIG_LIBOBJ_DIR. Interesting. But AC_CONFIG_LIBOBJ_DIR is documented just between AC_CONFIG_AUX_DIR and AC_CONFIG_HEADERS, which makes me

Re: canon-host errors

2005-09-04 Thread Jim Meyering
Derek Price [EMAIL PROTECTED] wrote: Would anyone object to a patch that caused canon-host to output warnings via error (0, ...) when one of the functions it calls fails? getaddrinfo returns errors differently than gethostbyname and gethostbyaddr, making outputting a useful error message upon

Re: canon-host errors

2005-09-04 Thread Jim Meyering
Derek Price [EMAIL PROTECTED] wrote: Hrm. A new enum parameter would mean duplicating a bunch of potential POSIX error codes from the other three functions. How about if I leave the enum parameter somewhat opaque and provide a canon_host_error (perhaps strcherror is a better name) to

Re: canon-host errors

2005-09-04 Thread Jim Meyering
Derek Price [EMAIL PROTECTED] wrote: Okay. Will do. Should I ignore single-threaded apps entirely, keep the error data in a global to simplify for single-threaded apps on NULL, or break the functions into canon_host, canon_host_r, strcherror, strcherror_r? I don't thinks it's worthwhile to

Re: canon-host errors

2005-09-04 Thread Jim Meyering
Derek Price [EMAIL PROTECTED] wrote: Derek Price wrote: Hrm. Why isn't canon-host dependant on getaddrinfo? It would The alternative is that the ch_strerror_r function I've been working on would need to handle ENOMEM too, which introduces a dependency on strerror_r... I almost have the

Re: pathmax module license

2005-09-05 Thread Jim Meyering
Yoann Vandoorselaere [EMAIL PROTECTED] wrote: On Wed, 2005-08-31 at 08:35 +0200, Jim Meyering wrote: Yoann Vandoorselaere [EMAIL PROTECTED] wrote: Hi Jim, Would it be possible to change the pathmax license from GPL to LGPL ? I would like to use the module from the prelude library, which

Re: canon-host errors

2005-09-13 Thread Jim Meyering
Derek Price [EMAIL PROTECTED] wrote: I've installed the attached patch. It is almost identical to my previous one, with a few extra portability and typo fixes. 2005-09-12 Derek Price [EMAIL PROTECTED] * modules/canon-host: Add canon-host.h. Depend on getaddrinfo. Make LGPL.

Re: gnulib update (Tue Sep 13 09:03:01 EDT 2005)

2005-09-13 Thread Jim Meyering
Derek Price [EMAIL PROTECTED] wrote: Jim, all, Is there a GNULIB standard for this yet? Paul Eggert just went through my glob_.h and tweaked the cpp spacing in the other direction. I assumed at the time this meant that double-include protection should be ignored for the purposes of

Re: gnulib update (Tue Sep 13 09:03:01 EDT 2005)

2005-09-13 Thread Jim Meyering
Derek Price [EMAIL PROTECTED] wrote: Jim Meyering wrote: Personally, I've found it useful enough to have consistently cpp-indented I like it too, but I was willing to go with the flow on GNULIB. :) sources that I wrote cppi, and to use it in a commit-hook for the coreutils. I don't know

fprintftime: a new interface to strftime/nstrftime

2005-09-16 Thread Jim Meyering
the result of formatting (according to the nstrftime format string, FMT) the time data, *TM, and the UTC and NANOSECONDS values. */ size_t fprintftime (FILE *fp, char const *fmt, struct tm const *tm, int utc, int nanoseconds); 2005-09-16 Jim Meyering [EMAIL PROTECTED

Re: pathmax module license

2005-09-19 Thread Jim Meyering
Jim Meyering [EMAIL PROTECTED] wrote: Yoann Vandoorselaere [EMAIL PROTECTED] wrote: On Wed, 2005-08-31 at 08:35 +0200, Jim Meyering wrote: Yoann Vandoorselaere [EMAIL PROTECTED] wrote: Hi Jim, Would it be possible to change the pathmax license from GPL to LGPL ? I would like to use

unicodeio.c: accidental extern function: unicode_to_mb

2005-09-21 Thread Jim Meyering
Hi Bruno, Since unicode_to_mb is not declared in any other file that I can see, nor is it used elsewhere in gnulib, I suspect it really should have file scope. Here's a patch: Index: unicodeio.c === RCS file:

Re: new gnulib module verify for compile-time assertions

2005-09-23 Thread Jim Meyering
Bruno Haible [EMAIL PROTECTED] wrote: Paul Eggert wrote: The first step is to add a new module verify, which defines macros verify(EXPR) and verify_expr(EXPR) that act like assert(EXPR) except they check EXPR at compile-time, not at run-time. verify(EXPR) is for declaration contexts, and

getaddrinfo needs socklen, sync from coreutils

2005-09-23 Thread Jim Meyering
I've just discovered/fixed a build problem with the getaddrinfo module. It didn't depend on the socklen module (for the declaration of socklen_t). So I've merged these changes from coreutils: 2005-09-23 Jim Meyering [EMAIL PROTECTED] * modules/getaddrinfo (Depends-on): Add socklen

Re: new gnulib module verify for compile-time assertions

2005-09-23 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: ... How about the following patch instead? I installed it in gnulib and coreutils (though I suspect it may not be the last word, with all these screwy compilers to test). 2005-09-23 Paul Eggert [EMAIL PROTECTED] * verify.h (GL_CONCAT0,

Re: getaddrinfo needs socklen, sync from coreutils

2005-09-23 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: Bruno Haible [EMAIL PROTECTED] writes: This is redundant. The module dependency from 'getaddrinfo' to 'socklen' already implies that gl_SOCKLEN_T must be invoked from configure.ac, directly or indirectly. No need to repeat the module dependencies in the

Re: exclude.c build failure with some sunstudio compiler

2005-09-23 Thread Jim Meyering
:-) Your patch does indeed solve the build failure. 2005-09-23 Paul Eggert [EMAIL PROTECTED] * m4/fnmatch.m4 (_AC_FUNC_FNMATCH_IF): Catch Sun Studio 10u1 on Linux bug reported by Jim Meyering. ___ bug-gnulib mailing list bug-gnulib

Re: new gnulib module verify for compile-time assertions

2005-09-23 Thread Jim Meyering
Bruno Haible [EMAIL PROTECTED] wrote: Paul Eggert wrote: I suspect it may not be the last word, with all these screwy compilers to test). Indeed, IRIX 6.5 cc gives warning: signed bitfield of length 1. Changing the verify_type__ macro like this makes it work without warning. # define

Re: new gnulib module verify for compile-time assertions

2005-09-23 Thread Jim Meyering
. # define verify_type__(R) \ struct { int verify_error_if_negative_size__ : (R) ? 2 : -1; } Or just make the bitfield use type `unsigned int'. Then people won't wonder why we used 2 instead of 1, and we won't have to worry about documenting it, either. I checked this in: 2005-09-24 Jim

Re: getaddrinfo needs socklen, sync from coreutils

2005-09-24 Thread Jim Meyering
Simon Josefsson [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: I've just discovered/fixed a build problem with the getaddrinfo module. It didn't depend on the socklen module (for the declaration of socklen_t). So I've merged these changes from coreutils: Hm. socklen_t

Re: new gnulib module verify for compile-time assertions

2005-09-26 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: I have a different idea: replace verify_expr(R) with a new macro verify_true(R) that acts like verify_expr(R), but is an integer constant expression that always yields true. The advantage of verify_true(R) is that it can be used in contexts where

making INT_STRLEN_BOUND tight for unsigned types

2005-09-26 Thread Jim Meyering
it with two INT_STRLEN_BOUND definitions, but that definition has enough grist that I prefer to define a new private macro. P.P.S: At least two other compilers do support __typeof__, but I don't think its worth the autoconf test required to let them use the tighter bound here. 2005-09-27 Jim Meyering

Re: making INT_STRLEN_BOUND tight for unsigned types

2005-09-27 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: 2005-09-27 Jim Meyering [EMAIL PROTECTED] * intprops.h (signed_type_or_expr__): Define. (INT_STRLEN_BOUND) [__GNUC__]: Use a slightly tighter bound for unsigned types. That looks good to me; thanks

Re: coreutils-5.90 build feedback

2005-10-01 Thread Jim Meyering
getservbyname ../lib/libcoreutils.a(getaddrinfo.o) That function is in -lsocket, but that library is not mentioned in the cc command. I've just fixed the above for coreutils: 2005-10-01 Jim Meyering [EMAIL PROTECTED] * getaddrinfo.m4 (gl_GETADDRINFO): Look

Re: Integrating crypto functions?

2005-10-03 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: Simon Josefsson [EMAIL PROTECTED] writes: ... 2) Could we re-license the sha1 module under LGPL? Tough call. Perhaps we also need to take that to [EMAIL PROTECTED], but Jim may have a different opinion. Asking [EMAIL PROTECTED] sounds prudent.

getaddrinfo.h: HAVE_SYS_TYPES_H needed?

2005-10-05 Thread Jim Meyering
Hi Simon, I noticed that getaddrinfo.h guards the inclusion of sys/types.h with an #ifdef HAVE_SYS_TYPES_H. Do you know of a system that lacks sys/types.h? I don't see any other uses of HAVE_SYS_TYPES_H in gnulib. How about HAVE_SYS_SOCKET_H? At least poll.c uses sys/socket.h without the

Re: syncing md5 against glibc

2005-10-11 Thread Jim Meyering
Simon Josefsson [EMAIL PROTECTED] wrote: Let's not wait for glibc to install my patch... What do you think about installing the following in gnulib now? It would sync gnulib with my proposed libc-patch. It also fixes the sha1 module to be standalone. I like it. Thanks for the clean-up. I

Re: rijndael

2005-10-14 Thread Jim Meyering
Simon Josefsson [EMAIL PROTECTED] wrote: Ok to install? Comments appreciated, of course. Hi Simon, In this function, +rijndael_rc +rijndaelMakeKey (rijndaelKeyInstance * key, rijndael_direction direction, +int keyLen, char *keyMaterial) the keyMaterial parameter should be

Re: rijndael

2005-10-14 Thread Jim Meyering
Simon Josefsson [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: Simon Josefsson [EMAIL PROTECTED] wrote: Ok to install? Comments appreciated, of course. Hi Simon, In this function, +rijndael_rc +rijndaelMakeKey (rijndaelKeyInstance * key, rijndael_direction direction

Re: rijndael

2005-10-14 Thread Jim Meyering
Simon Josefsson [EMAIL PROTECTED] wrote: Revised patch. Do those `U' suffixes serve any purpose, given an array base type of uint32_t? Index: lib/rijndael-alg-fst.c ... +static const uint32_t Te0[256] = { + 0xc66363a5U, 0xf87c7c84U, 0xee99U, 0xf67b7b8dU, + 0xfff2f20dU, 0xd66b6bbdU,

Re: rijndael

2005-10-15 Thread Jim Meyering
Simon Josefsson [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: Simon Josefsson [EMAIL PROTECTED] wrote: Revised patch. Do those `U' suffixes serve any purpose, given an array base type of uint32_t? I don't know. Should I remove them? Please do. I suspect they were

Re: syncing md5 against glibc

2005-10-17 Thread Jim Meyering
Simon Josefsson [EMAIL PROTECTED] wrote: The glibc maintainers didn't accept this patch, see: http://sourceware.org/bugzilla/show_bug.cgi?id=1439 I can understand why Ulrich would not want such a patch. It's probably hard to justify risking glibc stability for a relatively large change that

Re: generic crypto - remarks

2005-10-21 Thread Jim Meyering
Bruno Haible [EMAIL PROTECTED] wrote: Simon Josefsson wrote: you don't need it, because the rules for struct layout in C guarantee that a structure field is aligned to a multiple of the alignment of the previous field. Are you saying that even if we don't change the type of buffer to

Re: gettime's gettimeofday call may fail

2005-10-23 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: ... Anyone who sets the system clock past 2038 and then runs a gnulib-based program that they've compiled in hamstrung-to-32-bit-time_t mode deserves whatever misbehavior they provoke. I suppose a clock-hardware problem could provoke this, so it might not

Re: generic crypto - remarks

2005-10-25 Thread Jim Meyering
Simon Josefsson [EMAIL PROTECTED] wrote: ... And it also assumes no holes in integer representations. This is more portable: verify (offsetof (struct S, member_m) % alignof (uint32_t) == 0); where alignof is defined as with md5.c etc. The verify module is GPL. If you re-license it, md4

gethrxtime: fall back on gettime?

2005-11-10 Thread Jim Meyering
Hi Paul, What do you think of making gethrxtime fall back on gettime? Currently, if it can't find a monotonic timer, it tries gettimeofday, then resorts to using time. Those are also the last resorts of gettime. The difference is that if gethrxtime used gettime, it'd benefit by using nanotime

Re: gethrxtime: fall back on gettime?

2005-11-11 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: What do you think of making gethrxtime fall back on gettime? Yes, that makes sense to me. I installed the patch below. This also fixes the comments to match the code. Looks fine. Thanks! While we're

why we need openat et al in the kernel

2005-11-12 Thread Jim Meyering
[ I have to preface this by saying I'm not interested in the attribute-related semantics of openat, but rather in the fd-relative-open--related semantics. ] Why do we need openat and related functions in the kernel? Without openat-like functions[1], it is impossible to process an

openat status: new glibc emulation

2005-11-12 Thread Jim Meyering
: with this new openat emulation in glibc, we'll have to change gl_FUNC_OPENAT not to test solely for the presence of the openat function, since the gnulib emulation has to supersede the glibc one. I've just change coreutils' lib/openat.c to do this: 2005-11-12 Jim Meyering [EMAIL PROTECTED

Re: gethrxtime: fall back on gettime?

2005-11-12 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: Assuming someone cares about the affected systems, I'd be happy to let them do it. But in the meantime, everyone else who wanted to run on mingw would be left high and dry, as coreutils wouldn't build

mkstemp-safer.c must include config.h

2005-11-13 Thread Jim Meyering
- mkstemp_rpl definition). In coreutils I added a pre-release check target to ensure that this sort of thing doesn't happen again. We need something similar for gnulib. See below for more detail. 2005-11-14 Jim Meyering [EMAIL PROTECTED] * mkstemp-safer.c: Include config.h, required

c99+ pragma is ignored by gcc -std=gnu99

2005-11-15 Thread Jim Meyering
Hi Paul, In compiling coreutils with -std=gnu99, I see this new warning: xstrtod.c:33: warning: ignoring #pragma STDC FENV_ACCESS Why was this code needed? /* Tell the compiler that non-default rounding modes are used. */ #if 199901 = __STDC_VERSION__ #pragma STDC FENV_ACCESS ON

Re: style question - const char *

2005-11-18 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: Eric Blake [EMAIL PROTECTED] writes: Is there a preference for 'const char *' over 'char const *'? I prefer putting type qualifiers like const after the types they modify, as that's more consistent. For example, char * const * puts As you've probably

Re: bugs in dirname module

2005-11-18 Thread Jim Meyering
[EMAIL PROTECTED] (Eric Blake) wrote: ... so I am prepared to provide this segregation into base_name() vs. last_component() as part of my patch. I'd go along with that. ___ bug-gnulib mailing list bug-gnulib@gnu.org

FYI: new openat-like function: mkdirat

2005-11-30 Thread Jim Meyering
Jim Meyering [EMAIL PROTECTED] * mkdirat.c (mkdirat): New file and function. * openat.h (mkdirat): Declare. 2005-11-30 Jim Meyering [EMAIL PROTECTED] * openat.m4 (gl_FUNC_OPENAT): Require and compile mkdirat.c. Here is the important part of the new file: /* Solaris 10

Re: FYI: new openat-like function: mkdirat

2005-11-30 Thread Jim Meyering
Roland McGrath [EMAIL PROTECTED] wrote: I think that the Solaris *at functions were really primarily intended for use with O_XATTR to get at file attribute magic pseudo-directories rather than to optimize use of normal directories and files. Probably mkdirat doesn't make sense in Solaris

Re: FYI: new openat-like function: mkdirat

2005-11-30 Thread Jim Meyering
Roland McGrath [EMAIL PROTECTED] wrote: So I guess the exec*at business would ultimately be more complicated, with two file descriptor parameters: one identifying the working directory, and another by which to interpret the first parameter if it's a relative file name. It seems adequate to

  1   2   3   4   5   6   7   8   9   10   >