You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@serf.apache.org by Branko Čibej <br...@apache.org> on 2025/06/20 06:12:12 UTC
Strange bit of code in Serf hpack_buckets.c
Hi Bert,
I've been going through the Serf code on trunk, trying to fix compiler
warnings, and found something that I don't understand and don't want to
just "fix" and possibly introduce a bug. I'm asking for your help, as
you're the author of that code:
https://svn.apache.org/viewvc/serf/trunk/buckets/hpack_buckets.c?annotate=1926128#l1393
I see a warning that 'status' is assigned but never used, and indeed
that's the case; here is the assignment, on line 1479:
if (ctx->reuse_item)
{
status = hpack_table_get(ctx->reuse_item, tbl,
&keep_key, NULL,
&keep_val, NULL);
}
and the return value is just ignored, even though hpack_table_get() can
return an error. I don't know enough to make a safe decision, but just
removing the assignment and 'status' seems wrong.
I know it's been a long time since you wrote this. Still, do you have
any suggestions?
Thanks!
-- Brane
Re: Strange bit of code in Serf hpack_buckets.c
Posted by Branko Čibej <br...@apache.org>.
On 21. 6. 25 16:31, Daniel Sahlberg wrote:
> Den fre 20 juni 2025 kl 08:12 skrev Branko Čibej <br...@apache.org>:
>
> Hi Bert,
>
> I've been going through the Serf code on trunk, trying to fix
> compiler
> warnings, and found something that I don't understand and don't
> want to
> just "fix" and possibly introduce a bug. I'm asking for your help, as
> you're the author of that code:
>
> https://svn.apache.org/viewvc/serf/trunk/buckets/hpack_buckets.c?annotate=1926128#l1393
>
>
> I see a warning that 'status' is assigned but never used, and indeed
> that's the case; here is the assignment, on line 1479:
>
> if (ctx->reuse_item)
> {
> status = hpack_table_get(ctx->reuse_item, tbl,
> &keep_key, NULL,
> &keep_val, NULL);
> }
>
>
> and the return value is just ignored, even though
> hpack_table_get() can
> return an error. I don't know enough to make a safe decision, but
> just
> removing the assignment and 'status' seems wrong.
>
> I know it's been a long time since you wrote this. Still, do you have
> any suggestions?
>
> Thanks!
>
> -- Brane
>
>
> Maybe...:
>
> keep_key and keep_val are both initialized to NULL. The only use are
> the next two lines:
>
> own_key = (ctx->key && ctx->key != keep_key);
> own_val = (ctx->val && ctx->val != keep_val);
>
> They in turn control if we can reuse the key/value from the ctx or
> need to copy the string to the entry.
>
> hpack_table_get will fail if we send an invalid index (ctx->reuse_item
> == 0) or if the requested entry isn't found in the table. In both
> cases it will not modify keep_key and keep_val, remaining null, so
> own_key/own_val should be false, thus creating a copy.
>
> To me it looks like optimization to avoid creating a new copy of the
> key/value if it already exists in the hpack table. Worst case, if
> hpack_table_get return an error, a new copy will be made wasting a bit
> of memory (which would probably be a reasonable thing to do anyway if
> it fails).
That's the conclusion I've come to, yes. But if this is the case, well,
looking at the output of a function instead of its return value is not
intuitive and should be avoided.
-- Brane
P.S.: For another case of such suspect design, see Subversion's auth
providers, which always return "no error" but also set a "done" boolean
by reference, which is the _actual_ returned status.
Re: Strange bit of code in Serf hpack_buckets.c
Posted by Daniel Sahlberg <da...@gmail.com>.
Den fre 20 juni 2025 kl 08:12 skrev Branko Čibej <br...@apache.org>:
> Hi Bert,
>
> I've been going through the Serf code on trunk, trying to fix compiler
> warnings, and found something that I don't understand and don't want to
> just "fix" and possibly introduce a bug. I'm asking for your help, as
> you're the author of that code:
>
>
> https://svn.apache.org/viewvc/serf/trunk/buckets/hpack_buckets.c?annotate=1926128#l1393
>
>
> I see a warning that 'status' is assigned but never used, and indeed
> that's the case; here is the assignment, on line 1479:
>
> if (ctx->reuse_item)
> {
> status = hpack_table_get(ctx->reuse_item, tbl,
> &keep_key, NULL,
> &keep_val, NULL);
> }
>
>
> and the return value is just ignored, even though hpack_table_get() can
> return an error. I don't know enough to make a safe decision, but just
> removing the assignment and 'status' seems wrong.
>
> I know it's been a long time since you wrote this. Still, do you have
> any suggestions?
>
> Thanks!
>
> -- Brane
>
>
Maybe...:
keep_key and keep_val are both initialized to NULL. The only use are the
next two lines:
own_key = (ctx->key && ctx->key != keep_key);
own_val = (ctx->val && ctx->val != keep_val);
They in turn control if we can reuse the key/value from the ctx or need to
copy the string to the entry.
hpack_table_get will fail if we send an invalid index (ctx->reuse_item ==
0) or if the requested entry isn't found in the table. In both cases it
will not modify keep_key and keep_val, remaining null, so own_key/own_val
should be false, thus creating a copy.
To me it looks like optimization to avoid creating a new copy of the
key/value if it already exists in the hpack table. Worst case, if
hpack_table_get return an error, a new copy will be made wasting a bit of
memory (which would probably be a reasonable thing to do anyway if it
fails).
Cheers,
Daniel