With this change, passing invalid utf8 string to `dc_send_text_msg' does not
crash application, it prints warning and returns error code.
It should be admitted that this fix is sub-optimal: if input C string is valid
utf8 (which is likely), result of successful conversion to `&str' is discarded
in `dc_send_text_msg', and the same input C string is converted again with
`as_str' in `prepare_msg_raw'.
It is not clear how to fix it in non-disruptive way, since input C string is
passed down to call stack as part of `dc_msg_t' struct, which is part of C ABI.
This new command attempts to send malformed utf8 string to current chat with
dc_send_text_msg() function. Currently, instead of error code it causes
application crash with following backtrace:
thread 'main' panicked at 'Non utf8 string: '[255]' (Utf8Error { valid_up_to: 0, error_len: Some(1) })', src/dc_t
ools.rs:1571:9
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/libunwind.rs:88
1: backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:47
3: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:36
4: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:200
5: std::panicking::default_hook
at src/libstd/panicking.rs:214
6: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:477
7: std::panicking::continue_panic_fmt
at src/libstd/panicking.rs:384
8: std::panicking::begin_panic_fmt
at src/libstd/panicking.rs:339
9: deltachat::dc_tools::as_str::{{closure}}
at src/dc_tools.rs:1571
10: core::result::Result<T,E>::unwrap_or_else
at /rustc/0b680cfce544ff9a59d720020e397c4bf3346650/src/libcore/result.rs:818
11: deltachat::dc_tools::as_str
at src/dc_tools.rs:1570
12: deltachat::dc_chat::prepare_msg_raw
at src/dc_chat.rs:726
13: deltachat::dc_chat::prepare_msg_common
at src/dc_chat.rs:461
14: deltachat::dc_chat::dc_send_msg
at src/dc_chat.rs:905
15: deltachat::dc_chat::dc_send_text_msg
at src/dc_chat.rs:981
16: repl::cmdline::dc_cmdline
at examples/repl/cmdline.rs:955
17: repl::handle_cmd
at examples/repl/main.rs:566
18: repl::main_0
at examples/repl/main.rs:445
19: repl::main
at examples/repl/main.rs:578
20: std::rt::lang_start::{{closure}}
at /rustc/0b680cfce544ff9a59d720020e397c4bf3346650/src/libstd/rt.rs:64
21: std::rt::lang_start_internal::{{closure}}
at src/libstd/rt.rs:49
22: std::panicking::try::do_call
at src/libstd/panicking.rs:296
23: __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:82
24: std::panicking::try
at src/libstd/panicking.rs:275
25: std::panic::catch_unwind
at src/libstd/panic.rs:394
26: std::rt::lang_start_internal
at src/libstd/rt.rs:48
27: std::rt::lang_start
at /rustc/0b680cfce544ff9a59d720020e397c4bf3346650/src/libstd/rt.rs:64
28: main
29: __libc_start_main
30: _start
This change replaces calls to unwrap() function with "?" operator, propagating
error up the call stack. This way "chat foo" (for example) command results in
Error: invalid digit found in string
message instead of crashing whole repl.
Previously, just pressing "<Enter>" at prompt resulted in following error
message:
Error: Unknown command: "" type ? for help.
This message is harmless, but useless. Also, such behaviour is different from
many (if not all) interactive environments: python, bash, dash, ...
With this change empty input string is silently ignored.
