FreeRDP/winpr/libwinpr/clipboard/posix.c:397:20: error: conflicting types for ‘basename’
static const char* basename(const char* name)
^
In file included from FreeRDP/winpr/include/winpr/collections.h:25:0,
from FreeRDP/winpr/libwinpr/clipboard/posix.c:37:
/usr/include/string.h:599:14: note: previous declaration of ‘basename’ was here
extern char *basename (const char *__filename) __THROW __nonnull ((1));
Legacy bitmap update might fail with 'fast path update size (xxxxx) exceeds the client's maximum request size (xxxxx)'
Original code might update last fragment with exceeded fragment size incorrectly. Fix the logic to prevent it.
If numWindowRects/numVisibilityRects is zero a realloc might either
return NULL or a free able memory. In the first case the introduced
regression caused a double free.
As 0 is a possible value that can be received in both cases rail was
broken.
Fixes#4022
With some usb barcode scanners, repeated characters do not appear in the freerdp session.
It looks like this is because the KeyRelease signal is not sent for the first character.
Removing this if check fixes the problem.
If the server sends us garbage (or the client provides it) then it is
possible for the multiplication to overflow (as it is performed on
unsigned 32-bit values) which will result in a false positive failure of
the sanity check. Avoid it by rearranging arithmetics a little.
Keep the multiplication in the error message because we are interested
in the number of bytes in the stream and how it compares to the number
we have expected based on the presumed file count.
[libfreerdp/crypto/certificate.c:315] -> [libfreerdp/crypto/certificate.c:316]: (warning) Either the condition 'if(fingerprint&&fprint)' is redundant or there is possible null pointer dereference: fingerprint.
[channels/tsmf/client/tsmf_main.c:89] -> [channels/tsmf/client/tsmf_main.c:95]: (warning) Either the condition '!callback' is redundant or there is possible null pointer dereference: callback.
The data provided by local applications can be actually encoded in
UTF-16 (e.g., Firefox does this to HTML). UTF-16 allows embedded null
bytes so we should not use strlen() to fix up the data. The HTML format
synthesizer can handle trailing null bytes just fine and can detect
whether it deals with UTF-8 or UTF-16.
