newlib, FreeRTOS, reentrancy, heap and related questions

On Friday, February 7, 2020 at 8:31:10 AM UTC-5, pozz wrote:
> After your considerations, why use a printf that uses heap? There are 
> other good implementations that don't use heap at all and so are 
> intrinsically thread-safe.

There's a list of alternate printf implementations on my web page you referenced. Other library functions like strtok use malloc and friends.
Again, whatever you do, check the map and MAKE SURE you don't accidentally
drag in non-thread-safe uses of library malloc family...

Hope that helps,
Best Regards, Dave

David Brown <david.brown@hesbynett.no> writes:
> The point is that because the compiler knows what malloc and free do -
> they are specified in the standards - it can use that knowledge for
> optimisation.

In this case it has accessed unallocated memory.  I wonder if there is
an exploit.  Hmm.

On 07/02/2020 17:00, Paul Rubin wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> The point is that because the compiler knows what malloc and free do -
>> they are specified in the standards - it can use that knowledge for
>> optimisation.
> 
> In this case it has accessed unallocated memory.  I wonder if there is
> an exploit.  Hmm.
> 

No, it hasn't accessed unallocated memory at all.  It did not access 
anything.

The compiler could see that either the malloc worked fine and the result 
would be the value 6, or the malloc would fail (and return 0) in which 
case the program would have undefined behaviour (accessing a null 
pointer).  The compiler can assume that the programmer doesn't care what 
happens when executing undefined behaviour, and thus giving a result of 
6 is perfectly acceptable there too.  So the best code is simply to 
return 6 without any work at run time.

Ironically, if I had checked the result of malloc() for a null pointer, 
it could not have made this optimisation!

David Brown <david.brown@hesbynett.no> writes:
> No, it hasn't accessed unallocated memory at all.  It did not access
> anything.  The compiler could see that either the malloc worked fine
> and the result would be the value 6,

It's a question of how the compiler implemented the compile-time
execution.  I hope that it didn't really allocate 6 bytes of memory at
compile time, and then write past it.  But it makes me wonder.

On 09/02/2020 04:42, Paul Rubin wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> No, it hasn't accessed unallocated memory at all.  It did not access
>> anything.  The compiler could see that either the malloc worked fine
>> and the result would be the value 6,
> 
> It's a question of how the compiler implemented the compile-time
> execution.  I hope that it didn't really allocate 6 bytes of memory at
> compile time, and then write past it.  But it makes me wonder.
> 

I'm lost here.

Are you talking about the mistake I made in allocating 4 bytes, rather 
than 4 * sizeof(int) ?  It makes no difference to the code generated 
when that is corrected, and I don't see where "6 bytes" comes from.

The use of "malloc" in the source code bears no direct relation to 
having to allocate dynamic memory in the compiler.  Compile-time 
execution means figuring out what the effect of the code is, and 
simulating it at compile time - it does /not/ mean executing it 
directly.  And in particular, baring bugs in the compiler it does not 
mean executing undefined behaviour in the compiler - though it can mean 
ignoring it in the source code.

(It would have been nice if the compiler had spotted my mistake and told 
me about it, however.)

On Thursday, February 6, 2020 at 7:26:52 AM UTC-5, pozz wrote:
> [1] http://www.nadler.com/embedded/newlibAndFreeRTOS.html

Pozz, you mentioned you're trying to use ST's RubeMX.
Be careful, extremely buggy support libraries and examples!!
Latest unbelievable foolishness here:
https://community.st.com/s/question/0D50X0000CBmXufSQF/newlibmalloc-locking-mechanism-to-be-threadsafe
Avoid the ST suggestions!!!

Aaaaarrrrggggg.....