Inconsistent usage of local variable chunk_name

[irwir]

libpng/pngpread.c

Line 210 in 51f5bd6

chunk_name = png_ptr->chunk_name;

This variable is used in the long chain of if-else-if statements.
However, sometimes conditions still refer to png_ptr->chunk_name as in line 289 .
Also, switch statement should be preferable here (and in other similar places too) as more readable and often more efficient.

[jbowler]

cf Chris Lilley's comments here:

https://lists.w3.org/Archives/Public/public-png/2025Jan/0023.html

My response was sent directly to Chris, a mighty dude. But, summarised; live with it or maintain it. He has stepped up, despite his lofty status he has actually created a fork of the similarly unenlightened code and is now maintaining it.

Don't criticise, fork, and if you can't fork pull [request].

[jbowler]

@ctruta: somewhat entertainingly it happened here:

bb5cb14

Now who did that? There are, of course, only two candidates and Glenn was not known for CSE. It's a "bad" CSE because png_ptr is a restrict pointer in 1.6 and the only function call which may return outside the if else pseudo switch is the call to png_benign_error at the end of the preceding if.

Consider what happens if png_benign_error returns at that point. Unless I'm mistaken the IDAT gets handled as "unknown". (I may very well be mistaken and I certainly don't know what the infinitely complex three (IRC) APIs for unknown handling do.)

My attitude to code like this has always been to rewrite it, so I guess I'm agreeing with Chis Lilley at this point.

[jbowler]

@ctruta, @irwir, @svgeesus I have a change (tested) that completely eliminates this problem along with an enormous amount (based on LoC) of duplicated code.

I won't push it yet because I did it as part of the libpng PNGv3 conformance work and the next step - handling the precedence rules for colour space - is a little more tricky (to say the least :-) It's also more important since at present libpng completely and utterly violates the new rules.

[jbowler]

Resolved (incidentally) by #645 - there's no if/else, there's no switch, there's no difficult to determine # table either. :-) Let the compiler do it.