Hi Bruno,
Without this, coreutils' "make check-AUTHORS" test fails.
>From fd29488d5cc8acd037b3659d58775b96471fa7eb Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sun, 3 May 2009 06:46:23 +0200
Subject: [PATCH] propername: return UTF-8 translation when possible
* lib/propername.c (proper_name
Stefan Bienert wrote:
> Is it enough to put a line to each function,
> saying where it came from or should I sort everything in its original
> file?
No, it is better if the file structure is the same as in glibc. When doing
comparisons, we do it through "diff" of each file, or "diff -r" of the
d
Ludovic Courtès wrote:
> >> Should we conclude that this is a GCC bug?
> >
> > Possibly. And what result do you get with "gcc -mieee" ?
>
> It works (returns 1).
>
> The GCC manual (info "(gcc) DEC Alpha Options") reads this:
>
> `-mieee'
>
> [...]
> This option generates code fully I
Hello,
Bruno Haible writes:
> I meant %08X instead of %04X. DQNAN therefore likely is
> FFF8
> which decomposes into
> sign = 1 (irrelevant for NaNs),
> exponent = 0x7FF (highest possible value)
> mantissa = 0x8
> and this is precisely the common encoding of a qui
With coreutils-7.3, I mistakenly included a locally modified (i.e.,
not-committed -- and buggy!) version of lib/getdate.y in the release tarball.
How could it happen?
While there is a rule to ensure that no version-controlled file
in coreutils proper is included in a release, that rule was not
ext
Hi gnulibrarians!
New question toards the drand48 issue.
Message
http://lists.gnu.org/archive/html/bug-gnulib/2008-11/msg00031.html
states, that we should use the same file names as in glibc. The patch of
richard is all in one file. Is it enough to put a line to each function,
saying where it
Hello Ralf,
On Fri, May 01, 2009 at 09:50:23PM +0200, Ralf Wildenhues wrote:
> That NULTEST thing is cute but makes me cringe. If the second malloc
> runs out of memory, then you return, but leak memory from the first
> malloc. So in a tight memory situation, your code starts contributing
> to t
Ludovic Courtès wrote:
> > And finally, what's the hexdump of that DQNAN constant?
> >
> > #include
> > #include
> > int main()
> > {
> > printf("%04X%04X\n", DQNAN[1], DQNAN[0]);
> > return 0;
> > }
>
> FFF8
I meant %08X instead of %04X. DQNAN therefore likely is
FF
Bruno Haible writes:
> Hi Simon,
>
>> The reason is the fnmatch module doesn't create fnmatch.h. It needs
>> fnmatch-posix or fnmatch-gnu for that.
>
> Yes, but it was not possible for the 'glob' module to specify one or the
> other, because if the user wanted the other fnmatch module, it would
Hi Simon,
> The reason is the fnmatch module doesn't create fnmatch.h. It needs
> fnmatch-posix or fnmatch-gnu for that.
Yes, but it was not possible for the 'glob' module to specify one or the
other, because if the user wanted the other fnmatch module, it would collide.
This is now fixed.
> Ac
And here's a proposed simplification: Deprecate the 'fnmatch-posix'
module, and let the 'fnmatch' module take over its role. (Like we do
for the 'getpass' vs. 'getpass-gnu' modules.)
Any objections?
2009-05-02 Bruno Haible
* modules/fnmatch (Description, configure.ac): Taken from
We had a long-standing incompatibility between the modules fnmatch-gnu and
fnmatch-posix: It was not possible to both in the same configure.ac. This
fixes it.
2009-05-02 Bruno Haible
Remove incompatibility between modules fnmatch-posix and fnmatch-gnu.
* m4/fnmatch.m4 (gl_FUNC_
Simon Josefsson wrote:
> ./gnulib-tool --dir m --create-testdir --with-tests glob
> warning: module glob depends on a module with an incompatible license:
> mbsrtowcs
> warning: module glob depends on a module with an incompatible license:
> strnlen1
> ...
> Finally, Bruno, the license on strnlen
Looking at fnmatch.m4. These two small changes make it follow current practice.
2009-05-02 Bruno Haible
* m4/fnmatch.m4 (_AC_FUNC_FNMATCH_IF): Say "guessing no" instead of
"cross".
(gl_FUNC_FNMATCH_POSIX, gl_FUNC_FNMATCH_GNU): Update. Don't assume that
gnulib-t
Hi Bruno,
Bruno Haible writes:
> What's the result when you compile it with cc?
> $ cc foo.c -lm
> $ ./a.out
> $ echo $?
1
That's with "Compaq C V6.5-303 (dtk) on Compaq Tru64 UNIX V5.1B
(Rev. 2650)".
Should we conclude that this is a GCC bug? I'll try with different
versions.
> What'
* Bruno Haible wrote on Fri, May 01, 2009 at 11:45:09PM CEST:
> > Anyway, one solution is to stick '$(srcdir)/' before every reference of
> > those files.
>
> No, that would require the VPATH build to write those files into the
> source directory, which defeats the purpose of a VPATH build.
It is
Hi Bruno,
* Bruno Haible wrote on Fri, May 01, 2009 at 09:54:07PM CEST:
> > If you need a blurb about this in some gnulib documentation then please
> > show me where it would be appropriate; thanks.
>
> It's more in the automake documentation that I would expect this.
Good point, thanks. I'm pu
Hello,
when I try to
gnulib-tool --with-tests --test
with git Autoconf, I get this set of warnings:
configure.ac:2159: warning: AC_REQUIRE: `gl_PREREQ_VASNPRINTF_LONG_DOUBLE' was
expanded before it was required
glm4/vasnprintf.m4:101: gl_PREREQ_VASNPRINTF_INFINITE_LONG_DOUBLE is expanded
fro
The glob module fails on mingw:
./gnulib-tool --dir m --create-testdir --with-tests glob
warning: module glob depends on a module with an incompatible license: mbsrtowcs
warning: module glob depends on a module with an incompatible license: strnlen1
...
cd m
./configure --host=i586-mingw32msvc --b
19 matches
Mail list logo
