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 or
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 cod
[ 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 arbitra
k on using save_cwd and restore_cwd.
Note: 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
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
> le
temp_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 , re
Jim Meyering <[EMAIL PROTECTED]> wrote:
> The problem is that on systems for which m4/mkstemp.c
> would normally make an application use the replacement
> function, an application calling mkstemp_safer would end up
> using the buggy version, because mkstemp-safer.c didn
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
#e
Paul Eggert <[EMAIL PROTECTED]> wrote:
> However, for now the simplest thing to do is to remove the pragma so I
> installed the following patch, in both gnulib and coreutils.
>
> 2005-11-15 Paul Eggert <[EMAIL PROTECTED]>
>
> * xstrtod.c: Don't bother with #pragma STDC FENV_ACCESS ON, as
>
Paul Eggert <[EMAIL PROTECTED]> wrote:
> If we go this route, then base_name(F) cannot in general yield a
> suffix of F even on Unix systems, since we would want dir_name("a/b/")
> == "a/b" and base_name("a/b/") == ".". Hence base_name will need to
> allocate memory in general, even on Unix. On C
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'
[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
http://lists.gnu.org/mailman/
I wonder why.
2005-11-30 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 import
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 Solar
Roland McGrath <[EMAIL PROTECTED]> wrote:
>> cp, cpio, mv, and tar currently use mkfifo and mknod,
>> so you might want to add mkfifoat and mknodat to the list, too.
>
> I suppose, though those are used by so few programs it is a bit more
> questionable.
Either way, it doesn't change much, since o
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 ad
Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> You're talking about exec. If you're going to use execve anyway,
> there's no way you need your old initial working directory back, is
> there?
Right.
As James pointed out, the forked child can simply call
fchdir just before execvp, just as find alr
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
$ time ARGP_HELP_FMT=rmargin=2 tar --help > /dev/null
ARGP_HELP_FMT=rmargin=2 tar --help >
"Sergey Poznyakoff" <[EMAIL PROTECTED]> wrote:
> 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. O
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.
It's not my call here, but I'll give you
f the tv_nsec member of struct timespec? From
timespec.h: struct timespec { time_t tv_sec; long tv_nsec; };
The same goes for xtime_make's `ns' paramter. Here's a proposed
patch: 2005-12-14 Jim Meyering <[EMAIL PROTECTED]>
* xtime.h (xtime_nsec): Use `long int',
th no need for memory allocation, that's one fewer way to fail.
* fprintftime.c, fprintftime.h: New files.
ChangeLog
2005-12-16 Jim Meyering <[EMAIL PROTECTED]>
* modules/fprintftime: New module.
* MODULES.html.sh (Date and time ): Add fprintftime.
Index: m
[EMAIL PROTECTED] (James Youngman) wrote:
> On Fri, Dec 16, 2005 at 04:22:06PM +0100, Jim Meyering wrote:
>> I've just checked in the files that complete the
>> implementation of the new fprintftime module.
>> In coreutils, both date and du now use fprintftime.
>
>
[EMAIL PROTECTED] (Eric Blake) wrote:
> So experience in gnulib has shown that slightly different semantics,
> with dir_name that always mallocs, and (when my patch from a
> month ago is approved) base_name that mallocs and last_component
As far as I know, we're still waiting for confirmation from
me_make's `ns' paramter. Here's a proposed
patch:
2005-12-14 Jim Meyering <[EMAIL PROTECTED]>
* xtime.h (xtime_nsec): Use `long int', not `int', to be
consistent with type of timespec.tv_nsec.
(xtime_m
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> [I sent this message a few weeks ago, but it was
>> mistakenly MIME-format=flowed, so not very readable]
>
> Odd, I sent a reply (only to bug-gnulib), but I see it'
Paul Eggert <[EMAIL PROTECTED]> wrote:
> I installed this:
> Sync from coreutils.
Thanks for all of the merge work!
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
lers are supposed to check that files are
> not symbolic links before using lchmod, which obviously leads to race
> conditions, but that's the best we can do on hosts that lack lchmod.
>
> 2006-01-09 Paul Eggert <[EMAIL PROTECTED]>
...
> 2006-01-09 Jim Meyering <[EMAIL P
Bruno Haible <[EMAIL PROTECTED]> wrote:
> The reason is that m4/readutmp.m4 invokes gl_FUNC_FREE, but m4/free.m4 is not
> part of this module or its dependencies.
>
> Here is a fix. OK to commit?
Hi Bruno!
Thanks for working on this.
Adding the module dependency is fine.
However, I'm reluctant
I discovered a long-standing bug in fts.c yesterday:
2006-01-11 Jim Meyering <[EMAIL PROTECTED]>
* fts.c (fts_stat): When following a symlink-to-directory,
don't necessarily interpret stat-fails+lstat-succeeds as indicating
a dangling symlink. That can als
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> If any of you know of a system with file name resolution code that
>> doesn't fail for a chain of 400 symlinks, or for which you get a
>> different diagnostic than `
e actual diffs:
lib/fts.c | 217 +++---
lib/fts_.h| 14 +-
m4/fts.m4 |3
src/chmod.c |3
src/chown-core.c | 14 +-
tests/du/long-from-unreadable | 70 +++++
6 files
[EMAIL PROTECTED] (Eric Blake) wrote:
>> FTS API change:
>> ==
>>
>> This changes the fts API. Before, callers (those not using FTS_NOCHDIR)
>> could expect fts_read to change the current working directory so that
>> a simple directory entry name (fts_accpath) could be used to access
>
[EMAIL PROTECTED] (James Youngman) wrote:
> On Tue, Jan 17, 2006 at 10:33:18PM +0100, Jim Meyering wrote:
>> FTS API change:
>> ==
>>
>> This changes the fts API.
>
> Is there a way for autoconf-using gnulib client s to select only the
> gnulib ver
I wrote:
> FYI, I did most of the work to add FTS_CWDFD, just to see -- and it's
> not so bad, but the result is certainly less maintainable.
After saying the above, I figured I should produce the actual code,
so here it is. For now at least, I don't plan to check in these changes.
This patch re
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> For some reason, mingw32 uses non-POSIX names for shutdown's
...
> --- socket_.h 09 Jan 2006 17:13:09 +0100 1.1
> +++ socket_.h 19 Jan 2006 14:39:07 +0100
> @@ -34,4 +34,15 @@
> # include
> #endif
>
> +/* For shutdown(). */
> +#if !defined(SHUT_RD)
Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Jim Meyering on 1/19/2006 3:39 AM:
>> As I said, I'm reluctant to add this complexity,
>> without some evidence that it will be used.
>
> How about a simpler patch to gnulib: define FTS_CWDFD, then make gnulib
&g
Simon Josefsson <[EMAIL PROTECTED]> wrote:
>> Any objection to removing [useless parentheses]?
>
> No, please install them.
Ok. I've checked that in.
> I agree. I wish 'indent' could fix this
> too. Maybe it can? Even if I agree many code writing ideas given
> here, I forget them all the time
the security provided
by recording the dependency also in the .m4 file.)
2006-01-24 Jim Meyering <[EMAIL PROTECTED]>
* openat.m4 (gl_FUNC_OPENAT): Add AC_LIBSOURCES([intprops.h]).
Reported by Mark D. Baushke.
Index: m4/openat.m4
===
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Paul Eggert wrote:
>> I don't see any technical reason to prefer the parentheses.
>
> While I agree that there are no technical reason to put the parentheses,
> I wouldn't be religious on the issue, because the majority of the C
> programmers does it the ot
declaration may not appear after executable
> statement in block
> size_t maxarglen = fts_maxarglen(argv);
> ^
Thanks.
I've just checked in a fix for that, along with a few real bug fixes:
[Hmm.. I see I've also included the change adding O_NOCTTY and O_NONBLOCK.
I&#x
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Building the module 'fts-lgpl' on Linux/glibc fails like this:
>
> gcc -DHAVE_CONFIG_H -I. -I/packages/megatestdir/fts-lgpl/lib -I.. -g -O2
> -c /packages/megatestdir/fts-lgpl/lib/fts.c
> /packages/megatestdir/fts-lgpl/lib/fts.c:75:20: lstat.h: No such
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> [Hmm.. I see I've also included the change adding O_NOCTTY and O_NONBLOCK.
>> I'll update the ChangeLog entry to include that. ]
>
> But the change you checked i
safe.
I'll propagate this change to gnulib once it's undergone a little testing.
2006-02-02 Jim Meyering <[EMAIL PROTECTED]>
Eliminate the unwelcome (albeit unlikely) possibility of xmalloc
failure on deficient systems, and simplify gnulib lgpl dependencies.
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>> I tend to forget, too, so have automated quite a few policy checks,
>> over the years. You might try adding some checks like those in coreutils'
>> Makefile.maint. Here
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> I'm going through Coreutils GNUmakefile and Makefile.maint to identify
> useful rules. Some question pop up:
>
> 1)
>
> Is this rule generally safe? Does it assume GNU tar? Is there a real
> problem solved by this, or is it just "nice"?
>
> # Make tar
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> A lot of the tests look like:
>
> sc_cast_of_argument_to_free:
> @grep -E '\
> I.e., the paths and filenames are hardcoded.
Some are definitely tailored to the classic gnu lib,src lay-out --
or were just written a long time ago :-)
Just using $(C
ule
name to the list of all syntax-check rules.
Now, you just create a new rule, and as long as its name starts
with `sc_' it'll be used:
2006-02-11 Jim Meyering <[EMAIL PROTECTED]>
* Makefile.maint (syntax-check-rules): Automatically derive this
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> I think CVS_LIST has some disadvantages:
>
> * Unrelated to the core problem. The core problem is "how to list all
> C code or header files". Even if you use CVS_LIST, you'll have to
> filter it further, excluding generated files the maintainer has
Simon Josefsson <[EMAIL PROTECTED]> wrote:
>>> # Make tar archive easier to reproduce.
>>> export TAR_OPTIONS = --owner=0 --group=0 --numeric-owner
>>
>> Those options help minimize unnecessary differences between tar archives.
...
> Still, I think the TAR stuff is different. You can't set TAR_OPT
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> I'm now using this (with a couple of modifications) in GNU SASL.
>
> One thing that struck me as very useful, is the ability to invoke
> tests without having to autoreconf + configure.
...
If I forget to run ./configure ..., I'd rather get a warning
tha
e, as long as they're hooked to some
>>> nonstandard target.
>>
>> Yep, I agree. It should be possible to override this in Makefile.cfg,
>> for those of us how want to invoke autoreconf + configure
>> automatically.
>
> Here is an updated patch. Ok to ins
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Simon Josefsson <[EMAIL PROTECTED]> writes:
>
>> * build-aux/Makefile.maint:
>
> I will hurt my fingers over this name (and the related Makefile.cfg),
> when completing for Makefile.am, so I would prefer to have names that
> doesn't begin with 'Mak
Eric Blake <[EMAIL PROTECTED]> wrote:
>> Followup - with the earlier patch fixed, now AC_FUNC_STRERROR_R has a
>> warning, that was making the -Wall -Werror compilation think that
>> strerror_r returned int instead of char* on cygwin.
>>
>> 2006-02-16 Eric Blake <[EMAIL PROTECTED]>
>>
>> * l
Simon Josefsson <[EMAIL PROTECTED]> wrote:
>>> Ok.
>>> How about maint.mk and maint-cfg.mk?
>>
>> Sounds good. Installed.
>
> Auto-completing maint* is causing me problem already... while this is
> very minor, it also occurred to me that "cfg" is rather incorrect.
> maint-cfg.mk will likely conta
Davide Angelocola <[EMAIL PROTECTED]> wrote:
> hash.c with USE_OBSTACK fails to compile with gcc 3.3.4:
> hash.c:38:16: #if with no expression
Define it to `1' if you want to enable that:
i.e., -DUSE_OBSTACK=1 on the command line
or
#define USE_OBSTACK 1
___
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> 1) readline.m4 gives different results with cached reruns: for example,
> on x86_64-unknown-linux-gnu:
>
> ./configure -C
> -> LIBREADLINE="-lreadline -lncurses"
> ./config.status --recheck
> -> LIBREADLINE="-lreadline"
>
> This is becau
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> The following patch changes the last files over to the agreed-to style
> for inclusion of `config.h'.
>
> * lib/mkdtemp.c, lib/setenv.c, lib/unsetenv.c: Normalize
> inclusion of `config.h'.
Thanks.
Applied.
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> The following patch changes the last files over to the agreed-to style
> for inclusion of `config.h'.
>
> * lib/mkdtemp.c, lib/setenv.c, lib/unsetenv.c: Normalize
> inclusion of `config.h'.
Applied.
Hmm. Just noticed that those files are no
[EMAIL PROTECTED] (Karl Berry) wrote:
> This isn't a gnulib question, but this seems like the best set of people
> to ask :) -- I've recently gotten a couple new po files for Texinfo, but
> submitted via email instead of through the translation project.
>
> I've been telling them to go through the
[EMAIL PROTECTED] (Karl Berry) wrote:
> Hmm. Just noticed that those files are normally mirrored from
> gettext (see gnulib/config/srclist.txt).
>
> Yes, although I haven't "auto"updated yet because of those differences.
>
> Bruno, would you accept Ralf's patch so we don't have to
>
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> With this, getopt actually do seem to compile and work in Visual
> Studio. Tested with the CLI in libtasn1, part of GnuTLS, with long
> options.
>
> I'll install this shortly unless someone protests.
>
> 2006-02-28 Simon Josefsson <[EMAIL PROTECTED]>
consistently in gnulib (unlike Autoconf).
> I remember that `#error' does not provoke failure everywhere, but don't
> remember the offending compiler/system.
>
> But there is even a patch to the contrary in gnulib, from coreutils:
>
> | 2005-08-27 Jim Meyering <[EMAIL
I wrote:
> 2006-03-10 Jim Meyering <[EMAIL PROTECTED]>
>
> * src/remove.c (AD_pop_and_chdir): Fix a bug whereby a user with
> write access to a directory being removed could cause the removal
> of that directory to fail with an erroneous diagnostic abou
Simon Josefsson <[EMAIL PROTECTED]> wrote:
...
Hi Simon,
These are all already done in Makefile.maint :-)
> There should be some mechanism to exclude certain files on a per-rule
> basis. I'm not yet sure how to do this. Ideas appreciated.
That's why coreutils' Makefile.maint uses .x-sc* files
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Installed.
>
> 2006-03-03 Simon Josefsson <[EMAIL PROTECTED]>
>
> * build-aux/maint.mk: Add indent target.
>
> --- maint.mk 15 Feb 2006 11:40:27 +0100 1.2
> +++ maint.mk 03 Mar 2006 14:29:53 +0100
> @@ -50,3 +50,8 @@
> .PHONY: $(syntax-c
Paul Eggert <[EMAIL PROTECTED]> wrote:
> I recently redisovered the fact that actime_r and ctime_r, like
> asctime and ctime, are unsafe functions in the same sense that gets is
> unsafe: they can overrun their output buffers and there's no simple
> way for the user to detect in advance whether thi
Kenshi Muto <[EMAIL PROTECTED]> wrote:
> At Wed, 08 Mar 2006 08:59:55 +0100,
> Jim Meyering wrote:
>> Kenshi Muto <[EMAIL PROTECTED]> wrote:
>> So far, I am unable to reproduce the failure on ia32.
...
>> also, please run the failing command under str
Eric Blake <[EMAIL PROTECTED]> wrote:
> By the way, my patch added an "-*- Autoconf -*-" modeline, so that it
> was easier to edit in emacs (for example, AC_ macros are colorized by
> font-lock, and emacs looks for [] instead of `' as quoting pairs). Is
> it worth doing this to other m4 files in g
mpatible with the installed regex.
> This is helpful for installers who configure --without-included-regex.
> Problem reported by Emanuele Giaquinta.
I needed this additional change.
Applied in both gnulib and coreutils:
2006-03-17 Jim Meyering <[EMAIL PROTECTED]&
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * Paul Eggert wrote on Thu, Apr 20, 2006 at 01:50:48AM CEST:
>> Bruno Haible <[EMAIL PROTECTED]> writes:
>>
>> > + But about AC_CHECK_DECLS_ONCE: note that in
>> > + autoconf >= 2.60 the symbol separator is a comma, whereas here it is
>> > + whitespace.
Simon Josefsson <[EMAIL PROTECTED]> wrote:
>> May I add comments to getdelim.h?
>
> Hi! There is one in getdelim.c already. Maybe remove it? I'm not
> sure what the policy is on placing function documentation, although I
> usually keep them with the actual function.
>
> Or we could have two func
Any objection to adding a slight generalization of bison's warning.m4, below?
I'm going to use it in coreutils, so figured others might want to use it, too.
BTW, who's the author? Paul?
First, here's how bison uses it:
AC_ARG_ENABLE(gcc-warnings,
[ --enable-gcc-warnings turn on lots of GCC wa
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> Any objection to adding a slight generalization of bison's warning.m4, below?
>
> No objection here. But the only non-whitespace change in the file you
I've added
Tim Waugh <[EMAIL PROTECTED]> wrote:
> Here is a patch that makes use of getgrouplist() if it is available,
> for better efficiency.
Hi Tim,
Thanks for posting that.
Making this improvement is mentioned in the TODO file,
but there's a caveat. Using getgrouplist on libc-2.3.2
is documented to fai
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hi Jim,
>
> The module description of module 'getloadavg' appears to be missing the
> lib/getloadavg.c source file.
>
> To reproduce:
> $ ./gnulib-tool --dir=/smb/orlando/gnuprog/testdir --create-testdir
> `./gnulib-tool --list`
> ...
> checking for workin
Simon Josefsson <[EMAIL PROTECTED]> wrote:
...
> Wouldn't this be a good situation to have nanosleep depend on the
> unistd module, and make the replacement unistd.h include winsock2.h on
> mingw32 platforms? After all, nanosleep.c include unistd.h, and
> unistd.h define select on some platforms.
Bruno Haible <[EMAIL PROTECTED]> wrote:
> This fixes an outdated comment in getugroups.c. getgrent et al. are part
> of POSIX/XSI since the Base Specifications Version 5.
Applied. Thanks.
Paul Eggert <[EMAIL PROTECTED]> wrote:
> "Simon Wing-Tang" <[EMAIL PROTECTED]> writes:
>
>> This time it sorted correctly and created the temporary files over
>> 2GB as follows
>
> Thanks for testing it. I installed that patch (enclosed again below)
> into gnulib and the coreutils CVS trunk.
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> It'd be great if someone would write a gnulib-style getgrouplist
>> replacement function that provides a poor-man's implementation (using
>> something like coreutils' existing code) for syst
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Martin Lambers <[EMAIL PROTECTED]> writes:
>
>> Hi!
>>
>> I'd like to propose the following changes to the getpass module. They
>> only affect the W32 part of that module.
>> The first change updates the test for the native W32 API.
>> The second change
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
>
>> * c-strtod.m4 (gl_C99_STRTOLD): Use a link test rather than a
>> compile test, for Tru64 4.0D.
>
> Thanks; I installed that on both gnulib and coreutils trunk.
>
> Jim, OK if I put it into coreutils
Bruno Haible <[EMAIL PROTECTED]> wrote:
> /* Read the contents of an input stream, and return it, terminated with a NUL
>byte. */
> char* fread_file (FILE* stream)
> {
How about an interface that provides a length as well as a malloc'd
buffer, so that it works also when the file contains NUL b
[EMAIL PROTECTED] (Eric Blake) wrote:
...
> configuring with -Werror. Once configured, though, running
> make with -Werror is good policy for portability checks.
>
> What I meant to ask you to try, rather than
> 'configure CFLAGS=-Werror; make', was:
>
> $ ./configure CFLAGS=-Wall
> $ make CFLAGS=
[EMAIL PROTECTED] (Karl Berry) wrote:
> > OK to apply? These are the last five references within gnulib where
> > we did not assume the existance of errno.
>
> unsetenv was synced from coreutils. Do we prefer errno consistency or
> syncing? Help?
Hi Karl,
We want both :-)
I've just fix
"Sergey Poznyakoff" <[EMAIL PROTECTED]> wrote:
> 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 passe
"Derek R. Price" <[EMAIL PROTECTED]> wrote:
> Autoconf 2.60 declares the AC_FUNC_STRFTIME macro obsolescent since
> practical porting targets without a strftime function no longer exist.
>
> 2006-06-28 Derek R. Price <[EMAIL PROTECTED]>
>
> * lib/strftime.c: Assume strftime() exists.
>
remove m4/c-bs-a.m4, please don't forget to
> update MODULES.html.sh accordingly.
How about leaving it in for a while longer, but adding some sort of
assertion that will trigger if ever configure detects it's needed.
Here's what I did recently for coreutils:
Note that it does provi
"Derek R. Price" <[EMAIL PROTECTED]> wrote:
> Autoconf 2.60 declares the AC_FUNC_STRFTIME macro obsolescent since
> practical porting targets without a strftime function no longer exist.
>
> 2006-06-28 Derek R. Price <[EMAIL PROTECTED]>
>
> * lib/strftime.c: Assume strftime() exists.
>
> *snip*
>
>> +if test x"$SKIP_FTRUNCATE_CHECK" != xyes; then
>> + AC_MSG_FAILURE([Your system lacks the ftruncate function.
>> + Please report this, along with the output of "uname -a", to the
>> + bug-coreutils@gnu.org mailing list. To continue past this point,
>> + rerun
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * quoting myself:
>> * modules/same-inode: New module, comprising same-inode.h.
>> * modules/cycle-check: Depend on it, don't list same-inode.h.
>> * modules/mkdir-p, modules/same: Likewise.
>
> Never mind this patch. It needs either a bu
Hi Bruno,
I just grepped for HAVE_UNISTD_H in gnulib/ and found this
single remaining use. Any reason to keep it?
Index: lib/progreloc.c
===
RCS file: /sources/gnulib/gnulib/lib/progreloc.c,v
retrieving revision 1.8
diff -u -p -r1.
them:
#!/usr/bin/perl -n0
# Find doubled occurrences of words (e.g. in a TeX document).
# We often write "the the" with the duplicate words on separate lines.
# Written by Jim Meyering.
# $Id: doubleword,v 1.2 2006-07-09 11:42:01 meyering Exp $
use strict;
use warnings;
my %exclude = map
Eric Blake <[EMAIL PROTECTED]> wrote:
> POSIX states that:
> If, at normal process termination, a function registered by the atexit()
> function is called and a portable application needs to stop further exit()
> processing, it must call the _exit() function or the _Exit() function or one
> of
> t
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hi Paul,
>
> ok to apply this code simplification?
>
> diff -r -c3 --unidirectional-new-file --exclude=CVS
> gnulib-20060722/m4/stdint.m4 gnulib-20060722-modified/m4/stdint.m4
> *** gnulib-20060722/m4/stdint.m4 2006-07-11 13:54:20.0 +0200
> --
Bruno Haible <[EMAIL PROTECTED]> wrote:
> The stdarg.m4 macro is now tested (it's used in gettext-0.15). Any objections
> to this patch?
That looks fine.
Thank you!
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> I see that there are many other uses of "$result" in that file.
>> How about using a name that doesn't impinge on the configure.ac
>> writer's name space? E.g., s/result/gl_resu
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Eric Blake wrote:
>> POSIX requires [n]>&- and [n]<&- redirection operators to close
>> the respective stream, even when n is 0, 1, or 2. POSIX allows an
>> implementation to supply replacement file descriptors when exec'ing a
>> setuid or setgid program.
Paul Eggert <[EMAIL PROTECTED]> wrote:
>>> And wouldn't there be an easier workaround: At the beginning of main(),
>>> use fcntl() to determine whether 0,1,2 are closed, and if so, replace
>>> them with open("/dev/null") ?
>>
>> Possibly. And if we did, it would make more sense to open fd 0 as wr
For some modules (e.g., sys_stat), gnulib-tool generates
a mostlyclean-local rule like this:
mostlyclean-local:
@test -z "$(MOSTLYCLEANDIRS)" ||\
for dir in $(MOSTLYCLEANDIRS); do \
if test -d $$dir; then \
echo "rmdir $$dir"; rm
1 - 100 of 3892 matches
Mail list logo
