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.
- remove usage of "attr.s" across the code
- make msg.set_file() copy a file into blobdir if it isn't already
- regroup tests
- add set_draft/get_draft API
pattern -- re-indentation will come after this commit with a pure application of "cargo fmt"
- bring back comment from C code
- make some path helpers return bool
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.
dc_location_t is an incomplete copy of _dc_location
The difference is that it lacks `int independent` field.
As a result, calloc did not allocate memory for this field.
deltachat-core (C version) has only one dc_location_t, that includes the last field.
This is writes pkg-config/deltachat.pc file in the target directory,
using the PREFIX environment variable at build time. If this is
undefined at build time /usr/local is used.
For a few of the locations where error handling is done correctly this
does the right thing. For most other places it gracefully ignores any
issues which is what the original code did as well. Errors are
already logged by the called functions in those cases.
- Pass extra_link_args when using an installed libdeltachat
- Allow setting the liveconfig by envvar
- Show lifeconfig path in the pytest summary line
- Pass required envvars through tox
- Fix broken liveconfig passing in run-integration-test.sh
PEP-0394 (https://www.python.org/dev/peps/pep-0394/) recommends to use more specific shebangs.
For example, Debian allows /usr/bin/python to be configured to python2 via `update-alternatives python`, but the script does not work with Python 2.
