On Mon, Nov 14, 2016 at 12:11:47PM +0100, Anton Khirnov wrote: > Quoting Diego Biurrun (2016-11-14 11:58:34) > > On Mon, Nov 14, 2016 at 11:40:22AM +0100, Anton Khirnov wrote: > > > Quoting Diego Biurrun (2016-11-14 10:27:32) > > > > On Mon, Nov 14, 2016 at 10:12:02AM +0100, Anton Khirnov wrote: > > > > > Quoting Diego Biurrun (2016-11-14 10:03:43) > > > > > > On Mon, Nov 14, 2016 at 09:20:12AM +0100, Anton Khirnov wrote: > > > > > > > Quoting Diego Biurrun (2016-11-14 09:05:33) > > > > > > > > Fixes a number of warnings of the type > > > > > > > > libavutil/hmac.c:61:21: warning: assignment from incompatible > > > > > > > > pointer type > > > > > > > > > > > > > > No, this does not "fix" anything. It hides real warnings caused > > > > > > > by real > > > > > > > problems. I really wish you stopped fixing warnings and perhaps > > > > > > > fixed > > > > > > > the bugs that cause those warnings instead. > > > > > > > > > > > > Interestingly, this patch is from Kostya. I'm open to your > > > > > > suggestion > > > > > > of the "real fix". > > > > > > > > > > What does it matter who is it from? It is wrong. The compiler prints a > > > > > warning because you're calling a function using a wrong signature > > > > > (signed int vs unsigned). Strictly speaking, this is UB. The only > > > > > thing > > > > > this patch does is shut up the warning, but the problem is still > > > > > there - > > > > > you are still calling a function using a wrong signature. > > > > > > > > No, the signed vs. unsigned thing is not the issue and does not affect > > > > the > > > > warning(s). > > > > > > It may not be the _only_ reason for the warnings, but it is certainly > > > one of the reasons. > > > > You always need a cast to assign non-identical function pointers. > > > > What is it that you suggest should be done? Change the API for sha and > > md5 take unsigned or size_t as type for the length parameter? We use > > nt as type for sizes in 99% of all cases throughout the codebase. > > MD5 already takes int, it's just SHA that's unsigned. Ideally all of > those should be size_t, so breaking API is one possibility.
I've been advocating for size_t for sizes, but I have to admit that it feels a tad arbitrary to require size_t now given the amount of int-typed size variables that we have everywhere and that you yourself use even in current code. > Another, non-breaking one, would be to add wrappers to hmac.c, similarly > to what it already does for sha init. That would be pointless indirection IMO. Notice that the sha init wrappers pass an extra parameter of a fixed size. Diego _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
