| Age | Commit message (Collapse) | Author |
|---|
|
Tokstyle (check-cimple) will start enforcing comment formats at some
point. It will not support arbitrary stuff in comments, and will parse
them. The result can then be semantically analysed.
|
|
|
|
Using ~0 involves a bitwise operation on int, so depends on
the internal representation of signed integers.
|
|
|
|
|
|
|
|
- Bump FreeBSD to 12.1.
- Simplify stage1 logic.
- Re-try downloading the image from a different mirror if one fails.
- Use the `expect` utility instead of dealing with screen's log file.
- Re-run failed toxcore test one more time and in sequence.
|
|
We don't expose this to the user code, yet, because it would break the
API, but this is useful for future internal code.
|
|
The current code violates the C standard and causes crashes on strict
alignment architectures.
|
|
|
|
The latter is doing pretty much the same thing but in a confusing way (it
doesn't change the type of the variable, but does change the semantics).
|
|
|
|
|
|
|
|
It's a maintenance burden. Nobody uses this. It depends on an ancient
version of opencv that less and less systems actually have.
|
|
|
|
|
|
Removed av_test, because it depends on an ancient opencv that starts to
really not exist on modern systems anymore.
|
|
|
|
Put a future message number into the save file.
Peers require the message numbers of messages we send to increase
monotonically. If we save the current message number, then send further
messages, then quit without saving (e.g. due to a crash), and then
resume from the old save data, then monotonicity will fail. This commit
works around this problem by introducing an offset when the current
message number, so that even in the above circumstance, as long as fewer
messages than the offset were sent between saving and reloading, the
sent message numbers will increase monotonically.
The choice of offset is a balance between wanting it to be large enough
that there is room for plenty of messages to be sent in the above
scenario, and wanting to avoid the following potential problem: if we
repeatedly save and reload without sending any further messages, then
the message number may increase so far that peers will interpret an
eventual message as being old. This is not conceivably a practical issue
for the 32bit lossless message numbers, but is a concern for the 16bit
lossy message numbers.
|
|
|
|
ToxAV is not thread-safe at the moment, remove that claim from the
header file.
|
|
|
|
When tox_kill is called no other thread should be running anymore so
this locking is not needed there.
|
|
- Moving a pthread_mutex in memory (e.g. via realloc()) is undefined
behavior.
- add a state for allocated but not yet used crypto connections
- change crypto_connection_status signature
|
|
|
|
|
|
|
|
|
|
|
|
* unset global status callback in kill_groupchats
* avoid dangling friend connections
* fix num_introducer_connections leak
* stop trying to keep connection alive on freeze
* avoid relaying lossless messages back to sender where possible
* avoid sending gratuitous online packets
|
|
|
|
|
|
|
|
This could make mono_time loose overflows on Windows.
|
|
Since mono_time is accessed from the main thread as well as the toxav
thread it is needed to properly lock time updates.
|
|
|
|
This fixes a buffer overflow when a malformed *.tox save file is
loaded.
|
|
|
|
|
|
|
|
|
|
This fixes an redefinition error when creating amalgamation.cc during
static analysis
|
|
The test's intermittent failure may well be exposing a real bug in the
TCP relay and/or onion systems, but we can't find the bug, and keeping
the test is disrupting our CI.
|
|
To make this reproducible. With floating versions (always latest), this
can break any time a new bazel version is released.
|
|
|
|
|
|
|
|
A group loaded from a savefile starts with AV disabled.
|
|
|
