FYI, /usr/include/rpc/ no longer exists, as of F15's glibc-headers-2.13.90-10,
so hail's lib/cld_msg_rpc.h will have to do something about this #include:
$ grep rpc.h lib/cld_msg_rpc.h
#include
--
To unsubscribe from this list: send the line "unsubscribe hail-devel" in
the body of a messa
Pete Zaitcev wrote:
> On Fri, 31 Dec 2010 05:57:28 -0500
> Jeff Garzik wrote:
>
>> +struct cldc_tcp *tcp = private;
>> +ssize_t rc;
>> +struct ubbp_header ubbp;
>> +
>> +memcpy(ubbp.magic, "CLD1", 4);
>> +ubbp.op_size = (buflen << 8) | 1;
>> +#ifdef WORDS_BIGENDIAN
>> +swab
Jeff Garzik wrote:
> On 12/06/2010 12:44 PM, Pete Zaitcev wrote:
>> On Mon, 06 Dec 2010 12:32:22 -0500
>> Jeff Garzik wrote:
>>
>>> Keeping the "correct libtool macros in-tree" implies adding a pointless
>>> maintenance burden. The distro always gives us correct, up-to-date
>>> files. Why would
Pete Zaitcev wrote:
> Hi, Jim:
>
> Autoconf printed a warning when reconfiguting Hail, so I gave up and
> added this:
>
> diff --git a/configure.ac b/configure.ac
> index 9cfad23..d378854 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -62,6 +62,8 @@ AC_PROG_GCC_TRADITIONAL
> AM_PROG_CC_C_O
Jeff Garzik wrote:
...
>> But even if curl were requiring some suboptimal signature,
>> it would be nice not to impose that on all projects that use hail.
>> Are there older curl headers that do require the const-free signature?
>> If there are and you want to support them, too, let me know -- mayb
Jeff Garzik wrote:
...
>> Hi Jeff.
>>
>> Sorry I didn't notice that the first time.
>> I built with ./autogen.sh&& ./configure&& make.
>> It looks like you recommend -Wall -Wshadow.
>>
>> The two warnings above are the only ones I see with the patch,
>> and they're easy to fix. When storing cons
Jeff Garzik wrote:
> On 10/06/2010 08:07 AM, Jim Meyering wrote:
>>
>> Make write_cb callback's buffer parameter const, like all write-like
>> functions.
>> Give a few "char *" parameters the "const" attribute.
>>
>> Signed-off-by: J
Jeff Garzik wrote:
> On 10/06/2010 08:07 AM, Jim Meyering wrote:
...
>> It looks like most of hail's interfaces are const-correct,
>> but one stood out because it provokes a warning when I tried to
>> pass a const-correct write_cb function to hstor_get from iwhd:
...
&
n that now-read-only buffer.
Signed-off-by: Jim Meyering
---
test/large-object.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/test/large-object.c b/test/large-object.c
index dbe2027..fc7d03c 100644
--- a/test/large-object.c
+++ b/test/large-o
Make write_cb callback's buffer parameter const, like all write-like
functions.
Give a few "char *" parameters the "const" attribute.
Signed-off-by: Jim Meyering
---
It looks like most of hail's interfaces are const-correct,
but one stood out because it provokes
Jeff Garzik wrote:
> On 09/29/2010 11:20 AM, Jim Meyering wrote:
>>
>> chk_list_objs called fs_list_objs_open without also calling
>> fs_list_objs_close.
>>
>> 32,808 bytes in 1 blocks are definitely lost in loss record 413 of 419
>> at 0x4
(gthread.c:1893)
by 0x31BB407760: start_thread (pthread_create.c:301)
by 0x31BA8E151C: clone (clone.S:115)
Signed-off-by: Jim Meyering
---
Thanks to Pete for catching my error.
To make up for that, here's a real leak fix:
chunkd/selfcheck.c |1 +
1 files changed, 1 insertions(
Pete Zaitcev wrote:
> On Mon, 27 Sep 2010 10:53:06 +0200
> Jim Meyering wrote:
>
>> -stmp = huri_field_escape(strdup(val), QUERY_ESCAPE_MASK);
>> +v = strdup(val);
>> +stmp = huri_field_escape(v, QUERY_ESCAPE_MASK);
>> str = g_string_app
Signed-off-by: Jim Meyering
---
I would have preferred to insert a single line right before the
huri_field_escape call:
char *v = strdup(val);
[would result in a more compact, single-hunk patch]
but it looks like hail uses the anachronistic (pre-C99)
"declare all vars at outer
Jeff Garzik wrote:
> On 09/24/2010 07:32 AM, Jim Meyering wrote:
>> You can pull from the "oom" branch here:
>>git://git.infradead.org/users/meyering/tabled.git
>
> Got nearly everything perfect. Need one more minor yet important
> change. As describ
Jim Meyering wrote:
> Jeff Garzik wrote:
>
>> On 09/23/2010 03:19 PM, Jeff Garzik wrote:
>>> 3) I process patches similar to how Linus and others in the kernel do
>>> it: "git am /path/to/mbox_of_patches" That tends to impose some
>>> restriction
separate.
However, I did leave the copyright year updates in.
If they're a problem, let me know and I'll do another round.
Otherwise, I can send a patch to update all of the
remaining ones to include 2010 so this won't be an
issue for 3 more months.
$ git shortlog HEAD ^origin/mas
Jeff Garzik wrote:
> On 09/23/2010 04:43 AM, Jim Meyering wrote:
>>> From fb7865d158b0d32907dde703c4d37c70a26e738c Mon Sep 17 00:00:00 2001
>> From: Jim Meyering
>> Date: Thu, 23 Sep 2010 10:11:44 +0200
>> Subject: [PATCH tabled 1/2] server/config.c: don't der
Pete Zaitcev wrote:
> On Thu, 23 Sep 2010 00:32:09 -0400
> Jeff Garzik wrote:
>
>> >>> So, we go a longer route and re-hook the list of completions
>> >>> to a per-server global instead of a client. The patch is straight-
>> >>> forward. The only thing we need to be careful is to
Signed-off-by: Jim Meyering
---
Just noticed that sometimes tabled uses this idiom:
if (!(key = malloc(klen + 1)))
and sometimes this:
if ((key = malloc(klen + 1)) == NULL)
This time I used "... == NULL".
server/server.c |3 ++-
1 files changed, 2 insertions(+), 1 deletion
4ef4e96d Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Thu, 23 Sep 2010 12:47:32 +0200
Subject: [PATCH tabled] server/bucket.c: don't deref NULL upon failed malloc
Signed-off-by: Jim Meyering
---
server/bucket.c | 24 +++-
1 files changed, 15 insertions(+)
>From aed01fa24688257fdf6f3c5ecf6983f61b8749f8 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Thu, 23 Sep 2010 11:12:27 +0200
Subject: [PATCH tabled] server/status.c: don't deref NULL on failed strdup
Use a non-malloc'd string upon failed strdup so
we don't have to diagnos
>From 6193423b13197c63ff36d01438a23b4b1278825b Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Thu, 23 Sep 2010 11:02:36 +0200
Subject: [PATCH tabled] server/server.c: don't deref NULL on failed strdup
Here, pathtokey does handle a NULL argument, but the following
applog/prin
This first one is so small it barely deserved a commit.
The second fixes a bug.
>From 8e6255aa5cddd7bd58d7e4dbd2ecc81f84c51ea2 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Thu, 23 Sep 2010 10:47:22 +0200
Subject: [PATCH tabled 1/2] server/server.c: use "sizeof s" rather than
e
ggested it's possible, so...
>From fb7865d158b0d32907dde703c4d37c70a26e738c Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Thu, 23 Sep 2010 10:11:44 +0200
Subject: [PATCH tabled 1/2] server/config.c: don't dereference NULL on OOM
Signed-off-by: Jim Meyering
---
server/config.c |7
Jeff Garzik wrote:
> On 09/23/2010 03:55 AM, Jim Meyering wrote:
>> Better safe than sorry...
>> Unreported write failures can be unpleasant.
>> I fixed the one below so that a failure indication
>> can propagate up the call tree. You might also want to
>> repo
you'd rather separate those from the fix,
let me know and I can adjust and resend.
>From abe4be09fea8194fe0c4187c20ebaa45822c839c Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Thu, 23 Sep 2010 09:38:24 +0200
Subject: [PATCH tabled] server/server.c (net_write_port): Don't ignore
Jeff Garzik wrote:
> On 09/10/2010 08:55 AM, Jim Meyering wrote:
>>
>> * server/msg.c (msg_get): Copy only name_len bytes, then NUL-terminate,
>> rather than using snprintf to copy up to and including nonexistent NUL.
>> ---
>>
>> valgrind exposed thi
* server/msg.c (msg_get): Copy only name_len bytes, then NUL-terminate,
rather than using snprintf to copy up to and including nonexistent NUL.
---
valgrind exposed this. The use of snprintf would have been
correct if the inode name buffer (following the struct raw_inode)
were NUL-terminated, bu
29 matches
Mail list logo
