in lib/sha1.c line 190 (as of version 5.93):
/* Compute MD5 message digest for LEN bytes beginning at BUFFER. The
---
/* Compute SHA1 message digest for LEN bytes beginning at BUFFER. The
Thx,
James
***
The information
You have the wrong list; this is bug-coreutils which deals with the
coreutils package. If you suspect you have a glibc bug, there is a list
called bug-glibc.
Now that that is out of the way, here's an answer:
It is not a bug, but %n is causing vsprintf to expect an argument where
you have
Hi coreutils fans, while attempting to use direct I/O with dd on Tru64
5.1B, I discovered that Tru64 doesn't define O_DIRECT as coreutils 5.93
is expecting, but does define O_DIRECTIO which seems to act as I expect
direct I/O to act.
The open(2) man page states: O_DIRECTIO [Tru64 UNIX]
Paul Eggert writes:
The basic idea
here is that coreutils will attempt to detect the problem, and pass
the -qlanglvl=extc89 option to IBM's compiler. (It will pass
-qlanglvl=ansi to older versions of IBM's compilers.) I assume this
will work around the problem; if not, please let me know.
Yes, -qlanglvl=extc89 fixes it so we are good to go. Thanks.
-Original Message-
From: Paul Eggert [mailto:[EMAIL PROTECTED]
Sent: Monday, November 21, 2005 2:49 PM
To: Lemley James - jlemle
Cc: bug-coreutils@gnu.org
Subject: Re: FW: PMR 52061,370,000
Lemley James - jlemle [EMAIL
IBM's test case is fine, but it's not related to the bug. The
bug, as I understand it, is exhibited when you use bool. IBM's
test case does not involve bool.
Well, no. I've discovered that bool isn't really involved; it's an
unsigned problem when dealing with 64-bit math. The fact that we
From: Paul Eggert [mailto:[EMAIL PROTECTED]
Sent: Friday, October 07, 2005 2:00 PM
Also, could you please report the xlc bug to IBM?
After going back and forth with IBM some, it appears they don't think
there is problem with their compiler, even though with the default
options and
Paul, Jim and other interested parties:
The problem isn't with bool or _Bool; the problem reproduces with char
and unsigned char as well. Moreover, the assert won't catch it.
Looks like a rather severe compiler bug to me.
Example program output:
-2 + b is -1
-2 + b is -1
-2 + b is -1
d[-2
So, the problem occurs only in a subscript context? I really would
like to catch it if possible.
Near as I can tell, that's right. At least printf prints the right
thing.
Does the following program catch it? I'll looking for a way to detect
that compiler bug at compile-time.
Just what
Oh, I get it. I didn't realize you wanted fail at compile time. Hm...
No, that fails to compile in both 64-bit and 32-bit mode, as well as my
old development Linux box (gcc 2.96 on Redhat 7.2)
AIX says:
eggert.c, line 3.12: 1506-221 (S) Initializer must be a valid constant
expression.
GCC
Hi Coreutils Coders,
when compiling coreutils 5.90 on AIX 5.3 in 64 bit mode
(OBJECT_MODE=64),
sort dumps core at line 1724 or 1725 (coreutils 5.90).
It works fine in 32-bit mode, and debugging statements I add make it
seem like the code is doing the right thing.
Same thing is
It dumps core as before.
-Original Message-
...
Would you please see if it works with this syntax?
bool swap = !!(0 compare (lines[-1], lines[-2]));
...
**
The information contained in this communication is
I'm just a lurker so my opinion doesn't count. for much.
Certainly I don't expect everyone to be a programmer in order to be able
to shuffle their playlist, but perhaps an example needs to be added to
the sort man-page stating how easy is to accomplish with tools that are
likely already
Hi Paul, thanks for the good words!
That's an elegant solution - starting probe at 1 instead of in the middle,
to get the case where the key we want is already in the first file. I like
it. I had set up a test on my machine to try lots of different scenarios
with the original sort.c and my
Hi coreutils hackers,
I see this topic has come up on the list before (searching for NMERGE in the
archives), but in coreutils 5.3.0 sort.c, temporary files are still merged
in a linear-search fashion. Admittedly I am new to this list and haven't
read every note, but I didn't find a reason
Somewhat embarrassed by this, but that last sort.c patch I sent has been
de-uglified some. Try this one instead.
This patch is restructured slightly from the last one and performs even
better in my merge tests, both on random key files and dupe key files.
Sorry for sending that before I was
16 matches
Mail list logo
