function `set_global_param()` could panick without pre-checking

[cicilzx]

Hi, I'm developing a fuzzer to test the safe abstraction, and I found a segmentation fault when calling function z3/src/params/set_global_param(). Bellow is a test case:

#[allow(warnings, unused, non_snake_case)]
#[test]
fn test_set_global_param_isH12() {
    let k: String = String::from("\0");
    let v: String = String::from("");
    let _ = set_global_param(k.as_str(), v.as_str());
}

Output:

thread 'params::test_set_global_param_isH12' panicked at z3/src/params.rs:87:30:
called `Result::unwrap()` on an `Err` value: NulError(0, [0])
stack backtrace:
   0: rust_begin_unwind
             at /rustc/d84b9037541f45dc2c52a41d723265af211c0497/library/std/src/panicking.rs:652:5
   1: core::panicking::panic_fmt
             at /rustc/d84b9037541f45dc2c52a41d723265af211c0497/library/core/src/panicking.rs:72:14
   2: core::result::unwrap_failed
             at /rustc/d84b9037541f45dc2c52a41d723265af211c0497/library/core/src/result.rs:1658:5
   3: core::result::Result<T,E>::unwrap
             at /rustc/d84b9037541f45dc2c52a41d723265af211c0497/library/core/src/result.rs:1081:23
   4: z3::params::set_global_param
             at ./src/params.rs:87:14
   5: z3::params::test_set_global_param_isH12
             at ./src/params.rs:132:13
   6: z3::params::test_set_global_param_isH12::{{closure}}
             at ./src/params.rs:129:33
   7: core::ops::function::FnOnce::call_once
             at /rustc/d84b9037541f45dc2c52a41d723265af211c0497/library/core/src/ops/function.rs:250:5
   8: core::ops::function::FnOnce::call_once
             at /rustc/d84b9037541f45dc2c52a41d723265af211c0497/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I guess it's because the unwrap without checking.

[toolCHAINZ]

Thanks for the report!

This is a panic!() though, not a segmentation fault. panic!s definitely aren't ideal but don't represent a safety issue like a segfault would.

This function will be one to keep in mind when we implement #227, as it will be one of many that really should be returning a Result instead of panic!ing.