Re: [png-mng-implement] Macros to be discarded in 1.4

[Greg R. <ne...@po...>]

Cosmin wrote:

> I realize that perhaps not everyone will like my proposal, and I'm
> okay with that. But at the very least, I'd like to see some of the
> PNG_FOO_SUPPORTED permanently supported in libpng 1.4, and, for the
> future, to not accompany every single new PNG_BAR_SUPPORTED with
> PNG_NO_BAR, unless deemed necessary.

I don't agree with your proposal to start using loops in lieu of memset(),
but I'm completely in agreement with this.  I'd be willing to bet that
at least 30% of the _single_ PNG_NO_FOO macros are currently broken, and
I'd guess it's quite a bit over 50% when you consider all possible build
options.  It's certainly not tested at anywhere close to those numbers
(even building--it would be relatively trivial to set up an automated
regression suite with separate builds for every possible single-macro
option and perhaps for all pairwise options, but I don't believe anyone
has ever done this).  In short, the macro explosion adds a huge amount
of code complexity, a corresponding number of bugs, and I honestly don't
believe there's _any_ benefit to 90% of it.

Maintainability is _critical_ in a core system library like libpng, so
let's start whacking unreasonable macros and make the code cleaner, simpler,
and more modern.  I was (and am) a staunch supporter of portability, but
even I draw the line right around 15 years.  In particular, there's no
longer a need for pre-ANSI support, and that in turn means we can assume
the existence of most things in the standard C library (except where known
to be missing/broken on a notable platform, but I'd bet even that phenomenon
is pretty rare over the last decade).

Greg

P.S.  I'd still argue for a completely opaque png_struct with internal
      png_info structs, too, but I still don't have time to work on that
      myself.