Please review this test-only PR which introduces a test for an edge case in `ZipFile.Source.findEND`.
ZIP files may some times have bytes padded to them after the fixed-size END header. This may be bytes of the comment or just unrelated bytes. Because of this ,`ZipFile.Source.findEnd()` parses the ZIP file in a "backwards" manner, looking for ENDSIG sequences indicating that a candidate END header is found. If the position of the candidate END header and its declared comment length do not match up with the actual ZIP file length, this indicates padded bytes. In this case, `findEND()` will sanity check that the candidate END header points to LOCOFF and CENOFF positions which actually have the expected LOCSIG and CENSIG bytes. The case where a candidate END header is valid but has 'unexpected' bytes padded after it is currently tested by `ReadZip::bytesPaddedAtEnd`. However, there is no current testing for the case where an unrelated `ENDSIG` byte sequence is present in the padded bytes and the sanity check of the LOCOFF and CENOFF contents fails. This is edge case is propably rare in the real world, but it would still be nice to have an automated test of this scenario. ------------- Commit messages: - Update copyright year - Add test for skipping unrelated ENDSIG bytes while looking for the "real" END header Changes: https://git.openjdk.org/jdk/pull/29740/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29740&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377978 Stats: 33 lines in 1 file changed: 32 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29740/head:pull/29740 PR: https://git.openjdk.org/jdk/pull/29740
