This currently does not work, in particular resulting in scripting
raising an internal error on stop because it doesn't think all the
memory is freed because the allocated counter doesn't start out at zero
because the zero on allocation behavior is broken.
Cygwin has some support for overriding `malloc`
(https://cygwin.com/faq/faq.html#faq.programming.own-malloc), but when
this is attempted some logic in the runtime detects this case then
forwards all allocator calls (`free`/`calloc`/etc.) to the user provided
allocation functions. If only `malloc` is overridden, the other
functions just call themselves recursively until the stack overflows.
There is no supported way to use the original Cygwin allocator while
overriding `malloc`, but we do not want to include our own allocator
just for Cygwin.
Fortunately, in some sense, there is an unsupported way, and our goal
can be achieved by overwriting an internal pointer with our `malloc`
implementation after the Cygwin runtime logic checks and believes that
no overwrite has occurred, thereby never enabling the redirection and
allowing non-`malloc` functions to still work. Our version then calls
`calloc` to do the allocation and zeroing. Note that the old wrap of
`_malloc_r` was faulty as that symbol is no longer used by newlib; it's
just `#define`d to `malloc` these days.
Tested that at least the scripting issue is fixed by failing to
replicate it, plus tracing execution with `gdb` to confirm that our
wrapper function is executed and does its job.
The correct solution is to not make ArduPilot call `malloc` at all. We
still cannot safely change the semantics to make it returned zeroed
memory. This is quite the hack!
* named differently to emphasize different behavior
* always properly zeros newly available memory including trailing bytes
* fully defines new_size == 0
* always allocating and copying matches all existing implementations
except linux, so performance and memory usage won't be affected
This commit changes the way libraries headers are included in source files:
- If the header is in the same directory the source belongs to, so the
notation '#include ""' is used with the path relative to the directory
containing the source.
- If the header is outside the directory containing the source, then we use
the notation '#include <>' with the path relative to libraries folder.
Some of the advantages of such approach:
- Only one search path for libraries headers.
- OSs like Windows may have a better lookup time.