From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38777) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDbzQ-0000Fs-KG for qemu-devel@nongnu.org; Fri, 10 Jul 2015 13:21:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZDbzP-0005Vq-Fa for qemu-devel@nongnu.org; Fri, 10 Jul 2015 13:21:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39440) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDbzP-0005Vg-9g for qemu-devel@nongnu.org; Fri, 10 Jul 2015 13:21:31 -0400 Date: Fri, 10 Jul 2015 19:21:27 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Message-ID: <20150710172127.GA2448@potion> References: <1436531615-30183-1-git-send-email-rkrcmar@redhat.com> <20150710133131.GB3818@potion.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] crypt: fix build with nettle >= 3.0.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers 2015-07-10 14:56+0100, Peter Maydell: > On 10 July 2015 at 14:38, Peter Maydell wrot= e: >> On 10 July 2015 at 14:31, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >>> We pass 'ctx' as a 'void *' in the code, but these functions accept >>> specialized structures, which makes them incompatible: >>> >>> void nettle_cipher_func(const void *ctx, size_t length, [...]) >>> >>> void aes_decrypt(const struct aes_ctx *ctx, size_t length, [...]) >>> void des_decrypt(const struct des_ctx *ctx, size_t length, [...]) >> >> But aren't both the typedef and the aes/des_decrypt functions >> provided by the nettle library? Why is the library providing >> functions whose prototypes don't match its own typedef? >=20 > I had a suspicion that this was undefined behaviour, > and I was right: >=20 > http://stackoverflow.com/questions/559581/casting-a-function-pointer-to= -another-type/14044244#14044244 >=20 > If you have a function that takes "const struct foo *f" > but the library code is calling it using a function pointer > whose type says it's "const void *", then you can't just cast > the function pointer before handing it to the library. > You need to provide the obvious wrapper: >=20 > void aes_decrypt_wrapper(const void *ctx, size_t length, ...) > { > aes_decrypt(ctx, length, ...); > } Makes sense, thanks. 'void *' shenanigans got me on this one. (Btw. the library isn't casting it back to the original type before calling and its test cases don't use wrappers.) I've posted v2 that addresses this problem.