chrysn
Personally I won't insist on having a deprecation period -- especially in this case because using the old access will reliably fail. Adding @cgundogan to the pingees because I suspect...
This is not Rust specific -- I get the same issue when just using clang: ``` $ make -C examples/hello-world TOOLCHAIN=clang BOARD=microbit-v2 ```
I'd consider removing the `-Wl,--fatal-warnings` as this really *is* a warning, and maybe linker authors have gotten wiser in what they classify as critical. (IMO a warning should be just...
>when building the helloworld example for native. and anything for cortex boards?
Thanks, and just to check: you tested with TOOLCHAIN=llvm?
If we make the wiggling public (given this stack area, tell me where the wiggling would place the thread_t), I think this would suffice. The mechanism could even be private....
> `uint8_t stack[FOO];` If we go there, that should be aligned right away as well. Provided the stack wiggling is well enough understood to be public (even if the implementation...
That was the discussion in , whose last two comments I read as "there was offline discussion". The keyword there was futureproofing -- and I do see that requirements of...
> as long as we hand out PIDs and they can be checked for validity, it ensures a bit more that the pointed to stack (and thread_t) are valid The...
The solution for the purpose of having a handle that can be sure to never mean any different than thread than the one just created is, to me, solved with...