panic in version 0.5 when no problem in 0.4

[mark-summerfield]

This may not be a bug at all.

When I run my application using widestring 0.4 it works fine. But with 0.5 it crashed:

V:\myapp>rustc -V
rustc 1.56.0 (09c42c458 2021-10-18)

V:\myapp>\test.exe
thread 'main' panicked at 'range end index 18446744073709551615 out of range for slice of length 0', C:\Use
rs\mark\.cargo\registry\src\github.jparrowsec.cn-1ecc6299db9ec823\widestring-0.5.0\src\ucstring.rs:119:15
stack backtrace:
   0:        0x13fd17c60 - std::sys_common::backtrace::_print::impl$0::fmt
                               at /rustc/09c42c45858d5f3aedfa670698275303a3d19afa\/library\std\src\sys_common\backtrace.rs:46
   1:        0x13fcf25fa - core::fmt::write
                               at /rustc/09c42c45858d5f3aedfa670698275303a3d19afa\/library\core\src\fmt\mod.rs:1150
   2:        0x13fd175a8 - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
                               at /rustc/09c42c45858d5f3aedfa670698275303a3d19afa\/library\std\src\io\mod.rs:1667
   3:        0x13fd16cfd - std::panicking::rust_panic_with_hook
                               at /rustc/09c42c45858d5f3aedfa670698275303a3d19afa\/library\std\src\panicking.rs:624
   4:        0x13fd1ded5 - std::panicking::begin_panic_handler::closure$0
                               at /rustc/09c42c45858d5f3aedfa670698275303a3d19afa\/library\std\src\panicking.rs:521
   5:        0x13fd1de49 - std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure$0,never$>
                               at /rustc/09c42c45858d5f3aedfa670698275303a3d19afa\/library\std\src\sys_common\backtrace.rs:141
   6:        0x13fd1de04 - std::panicking::begin_panic_handler
                               at /rustc/09c42c45858d5f3aedfa670698275303a3d19afa\/library\std\src\panicking.rs:517
   7:        0x13fd30280 - core::panicking::panic_fmt
                               at /rustc/09c42c45858d5f3aedfa670698275303a3d19afa\/library\core\src\panicking.rs:101
   8:        0x13fd30387 - core::slice::index::slice_end_index_len_fail
                               at /rustc/09c42c45858d5f3aedfa670698275303a3d19afa\/library\core\src\slice\index.rs:41
   9:        0x13fce6089 - __acrt_rg_country_count
  10:        0x13fce1006 - __acrt_rg_country_count
  11:        0x13fcf110d - main
  12:        0x13fd23a35 - __scrt_common_main_seh
                               at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253
  13:         0x76e0571d - BaseThreadInitThunk
  14:         0x7706385d - RtlUserThreadStart

Unfortunately, this does not appear to give me any clue as to which widestring function is failing.
In my code I use only two widestring functions, WideCString::from_ptr_str and
WideCString::from_str. The former is only used inside one function:

pub fn str_for_win16(p: *const Wchar) -> String {
    if p.is_null() {
        return String::new();
    }
    unsafe { WideCString::from_ptr_str(p).to_string_lossy() }
}

The docs say that WideCString::from_ptr_str will panic if the pointer is null, but as you can see I always avoid this.

However, I use WideCString::from_str in many places and it turned out that one of these uses was the problem for me. The solution I applied was to replace from_str with from_str_truncate. This changed all my failing tests to passes when using widestring 0.5.

[VoidStarKat]

Yup, this is indeed a new bug in from_str (or rather, from_vec, which is called by from_str), specifically with 0-length strings/vectors. I'll get a fix out

[VoidStarKat]

0.5.1 has been published with this fix