Condition '!imffields.is_null()' is always true, since it is contained in conditional
if !(in_out_message.is_null() || imffields.is_null()) {
which is equivalent to
if !in_out_message.is_null() && !imffields.is_null() {
Previous version of patch, that changed type of `dc_msg_t.text' to String had
been breaking `prepare_and_send' test in Python.
This commit adds same regression test, reimplemented in Rust, since running
Rust tests is simplier and faster.
With this change, kind of message is represented by value of enum
`Viewtype' instead of raw libc::c_int, providing more type safety. This
enum replaces DC_MSG_* constants. The only way to create `Viewtype' from
libc::c_int is smart constructor.
With this change, functions `dc_get_chat_media' and `dc_get_next_media' became
less forgiving about invalid message type arguments. Previously, invalid
message types were implicitly interpreted as 0 (Viewtype::Unknown). Now,
function calls with invalid message type arguments are rejected (error code
returned) on FFI boundary.
Additionally, when `Viewtype' is read from database, it is checked to have
sensible value.
No tests assumed forgiving behaviour.
This change removes global override of `non_shake_case' warning and replaces it
with per-function overrrides. This way, compiler will complain about style
guide violation in new code.
It should be noted, that `rustc' is not smart enough to emit warning when
override is no longer needed, it must be checked manually.
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.
This patch changes output of following command (from README.md)
$ cargo run --example repl -- /tmp/main.db
from
First time init: creating tables in ""/tmp/main.db""
[...]
Opened ""/tmp/main.db"".
to
First time init: creating tables in "/tmp/main.db"
[...]
Opened "/tmp/main.db".
Note lack of double quotation mark, which was confusing and could have been
interpreted as part of file name.
Previously, dc_send_text_msg() silently returned 0 in case of incorrect
input. This way "send" command in repl reported "Sending failed" without
any clue what exactly went wrong.
Dmitry Bogatov