If the FileBase::lookup operation in the constructor of FilePath returns
NULL, subsequent operations (such as isFile()/isFileSystem()) will call
methods on a NULL 'fb' pointer. This commit fixes this issue by adding
explicit NULL checks and a new method in FilePath (exists()).
I verified that the hang issue I was seeing when building and running
the mbed official networking tests with GCC_ARM was related to this
issue reported on the mbed forums:
http://mbed.org/forum/mbed/topic/3803/?page=1#comment-18934
If you are using the 4.7 2013q1 update of GCC_ARM or newer then it
will have a _sbrk() implementation which checks the new top of heap
pointer against the current thread SP, stack pointer.
See this GCC_ARM related thread for more information:
https://answers.launchpad.net/gcc-arm-embedded/+question/218972
When using RTX RTOS threads, the thread's stack pointer can easily
point to an address which is below the current top of heap so this
check will incorrectly fail the allocation.
I have added a _sbrk() implementation to the mbed SDK which checks the
heap pointer against the MSP instead of the current thread SP. I have
only enabled this for TOOLCHAIN_GCC_ARM as this is the only GCC based
toolchain that I am sure requires this.
These were done to silence GCC warnings and fix potential bugs where
they would never be equal when the enumeration wasn't a 32-bit type.
For example, common/pinmap_common.c used to contain this code:
if (pin == (uint32_t)NC)
I switched it to:
if (pin == (PinName)NC)
I wonder why this casting to uint32_t was done in the first place?
Maybe another supported compiler requires it?
- rename stdio.cpp to retarget.cpp, since it doesn't contain only stdio-related
code
- move __cxa_pure_virtual from exit.c to retarget.cpp where it belongs.
Now the I2C send/receive functions in the mbed HAL return the number of
bytes actually transferred or an error code (a negative value). The
public API remains unchanged.
Bogdan Marinescu
Adam Green
Bogdan Marinescu
Matthew Else
Joris Aerts
Emilio Monti
Joe Turner