> In terms of bounds analysis here, in case I have to discuss this with > the Fedora people: since bordermode is forced to not be BORDER_CLAMP > in this branch, prepare_tap_boundaries() will set xtap_first to 0 and > xtap_last to 2 * itor->width, and itor->width is asserted as less than > 4 at the start of the function. Thus we can't go outside the 0..7 range > of the kernelh[8] array. Is that a correct analysis or am I missing > something subtle?
This may not be of consequence, but what happens if itor->width is a large negative number? I would test this myself, but I don't have gcc-5.1 set up. If you clamp itor- >width to be >= 0, does the problem go away> Taahir Ahmed
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/
_______________________________________________ darktable-devel mailing list darktable-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/darktable-devel
