This removes the dc_context_unref function from the Rust API which was
just an alias for dc_close. It still exists on the C API where it
makes sure to free the memory.
It also implements Drop for the context which just calls dc_close to
make sure all the memory is freed. Since you can call dc_close as
many times as you like this ensures that at the Rust level you can't
Drop the struct without releasing the memory.
Finally since memory is now freed by dropping the struct this removes
the #[repr(C)] for the struct. This struct is fully opaque to the C
API.
This marks the function safe and returns Result, it also now returns
the ConfiguredAddr since it has to look this up anyway and it makes
testing more easy. Turns out it reduces some duplicate SQL query in
some callers too.
More test code has been moved from dc_imex to test_utils as it's
more genrally applicable.
* refactor(contact): rename and rusty memory allocations
* refactor(contact): use enum to indidcate origin
* refactor(contact): safe blocking and unblocking api
* refactor(contact): only safe and no more cstrings
Add a trait for str.strdup() to replace to_cstring() which avoid the
signature ambiguity with .to_string().
Also instruduce CString::yolo() as a shortcut to
CString::new().unwrap() and use it whenever the variable does can be
deallocated by going out of scope. This is less error prone.
Use some Path.to_c_string() functions where possible.
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.
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.
Simon Laux