Compilers allocate some section of memory without using wrapper function,
which is later freed when wrappers were initialized. Since the allocated
memory didn;t contain wrapper header the pointer got corrupt when calling to free.
This implementation of signature addition during malloc and signature check during
free helps in freeing the memory allocated by wrapper functions properly and
also the internal memory allocated by compilers (without malloc wrappers).
malloc guarantees aligned memory. If we add an alignment here, we are adding
additonal unused 4 bytes. Each allocator has its own 4/8 byte header
(GGC / ARM have 4 bytes).
So if user request for 8 bytes of memory stats will add 8 + allocator 8.
However if we remove the alignment in stats header, allocator will consider
add 4 bytes to 12 byte request and zero padding.
It will be beneficial to leave the padding to allocator.
You are allowed in POSIX / ANSI C to read and write on the same stream, but you
have to do an fseek in between read and write call (getc->fseek->putc)
Thanks @Alex-EEE for sharing the fix: https://github.com/ARMmbed/mbed-os/pull/7749
Added test case for verification of the behavior
Heap statistics are used for analysing heap stats, but it doesn't tell anything
about real heap usage or malloc overheads. Adding `overhead_size` element
will help users to get the real heap usage.
Low power Timer is used as RTC for platforms that don't have HW RTC capabilities (like NRF52832).
`_rtc_lpticker_read(void)` function currently uses `Timer::read()` function to trace elapsed time.
`Timer::read()` returns seconds represented as `float` value, but this value is calculated from `int` since `Timer::read_us()` returns `int`.
This limits time tracing to ~35 min.
To fix this problem we will use `timer::read_high_resolution_us()` (which returns unsigned 64 bit value) instead of `Timer::read()`.
Add a config option for the following values:
MBED_SYS_STATS_ENABLED
MBED_STACK_STATS_ENABLED
MBED_CPU_STATS_ENABLED
MBED_HEAP_STATS_ENABLED
MBED_THREAD_STATS_ENABLED
MBED_CONF_APP_MAIN_STACK_SIZE
MBED_CONF_APP_TIMER_THREAD_STACK_SIZE
MBED_CONF_APP_IDLE_THREAD_STACK_SIZE
MBED_CONF_APP_THREAD_STACK_SIZE
To maintain backwards compatibility inside the RTOS both
APP and RTOS config values can be used.
Code had mixed up order of 'c' and 'n' arguments to memset().
Fix this.
Spotted-by: kjbracey-arm & a GCC profile without "-fno-builtin"
Related GCC warnings:
---8<---8<----
[Warning] mbed_error.c@123,5: 'memset' used with constant zero length parameter; this could be due to transposed parameters [-Wmemset-transposed-args]
[Warning] mbed_error.c@282,5: 'memset' used with constant zero length parameter; this could be due to transposed parameters [-Wmemset-transposed-args]
Sometimes you want don't want to directly call a method on your
SingletonPtr-wrapped object, but you want to pass it to something
else.
For example
SingletonPtr<PlatformMutex> mutex;
mutex->lock();
is fine, but what about
SingletonPtr<PlatformMutex> mutex;
ScopedLock<PlatformMutex> lock(*mutex.get());
Add an overload for operator* to make this more elegant:
SingletonPtr<PlatformMutex> mutex;
ScopedLock<PlatformMutex> lock(*mutex);
This addition is consistent with standard C++ classes such as
`unique_ptr` and `shared_ptr`, which likewise have
get, operator-> and operator*.
Copy construction between Span of compatible type is allowed to fulfil the use
case Span<T> -> Span<const T>. This is achieved by a templated copy constructor
like constructor.
In p0122, the overload is discarded from the constructor set if the ElementType
of the Span in input is not convertible into the ElementType of the Span being
constructed.
To discard function overload, SFINAE has to be used which polutes the documentation
and make the code harder to read and maintain.
Unlike p0122, our Span class doesn't exposes (yet) functions with default argument
or functions that convert container in input into span the only overload with the
a single parameter that we exposes are:
- template<size_t N> Span(ElementType (&element)[N])
- Span(const Span& other): <- generated by the compiler.
For both of this functions we expect exact match and their resolution should not
interfere with the constructor that converts from another type of Span.
As a result it is possible to rely solely on C++ default resolution rules as we
won't hit cases were constructors convert from another type (std::array, std
container, span) and raise an error with a static assert if the element type
can't be converted.
If another copy - conversion - constructor is added then SFINAE has to be
reintroduced.