Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> * Paul Eggert wrote on Thu, Sep 14, 2006 at 12:41:51AM CEST:
>> Since nobody needs HAVE_CONFIG_H any more, [...]
>
> What makes you reach this conclusion (for third-party packages, not for
> some well-maintained GNU packages)
Jim Meyering <[EMAIL PROTECTED]> writes:
> I'm surprised that the compromise of adding advisory comments rubs
> you (Bruno) so hard the wrong way. Does anyone else object to
> adding both lines?
I'm afraid I'm mildly annoyed by them too. I use Emacs with (setq
enable-local-variables 0), so I ge
Jim Meyering <[EMAIL PROTECTED]> writes:
> aren't the warning and possible annoyance at least a little more
> appropriate for the build-generated files whose rules I was proposing
> to change in gnulib?
I suppose so, yes.
Isn't this a generic problem that has been around for years?
For example,
For Bison, I installed the following to add support for
Automake-supplied variables to configmake.
The javaversion module can now be simplified a bit, by adding a
dependency on configmake, so that its 'make' output is made a bit
shorter.
2006-09-15 Paul Eggert <[EM
I installed this fix as part of updates to coreutils.
2006-09-15 Paul Eggert <[EMAIL PROTECTED]>
* modules/mkancesdirs (Depends-on): Add fcntl.
* modules/savewd: New file.
* MODULES.html.sh (File system functions): Add savewd.
* lib/dirchownmod.c: Don
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> * gnulib-tool (func_exit): New function, to allow to pass the
> exit status portably through the trap. Use everywhere.
> (--help, --version): Signal a write error.
> (trap): catch SIGPIPE, for write errors.
> Exit at the
[EMAIL PROTECTED] (Karl Berry) writes:
> strtok_r.c was synced, but the config.h removal broke that.
Sorry, I tried to keep everything synced that was already synced,
since it's not a big deal either way. Could you please restore
the sync at your next opportunity?
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> The file modules/savewd does not exist in the current CVS, neither
> do lib/savewd.[ch], m4/savewd.m4.
Sorry about that. I did "cvs add" them, but I forgot to check them
in. It's fixed now.
> Do I understand correctly that it was intended to have b
Bruce Korb <[EMAIL PROTECTED]> writes:
> It has always been an irritant that you cannot mmap a text file
> and be sure that there is a terminating NUL, without going to a
> lot of hassle.
But the GNU coding standards say that programs generally must treat
NUL bytes as valid data. There might be
I installed this:
2006-09-18 Paul Eggert <[EMAIL PROTECTED]>
* gnulib-tool (avoidlist): Fix typo that broke options like
--avoid=lock that are used by coreutils bootstrap.
--- gnulib-tool.~1.166.~2006-09-18 08:50:05.0 -0700
+++ gnulib-tool 2006-09-18
Bruno Haible <[EMAIL PROTECTED]> writes:
> * modules/javaversion (Makefile.am): Remove DEFS setting.
> (Depends-on): Add configmake, for PKGDATADIR definition.
Thanks. Don't you also need to add an #include "configmake.h" line to
lib/javaversion.c?
"Mark D. Baushke" <[EMAIL PROTECTED]> writes:
> * inttypes.m4 (gl_cv_header_working_stdint_h): Avoid
> 'test: =: unary operator expected' on Solaris 9.
> (gl_cv_header_inttypes_h): Be consistent in quoting.
Thanks, I installed that.
Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
> While building coreutils v6.1 on Tru64 Unix, I found a minor typo
> breaking the build. Here is a patch to fix it.
Thanks; I installed that patch into gnulib.
> diff -ur src-6.1/lib/getaddrinfo.c src-6.1-local/lib/getaddrinfo.c
> --- src-6.1/lib
's a bit less ugly than the one you sent in, and should
work even with the alternative prototypes.
It's a bit weird, though, that Tru64 has getnameinfo declared but
getaddrinfo is not defined. Is that correct, or am I missing
something?
2006-09-18 Paul Eggert <[EMAIL PROTECTED
Eric Blake <[EMAIL PROTECTED]> writes:
> CVS m4 wants to use $(pkglibexecdir) defined as
> $(libexecdir)/$(PACKAGE) as the location of its installed but
> unversioned libtool modules. Any chance we can add that to the
> configmake module? Is it worth pushing for $(pkglibexecdir)
> upstream in au
Bruno Haible <[EMAIL PROTECTED]> writes:
> OSF/1 4.0 declares neither getnameinfo nor getaddrinfo.
>
> OSF/1 5.1 declares both in but has this:
>
> #if defined (_SOCKADDR_LEN) || defined (_XOPEN_SOURCE_EXTENDED)
> #define getaddrinfo ngetaddrinfo
> #else
> #define getaddrinfo ogetaddrinfo
> #endi
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> * gnulib-tool (func_version): Create output all at once, to
> avoid triggering unnecessary SIGPIPEs.
gnulib-tool doesn't trap SIGPIPE before invoking that code, so you
must be worried about the case where the caller traps SIGPIPE? That
do
Mikhail Teterin <[EMAIL PROTECTED]> writes:
> I see -- would you have a test-case, that detects this difference?
No, but you can read the thread containing this message:
http://lists.gnu.org/archive/html/bug-gnulib/2004-10/msg00171.html
to see some of the issues here, and why gnulib getopt.m4 r
I installed this:
2006-09-20 Paul Eggert <[EMAIL PROTECTED]>
Import this patch from libc:
2006-04-07 Ulrich Drepper <[EMAIL PROTECTED]>
* lib/tempname.c (__gen_tempname): Change attempts_min
into a macro. Use preprocessor to decide how t
Bruce Korb <[EMAIL PROTECTED]> writes:
> If valid data is supposed to be ASCII text, then what meaning
> do you give to the NUL byte?
It depends on the application. The NUL character is valid in
ASCII. For 'sort', for example, it participates in comparison
as the least-possible character.
> If
I also installed this further change, which shouldn't hurt either.
That old HAVE_MKSTEMP code was bogus anyway, since it should have
been HAVE_DECL_MKSTEMP.
2006-09-20 Paul Eggert <[EMAIL PROTECTED]>
* mkstemp-safer.c: Include "mkstemp.h" instead of .
(mk
Mikhail Teterin <[EMAIL PROTECTED]> writes:
> However, there is not a single place anywhere in m4's code (outside of
> getopt*.c), where optind is set to zero.
Other gnulib-using programs do rely on that functionality, though, so
we test for it in gnulib.
It's not worth the configuration hassle
ot;.
I don't know whether the following patch will fix his problem (we need
more info for that) but I don't see how it could hurt, so I installed
it into gnulib.
2006-09-20 Paul Eggert <[EMAIL PROTECTED]>
* modules/mkstemp (Depends-on): Add extensions, so that
mk
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
>> That doesn't sound like much of a real problem, but if it is, this
>> looks to me like a band-aid that doesn't solve things; it'd cut down
>> the number of bogus messages without eliminating them.
>
> This I don't understand. If I do the output with
I intsalled this:
2006-09-20 Paul Eggert <[EMAIL PROTECTED]>
* modules/mkstemp (Files): Add mkstemp.h.
--- modules/mkstemp 20 Sep 2006 18:48:29 - 1.10
+++ modules/mkstemp 20 Sep 2006 22:32:08 -
@@ -2,6 +2,7 @@ Description:
mkstemp() function: create a p
Mikhail Teterin <[EMAIL PROTECTED]> writes:
> :-( Are there regex-patches currently waiting to be merged into GNU's libc?
You can just do a diff between glibc and regex to find the list of
patches. They aren't marshaled into a coherent set of small patches,
which is the bottleneck. However, yo
I installed this:
2006-09-20 Paul Eggert <[EMAIL PROTECTED]>
Import this patch from libc:
2006-09-06 Jakub Jelinek <[EMAIL PROTECTED]>
* lib/regex_internal.c (re_string_reconstruct): Handle
offset < pstr->valid_raw_len &&
Mikhail Teterin <[EMAIL PROTECTED]> writes:
> I wonder, how GNU's getopt implementation, where flags' arguments can be
> optional, deals with the cases of such an option followed by something, that
> begins with a dash itself:
>
> m4 -d -X
It's the same way that (for example) 'pr -e' work
[EMAIL PROTECTED] (Eric Blake) writes:
> Is it worth updating the getopt
> module to depend on posixver and avoid this term except when
> _POSIX2_VERSION is set to the older version of POSIX?
I'd say "no". Such an update would affect behavior only if
POSIXLY_CORRECT is set, right? Normally it's
>> Should be: for integer and pointer types there are _no_ "trap
>> representations".
>
> I don't think that is guaranteed by C99.
That's correct. As I recall, only unsigned char objects are
guaranteed to be free of trap representations.
> Certainly the practical value of this for gnulib is que
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> 21 checking for SIZE_MAX... yes
>
> as the top gnulib candidates. The SIZE_MAX test is cheap on systems
> that have it
There's no reason to have a separate SIZE_MAX module any more, except
for inertia, as the stdint module should now do that for
up on
a different thread)
I installed this:
2006-09-25 Paul Eggert <[EMAIL PROTECTED]>
* modules/clock-time (Maintainer): Add self.
* modules/getlogin_r (Depends-on): Add extensions.
2006-09-25 Ralf Wildenhues <[EMAIL PROTECTED]>
* m4/host-os.m4 (gl_
gcc warned that 'raise' was undeclared when building on Solaris 8 for
coreutils 6.2. I installed the following to forestall further problems
in this area.
2006-09-26 Paul Eggert <[EMAIL PROTECTED]>
* lib/savewd.c: Include , for 'raise'.
* module
Eric Blake <[EMAIL PROTECTED]> writes:
>> /opt/lsb/bin/lsbcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -c close-stream.c
>> In file included from __fpending.h:25,
>> from close-stream.c:27:
>> /usr/include/stdio_ext.h:47: error: expected `=', `,', `;', `asm' or
>> `__attribute__' b
<[EMAIL PROTECTED]> writes:
> Does the new coreutils+gnulib call sync(2) at
> appropriate places?
coreutils calls 'sync' only in the 'sync' and 'shred' and 'df --sync'
commands, which are irrelevant here.
Applications should never have to call 'sync' to do ordinary things
like remove files, so I
<[EMAIL PROTECTED]> writes:
> On 2006-09-26 17:47:51 -0500, Jim Meyering <[EMAIL PROTECTED]> said:
>> Probably because you're not using a new enough version of bison.
>
> Got bison-2.3a from the alpha repo,
2.3a should work as far as I know, but you shouldn't need 2.3a; 2.3
will do.
> Apple inst
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> * m4/poll.m4: Test for sys/ioctl.h and sys/filio.h.
> * lib/poll.c (poll) [__APPLE__]: Use FIONREAD instead of MSG_PEEK.
Looks reasonable to me. But you don't need our permission to install;
you're the maintainer.
u verify whether it works for you?
2006-09-27 Paul Eggert <[EMAIL PROTECTED]>
* lib/__fpending.h: Don't include unless
HAVE_DECL___FPENDING. This avoids a bug with lsbcc, where
it causes to cause a compile-time error.
Problem reported by Nelson
mwoehlke <[EMAIL PROTECTED]> writes:
> That said, given the address when I set a breakpoint there, I am
> guessing it is the system getaddrinfo?
Yes, that's right. I installed the following patch; does it fix
things for you?
2006-09-27 Paul Eggert <[EMAIL PROTECTED]&g
<[EMAIL PROTECTED]> writes:
> Can I validly talk Apple into upgrading their provided gzip to 1.3.5
> when this is not in the stable category (for _whatever_ reason[s])?
> If 1.3.5 is fine to use, it needs to be assigned as such, or Apple
> would find an argument to close the bug rather quickly.
D
<[EMAIL PROTECTED]> writes:
> Seriously, would you take a look at my post's
> attachment above that started this subthread, please?
Sorry, I haven't a clue what started this thread.
> It was the make that raised the bison error, not the
> bootstrap script.
After a bootstrap, when you do a 'make
"Nelson H. F. Beebe" <[EMAIL PROTECTED]> writes:
> This is the same problem as before with size_t being used before
> it is defined with this compiler.
is one thing; it's not standardized. But
is another. The compiler is seriously broken if does
not define size_t.
As I recall, the last main
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> I don't have CVS access to gnulib; anyway I preferred to have a second
> opinion.
I added you just now. Please install that patch, as it looks good.
<[EMAIL PROTECTED]> writes:
> http://permalink.gmane.org/gmane.comp.lib.gnulib.bugs/7179
> ...
> When building coreutils-5.97 from the long available stable tarball, make
> runs bison and works with Apple's provided versions of the tools.
That's not what that URL says. It says you built from CVS
Jim Meyering <[EMAIL PROTECTED]> writes:
> I noticed that mkdir-p.c includes dirchownmod.c, rather than
> dirchownmod.h. I think that must have been unintentional
No kidding! Wow. Thanks for fixing that.
"Nelson H. F. Beebe" <[EMAIL PROTECTED]> writes:
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=773937&group_id=1107&atid=101107
That's a bug report against the LSB spec, not against lsbcc.
As I understand it, the bug was resolved by saying that
the LSB spec defers to POSIX,
[EMAIL PROTECTED] (Karl Berry) writes:
> > with http://directory.fsf.org/gzip.html; no mention there)... which, of
>
> 1.3.5 is mentioned on that Directory page as the "(devel)" release.
>
> Anyway, I wrote rms about the lack of official releases in recent
> decades.
For what it's worth, I w
Bruno Haible <[EMAIL PROTECTED]> writes:
> Hi Paul and Jim,
>
> It bothers me that in order to implement a basic functionality like the
> 'closeout' module, you need the __fpending module, which is not based on
> POSIX but rather a case-by-case hack for various platforms.
>
> Here is a proposed pa
Bruno Haible <[EMAIL PROTECTED]> writes:
> + /* Close standard error. This is simpler than fwriteerror_no_ebadf,
> because
> + upon failure we don't need an errno - all we can do at this point is to
> + set an exit status. */
> + errno = 0;
> + if (ferror (stderr) || fflush (st
mwoehlke <[EMAIL PROTECTED]> writes:
> Would that (and the 2003 update date) mean that gzip is unmaintained?
Not necessarily, no.
broke the openat emulation. I installed the
following into gnulib to work around the problem.
2006-09-29 Paul Eggert <[EMAIL PROTECTED]>
Work around bug in Solaris 10 /proc file system:
/proc/self/fd/NNN/.. isn't the parent directory of
the directory whose f
[EMAIL PROTECTED] (Eric Blake) writes:
> I'll have to test if your fix helps (my hack was just to check
> in lib/at-func.c if the current file name is "..",
That doesn't suffice in general, since the file name might be a
symlink to "..", either directly or indirectly (But you probably knew
that.
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> * lib/quotearg.c [!HAVE_MBRTOWC]: Define mbstate_t to int.
Thanks, I installed that.
I installed this:
2006-10-05 Paul Eggert <[EMAIL PROTECTED]>
Remove macros that are no longer needed now that stdint.h is
reliable.
* lib/fsusage.c (UINTMAX_MAX): Remove.
* lib/human.c (SIZE_MAX, UINTMAX_MAX): Remove.
* lib/utimecmp.c (SIZE_MAX):
an't test this easily since I don't have such a kernel.
Most of this patch is to gnulib, so I'll CC: this to bug-gnulib.
2006-10-05 Paul Eggert <[EMAIL PROTECTED]>
* lib/fcntl_.h (O_NOFOLLOW): Don't depend on O_NOFOLLOW_IS_INEFFECTIVE;
we now test
Eric Blake <[EMAIL PROTECTED]> writes:
> May I apply the patch below to gnulib?
That's fine with me, for the close-stream/fcntl-safer/stdio-safer
side. I wish there were a simpler way but I don't see it offhand.
(Bruno of course needs to look at the clean-temp side.)
27;ing to gnulib since some of it affects gnulib.)
2006-10-06 Paul Eggert <[EMAIL PROTECTED]>
Fix bug reported today by Mike Frysinger: mkdir -pv is logging the
wrong file name in some cases. Lars Wendler reported a bug in
my original fix.
* lib/mkancesd
Bruno Haible <[EMAIL PROTECTED]> writes:
> I took the liberty of moving this ChangeLog entry to m4/ChangeLog and
> lib/ChangeLog, respectively.
I'd prefer having just one ChangeLog for all of gnulib, since it's
easier to follow changes that affect both lib/ and m4/. Would anybody
object if I mer
I see the problem now; you can't include , then
, then , due to having some
semi-obsolescent definitions of intmax_t (due to gettext not yet
upgrading to assume inttypes.h).
I installed this into gnulib to fix things:
2006-10-08 Paul Eggert <[EMAIL PROTECTED]>
Don't i
I merged all the gnulib ChangeLog files into one ChangeLog, at the
top. The merge was mostly done automatically, and no doubt could be
done better (i.e., related changes put together), but that can be done
later if someone has the time.
The changes are long and mechanical, so I'm not including th
Bruno Haible <[EMAIL PROTECTED]> writes:
> filemode.c:171: warning: implicit declaration of function `strmode'
Thanks for reporting this. It's better to fix this in filemode.h, for
the benefit of filemode's users, so I installed this into gnulib:
2006-10-09 Paul E
Bruno Haible <[EMAIL PROTECTED]> writes:
> @code{gnulib-tool} can make symbolic links instead of copying the
> ! source files. The option to specify for this is @samp{--symlink}, or
> ! @samp{-s} for short. This can be useful to save a few kilobytes of disk
> ! space.
-s isn't for saving disk
thout --copy. Also, it uses "cp -p", which
more-closely approximates the symlink and gives builders a better idea
of when the source file actually changed.
2006-10-09 Paul Eggert <[EMAIL PROTECTED]>
* bootstrap (usage, main program, symlink_to_gnulib): Add option
--cop
Eric Blake <[EMAIL PROTECTED]> writes:
> that double copy is bothering me; I would really like to reopen a
> finished object for further growth without having to use temporary
> storage. Any thoughts on the matter? Is this worth taking up with
> glibc?
Might be. How much would it change/slow d
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> A failure case with `cp -p':
> cd gnulib && cvs up
> cd .../coreutils && make && ./bootstrap && make
I don't understand this failure case. "cvs up" modifies the
time stamps to the current date, and "cp -p" will copy
the modified time stamps, so i
Eric Blake <[EMAIL PROTECTED]> writes:
> Is the name okay? Is it worth adding to gnulib?
Ideally I suppose it'd be added to glibc as well. This means patching
the documentation, adding implementations for non-GCC compilers, etc.
The name is fine with me.
The style should use the same style as
I installed the following into gnulib in an attempt to address part of
the porting problem that you mentioned.
2006-10-10 Paul Eggert <[EMAIL PROTECTED]>
Port to Tandem NSK OSS, which has 64-bit signed int but at most
32-bit unsigned int. Problem reported by Matthew Woeh
ested these changes on Tandem but
have compiled and run them on Debian stable x86 and in principle they
look fairly safe to me.
2006-10-10 Paul Eggert <[EMAIL PROTECTED]>
Port to Tandem NSK OSS, which has 64-bit signed int but at most
32-bit unsigned int. Problem reported
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> Argh, it was incomplete, sorry. Assume the first `make' causes some
> object files to be updated, say, because of a previous `make clean',
> or simply because they were out of date. Those object files will then
> have a timestamp that is newer than t
> Date: Wed, 11 Oct 2006 08:43:14 +0200
> From: Ralf Wildenhues <[EMAIL PROTECTED]>
>
> > Yes, but exactly the same problem exists with symbolic links.
>
> I don't see how. The first `make' already sees the new files from the
> gnulib tree, through the symlinks.
Symlinks pass through the last-m
mwoehlke <[EMAIL PROTECTED]> writes:
#error "Right shift of integers of type char does not work!!"
#error "Casts from char to short works by zero-extend!!"
#error "Casts from char to int works by zero-extend!!"
#error "Casts from char to long works by zero-extend!!"
#error "Casts from ch
>> Symlinks pass through the last-modified time of the gnulib files.
>> cp -p also passes through the last-modified time of the gnulib files.
>> So if the first "make" already sees the new files from the gnulib
>> tree through the symlinks, it will also see the new files from
>> the gnulib files th
Bruno Haible <[EMAIL PROTECTED]> writes:
> I wish to export the symbols of external{i}.c without modifications,
> whereas the symbols of internal{j}.c should get a prefix.
Doesn't the question of whether a symbol should get a prefix more
properly belong to .h files than to .c files? That is, if
Sorry about combining the two ideas into a single patch. Since the
first part has been installed, here's the second proposed part, which
I'm creating so that Bruno doesn't have to go to the work of creating
it.
2006-10-11 Paul Eggert <[EMAIL PROTECTED]>
Don't
mwoehlke <[EMAIL PROTECTED]> writes:
> In the midst of all these changes to printf-friends, is anyone (else)
> aware that the 'long long' suffix for the system printf on OSS is "L"
> ("ll" is not recognized)?
That's news to me. I suppose we could configure it as well, though
I'd rather avoid it
mwoehlke <[EMAIL PROTECTED]> writes:
> j=1
> shc=1
> sample1=a84e715a515523b4
> sample2=0
This was test_integer_sshift, right? In that case, the C standard
says that the behavior of sample1>>shc is implementation-defined if
sample1 is negative, which is the case here. So Tandem C is within
its
today for this.
2006-10-11 Paul Eggert <[EMAIL PROTECTED]>
* m4/extensions.m4 (gl_USE_SYSTEM_EXTENSIONS): Undo previous
change, since Autoconf's version may no longer be appropriate now
that we are using CVS Autoconf's version. Add support for Tandem.
--
as sometimes mishandled)
and installed the following more-general patch into gnulib.
2006-10-11 Paul Eggert <[EMAIL PROTECTED]>
* lib/rename-dest-slash.c: Include stdbool.h but not string.h.
(has_trailing_slash): Omit size arg; all callers changed.
Omit 'inline&
to gnulib. Can you find out
more about this, by looking at the Tandem documentation and/or asking
your Tandem support guys? If you can, I'd like the "defined
_TNS_R_TARGET" to be more accurate.
2006-10-11 Paul Eggert <[EMAIL PROTECTED]>
* lib/inttypes_.h (_
mwoehlke <[EMAIL PROTECTED]> writes:
> lib/mkdir-p.c needs:
> #ifndef HAVE_FCHMOD
> # define HAVE_FCHMOD 0
> #endif
Thanks, I installed this:
2006-10-11 Paul Eggert <[EMAIL PROTECTED]>
* lib/mkdir-p.c (HAVE_FCHMOD): Define to false if not already
defin
I bootstrapped successfully from
scratch after it. Dunno why I missed it before, perhaps because I
didn't do a full bootstrap.
2006-10-12 Paul Eggert <[EMAIL PROTECTED]>
* m4/extensions.m4 (AC_USE_SYSTEM_EXTENSIONS): Renamed from
gl_USE_SYSTEM_EXTENSIONS, to fix a c
Bruno Haible <[EMAIL PROTECTED]> writes:
> $ gnulib-tool --create-testdir --dir=/tmp/testdir `gnulib-tool --list`
> but this is no longer possible, since the config-h breaks a few other modules.
Would anybody object if I changed all the other modules to be
compatible with config-h? The only do
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> - [AC_TRY_COMPILE(, [signed char x; return !x;],
> + [AC_TRY_COMPILE(, [signed char x; return !sizeof x;],
Wouldn't this be a bit better, in the sense of catching
more compilers that are a bit dodgy?
[AC_TRY_COMPILE(, [signed char x = -127, y
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> config-h is not the only problem child.
> fnmatch-posix and fnmatch-gnu are documented to collide as well.
That's OK. Part of my motivation for getting rid of "#ifdef
HAVE_CONFIG_H" is to remove unnecessary differences between
gnulib/lib/foo.c and co
also needed the following change, which I installed into gnulib.
2006-10-12 Paul Eggert <[EMAIL PROTECTED]>
* modules/error (Makefile.am): Distribute files through
EXTRA_DIST, not lib_SOURCES.
--- lib/error.~1.9.~2006-10-12 14:30:39.0 -0700
+++ lib/error 200
Bruno Haible <[EMAIL PROTECTED]> writes:
> + /* Set of currently blocked and pending signals. */
> + static volatile char pending_array[NSIG] /* = { 0 } */;
Surely this should be sig_atomic_t rather than char?
> + int
> + sigfillset (sigset_t *set)
> + {
> + *set = -2U << (NSIG - 1);
This do
Eric Blake <[EMAIL PROTECTED]> writes:
> Best of all, this patch deletes more than twice as many lines than what it
> adds
> in new files :)
I like that part!
As for mkstemp, there is some desire to keep the sources as close
to glibc as possible, with the idea of migrating our fixes back.
So,
Eric Blake <[EMAIL PROTECTED]> writes:
> It didn't make it into automake 1.10, but Alexandre approved it for the
> next release:
> http://www.nabble.com/forum/ViewPost.jtp?post=6824228&framed=y. OK to
> apply this to gnulib for projects living on the bleeding edge?
Sure, please go ahead. But pl
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
> A new version of gnupload is in Automake's CVS (and attached).
Thanks, but it's not in Automake's CVS yet. Did you have second
thoughts?
I did not install it into gnulib, since I wanted to double-check
first.
actually used, rather than "gcc -m64 -std=gnu99 -I.".
2006-10-16 Paul Eggert <[EMAIL PROTECTED]>
* lib/stdint_.h: Include after ,
for AIX 5.3. Problem reported by Perry Smith in
<http://lists.gnu.org/archive/html/bug-coreutils/2006-10/msg00222.htm
I installed this minor patch:
2006-10-16 Paul Eggert <[EMAIL PROTECTED]>
* lib/fsusage.c (PROPAGATE_ALL_ONES): Don't assume uintmax_t is
at least as wide as intmax_t.
--- lib/fsusage.c 5 Oct 2006 21:23:21 - 1.56
+++ lib/fsusage.c 16 Oct 20
ut only because
localcharset does. The localcharset test slows down 'configure' and
does not affect how the code actually behaves. OK to install this?
2006-10-17 Paul Eggert <[EMAIL PROTECTED]>
Simplify localcharset code a bit and speed up configuration
by removing te
Matthew Woehlke <[EMAIL PROTECTED]> writes:
> Are you not catching the discussion on the coreutils list?
Quite possibly he's not. To summarize what I have observed so far:
We have observed no bugs when compiling without -O, so that seems to
be a viable platform.
We haven't observed any bug wit
Matthew Woehlke <[EMAIL PROTECTED]> writes:
> Paul Eggert wrote:
>> We haven't observed any bug with left shift of long long int, even
>> with -O.
>
> We haven't? I thought I'd said both had problems;
Sorry; evidently I misunderstood you.
> I sho
Eric Blake <[EMAIL PROTECTED]> writes:
> It just looks nicer if we provide gnulib
> modules with exported APIs that do not lie in the reserved namespace.
Sure, but can't you do something like the following (taken from
mktime.c)? This minimizes the changes from libc and packages it
inside "#ifnde
e patch to the original 6.3 lib/stdint_.h.)
If this patch doesn't work, please send the compiler
diagnostics along with the complete output of the command
"gcc -std=gnu99 -I. -E xstrtoimax.c".
Thanks.
2006-10-18 Paul Eggert <[EMAIL PROTECTED]>
* lib/stdint_.h: Inclu
Ben Pfaff <[EMAIL PROTECTED]> writes:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> Simon Josefsson wrote:
>>> Why can we assume setlocale exists?
>>> Is it POSIX?
>>
>> Even more: It's specified by ISO C 99.
>
> Even more than that: it's in C90 also.
Yes, that's the key point: it was in ISO C9
Thanks for the bug report; I installed the fix to gnulib.
Eric Blake <[EMAIL PROTECTED]> writes:
> So, what should we do about the untranslated strings in xstrtol.h?
> Is it safe to make xstrtol depend on gettext-h, to pull in gettext.h
> in a header?
I think so. I installed this:
2006-10-19 Paul Eggert <[EMAIL PROTECTED]>
Bruno Haible <[EMAIL PROTECTED]> writes:
> ! error (0, 0,
> ! (problem == -1
> ! ? _("invalid argument %s for %s")
> ! : _("ambiguous argument %s for %s")),
> ! quotearg_n_style (0, ARGMATCH_QUOTING_STYLE, value),
>quote_n (1, context));
That looks good, thanks, bu
401 - 500 of 6212 matches
Mail list logo
