We've been using standard C library functions `memcpy`/`memset` for these since
2016 with 67f65f6639.
There was still the possibility for third-party platform ports to override the
definitions with a custom header, but this doesn't seem useful anymore.
Backport of #48239.
Happy new year to the wonderful Godot community!
2020 has been a tough year for most of us personally, but a good year for
Godot development nonetheless with a huge amount of work done towards Godot
4.0 and great improvements backported to the long-lived 3.2 branch.
We've had close to 400 contributors to engine code this year, authoring near
7,000 commit! (And that's only for the `master` branch and for the engine code,
there's a lot more when counting docs, demos and other first-party repos.)
Here's to a great year 2021 for all Godot users 🎆
(cherry picked from commit b5334d14f7)
See #43689.
Also 'fixed' some spelling for behavior in publicly visible strings.
(Sorry en_GB, en_CA, en_AU, and more... Silicon Valley won the tech spelling
war.)
(cherry picked from commit a655de89e3)
Happy new year to the wonderful Godot community!
We're starting a new decade with a well-established, non-profit, free
and open source game engine, and tons of further improvements in the
pipeline from hundreds of contributors.
Godot will keep getting better, and we're looking forward to all the
games that the community will keep developing and releasing with it.
The misterious windows networking stack...
Using connect instead of WSAConnect causes socket error 10022 under
certain conditions.
See: https://github.com/godotengine/webrtc-native/ (issue 6)
Having to guess, code path for connect is different then WSAConnect with
NULL extra parameters.
The only reference about weird error with this code mentions something
called "Windows Filtering Platform" but windows internals are, as
always, obscure.
This might be something to try and report to Microsoft if anyone has the
time to spare with the likely outcome of being ignored.
On Unix systems, sockets are like file descriptors, and file descriptors
are usually shared among child processes.
This means, that if we spawn a subprocess (or we fork) like we do in the
editor, open file descriptors will leak to the new process.
This causes issue with sockets as they might remain open and bound
(listening) when the original process closes.
Warnings raised by Emscripten 1.38.0 and MinGW64 5.0.4 / GCC 8.3.0.
JS can now build with `werror=yes warnings=extra`.
MinGW64 still has a few warnings to resolve with `warnings=extra`,
and only one with `warnings=all`.
Part of #29033 and #29801.
Fixes the following GCC 5 warnings and actual bugs:
```
drivers/unix/net_socket_posix.cpp:562:28: warning: comparison between 'enum IP::Type' and 'enum NetSocket::Type' [-Wenum-compare]
modules/gdscript/gdscript_function.cpp:792:26: warning: comparison of constant '17' with boolean expression is always true [-Wbool-compare]
modules/gdscript/gdscript_function.cpp:792:26: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
modules/gdscript/gdscript_parser.cpp:5082:58: warning: comparison of constant '6' with boolean expression is always false [-Wbool-compare]
modules/gdscript/gdscript_parser.cpp:5082:58: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
modules/mbedtls/stream_peer_mbed_tls.cpp:286:45: warning: comparison between 'enum StreamPeerTCP::Status' and 'enum StreamPeerSSL::Status' [-Wenum-compare]
modules/mbedtls/stream_peer_mbed_tls.cpp:313:45: warning: comparison between 'enum StreamPeerTCP::Status' and 'enum StreamPeerSSL::Status' [-Wenum-compare]
```
Since Windows 2000:
Calling recv/recvfrom when an ICMP reply was received from a previous
send/sendto, may result in a WSAECONNRESET error.
Since Windows Vista(?)/Windows Server 2008:
Calling recv/recvfrom when an ICMP reply was received from a previous
send/sendto, may also result in a WSAENETRESET error.
Both those features are disabled by this commit using disabling
SIO_UDP_CONNRESET and SIO_UDP_NETRESET on newly created UDP sockets.
WSAPoll is broken by design.
It was announced as the new way to introduce compatibility to posix
sockets, their implementation was broken, and they decided not to fix it.
You can read the full story here:
https://daniel.haxx.se/blog/2012/10/10/wsapoll-is-broken/
Unified BSD and Winsock sockets into a single implementation of a
generic NetSocket interface.
This is some ground work for few network improvements:
- Reuse as much code as possible between Posix and Windows.
- Provide a single point of implementation for exotic sdks (consoles).
- Provide platform agnostic StreamPeerTCP and PacketPeerUDP in core.
- Implement connect for UDP allowing for DTLS implementation.
