The component resamplers are not written to support this and I've
never seen it happen in a real (non-crafted) JPEG file so I'm
fine rejecting this as outright corrupt.
Fixes issue #1178.
1. Always use large rects mode to avoid definition of stbrp_coord
in header file depending on implementation #defines
2. Expose STBRP__MAXVAL to users
3. Fix value of STBRP__MAXVAL for large rect mode (stbrp_coord
is a 32-bit int, so needs to be <=0x7fffffff, 0xffffffff
doesn't work)
4. Add comment at the top about which #define to set to get the
implementation.
Fixes issue #1143, or rather, replaces that pull request.
Factor out string length computation into helper func, comment
it a bit more, always use a limit to avoid 32b unsigned overflow,
and avoid reading past the bounds of non-0-terminated strings given
with specified precision.
Fixes issue #966.
Required some tinkering, hope I didn't mess the logic up.
This now requires the config section to be set for the header
file, and different sites that include it should agree on what
the values are. This is kind of iffy but hard to avoid.
Fixes issue #647.
To pacify GCC warnings at -Wimplicit-fallthrough=4. Why the
all-caps version works and the others don't, I'm not sure; the
GCC manual page lists regular expressions that GCC is checking for
but does not say which regular expression syntax variant it's using,
whether it's looking for a substring match or a full match for
the comment, and what exactly the text being matched against is
for a single-line comment. Sigh.
Fixes issue #507.
Was using 4-character spaces and otherwise formatted unlike the
rest of the code, fix this. Also get rid of the outer switch in
GetGlyphGPOSInfoAdvance with just one case; just use an if.
No behavioral changes.
Glyphs not assigned a glyph class should default to class 0 as
per the OpenType spec. Also, change the code to treat malformed
data as an error to be handled, not an assert, and change the
way the version checking works.
Fixes the issue mentioned in PR #1035. Also, this part of the
code is indented incorrectly; will fix that in a subsequent
commit.
If the data was uncompressible and this deflate implementation expanded
by more than the overhead of simply storing it uncompressed, fall back
to deflate's uncompressed storage mode. This bounds the maximum deflated
size at the original size plus an overhead of 6 fixed bytes with another
5 bytes per 32767 byte block.
Fixes issue #948.
These mostly add very little and have caused problems for people,
nor does it make sense to require this when the underlying
computations are performed in floating-point arithmetic depending
on ratios of user-passed in image dimensions.
Arbitrary absolute epsilons here would just be garbage; we could
try and compute desired relative error bounds based on the
determined scale values, but this still leaves the questions of
what purpose this would even serve, which is unclear.
Leave the filter kernel asserts as comment for documentation
of what the behavior would be with exact math, but don't actually
bother asserting here.
Fixes issue #736.
We've established the signs of values before so we can carefully
jiggle the expressions to be guaranteed overflow-free; the tests
for <0 here were meant to check if the value was "still negative",
i.e. if the sum did not underflow below INT_MIN, and we can
rewrite that using algebra to be overflow-free.
We need an extra case in the Euclidean dvision for
INT_MIN / INT_MIN which is a bit annoying but trivial; finally,
for two's complement platforms, note that abs(x) = (x > 0) ? x : -x
does not work (since for x=INT_MIN, -x still gives INT_MIN),
but the equivalent formulation for _negative_ absolute value
(x < 0) ? x : -x is always in range and overflow-free, so
rewrite the relevant expressions using that negative absolute
value instead.
Fixes issue #741.
Sean Barrett
Fabian Giesen
Sean Barrett
Randy
ocornut
Andrew Kensler