Following up on commit 7c67f70da1:
Replace 22 deprecated pointer typedefs with their underlying types.
The typedefs replaced are:
1. Core structure types:
- png_structp, png_structrp, png_structpp and const variants
- png_infop, png_inforp, png_infopp and const variants
2. Utility structure types:
- png_row_infop, png_row_infopp
- png_imagep, png_imagepp
- png_controlp
3. Color structure types:
- png_colorp, png_colorpp and const variants
- png_color_8p, png_color_8pp and const variants
- png_color_16p, png_color_16pp and const variants
4. Text and time structure types:
- png_textp, png_textpp and const variants
- png_timep, png_timepp and const variants
5. Chunk structure types:
- png_unknown_chunkp, png_unknown_chunkpp and const variants
- png_sPLT_tp, png_sPLT_tpp and const variants
- png_sPLT_entryp, png_sPLT_entrypp and const variants
6. Internal types:
- png_compression_bufferp
- png_dsortp, png_dsortpp
Remove all remaining uses of spurious PNG_RESTRICT qualifiers.
Non-aliasing has already been guaranteed by the type-based aliasing
rules combined with the libpng usage pattern of a single pointer per
type.
Update the user manual accordingly.
This completes the systematic replacement of deprecated pointer
typedefs across the entire libpng codebase. The typedef declarations
remain in png.h for backward compatibility, marked as deprecated.
Reviewed-by: Chris Blume <ProgramMax@gmail.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Following up on commit ddce3ff853:
1. Replace 28 deprecated pointer typedefs with their underlying types.
The typedefs replaced are:
- Basic: png_voidp, png_charp and const variants
- Byte: png_bytep, png_const_bytep, png_bytepp
- Numeric:
- Integer: 16/32-bit integer pointer variants
- Fixed-point: png_fixed_point_p and variants
- Floating-point: png_doublep and variants
2. Remove a spurious PNG_RESTRICT qualifier. Non-aliasing has already
been guaranteed by the type-based aliasing rules.
3. Update the user manual accordingly.
Reviewed-by: Chris Blume <ProgramMax@gmail.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
The change removes the need for build configuration of target specific
code such as SIMD enhancements.
The extensible framework is based on checks in the new file named
pngtarget.h and allows per target description of requirements and
capabilities using macros with the prefix PNG_TARGET_. These macros are
interpreted by the core libpng code in a target independent way.
The PNG_TARGET_ prefixed macros describe the target specific
implementation and document how to include it. The actual inclusion of
the code is done, at present, by a single target independent core file
named pngsimd.c.
This approach ensures that no special configuration in the build system
is required on any system. It is not required on a system which is
compiling for the build host where we can reasonably assume that the
compiler is correctly set up. Neither is it required for cross builds
so long as the toolchain is correctly set up. In this case the
toolchain means the cross build system and any ancilliary programs it
requires.
More details of the implementation are included in the source files
named pngtarget.h and pngsimd.c. These files document in C comments how
additional target specific code might be added.
The changes consist primarily of movement of target specific code from
the core libpng source files to the existing target specific
subdirectories such as the ones named intel and arm. This isolates the
code into the corresponding subdirectory and eliminates the requirement
for changes across the libpng structure.
As part of this the ARM processor NEON instruction set specific palette
to RGB code has been generalised to allow implementation in other
architectures. The resultant updated version of the original (ARM Ltd)
implementation has been moved to the subdirectory named arm.
In addition some selected changes have been included to allow testing
with higher warning levels than the typical compiler defaults.
Reviewed-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
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, size_t became a required type. It should be used
consistently. To maintain backwards compatibility, png_size_t
is still maintained in deprecated form.
