This patch allows to use lwIP as the implementation of the usocket module,
instead of the existing socket-multiplexer that delegates the entire TCP/IP
layer to the NIC itself.
This is disabled by default, and enabled by defining MICROPY_PY_LWIP to 1.
When enabled, the lwIP TCP/IP stack will be included in the build with
default settings for memory usage and performance (see
lwip_inc/lwipopts.h). It is then up to a particular NIC to register itself
with lwIP using the standard lwIP netif API.
Without this, if GC threshold is hit and there is not enough memory left to
satisfy the request, gc_collect() will run a second time and the search for
memory will happen again and will fail again.
Thanks to @adritium for pointing out this issue, see #3786.
Under ubsan, when evaluating hash(-0.) the following diagnostic occurs:
../../py/objfloat.c:102:15: runtime error: negation of
-9223372036854775808 cannot be represented in type 'mp_int_t' (aka
'long'); cast to an unsigned type to negate this value to itself
So do just that, to tell the compiler that we want to perform this
operation using modulo arithmetic rules.
Before this, ubsan would detect a problem when executing
hash(006699999999999999999999999999999999999999999999999999999999999999999999)
../../py/mpz.c:1539:20: runtime error: left shift of 1067371580458 by
32 places cannot be represented in type 'mp_int_t' (aka 'long')
When the overflow does occur it now happens as defined by the rules of
unsigned arithmetic.
When computing e.g. hash(0.4e3) with ubsan enabled, a diagnostic like the
following would occur:
../../py/objfloat.c:91:30: runtime error: shift exponent 44 is too
large for 32-bit type 'int'
By casting constant "1" to the right type the intended value is preserved.
Fuzz testing combined with the undefined behavior sanitizer found that
parsing unreasonable float literals like 1e+9999999999999 resulted in
undefined behavior due to overflow in signed integer arithmetic, and a
wrong result being returned.
There is no need to use the mp_int_t type which may be 64-bits wide, there
is enough bit-width in a normal int to parse reasonable exponents. Using
int helps to reduce code size for 64-bit ports, especially nan-boxing
builds. (Similarly for the "dig" variable which is now an unsigned int.)
Calling memset(NULL, value, 0) is not standards compliant so we must add an
explicit check that emit->label_offsets is indeed not NULL before calling
memset (this pointer will be NULL on the first pass of the parse tree and
it's more logical / safer to check this pointer rather than check that the
pass is not the first one).
Code sanitizers will warn if NULL is passed as the first value to memset,
and compilers may optimise the code based on the knowledge that any pointer
passed to memset is guaranteed not to be NULL.
This patch makes it so that UART(0) can by dynamically attached to and
detached from the REPL by using the uos.dupterm function. Since WebREPL
uses dupterm slot 0 the UART uses dupterm slot 1 (a slot which is newly
introduced by this patch). UART(0) must now be attached manually in
boot.py (or otherwise) and inisetup.py is changed to provide code to do
this. For example, to attach use:
import uos, machine
uart = machine.UART(0, 115200)
uos.dupterm(uart, 1)
and to detach use:
uos.dupterm(None, 1)
When attached, all incoming chars on UART(0) go straight to stdin so
uart.read() will always return None. Use sys.stdin.read() if it's needed
to read characters from the UART(0) while it's also used for the REPL (or
detach, read, then reattach). When detached the UART(0) can be used for
other purposes.
If there are no objects in any of the dupterm slots when the REPL is
started (on hard or soft reset) then UART(0) is automatically attached.
Without this, the only way to recover a board without a REPL would be to
completely erase and reflash (which would install the default boot.py which
attaches the REPL).
Add CONFIG_NET_DHCPV4, which, after
https://github.com/zephyrproject-rtos/zephyr/pull/5750 works as follows:
static addresses are configured after boot, and DHCP requests are sent
at the same time. If valid DHCP reply is received, it overrides static
addresses.
This setup works out of the box for both direct connection to a
workstation (DHCP server usually is not available) and for connection
to a router (DHCP is available and required).
Damien George
Daniel Shaulov
Jeff Epler
Paul Sokolovsky
Keith Wiley