* use x_rpcbuf_t for reply payload assembly and byte-swap
* do byte-swap of header fields explicitly instead of cryptic functions
* drop extra length computation
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use x_rpcbuf_t for reply payload assembly and byte-swap
* do byte-swap of header fields explicitly instead of cryptic functions
* drop extra length computation
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use x_rpcbuf_t for reply payload assembly and byte-swap
* do byte-swap of header fields explicitly instead of cryptic functions
* drop extra length computation
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Fix compiler warnings by explicit type casts.
In this case, we know that those values can't be bigger than int can take,
neither become negative.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use explicit cast to match WriteToClient()'s expectation and
return ssize_t, as coming from WriteToClient()
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The 2nd loop is supposed to free the privates and also clear the pointer
to them. But it instead of clearing the walk'ed pointer, it only clears
the one in the last screen left from the upper loop.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The client index (in the client table) can never be negative, thus
make it an unsigned short.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
If we've already got the ScreenPtr, there's no need to retrieve it again
via the screen number, which we're getting via the ScreenPtr that we've
already got.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use the payload size from the rpcbuf, but also compare that with our
computation as sanity check and log error on mismatch.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead doing an exrtra loop for our own calculation of the
payload size, just the wpos from rpcbuf.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
In preparation for subsequent refactoring, assembling the reply header
at once, instead of doing it piece by pice.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The payload length is already known after writing everything to the
buffer, so no need for extra size computation anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Preparation for subsequent changes: instead of returning early when no
payload to send, move that into a conditional block.
(the WriteRpcbufToClient() call on potentially empty buffer is intentional)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
As a prepration for upcoming changes, move assembly of the the reply
header further downwards where all values are already known, so we'll
have to touch it only once. Also eliminate the separate write path for
the case where Xv is disabled.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
For easier understanding the code, declare the variables right where
they're assigned first.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use x_rpcbuf_t for reply payload assembly and byte-swap
* do byte-swap of header fields explicitly instead of cryptic functions
* drop extra length computation
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function was badly broken, among other things doing a
use after free, a NULL-pointer dereferrence, and not doing
what it was supposed to do.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
Flushclient implicitly cast the result from a write-like call
to size_t, which turned it's error return value, -1,
into a large positive value, breaking the surrounding error-checking code.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
Since FlushClient only writes the data in the client's buffer,
with no extra data or padding, we only write at most as many bytes
as there are in the client buffer.
we just have to set oco->count to notWritten, the amount we still
have to write.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
