Thread::new tries to avoid invoking the global allocator for re-entrancy reasons (https://doc.rust-lang.org/nightly/std/alloc/trait.GlobalAlloc.html#re-entrance), but CString::new invoked indirectly here will reserve an extra byte of memory in the passed String using the Global, not System, allocator. I think we don't actually have a problem here because Thread::new isn't called with a name from thread::current(), but it's probably worth adding some comments for that.
Separately from those comments, I also noticed while poking at this that the PR adding those guarantees (#144465) didn't add tests confirming that the functions in question didn't invoke the global allocator when called. I don't recall seeing a subsequent PR with tests but cutting this to track adding some. I think we wouldn't be able to easily write a unit test since those run concurrently, but it seems doable to put together a UI test or run-make test (we may need to use a C / raw pthread spawned thread, not sure).
cc @orlp
Thread::newtries to avoid invoking the global allocator for re-entrancy reasons (https://doc.rust-lang.org/nightly/std/alloc/trait.GlobalAlloc.html#re-entrance), butCString::newinvoked indirectly here will reserve an extra byte of memory in the passed String using the Global, not System, allocator. I think we don't actually have a problem here becauseThread::newisn't called with a name fromthread::current(), but it's probably worth adding some comments for that.Separately from those comments, I also noticed while poking at this that the PR adding those guarantees (#144465) didn't add tests confirming that the functions in question didn't invoke the global allocator when called. I don't recall seeing a subsequent PR with tests but cutting this to track adding some. I think we wouldn't be able to easily write a unit test since those run concurrently, but it seems doable to put together a UI test or run-make test (we may need to use a C / raw pthread spawned thread, not sure).
cc @orlp