Good points :-) sorry for the noise.
On 28 July 2017 at 14:07, Willy Tarreau <w...@1wt.eu> wrote:
> Hi David,
>
> On Fri, Jul 28, 2017 at 01:58:29PM +0100, David CARLIER wrote:
> > Hi all,
> >
> > Nothing serious, just a patch proposal to silent compiler warning about
> > function parameter types.
> >
> > Kind regards.
>
> > From 6ed9b28287440ca74e7a29016f9c4d081cd902d5 Mon Sep 17 00:00:00 2001
> > From: David Carlier <devne...@gmail.com>
> > Date: Fri, 28 Jul 2017 14:42:42 +0100
> > Subject: [PATCH] CLEANUP: spoe: silencing compiler warning.
> >
> > Here we cast explicitally to silence gcc complains mismatches.
> > ---
> > src/flt_spoe.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/flt_spoe.c b/src/flt_spoe.c
> > index 5d574477..4df16ef6 100644
> > --- a/src/flt_spoe.c
> > +++ b/src/flt_spoe.c
> > @@ -706,7 +706,7 @@ spoe_handle_agenthello_frame(struct appctx *appctx,
> char *frame, size_t size)
> > SPOE_APPCTX(appctx)->status_code =
> SPOE_FRM_ERR_INVALID;
> > return 0;
> > }
> > - if (decode_varint(&p, end, &sz) == -1) {
> > + if (decode_varint(&p, end, (uint64_t *)&sz) == -1)
> {
> (...)
>
> I noticed these ones as well recently but I'd rather avoid to start casting
> the pointers, or sooner or later we'll regret it. And by the way it's a
> real
> bug, as decode_varint() takes an uint64_t* while size_t will generally be
> an
> uint32_t on 32-bit architectures.
>
> We'll more generally need to slightly modify the internal prototypes to use
> either one or the other type. By experience I tend to be used to see that
> when you change one of them it can propagate far away. But it will be safer
> (and will address the issue on 32-bit).
>
> As long as we have this warning we have a reminder that there's something
> to fix ;-)
>
> Thanks!
> Willy
>
