Static builds of ext/imap have duplicate symbols, and so won't link on Windows.
To get around this issue, we simply disallow static building of the extension.
Say the string is \377\000, basename will use mbrlen() to check whether
it's a start of a multibyte sequence. While on Linux it'll return -1 for
any char in the extended ASCII, on Windows it's returning 1. From what I
see the reason is that Windows doesn't implement UTF-8 in the CRT lib,
it's rather 16-bit Unicode or DBCS. Since extended ASCII is convertable
to Unicode directly - thus the behavior. On Linux however, it's a true
UTF-8 locale and implementation, for it \377\000 is invalid.
Maybe mbrlen needs an independent implementation for Windows supporting
UTF-8. For now I just split out this case so the most of the big basename
test doesn't fail on this one case.
The constants have already been added long ago. This patch just adds a PHPT
which checks the recognition of the respective compression methods.
Unfortunately, I've not been able to assemble a zip with all compression
methods.
Very large WBMP (width or height greater than 2**31-1) cause an overflow and
circumvent the size limitation of 2048x2048 px. Very small WBMP (less than 12
bytes) cause a read error and are not recognized. This patch fixes both bugs.
ext/gd/libgd/gd_webp.c has been taken from libgd[1]. Mainly, gd_error(X) has
been subsituted by zend_error(E_ERROR, X) and BGD_DECLARE(X) by X. Further
modifications are obvious from the diff.
All GD tests are passing, what raises hope, but we need more WebP tests,
anyway.
[1] <https://github.com/libgd/libgd/blob/7ec030c4f1dae75ed5d82c3eed2abe6775742c75/src/gd_webp.c>
The stack overflow is caused by the recursive algorithm in combination with a
very large negative coordinate passed to gdImageFillToBorder(). As there is
already a clipping for large positive coordinates to the width and height of
the image, it seems to be consequent to clip to zero also.
Contrary to imagefilledrectangle(), imagerectangle() has the documented
limitation that the given points have to be the upper left and the lower right
corner, respectively. However, libgd already caters to upper right / lower left
pairs, and not catering to the other two combinations seems to be an oversight.
Anatol Belski