Re: libpng-12.58rc01, 1.4.21rc01, 1.5.29rc01, 1.6.32rc01, and 1.7.0beta89 are available

J Decker <[email protected]>
Newsgroups gmane.comp.graphics.png.devel
Message-ID <CAA2GJqVsh6vNA4rvcdbrxBWsiOCYytBSNb6Am9gmEAEeCDn3nA@mail.gmail.com>
compiling 1.7.0b89 with visual studio...
generates quite a few warnings

...\libpng-1.7.0b89\pngchunk.h(47): warning C4028: formal parameter 2
different from declaration (compiling source file
...\libpng-1.7.0b89\pngrutil.c)

This is caused because png_inforp (what is used in png_handle_IHDR) is not
exactly the same as png_infop which is used for the function declaration....


(line 627 in png.h)
typedef png_info * PNG_RESTRICT png_inforp;

(line 610 in png.h)
typedef png_info * png_infop;


These can be fixed by adding PNG_RESTRICT macro to png_infop...
typedef png_info * PNG_RESTRICT png_infop;


All of these lines should be updated...
(line 586&587 png.h)
typedef const png_struct * PNG_RESTRICT png_const_structp;
typedef png_struct * PNG_RESTRICT png_structp;

(line 610&611 png.h)
typedef png_info * PNG_RESTRICT png_infop;
typedef const png_info * PNG_RESTRICT png_const_infop;

The others are only used in tests... I don't build those, so I only know by
searching for the symbol.

(612)
typedef png_info * * png_infopp;

-----------------------
...\libpng-1.7.0b89\pngrutil.c(4251): warning C4018: '>=': signed/unsigned
mismatch
                        pass >= PNG_LAST_PASS(width, height))

pass is unsigned... the macro is
(line 3094, png.h)

#define PNG_LAST_PASS(width, height) ((height) > 1 ? 6 : ((width) > 1 ? 5 :
0))

and should be

#define PNG_LAST_PASS(width, height) ((height) > 1 ? 6U : ((width) > 1 ? 5U
: 0))

----
This sort of expression

pixel_block & -pixel_block

is used quite a bit, it generates warning
...\libpng-1.7.0b89\pngwutil.c(859): warning C4146: unary minus operator
applied to unsigned type, result still unsigned

Maybe such a test for (LOWEST_SET_BIT) could be made as a macro so a one
place fix could be made... (though I don't know a good fix)

-----

...libpng-1.7.0b89\pngwutil.c(1564): warning C4334: '<<': result of 32-bit
shift implicitly converted to 64 bits (was 64-bit shift
            while (windowBits < 15 && (1U << windowBits) < test_size)

This sort of warning I really hate.  It's range tested to be under 32 bits,
and there's no way to make visual studio keep it as 32 bit... even applying
like (windowBits & 0xF) on the value.  And maybe it's because it's a 64 bit
build...

-----
The final bit of warnings are

...\libpng-1.7.0b89\pngrtran.c(610): warning C4146: unary minus operator
applied to unsigned type, result still unsigned
...\libpng-1.7.0b89\pngrtran.c(626): warning C4146: unary minus operator
applied to unsigned type, result still unsigned
...\libpng-1.7.0b89\pngrtran.c(642): warning C4146: unary minus operator
applied to unsigned type, result still unsigned
...\libpng-1.7.0b89\pngrtran.c(909): warning C4146: unary minus operator
applied to unsigned type, result still unsigned
...\libpng-1.7.0b89\pngrtran.c(932): warning C4146: unary minus operator
applied to unsigned type, result still unsigned
...\libpng-1.7.0b89\pngrtran.c(966): warning C4146: unary minus operator
applied to unsigned type, result still unsigned
...\libpng-1.7.0b89\pngrtran.c(5781): warning C4146: unary minus operator
applied to unsigned type, result still unsigned

(for example)

unsigned int shift = 7U & -(tc->width << 2)/*overflow ok*/;

no suggestion on a fix for this...

-----
Just reporting; I don't have a preference whether these are fixed or not.









On Fri, Aug 18, 2017 at 7:13 PM, Glenn Randers-Pehrson <[email protected]>
wrote:

> libpng-1..2.58rc01, 1.4.21rc01, 1.5.29rc01, 1.6.32rc01, and 1.70beta89
> are available from
> https://ftp-osl.osuosl.org/pub/libpng/src/beta/
> ftp://ftp-osl.osuosl.org/pub/libpng/src/beta/
> http://libpng.download/src/beta/
> and from
> http://libpng.sf.net
>
> version 1.2.58rc01 [August 19, 2017]
>   Check for 0 return from png_get_rowbytes() and added some (size_t)
> typecasts
>     in contrib/pngminus/*.c to stop some Coverity issues (162705, 162706,
>     and 162707).
>
> version 1.4.21rc01 [August 19, 2017]
>   Check for 0 return from png_get_rowbytes() and added some (size_t)
> typecasts
>     in contrib/pngminus/*.c to stop some Coverity issues (162705, 162706,
>     and 162707).
>
> version 1.5.29rc01 [August 19, 2017]
>   Check for 0 return from png_get_rowbytes() in contrib/pngminus/*.c to
> stop
>     some Coverity issues (162705, 162706, and 162707).
>
> Version 1.6.32rc01 [August 18, 2017]
>   Added a set of "huge_xxxx_chunk.png" files to contrib/testpngs/crashers,
>     one for each known chunk type, with length = 2GB-1.
>   Check for 0 return from png_get_rowbytes() and added some (size_t)
> typecasts
>     in contrib/pngminus/*.c to stop some Coverity issues (162705, 162706,
>     and 162707).
>   Renamed chunks in contrib/testpngs/crashers to avoid having files whose
>     names differ only in case; this causes problems with some platforms
>     (github issue #172).
>
> Version 1.7.0beta89 [August 19, 2017]
>   Check for 0 return from png_get_rowbytes() in contrib/pngminus/*.c to
> stop
>     some Coverity issues (162705, 162706, and 162707).
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> png-mng-implement mailing list
> png-mng-implement-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/png-mng-implement
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
png-mng-implement mailing list
png-mng-implement-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/png-mng-implement
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.