Visualizer not displaying all threads if thread names not set about remotery

[dwilliamson]

Are the auto-generated thread names unique among those 8 threads? I can't see anything else that would mess this up.

[dougbinks]

That seems it. The issue is the 64bit version of Base64_Encode appears to have a problem. If I print the name and address we get the following, showing all the addresses come to the same name. I'll see if I can fix and submit a pull request.

TS name: zc3NTs3NM04=
TS address: 0x0000006FDB710E90
TS name: zc3NTs3NM04=
TS address: 0x0000006FDB71B8A0
TS name: zc3NTs3NM04=
TS address: 0x0000006FDB71BE70
TS name: zc3NTs3NM04=
TS address: 0x0000006FDB71BFD0
TS name: zc3NTs3NM04=
TS address: 0x0000006FDB71C290
TS name: zc3NTs3NM04=
TS address: 0x0000006FDB71BDC0
TS name: zc3NTs3NM04=
TS address: 0x0000006FDB71BF20
TS name: zc3NTs3NM04=
TS address: 0x0000006FDB71C080
TS name: zc3NTs3NM04=
TS address: 0x0000006FDB71C6B0

[dougbinks]

Quick Q: Would you prefer Unamed%d instead? Could be done with an atomically incremented thread count fairly easily (unless you already have a suitable thread number available).

[dwilliamson]

Yes, anything would be better than Base64_Encode, as long as it doesn't introduce API calls that are hard to make cross-platform with C89 (e.g. snprintf).

[dougbinks]

I've added the simple fix for now (you'll laugh I hope), and will look into a better one.

[dwilliamson]

I actually think the Base64_Encode function is horribly broken. Which would make things interesting for the WebSocket handshake...

[dwilliamson]

Oh, and hang on... you do realise that the fix you've made actually makes the code do what the comment says it does!? I can be a numpty sometimes...

[dwilliamson]

Found the regression: ad9c926#diff-3b5be79006d8af568f3844e9e5bf7d93L3568