ascii_i32 fallback only works on valid UTF-8

[inferiorhumanorgans]

https://git.sr.ht/~az1/iso9660-rs/commit/47258d9499bce1b5cd7327e59367b66744f6a6a9.patch

From 47258d9499bce1b5cd7327e59367b66744f6a6a9 Mon Sep 17 00:00:00 2001
Date: Thu, 31 Aug 2023 13:18:10 -0700
Subject: [PATCH] ascii_i32: Treat zero-filled data as '0'.

This allows ascii_i32 to fall back on the default values for each date
component.  This allows iso9660 to parse this image:

https://archive.org/details/nokia-6210
---
 src/parse/date_time.rs | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/src/parse/date_time.rs b/src/parse/date_time.rs
index 7ff19f3..a9f0b45 100644
--- a/src/parse/date_time.rs
+++ b/src/parse/date_time.rs
@@ -1,7 +1,9 @@
 // SPDX-License-Identifier: (MIT OR Apache-2.0)
 
-use nom::bytes::complete::take;
-use nom::combinator::map_res;
+use nom::branch::alt;
+use nom::bytes::complete::{tag, take};
+use nom::combinator::{map_res, value};
+use nom::multi::count;
 use nom::number::complete::le_u8;
 use nom::sequence::tuple;
 use nom::IResult;
@@ -34,7 +36,12 @@ pub fn date_time(i: &[u8]) -> IResult<&[u8], OffsetDateTime> {
 }
 
 fn ascii_i32(n: usize) -> impl Fn(&[u8]) -> IResult<&[u8], i32> {
-    move |i: &[u8]| map_res(map_res(take(n), str::from_utf8), str::parse::<i32>)(i)
+    move |i: &[u8]| {
+        alt((
+            map_res(map_res(take(n), str::from_utf8), str::parse::<i32>),
+            value(0, count(tag(b"\0"), n)),
+        ))(i)
+    }
 }
 
 pub fn date_time_ascii(i: &[u8]) -> IResult<&[u8], OffsetDateTime> {

[ids1024]

So this ISO has some kind of invalid bytes sequence in place of the date?

I wonder how other implementations handle this sort of thing.

[inferiorhumanorgans]

Yes. There's a link to the image above. It mounts on OSX, I've not tested any other operating systems. It's worth noting though that UTF-8 non-digit characters would already fall through to the default date (when perhaps they ought not). This just accepts an empty field (all zeroes) as well.

[inferiorhumanorgans]

Also, this is more or less the same issue as #8.