Hey Peter,

I'm fine with your version of patch and noone else had objections so I
believe we can patch it your way.

Did you fix it upstream? I'm still seeing 1.11 as the latest release.
I can patch it only for Debian but I believe we should have it fixed for
every other distros / ways of distribution.

regards
Bartek

W dniu 3/21/2015 o 12:28 AM, Peter Selinger pisze:
> Here's the patch that I am planning to apply upstream. Please comment
> if you see anything wrong with it. 
> 
> While the general idea is similar to Tomasz's patch, I've solved the
> details a bit differently.
> 
> * I prefer to use ssize_t instead of unsigned long long int for memory
>   manipulations. Since size_t is the type used by malloc, memcpy, etc,
>   it is big enough to hold the relevant values. The reason I use a
>   signed rather than unsigned type is that the "dy" field in the
>   potrace_bitmap_s structure may be positive or negative, depending on
>   whether the bitmap is stored top-to-bottom or bottom-to-top. Potrace
>   itself always uses a positive dy, but other applications that link
>   against the Potrace library may use their own convention. Tomasz's
>   patch used an unsigned type which would break applications that use
>   a negative dy.
> 
>   The code now checks that the bitmap dimensions are indeed such that
>   all relevant values fit within ssize_t. A remaining assumption is
>   that ssize_t is at least as big as int, which I think is guaranteed.
> 
> * I prefer to use calloc instead of safe_malloc. Calloc is appropriate
>   whenever the memory to be allocated is a number of copies of items
>   of a given size. Unlike malloc(x*y), calloc(x, y) actually checks
>   that x*y does not overflow. (I checked the glibc source code for
>   calloc to be sure that such a check is actually performed). In the
>   few cases where the argument of malloc is calculated differently
>   (say as a product of three numbers), I have added an explicit
>   overflow check. This is safer, in my opinion, than safe_malloc(x*y);
>   in particular, there is no difference bewteen safe_malloc and
>   ordinary malloc when size_t = unsigned long long int.
> 
> * I also fixed analogous issues in Mkbitmap and throughout the rest of
>   the code.
> 
> I'll post an updated upstream package in a day or two unless there's
> feedback requiring additional changes.
> 
> Thanks, -- Peter
> 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to