Prevent string slicing inside char boundaries

[pitdicker]

This takes care of the problematic string slicing found in #1010 replay 4.

I believe all string slicing on arbitrary boundaries in this module now happen on u8 slices.

[pitdicker]

The failed CI run is unrelated to this PR.

[djc]

Can you just explain why this fixes it? It's not obvious to me why we even get the incorrect boundaries in there.

[pitdicker]

The pattern in this module is that it takes the length of a possible match, say 5 bytes, and takes a slice of that length from the input (in bytes). The possible match and the slice are then compared case insensitively with the equals function.

For just the comparison we don't care about proper character boundaries, but that means equals should be working on &[u8] instead of &str.

[djc]

Don't we know up front that the "possible match" is up to a valid character boundary?

[pitdicker]

Not with the way the code currently works.

For example https://github.com/chronotope/chrono/blob/main/src/format/scan.rs#L167:

pub(super) fn short_or_long_weekday(s: &str) -> ParseResult<(&str, Weekday)> {
    // lowercased weekday names, minus first three chars
    static LONG_WEEKDAY_SUFFIXES: [&str; 7] =
        ["day", "sday", "nesday", "rsday", "day", "urday", "day"];

    let (mut s, weekday) = short_weekday(s)?;

    // tries to consume the suffix if possible
    let suffix = LONG_WEEKDAY_SUFFIXES[weekday.num_days_from_monday() as usize];
    if s.len() >= suffix.len() && equals(&s[..suffix.len()], suffix) {
        s = &s[suffix.len()..];
    }

    Ok((s, weekday))
}

This will take up to 7 times a slice out of s, with the lengths in bytes of 3, 4, 6, 5, etc. for the possible matches in LONG_WEEKDAY_SUFFIXES. To say it differently, the length of the slice is not determined by the input s, but by the length of the possible match.

[djc]

Thanks!