John Bowler

Closed: irrelevant; m

Application bug: [bug 457](https://github.com/glennrp/libpng/issues/457) is a duplicate of this. [457-2.patch](https://github.com/glennrp/libpng/files/11839657/457-2.patch) (in the duplicate) applies to this as well as does [458.patch](https://github.com/glennrp/libpng/files/11839910/458.patch) (which is an RTFM).

@ctruta: please close, PR457 is a duplicate

> I think `Makefile.in` should be updated https://github.com/glennrp/libpng/blob/libpng16/Makefile.in#L111 It's a generated file; github is a distribution medium (it contains other configure generated files) so the Makefile.in change would automatically happen...

> I am particularly happy to receive any contribution that consists in removing obsolete code. _Off topic_; this is why github discussions are useful :-) @ctruta: Now you have `cmake`...

I can't repro this: ``` git checkout v1.6.37 git clean -dfx mkdir ../v1.6.37 cd !$ make all gcc -O2 -o pngcp ../git/contrib/tools/pngcp.c libpng16.so.16 -lz ./pngcp fried_rice.png test.png ``` There's not...

@MrJiangSheng the cmake build system has been considerably updated and, in particular, zlib handling has been modified. Please test the latest libpng version to see if this problem remains.

I wrote it that way for good reasons. The only argument permitted is an lvalue array name. There is some chance that if the macro is abused by a future...

Like I said. To put in another way don't fix things that work.

Silencing a warning by changing the semantics of the code is not correct. The macro requires an argument of type (char{]); find me a place where the macro is used...