From Newsgroup: comp.lang.tcl

At Sun, 8 Feb 2026 22:40:39 +0100 undroidwish <undroidwish@googlemail.com> wrote:

On 2/8/26 20:26, Harald Oehlmann wrote:

Am 08.02.2026 um 20:05 schrieb saito:

I was not expecting this to throw an error. Docs says it should return
0 or 1. How would you do this check?

% package req Thread
2.8.5

% thread::exists ""
invalid thread handle ""

% thread::exists abc
invalid thread handle "abc"


But then this works:

% thread::exists tid1
0

Weird. It looks like the check expects the argument to start with
"tid" and a number.

Yes, please file a bug report:

https://core.tcl-lang.org/thread/ticket

Honestly am I puzzled. Why should this non-problem deserve a bug report?
The fact to construct a thread identifier out of blue strings seems to
me to be a somehow somewhat malicious act. So how can there be any expectations on arbitrary generated thread identifiers being error'd?
Or answered as non existing?

In other words: the errors thrown on impossible thread identifiers is
the correct answer for the query on thread existence.

Finally, IMO please do not create a ticket.

The OP is NOT expecting thread::exists to behave any differently than it does, just that thread::exists behavior be completely and accurately documented. Appearently, the documentation is mute as to what thread::exists does when given a string that is not a proper thread id, with the (erronious) *presumption* that it would return 0 (which is in fact NOT what it does). This is a *documentation* bug. And the suggested bug report relates to the *documentation*, not the actual code.

BR,
Christian

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 2/8/2026 4:40 PM, undroidwish wrote:

On 2/8/26 20:26, Harald Oehlmann wrote:

Am 08.02.2026 um 20:05 schrieb saito:

Weird. It looks like the check expects the argument to start with
"tid" and a number.

Yes, please file a bug report:

https://core.tcl-lang.org/thread/ticket

Honestly am I puzzled. Why should this non-problem deserve a bug report?

Well, it wasn't my suggestion to file a bug report.

There is a discrepancy and a potentially dangerous, unfounded assumption behind that simple command. Consider the intention behind using thread::exists. It is plainly so to avoid mistakes or core dumps. But
here, it does the exact opposite.

Consider a similar construct in prupose, "string is integer": before
jumping to performing some arithmetic, you may want to use it for
protection. But if it blows up, then how can you ever fix it or do
anything with it?

The fact to construct a thread identifier out of blue strings seems to
me to be a somehow somewhat malicious act.

It happens when you get it from external source or the network fails or
comms gets corrupted or whatever. I am curious why anyone should care
about what an identifier handle or string should look like. It is just a
bunch of mumbo jumbo, apart from the fact that it is unique and provides access to a certain thing.

If it is important, then it should be documented. You think it is "tid" followed by numbers? Not so. Why is "tidabc" ok here but not "tidxyz"?

% thread::exists tidabc
0

% thread::exists tidxyz
invalid thread handle "tidxyz"


Continuing with the string example above, see how the string integer
check does what it says and protects you from blindly going forward with
what you have.

% string is integer abc
0

% string is integer "123 . 456"
0

% string is integer [image create photo]
0

% string is integer {^@<83>B|e&-+<86>}
0

thread::exists exists for the same purpose but it does not do the same
thing.










--- Synchronet 3.21d-Linux NewsLink 1.2