Most code is already using gdPutC instead of Putchar -- only the bmp
module is using Putchar. It's unclear why we have this other form as
they should be equivalent: gdPutC takes an unsigned char (8-bits) and
then calls ctx->putC while Putchar takes a signed int, masks it with
0xff, and then calls ctx->putC.
The history of these funcs goes back to when it's initially imported
as part of the 1.5.0 release, and there doesn't seem to be any notes
as to why.
So change bmp to use gdPutC so we can delete Putchar entirely. The
function isn't exported so no one should even notice. Our tests are
still passing, so hopefully that provide good coverage.
Git ident attributes were in most cases utilized with SVN and keywords
substitutions, where $Id$ were replaced with certain revision from the
repository. In Git this functionality is different. Each $Id$ needs to
be defined in .gitattributes file to be effective. This patch removes
unused and outdated attributes.
oss-fuzz pointed out:
gd_bmp.c:641:18: runtime error: negation of -2147483648 cannot be represented in type 'int';
cast to an unsigned type to negate this value to itself
This is a bit of a false positive issue as -2147483648 is -2147483648
with gcc/clang which we check for later on. But lets check for it up
front to avoid the undefined behavior.
For OS/2 BMP 1.0 files, the spec says only 1/4/8/24 bit images are
supported, so ignore other depths as invalid.
oss-fuzz pointed out:
gd_bmp.c:670:22: runtime error: shift exponent 12803 is too large for 32-bit type 'int'
Although libgd is not really affected by this issue, because contrary
to PHP's bundled libgd it does not allow to read from negative offsets,
we consider it still a bug that `dynamicSeek()` does not behave like
`fileSeek()` with regard to negative positions.
As this behavior cannot be probed from outside, we omit the regression
test.
That happens only when RLE is applied. The culprit is in compress_row(),
where the rightmost pixels which wouldn't be run-length encoded were
ignored; instead we now add them uncompressed to the `row`.
That happens only when RLE is applied. The culprit is in compress_row(),
where the rightmost pixels which wouldn't be run-length encoded were
ignored; instead we now add them uncompressed to the `row`.
We use ceill and ceil in this code, but it's not clear we need the long
double variant of ceill here. The input multiply is already done with
double precision (the 0.1 literal is a double), and not all C libraries
offer long double variants. Change to ceil and see if anyone notices.
Closes issue #123.
Pierre Joye
Mike Frysinger
Romain DÉOUX
Peter Kokot
Christoph M. Becker
Ondřej Surý
Remi Collet
pierrejoye