On 2015-11-04 13:39:14 [+0100], Andreas Cadhalpun wrote: > Hi Sebastian, Hi Andreas,
> I consider it OK to cast const away, when one has manually checked that > it's not a problem. But removing the const in clamav should be fine, too. > > >> It would also be useful to check what other programs using tomsfastmath > >> in Debian expect. > > Okay, I can do it. > > Anyway, if it's not only clamav that expects the const, patching tomsfastmath > might still be the better approach. It is tricky. tomcrypt has a tfm layer where it can be be compiled against tomfastmath instead of tommath. This one casts the const away [0]. There is a similar function in tommath called mp_read_radix() which is const [1]. wolfcrypt is the only package that codesearch.d.n found that uses the function as const. It seems they used tommath in the past and made then a layer which now invokes tomfastmath in the background and therefore they kept the const [2]. I will try to address that header change upstream but I doubt there will be a new release just with this change :) So I would say it is up to you whether we should ship that patch in tfm or not. I'm fine both ways. [0] https://github.com/libtom/libtomcrypt/blob/develop/src/math/tfm_desc.c#L171 [1] https://github.com/libtom/libtommath/blob/develop/bn_mp_read_radix.c#L19 [2] http://sources.debian.net/src/wolfssl/3.4.8%2Bdfsg-1/wolfcrypt/src/tfm.c/?hl=2499#L2558 > Best regards, > Andreas > Sebastian _______________________________________________ Pkg-clamav-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-clamav-devel
