As per the const correctness rules, top-level const-ness of data
in automatic scopes does not propagate outside of these scopes
(unlike const-ness at lower levels, such as pointers to const data).
Previously, const was used liberally, but inconsistently across the
libpng codebase. Using const wherever applicable is not incorrect.
However, _consistent_ use of const is difficult to maintain in such
conditions.
In conclusion, we shall continue to use const only where doing so is
strictly necessary:
1. If a function guarantees that it will not modify an argument
passed by pointer, the corresponding function parameter should be
a pointer-to-const (const T *).
2. Static data should not be modified, therefore it should be const.
Reference:
Google C++ Style Guide
https://google.github.io/styleguide/cppguide.html#Use_of_const
In v1.6.0, compiler support for const became a requirement.
It should be used consistently. To maintain backwards compatibility,
PNG_CONST is still maintained in deprecated form.
In v1.6.0, size_t became a required type. It should be used
consistently. To maintain backwards compatibility, png_size_t
is still maintained in deprecated form.
result when integers appear on both sides of a compare. Worked around the
others by forcing the strict-overflow setting in the relevant functions to
a level where they are not reported.
Changed "FALL THROUGH" comments to "FALLTHROUGH" because GCC doesn't like
the space.
Worked around some C-style casts from (void*) because g++ 5.4.0 objects
to them.
Increased the buffer size for 'sprint' to pass the gcc 7.1.0 'sprint
overflow' check that is on by default with -Wall -Wextra.
When an input file contains a zero length IDAT and pngfix is not applying the
IDAT rechunking (--max) option pngfix will go into a loop writing the zero
length IDAT for ever.
This is a fairly minor issue for interactive use; zero length IDAT is very rare,
the problem is obvious (pngfix hangs) and the fix (use --max, or --max=4096
etc), while not obvious, is easy.
For non-interactive use, e.g. trying to automatically repair a PNG that cannot
be read by libpng, there are security consequences:
1) pngfix hangs. This may permit a DoS attack.
2) When the --out option is used pngfix will just keep writing. This is a very
likely DoS scenario.
Signed-off-by: John Bowler <jbowler@acm.org>
The fixed size buffer for the file name being processed could have a byte
written beyond the end; a bug where the test was updated without changing the
size of the buffer. This commit reduces the buffer to the system maximum.
png_getrowbytes could, in theory, return 0; probably only if there is a bug in
libpng but the code now checks.
Signed-off-by: John Bowler <jbowler@acm.org>
If PNG_PNGCP_TIMING_SUPPORTED is defined maximal resolution CPU time logging of
png_read_png and png_write_png is enabled via the --time command line option.
This is not on by default but is enabled by contrib/conftests/pngcp.dfa
Signed-off-by: John Bowler <jbowler@acm.org>
This adds pngcp to the build together with a pngcp.dfa configuration test; the
test revealed some configuration bugs which are fixed by corrections to the
_SUPPORTED macros.
pngcp builds on all tested configurations and a number of bugs have been fixed
to make this happen relative to the version in libpng 1.7 contrib/examples.
pngcp.dfa will have to be different for 1.7 but pngcp.c should work fine (not
yet tested). pngcp itself is still missing a usage message; this is a
preliminary version, although since it behaves the same way as 'cp' most unoids
shouldn't have a problem using it correctly.
Signed-off-by: John Bowler <jbowler@acm.org>
This updates libpng16 with all the test changes from libpng17,
including changes to pngvalid.c to ensure that the original,
distributed, version of contrib/visupng/cexcept.h can be used.
pngvalid contains the correction to the use of SAVE/STORE_
UNKNOWN_CHUNKS; a bug revealed by changes in libpng 1.7. More
tests contain the --strict option to detect warnings and the
pngvalid-standard test has been corrected so that it does not
turn on progresive-read (there is a separate test which does
that.)
Some signed/unsigned fixes have been made.
Signed-off-by: John Bowler <jbowler@acm.org>
handling in contrib/libtests/pngstest.c; possible overflow of
unsigned char in contrib/tools/png-fix-itxt.c). To use the "secure"
file handling, define PNG_USE_MKSTEMP, otherwise "tmpfile()" will
continue to be used.
simpleover. Also added a comment to png.h pointing out that the pointer must
be set to NULL! (simpleover crashes with any slightly complex command lines
without this fix.)