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
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!
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.)
Pozz, you mentioned you're trying to use ST's RubeMX. Be careful, extremely buggy support libraries and examples!! Latest unbelievable foolishness here:
Aaaaarrrrggggg.....
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.