| Age | Commit message (Collapse) | Author |
|---|
|
The parameter names were taken from function definitions to update the names in
function declarations (prototypes).
|
|
|
|
Also, no longer #include the group code into tox.c. Instead, compile it
separately in tox_group.c. This is a bit less surprising to someone looking
around the code. Having some implementations in a .h file is certainly a bit
surprising to a disciplined C programmer, especially when there is no technical
reason to do it.
|
|
|
|
These functions simply return the constants. They are a stable ABI, so that if
constants change, the ABI of these functions won't. Code solely relying on these
functions will remain compatible with future values of those constants.
The functions are currently not exposed in tox.h, because this is pending a
change in apidsl to generate accessors for "const" values.
|
|
This removes the global logger (which by the way was deleted when the first tox
was killed, so other toxes would then stop logging). Various bits of the code
now carry a logger or pass it around. It's a bit less transparent now, but now
there is no need to have a global logger, and clients can decide what to log and
where.
|
|
|
|
|
|
|
|
Moved a few #defines to the top of the header for better readability
|
|
See #40 for details.
|
|
This behaviour is consistent with free() and operator delete.
|
|
See #27 and #40 for details.
|
|
**What are we doing?**
We are moving towards stateless callbacks. This means that when registering a
callback, you no longer pass a user data pointer. Instead, you pass a user data
pointer to tox_iterate. This pointer is threaded through the code, passed to
each callback. The callback can modify the data pointed at. An extra indirection
will be needed if the pointer itself can change.
**Why?**
Currently, callbacks are registered with a user data pointer. This means the
library has N pointers for N different callbacks. These pointers need to be
managed by the client code. Managing the lifetime of the pointee can be
difficult. In C++, it takes special effort to ensure that the lifetime of user
data extends at least beyond the lifetime of the Tox instance. For other
languages, the situation is much worse. Java and other garbage collected
languages may move objects in memory, so the pointers are not stable. Tox4j goes
through a lot of effort to make the Java/Scala user experience a pleasant one by
keeping a global array of Tox+userdata on the C++ side, and communicating via
protobufs. A Haskell FFI would have to do similarly complex tricks.
Stateless callbacks ensure that a user data pointer only needs to live during a
single function call. This means that the user code (or language runtime) can
move the data around at will, as long as it sets the new location in the
callback.
**How?**
We are doing this change one callback at a time. After each callback, we ensure
that everything still works as expected. This means the toxcore change will
require 15 Pull Requests.
|
|
We run astyle on Travis and check if there is a diff. The build terminates if
git finds a difference.
|
|
|
|
|
|
|
|
fix: make increment_nonce & increment_nonce_number independent of user-controlled input
fix: make crypto_core more stable agains null ptr dereference
|
|
|
|
|
|
Add a way to select the type of savedata (normal savedata, load a
secret key, potentially others?) to load.
|
|
Removed useless code.
|
|
Functionality of both no longer overlaps.
If address has more than 1 ip, call the internal function on all of them.
|
|
TODO: tell friends we are hosting a relay and prioritize using relays
hosted by friends over bootstrap ones.
|
|
|
|
also removed remnants of the no longer used variable ping_lastrecv
|
|
|
|
Renamed tox_file_send_seek to tox_file_seek.
|
|
other size (except streaming of course).
|
|
any file number for them in core.
These can be used to tell friends we don't have an avatar set or to unset
a set avatar.
|
|
A couple of minor reasons, combined warrant a PR imo:
a) fileChunkRequested is a better signal name than fileRequestChunkReceived, and I don't want to break consistency by reordering words for just this signal
b) "request chunk" is parsed by English speakers as a verb-object combination,
implying sending the request, not receiving, whereas "chunk requested" is
parsed (more correctly) as an adjective-noun combo (in particular, request is
a noun not a verb), and thus reads far more like "hey heads up we just got a request"
For instance some tests/testing code had some callbacks to *receive* chunk requests, and they were called "tox_file_request_chunk"... to receive a chunk, not request it. Now they're called "tox_file_chunk_request".
So yeah...
|
|
new_api
|
|
|
|
messaging function.
This removes code duplication and allows us to easily add new message
types to the api without having to add new functions.
|
|
friend_get_connection_status
|
|
receive to recv in file receive functions.
Added TOX_MAX_FILENAME_LENGTH define.
|
|
|
|
|
|
Make sure some assumptions are always correct.
|
|
|
|
This function can be used to seek an incoming file tranfer right
before accepting it.
It is meant to be used to resume incomplete file tranfers by clients.
|
|
Pointer in callback will be NULL if length is 0.
|
|
file_id is a 32byte identifier that can be used by users to identify
file tranfers across core/client restarts in order to resume broken
file tranfers.
In avatar tranfers it corresponds to the hash of the avatar.
Added tox_file_get_file_id() function to api to obtain the file_id
of an ongoing file transfer.
If not set, core will generate a random one.
|
|
|
|
|
|
first 32 bytes.
Enforce length of filename in core when transfer is an avatar type
transfer to make things more safe.
|
|
|
|
|
|
|
