mallinfo and CONFIG_CAN_PASS_STRUCTS

hi, depending on CONFIG_CAN_PASS_STRUCTS, mallinfo has a different prototype. #ifdef CONFIG_CAN_PASS_STRUCTS struct mallinfo mallinfo(void); #else int mallinfo(FAR struct mallinfo *info); #endif and we have a lot of #ifdef CONFIG_CAN_PASS_STRUCTS for this even in APPDIR. i'd like to suggest

Build failed in Jenkins: NuttX-Nightly-Build #68

See Changes: -- [...truncated 503.84 KB...] Copy files Select CONFIG_HOST_LINUX=y Refreshing... Building NuttX... --

Re: pthread_mutex_lock() and signals

On Wed, Mar 18, 2020 at 1:31 PM Gregory Nutt wrote: > There are some complexities and the possibility to break things. If you > want, you could just create an issue with all of the relevant > information and let it pend of awhile. I don't think there is any rush > to change this behavior, is ther

Build errors with inline functions

Hello, I updated master on my repo yesterday and noticed that I can no longer build STM32H7 or F7 based boards.  The compiler error in question is shown below. For what its worth, I am using standard arm-none-eabi toolchain on Ubuntu Linux. LD: nuttx nuttx/staging/libarch.a(stm32_allocatehea

Re: pthread_mutex_lock() and signals

On Wed, Mar 18, 2020 at 1:31 PM Gregory Nutt wrote: > > To get the behavior POSIX specifies ("If a signal is delivered to a > > thread waiting for a mutex, upon return from the signal handler the > > thread resumes waiting for the mutex as if it was not interrupted.") > > would require additional

Re: pthread_mutex_lock() and signals

To get the behavior POSIX specifies ("If a signal is delivered to a thread waiting for a mutex, upon return from the signal handler the thread resumes waiting for the mutex as if it was not interrupted.") would require additional handling, such as (I'm guessing) checking the cause of the wake-u

Re: pthread_mutex_lock() and signals

On Wed, Mar 18, 2020 at 10:11 AM Gregory Nutt wrote: > >> There is one issue we have to be careful about: pthread > >> _mutex_timedlock(): It needs the signal in order to wake up and return > >> from the wait. pthread_mutex_lock() just calls pthread_mutex_timedlock() > >> with and time value of

Re: pthread_mutex_lock() and signals

There is one issue we have to be careful about: pthread _mutex_timedlock(): It needs the signal in order to wake up and return from the wait. pthread_mutex_lock() just calls pthread_mutex_timedlock() with and time value of NULL. So it is this NULL argument that is passed must cause different