tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Ashok N. <apn...@ya...>]

Just for the record, I would still prefer a stub entry even if the panic gives more useful information with the macro.

/Ashok
________________________________
From: Jan Nijtmans <jan...@gm...>
Sent: Tuesday, May 6, 2025 1:20 AM
To: Ashok Nadkarni <apn...@ya...>
Subject: Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

Op ma 5 mei 2025 om 21:39 schreef Jan Nijtmans:
> > I do not understand why the implementation does not simply define a new stub entry for Tcl_AttemptCreateHashEntry instead of introducing all that macro bloat.

Reading this question again, you were talking about 'stub entry', It
would indeed be
possible to create a new stub entry for that. Doing it inline gives
the possibility
for the Tcl_Panic to provide much more useful information. If TCL_MEM_DEBUG
is defined, this is fully utilized: If the Tcl_CreateHashEntry() call fails,
the panic will give the filename and linenumber where it happened.

Hope this helps,
      Jan Nijtmans

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Ashok N. <apn...@ya...>]

Jan,

Re. Stub entry, understood, thanks.

Re. Bloat, responded in previous post.

Re. Tcl_FindHashEntry - forgot I had already responded in the ticket

/Ashok
________________________________
From: Jan Nijtmans
Sent: Tuesday, May 6, 2025 1:09 AM
To: Ashok Nadkarni
Cc: Tcl Core List
Subject: Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

Op ma 5 mei 2025 om 19:54 schreef Ashok Nadkarni via Tcl-Core:
> I have questions about the implementation.
>
> I do not understand why the implementation does not simply define a new stub entry for Tcl_AttemptCreateHashEntry instead of introducing all that macro bloat.

That's not possible due to binary compatibility. sizeof(struct Tcl_HashTable)
must stay the same, otherwise all extensions need to be recompiled. We
can only do that in a major release, not in Tcl 9.1.

>
> Consider the compiled code from a single call to Tcl_CreateHashEntry from trunk versus the TIP717 implementation.

It's not as bad as you describe. If a file has multiple Tcl_CreateHashEntry()
calls, this 'bloat' will only occur once. If the linker has LTO, all the
'bloat'ed stuff will be merged into one. Did you compare the size
of tcl91.dll with and without TIP #717? It's at most a few kBytes
which are added.

More work will be done replacing all Tcl_CreateHashEntry()
calls with Tcl_AttemptCreateHashEntry(). So this 'bloat'
will gradually disappear while this work advances.

....
> I also do not understand the macro overloading of Tcl_FindHashEntry -> Tcl_CreateHashEntry. What is the new need in Tcl 9.1 that made this necessary when it was not present in 9.0?

It's just an optimization. See:
<https://core.tcl-lang.org/tcl/tktview/236d18f49b>

Hope this helps,
    Jan Nijtmans

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Ashok N. <apn...@ya...>]

Below is a (admittedly contrived and hopefully not buggy) test case illustrating the failure. Maybe just replacing the macro with inline functions may fix the macro parameter duplication cause of failure.

int
TestCreateHashObjCmd(
    void *dummy,  /* Not used. */
    Tcl_Interp *interp,       /* Current interpreter */
    int objc,                 /* Number of arguments */
    Tcl_Obj *const objv[]     /* Argument strings */
    )
{
    const char *keys[4] = {"one", "two", "one", NULL};
    const char **keyPtr;
    int isNew[3] = {0, 0, 0};
    Tcl_HashTable htab;
    int *isNewPtr;
    int i;

    Tcl_InitHashTable(&htab, TCL_STRING_KEYS);

    keyPtr = keys;
    isNewPtr = isNew;
    i = 0;
    Tcl_Obj *resultPtr = Tcl_NewListObj(3, NULL);
    while (*keyPtr) {
        (void) Tcl_CreateHashEntry(&htab, *keyPtr++, isNewPtr++);
        Tcl_ListObjAppendElement(interp, resultPtr, Tcl_NewIntObj(isNew[i++]));
    }
    Tcl_SetObjResult(interp, resultPtr);
    return TCL_OK;
}

trunk returns expected values:
% sandbox::testcreatehash
1 1 0

tip-717 returns:
% sandbox::testcreatehash
0 1 0


________________________________
From: Ashok Nadkarni via Tcl-Core
Sent: Monday, May 5, 2025 11:23 PM
To: Tcl Core List
Subject: Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()


In passing, I also believe the current implementation of the macro is broken but have not created a test case to prove it. That would however be presumably fixable so the real issue is why the macros instead of a stub entry?

/Ashok



________________________________
From: Jan Nijtmans
Sent: Thursday, May 1, 2025 2:52 PM
To: Tcl Core List
Subject: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

This is a CFV warning for TIP #717. for Tcl 9.1+:
    New function: Tcl_AttemptCreateHashEntry()
    <https://core.tcl-lang.org/tips/doc/trunk/tip/717.md>

If you think this is a bad idea, speak up now. If not,
I'll start the vote in a few days.

Regards,
         Jan Nijtmans


_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core
S

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Ashok N. <apn...@ya...>]

Sergey, indeed I passed cdebug=-Zi without realizing that also removed the -O2. I fixed the comparison below.

Sergey, Jan, I was not thinking about Tcl core size or a single compilation unit at all but rather calls from extensions so Sergey's godbolt snippet or LTO are not relevant. Below is a hopefully more valid (-O2) comparison when called from an extension.

trunk:
    (void) Tcl_CreateHashEntry(&htab, "key", &i);
00007FFB2E381178  lea         r8,[i]
00007FFB2E38117D  lea         rdx,[string "key" (07FFB2E3831C0h)]
00007FFB2E381184  lea         rcx,[htab]
00007FFB2E381189  call        qword ptr [rsp+88h]


tip-717:
    (void) Tcl_CreateHashEntry(&htab, "key", &i);
00007FFB410D1179  lea         rax,[i]
00007FFB410D117E  lea         r8,[i]
00007FFB410D1183  lea         rdx,[string "key" (07FFB410D31ECh)]
00007FFB410D118A  lea         rcx,[rbp-79h]
00007FFB410D118E  cmp         rax,0FFFFFFFFFFFFFFFFh
00007FFB410D1192  je          TestCreateHashObjCmd+0A6h (07FFB410D11B6h)
00007FFB410D1194  call        qword ptr [rbp-21h]
00007FFB410D1197  test        rax,rax
00007FFB410D119A  jne         TestCreateHashObjCmd+0A9h (07FFB410D11B9h)
00007FFB410D119C  mov         rax,qword ptr [tclStubsPtr (07FFB410D5100h)]
00007FFB410D11A3  lea         rdx,[string "Tcl_CreateHashEntry" (07FFB410D31D8h)]
00007FFB410D11AA  lea         rcx,[string "%s: Memory overflow" (07FFB410D31C0h)]
00007FFB410D11B1  call        qword ptr [rax+20h]
00007FFB410D11B4  jmp         TestCreateHashObjCmd+0A9h (07FFB410D11B9h)
00007FFB410D11B6  call        qword ptr [rbp-21h]

So there is still significant difference. The inlining of the panic probably hurts. I really don't know if the difference is enough to matter or not. I am just pointing it out.

/Ashok


________________________________
From: Dipl. Ing. Sergey G. Brester
Sent: Tuesday, May 6, 2025 1:46 AM
To: Ashok Nadkarni
Cc: Tcl Core List
Subject: Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()


How you compiled it, Ashok?
I assume without any optimization, right? You need to try it with -O1 or better with -O2, then it'd be much better.

Also I guess you don't see deeply enough, because at the moment one of the jumps (check for NULL and panic if yes) happens inside the CreateHashEntry function, where later it'd happen in the caller scope. In both cases the jump is there.

Here is the comparison that can illustrate the behaviour: https://godbolt.org/z/o5GzWKWM4<https://godbolt.org/#z:OYLghAFBqd5TKALEBjA9gEwKYFFMCWALugE4A0BIEAZgQDbYB2AhgLbYgDkAjF%2BTXRMiAZVQtGIHgBYBQogFUAztgAKAD24AGfgCsp5eiyagA%2BudTkVjVEQJDqzTAGF09AK5smUgOzknADIETNgAcp4ARtikUgAc5AAO6ErE9kyuHl6%2BicmpQkEh4WxRMTzx1ti2aSJELKREGZ7eAExW2DZ2QjV1RAVhkdFxVrX1jVmtSiO9wf3Fg2UAlFbo7qSonFwApM0AzMGoHjgA1Js7zpOY9AQRAHRIp7ibWgCC23tMB%2B7Hp%2BdEhOh3B5PV4vABu6AImCOABUDqZVMYCKgIBgmJMjqgkHUjgAqQSkNgsIjkI43MkLU4AIWBwIA9LSjpTsPjsDCAJKqI4%2BHh%2BI4IphIo7BI7OUjYInYAASLCUSFwwlIAE8aWCIVCcSKxRLpbL5UQlTwIODIbjahFGKp9STUejMdicQBrbCKknBIi4kIAd0tpApL02PmpLyOIaOxvVSFZpwAIkdCfR6OhkTwtFoKTsg89Q0KaEcIGAwJGFidA8DsyHYfR4YjkdtmtsAKxKEBHACy2DYZEVR3QoOiNETnrrJLrldMovFRClMrlCsVPDr6cz2YD0bLobFRFWTCOkapNJ8a/9/t2ODoIRhcIn2pneoNEDNFqtRydLqOXp9xc2DecKoAnNeU46rO%2Brzg%2BLDmmoz4okItpYqQuILBAr5LHmH76gsfogs8bpxiwwQQF%2BpbBqG64hnaCFmt%2BlIpt%2Ba4ZmRYZqrie4MSRIa4V6ABqEj7seWahpGJw7LGY6AdOupzoaZojs0zSvsOJzNAAbNxEhLoxCSkG6NAQHWOIao2CSKUWfGvIewJcEs9DcA2/DeFwOjkOg3DOEcSgrGsUa7Hw5BENoVlLJGLA4DEhGGNw0j8GwIANlo5AOU5LlcPwzbxf5jlWeQcCwCgGA4PgxBkJQ1B0IwrAcNwvmCMIYgSJwMhyMIyhqJomXkPorRGCYIDmKYlgVFUDgQE4YzeDw/hMJgfRFCUBhJCknTpG4TTzbkS0zQMpRtB01RTGNBiDUt3T1JtczbZMPQHRNl2nTMs3zEsHmrOs3BvPshxRmcFxXLc9w7I8J7vJ83zfX89iAgDKrPOGl5VvySIwWi7oUbi%2BKEsSpLkmZdIMs8NBTgh0IclyPIkgjqBCjuYlakBt5ztDl12JTwRXBesM4sClYU2yNDhAmensUxJo4swoHkIxNoo/BaNMFhAbLjmeYFmLSpEZmTx/mOFN6XJjbNm2HZdj2fakAO6BDnJJI0HLZkhqu66btuRyq8qbHmUe2Ec5qk4SSBSrNEazE4o%2BUEUBisHS/ar6usIHrYN6GEHorIYc0JMZ4QmSYQCmaZ2xu2BbqQO6sRrFn8W8Z4zHD46037d6KoHoc%2BiSMfvgnn55hA6EIQWGcQLhOILAAtDwX4/v%2BpwAGJwzzfPuAL4nAQ3TcQU%2B4ffr%2Bx5/prSNwfaSEoSS3cdxhqGjledfL3O9ZyePW8gn%2BLZL/ToGr5BLd5lLGIy0PyHOqhE%2BidfSYWhrhQkBF1aMUljLKiDYaJaDovnVOwdS6MU4gnHi9AcZC3TiJGuL9JJv3AhEWS8lnSKW2KpTB6lkFHC0jpXWzQDJKQbMZK2u5sAaX9OXZ4WUbJcDsglAKzlXLuU8usJSOxmj8AyjoTC5BgqhWoEsB0UhlI3GUlo7ROidHxAEVFcgMU4rCPaslVKIB0oBQUWo6QOwbg%2BGkA2HwOxlIqT/NyWIDZYiyAETseyIjzF%2BWsdlRAEA8roDYAkBg0QSowSiTEmIqBgA8AbBNMqhNmwQAiCIiIwQ6iKiqvwPJrAlQAHkIi6EqBlXyGA2AcGEGUpg9BCntRwBEdwwBnASHoM2Xg/AcCEhMJINpBAxRVD7H0py2B1CVHcFOIplBhDtBEb9UgBTXA4BEfqAgMV%2BnkFNhEZI2BowdmMMANmoBMpLAHCwYASguIEATmUhIzBFk1VEOISQjUPktQ0CI/QE1upmAsIYa4zZIBLHQAkJafTh5lJkc5U22kcAQvCkdNIjgprXUmtNe6W01qLTSDihaeQmBnTmjddo1S9pXRWlkKlu0uhTApfMYYdLMjjXZXdQoBKx7LBeg1aytkAlmO4EcdQsRlLD2UtII4wBUCU1STcHgeZCokAQm8MesjrGqJACpG4Ow/w8D/MpP8zRpDKRNc0VJ%2BjIrRSkKmUxSVuAWKsdc0J8BwloEidExgFAqDxL9YMZJqT0kMEydQHJ7USkFMWbG8plTqmLLqQ0ogTSWkiPaZ07pCY%2Bm%2BUGeckZTlCDjLsJMkRMy5kLP2W6FZ7U1kbKwBsJyOy9m%2BUOcc05QyLnBCufIgQRh7mPOea8hy1V5B1W%2BbIX5Kh/ntX0DsQw5zeqgt%2BmiqFMK0hwoRfwXs0QUXYA3TtGlw1Rr0q5YEfF51CVkpJetNIrKLrUqGkwE6DQL2HRfcdFl17KXco/Zyw6v7eU3v5c9Ly%2BrhWCNFS6rgEqpUyrlQqpVDYVVqsIBqqRzQFg6uuUFcUyjwpqOaH%2BG4Uq5J/mkNIHxWhYjmobBFLghjEp7tdVYSxwT8NMcRax0RKUuPyKWKbFIDhpBAA%3D>

However, I also see a few points to criticize:

  *   I don't understand the intention to use the macro for Tcl_CreateHashEntry, especially if a part of it (TclPanicIfNull) is an inline function now... If it is because of TCL_MEM_DEBUG (why is it necessary?), one could #ifdef it inside the inline function, or at least write content of the wrapper once.
  *   Also this makes the usage of Tcl_CreateHashEntry vulnerable, e. g. code like this becomes buggy after update (hint - tabPtr will be incremented twice or throw an error in static analysis tools and some modern compilers):
while (tabPtr < endPtr) {
  ...
  he = Tcl_CreateHashEntry(tabPtr++, ...)
}
  *   are the memsets really necessary in AllocStringEntry (e. g. we could possibly avoid 1 conditional jump)
  *   Removal of FindHashEntry is a bit unexpected (why at all?)... Also see the objections about TCL_HASH_FIND below...
  *   Removal of tablePtr->findProc is totally unexpected, I don't follow why one shall necessarily combine findProc and createProc, vice versa I'd prefer not to do that (even if a create may imply the find functionality) - don't try to be a compiler and/or optimizer, especially because the compiler can do it often better than you, and mostly without extra jump by inlining of function.
Conceptually the findProc is another thing than createProc (e. g. doesn't have newPtr) and therefore better would be to hold them completely different from header to the implementation, even if createProc would internally invoke findProc, it'd do better optimization (better use the registers and inline the function if necessary). And to avoid code duplication one could create inline function FindHashEntry and then include it in ahead of CreateHashEntry. The compiler would be thankful for that too.
  *   The new artificial pointer TCL_HASH_FIND is in my opinion additional "improvement" (e. g. because of code review), to make possible to create hash entry without to supply newPtr...
I had simply split the function in 2 (inline) functions - the 1st part for search and 2nd for create - it'd be much more consistent and wouldn't need constructs like if (newPtr && (newPtr != TCL_HASH_FIND)).
Anyway strange approach and has nothing to do with the subject.
  *   Changes on function Tcl_FirstHashEntry are neither mentioned in the TIP, nor the new behaviour is compatible (previously it'd panic and always returns not NULL, whether new version can return NULL and thus segfault in code that doesn't expect that).

Regards,
Serg.

05.05.2025 19:53, Ashok Nadkarni via Tcl-Core wrote:

TIP 717 has two proposals that are really independent


  *
Tcl_AttemptCreateHashEntry is new API
  *
Allowing isNew to be NULL is an enhancement to the existing Tcl_CreateHashEntry


Both look reasonable to me.

I have questions about the implementation.

I do not understand why the implementation does not simply define a new stub entry for Tcl_AttemptCreateHashEntry instead of introducing all that macro bloat.

Consider the compiled code from a single call to Tcl_CreateHashEntry from trunk versus the TIP717 implementation.

Trunk:
240:  48 89 54 24 10          mov    %rdx,0x10(%rsp)
 245: 48 89 4c 24 08          mov    %rcx,0x8(%rsp)
 24a: 48 83 ec 28             sub    $0x28,%rsp
 24e: 4c 8b 44 24 38          mov    0x38(%rsp),%r8
 253: 48 8d 15 00 00 00 00    lea    0x0(%rip),%rdx        # 25a <CreateHash+0x1a>
 25a: 48 8b 4c 24 30          mov    0x30(%rsp),%rcx
 25f: 48 8b 44 24 30          mov    0x30(%rsp),%rax
 264: ff 50 58                call   *0x58(%rax)
 267: 48 83 c4 28             add    $0x28,%rsp
 26b: c3                      ret

The same call with TIP 717:

280:  48 89 54 24 10          mov    %rdx,0x10(%rsp)
 285: 48 89 4c 24 08          mov    %rcx,0x8(%rsp)
 28a: 48 83 ec 38             sub    $0x38,%rsp
 28e: 48 83 7c 24 48 ff       cmpq   $0xffffffffffffffff,0x48(%rsp)
 294: 74 2f                   je     2c5 <CreateHash+0x45>
 296: 4c 8b 44 24 48          mov    0x48(%rsp),%r8
 29b: 48 8d 15 00 00 00 00    lea    0x0(%rip),%rdx        # 2a2 <CreateHash+0x22>
 2a2: 48 8b 4c 24 40          mov    0x40(%rsp),%rcx
 2a7: 48 8b 44 24 40          mov    0x40(%rsp),%rax
 2ac: ff 50 58                call   *0x58(%rax)
 2af: 48 8d 15 00 00 00 00    lea    0x0(%rip),%rdx        # 2b6 <CreateHash+0x36>
 2b6: 48 8b c8                mov    %rax,%rcx
 2b9: e8 00 00 00 00          call   2be <CreateHash+0x3e>
 2be: 48 89 44 24 20          mov    %rax,0x20(%rsp)
 2c3: eb 1e                   jmp    2e3 <CreateHash+0x63>
 2c5: 4c 8b 44 24 48          mov    0x48(%rsp),%r8
 2ca: 48 8d 15 00 00 00 00    lea    0x0(%rip),%rdx        # 2d1 <CreateHash+0x51>
 2d1: 48 8b 4c 24 40          mov    0x40(%rsp),%rcx
 2d6: 48 8b 44 24 40          mov    0x40(%rsp),%rax
 2db: ff 50 58                call   *0x58(%rax)
 2de: 48 89 44 24 20          mov    %rax,0x20(%rsp)
 2e3: 48 83 c4 38             add    $0x38,%rsp
 2e7: c3                      ret

That's something like 4x code bloat (ignoring the function enter/exit boilerplate above) at every call site and probably a performance cost associated with the additional jumps. And that does not even include the additional bloat not shown above from the TclDbPanicIfNull call being added to every file where Tcl_CreateHashEntry is called (luckily the compiler ignores the inline directive else it would be even more code bloat).

So the question is, why the macro wrapper overloading Tcl_CreateHashEntry with the (int *)-1 argument instead of a simple additional stub entry?

I do not like this proliferation of macro use. Here, and in other cases, it makes the compiler generate code for runtime decisions for conditions that are known at compile time while losing some level of type safety.

I also do not understand the macro overloading of Tcl_FindHashEntry -> Tcl_CreateHashEntry. What is the new need in Tcl 9.1 that made this necessary when it was not present in 9.0?

In passing, I also believe the current implementation of the macro is broken but have not created a test case to prove it. That would however be presumably fixable so the real issue is why the macros instead of a stub entry?

/Ashok




________________________________
From: Jan Nijtmans
Sent: Thursday, May 1, 2025 2:52 PM
To: Tcl Core List
Subject: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

This is a CFV warning for TIP #717. for Tcl 9.1+:
    New function: Tcl_AttemptCreateHashEntry()
    <https://core.tcl-lang.org/tips/doc/trunk/tip/717.md>

If you think this is a bad idea, speak up now. If not,
I'll start the vote in a few days.

Regards,
         Jan Nijtmans


_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core
S

_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] TIP 716 ready for comments

[Jan N. <jan...@gm...>]

Op ma 5 mei 2025 om 19:22 schreef Ashok Nadkarni:
> Now, with regard to the mingw msvcrt comment...
>
> It seems to me from your comment about GetACP() in MingW that you think I was suggesting the manifest would not work in MingW. That is not so. GetACP() will work the same way and return utf-8 in the presence of a manifest but the problem is MSVCRT does not support UTF-8.
>
> I do not know if you read the link that I had referenced in the TIP https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt
>
> To quote from there - It doesn't support the UTF-8 locale ("It" being MSVCRT)
>
> When the official release document says MSVCRT does not support UTF-8, I take that at face value.

Let me clarify then. See:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale?view=msvc-170

With msvcrt, you cannot do a setlocale("en_US.UTF8"), with UCRT it works;

Tcl doesn't support that either. The only setlocale() call is here:
    <https://core.tcl-lang.org/tcl/file?name=win/tclAppInit.c&ci=ead995eddf5fff98&ln=111>

MSVCRT supports the "utf-8" _encoding_, not the "utf-8" _locale_,
that's a different thing

Hope this clarifies enough.

Happy hacking,
     Jan Nijtmans

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Dipl. I. S. G. B. <se...@us...>]

 

How you compiled it, Ashok?
I assume without any optimization, right? You need to try it with -O1 or
better with -O2, then it'd be much better.

Also I guess you don't see deeply enough, because at the moment one of
the jumps (check for NULL and panic if yes) happens inside the
CreateHashEntry function, where later it'd happen in the caller scope.
In both cases the jump is there. 

Here is the comparison that can illustrate the behaviour:
https://godbolt.org/z/o5GzWKWM4 [3] 

However, I also see a few points to criticize: 

 	* I don't understand the intention to use the macro for
Tcl_CreateHashEntry, especially if a part of it (TclPanicIfNull) is an
inline function now... If it is because of TCL_MEM_DEBUG (why is it
necessary?), one could #ifdef it inside the inline function, or at least
write content of the wrapper once.

	* Also this makes the usage of Tcl_CreateHashEntry vulnerable, e. g.
code like this becomes buggy after update (hint - tabPtr will be
incremented twice or throw an error in static analysis tools and some
modern compilers):
while (tabPtr < endPtr) {
 ...
 he = Tcl_CreateHashEntry(tabPtr++, ...)
} 	* are the memsets really necessary in AllocStringEntry (e. g. we
could possibly avoid 1 conditional jump)
 	* Removal of FindHashEntry is a bit unexpected (why at all?)... Also
see the objections about TCL_HASH_FIND below...

	* Removal of tablePtr->findProc is totally unexpected, I don't follow
why one shall necessarily combine findProc and createProc, vice versa
I'd prefer not to do that (even if a create may imply the find
functionality) - don't try to be a compiler and/or optimizer, especially
because the compiler can do it often better than you, and mostly without
extra jump by inlining of function.
Conceptually the findProc is another thing than createProc (e. g.
doesn't have newPtr) and therefore better would be to hold them
completely different from header to the implementation, even if
createProc would internally invoke findProc, it'd do better optimization
(better use the registers and inline the function if necessary). And to
avoid code duplication one could create inline function FindHashEntry
and then include it in ahead of CreateHashEntry. The compiler would be
thankful for that too. 
	* The new artificial pointer TCL_HASH_FIND is in my opinion additional
"improvement" (e. g. because of code review), to make possible to create
hash entry without to supply newPtr... 
I had simply split the function in 2 (inline) functions - the 1st part
for search and 2nd for create - it'd be much more consistent and
wouldn't need constructs like if (newPtr && (newPtr != TCL_HASH_FIND)).
Anyway strange approach and has nothing to do with the subject. 	*
Changes on function Tcl_FirstHashEntry are neither mentioned in the TIP,
nor the new behaviour is compatible (previously it'd panic and always
returns not NULL, whether new version can return NULL and thus segfault
in code that doesn't expect that).

Regards,
Serg. 

05.05.2025 19:53, Ashok Nadkarni via Tcl-Core wrote: 

> TIP 717 has two proposals that are really independent 
> 
> * 
> Tcl_AttemptCreateHashEntry is new API 
> * 
> Allowing isNew to be NULL is an enhancement to the existing Tcl_CreateHashEntry 
> 
> Both look reasonable to me. 
> 
> I have questions about the implementation. 
> 
> I do not understand why the implementation does not simply define a new stub entry for Tcl_AttemptCreateHashEntry instead of introducing all that macro bloat. 
> 
> Consider the compiled code from a SINGLE call to Tcl_CreateHashEntry from trunk versus the TIP717 implementation. 
> 
> Trunk: 
> 240:  48 89 54 24 10    mov %rdx,0x10(%rsp) 
> 245: 48 89 4c 24 08    mov %rcx,0x8(%rsp) 
> 24a: 48 83 ec 28    sub $0x28,%rsp 
> 24e: 4c 8b 44 24 38    mov 0x38(%rsp),%r8 
> 253: 48 8d 15 00 00 00 00    lea 0x0(%rip),%rdx # 25a <CreateHash+0x1a> 
> 25a: 48 8b 4c 24 30    mov 0x30(%rsp),%rcx 
> 25f: 48 8b 44 24 30    mov 0x30(%rsp),%rax 
> 264: ff 50 58    call *0x58(%rax) 
> 267: 48 83 c4 28    add $0x28,%rsp 
> 26b: c3    ret 
> 
> The same call with TIP 717: 
> 
> 280: 48 89 54 24 10    mov %rdx,0x10(%rsp) 
> 285: 48 89 4c 24 08    mov %rcx,0x8(%rsp) 
> 28a: 48 83 ec 38    sub $0x38,%rsp 
> 28e: 48 83 7c 24 48 ff    cmpq $0xffffffffffffffff,0x48(%rsp) 
> 294: 74 2f    je 2c5 <CreateHash+0x45> 
> 296: 4c 8b 44 24 48    mov 0x48(%rsp),%r8 
> 29b: 48 8d 15 00 00 00 00    lea 0x0(%rip),%rdx # 2a2 <CreateHash+0x22> 
> 2a2: 48 8b 4c 24 40    mov 0x40(%rsp),%rcx 
> 2a7: 48 8b 44 24 40    mov 0x40(%rsp),%rax 
> 2ac: ff 50 58    call *0x58(%rax) 
> 2af: 48 8d 15 00 00 00 00    lea 0x0(%rip),%rdx # 2b6 <CreateHash+0x36> 
> 2b6: 48 8b c8    mov %rax,%rcx 
> 2b9: e8 00 00 00 00    call 2be <CreateHash+0x3e> 
> 2be: 48 89 44 24 20    mov %rax,0x20(%rsp) 
> 2c3: eb 1e    jmp 2e3 <CreateHash+0x63> 
> 2c5: 4c 8b 44 24 48    mov 0x48(%rsp),%r8 
> 2ca: 48 8d 15 00 00 00 00    lea 0x0(%rip),%rdx # 2d1 <CreateHash+0x51> 
> 2d1: 48 8b 4c 24 40    mov 0x40(%rsp),%rcx 
> 2d6: 48 8b 44 24 40    mov 0x40(%rsp),%rax 
> 2db: ff 50 58    call *0x58(%rax) 
> 2de: 48 89 44 24 20    mov %rax,0x20(%rsp) 
> 2e3: 48 83 c4 38    add $0x38,%rsp 
> 2e7: c3    ret 
> 
> That's something like 4x code bloat (ignoring the function enter/exit boilerplate above) at EVERY call site and probably a performance cost associated with the additional jumps. And that does not even include the additional bloat not shown above from the TclDbPanicIfNull call being added to every file where Tcl_CreateHashEntry is called (luckily the compiler ignores the inline directive else it would be even more code bloat). 
> 
> So the question is, why the macro wrapper overloading Tcl_CreateHashEntry with the (int *)-1 argument instead of a simple additional stub entry? 
> 
> I do not like this proliferation of macro use. Here, and in other cases, it makes the compiler generate code for runtime decisions for conditions that are known at compile time while losing some level of type safety. 
> 
> I also do not understand the macro overloading of Tcl_FindHashEntry -> Tcl_CreateHashEntry. What is the new need in Tcl 9.1 that made this necessary when it was not present in 9.0? 
> 
> In passing, I also believe the current implementation of the macro is broken but have not created a test case to prove it. That would however be presumably fixable so the real issue is why the macros instead of a stub entry? 
> 
> /Ashok 
> 
> -------------------------
> 
> FROM: Jan Nijtmans
> SENT: Thursday, May 1, 2025 2:52 PM
> TO: Tcl Core List
> SUBJECT: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry() 
> 
> This is a CFV warning for TIP #717. for Tcl 9.1+:
> New function: Tcl_AttemptCreateHashEntry()
> <https://core.tcl-lang.org/tips/doc/trunk/tip/717.md [2]>
> 
> If you think this is a bad idea, speak up now. If not,
> I'll start the vote in a few days.
> 
> Regards,
> Jan Nijtmans
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core [1] S
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core [1]
 

Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/tcl-core
[2] https://core.tcl-lang.org/tips/doc/trunk/tip/717.md
[3]
https://godbolt.org/#z:OYLghAFBqd5TKALEBjA9gEwKYFFMCWALugE4A0BIEAZgQDbYB2AhgLbYgDkAjF%2BTXRMiAZVQtGIHgBYBQogFUAztgAKAD24AGfgCsp5eiyagA%2BudTkVjVEQJDqzTAGF09AK5smUgOzknADIETNgAcp4ARtikUgAc5AAO6ErE9kyuHl6%2BicmpQkEh4WxRMTzx1ti2aSJELKREGZ7eAExW2DZ2QjV1RAVhkdFxVrX1jVmtSiO9wf3Fg2UAlFbo7qSonFwApM0AzMGoHjgA1Js7zpOY9AQRAHRIp7ibWgCC23tMB%2B7Hp%2BdEhOh3B5PV4vABu6AImCOABUDqZVMYCKgIBgmJMjqgkHUjgAqQSkNgsIjkI43MkLU4AIWBwIA9LSjpTsPjsDCAJKqI4%2BHh%2BI4IphIo7BI7OUjYInYAASLCUSFwwlIAE8aWCIVCcSKxRLpbL5UQlTwIODIbjahFGKp9STUejMdicQBrbCKknBIi4kIAd0tpApL02PmpLyOIaOxvVSFZpwAIkdCfR6OhkTwtFoKTsg89Q0KaEcIGAwJGFidA8DsyHYfR4YjkdtmtsAKxKEBHACy2DYZEVR3QoOiNETnrrJLrldMovFRClMrlCsVPDr6cz2YD0bLobFRFWTCOkapNJ8a/9/t2ODoIRhcIn2pneoNEDNFqtRydLqOXp9xc2DecKoAnNeU46rO%2Brzg%2BLDmmoz4okItpYqQuILBAr5LHmH76gsfogs8bpxiwwQQF%2BpbBqG64hnaCFmt%2BlIpt%2Ba4ZmRYZqrie4MSRIa4V6ABqEj7seWahpGJw7LGY6AdOupzoaZojs0zSvsOJzNAAbNxEhLoxCSkG6NAQHWOIao2CSKUWfGvIewJcEs9DcA2/DeFwOjkOg3DOEcSgrGsUa7Hw5BENoVlLJGLA4DEhGGNw0j8GwIANlo5AOU5LlcPwzbxf5jlWeQc
CwCgGA4PgxBkJQ1B0IwrAcNwvmCMIYgSJwMhyMIyhqJomXkPorRGCYIDmKYlgVFUDgQE4YzeDw/hMJgfRFCUBhJCknTpG4TTzbkS0zQMpRtB01RTGNBiDUt3T1JtczbZMPQHRNl2nTMs3zEsHmrOs3BvPshxRmcFxXLc9w7I8J7vJ83zfX89iAgDKrPOGl5VvySIwWi7oUbi%2BKEsSpLkmZdIMs8NBTgh0IclyPIkgjqBCjuYlakBt5ztDl12JTwRXBesM4sClYU2yNDhAmensUxJo4swoHkIxNoo/BaNMFhAbLjmeYFmLSpEZmTx/mOFN6XJjbNm2HZdj2fakAO6BDnJJI0HLZkhqu66btuRyq8qbHmUe2Ec5qk4SSBSrNEazE4o%2BUEUBisHS/ar6usIHrYN6GEHorIYc0JMZ4QmSYQCmaZ2xu2BbqQO6sRrFn8W8Z4zHD46037d6KoHoc%2BiSMfvgnn55hA6EIQWGcQLhOILAAtDwX4/v%2BpwAGJwzzfPuAL4nAQ3TcQU%2B4ffr%2Bx5/prSNwfaSEoSS3cdxhqGjledfL3O9ZyePW8gn%2BLZL/ToGr5BLd5lLGIy0PyHOqhE%2BidfSYWhrhQkBF1aMUljLKiDYaJaDovnVOwdS6MU4gnHi9AcZC3TiJGuL9JJv3AhEWS8lnSKW2KpTB6lkFHC0jpXWzQDJKQbMZK2u5sAaX9OXZ4WUbJcDsglAKzlXLuU8usJSOxmj8AyjoTC5BgqhWoEsB0UhlI3GUlo7ROidHxAEVFcgMU4rCPaslVKIB0oBQUWo6QOwbg%2BGkA2HwOxlIqT/NyWIDZYiyAETseyIjzF%2BWsdlRAEA8roDYAkBg0QSowSiTEmIqBgA8AbBNMqhNmwQAiCIiIwQ6iKiqvwPJrAlQAHkIi6EqBlXyGA2AcGEGUpg9BCntRwBEdwwBnASHoM2Xg/AcCEhMJINpBAxRVD7H0py2B1CVHcFOIplB
hDtBEb9UgBTXA4BEfqAgMV%2BnkFNhEZI2BowdmMMANmoBMpLAHCwYASguIEATmUhIzBFk1VEOISQjUPktQ0CI/QE1upmAsIYa4zZIBLHQAkJafTh5lJkc5U22kcAQvCkdNIjgprXUmtNe6W01qLTSDihaeQmBnTmjddo1S9pXRWlkKlu0uhTApfMYYdLMjjXZXdQoBKx7LBeg1aytkAlmO4EcdQsRlLD2UtII4wBUCU1STcHgeZCokAQm8MesjrGqJACpG4Ow/w8D/MpP8zRpDKRNc0VJ%2BjIrRSkKmUxSVuAWKsdc0J8BwloEidExgFAqDxL9YMZJqT0kMEydQHJ7USkFMWbG8plTqmLLqQ0ogTSWkiPaZ07pCY%2Bm%2BUGeckZTlCDjLsJMkRMy5kLP2W6FZ7U1kbKwBsJyOy9m%2BUOcc05QyLnBCufIgQRh7mPOea8hy1V5B1W%2BbIX5Kh/ntX0DsQw5zeqgt%2BmiqFMK0hwoRfwXs0QUXYA3TtGlw1Rr0q5YEfF51CVkpJetNIrKLrUqGkwE6DQL2HRfcdFl17KXco/Zyw6v7eU3v5c9Ly%2BrhWCNFS6rgEqpUyrlQqpVDYVVqsIBqqRzQFg6uuUFcUyjwpqOaH%2BG4Uq5J/mkNIHxWhYjmobBFLghjEp7tdVYSxwT8NMcRax0RKUuPyKWKbFIDhpBAA%3D

Re: [TCLCORE] To the best of my recollection regarding TIP#302

[Dipl. I. S. G. B. <se...@us...>]

 

Just to point to existing implementation of monotonic and after at -
[fdfbd5e10] [2]. 

In my own fork it works (in production) in more or less exact this form
longer than 10 years without any issues
(and after the switch of almost all timers and timeouts to monotonic
time without "unexplainable" large "hangs", in case of backwards time
jumps or adjustments). 

Regarding the Christians points, mostly agree with almost everything
(excepting removal of virtual time). 

Regarding the slave interp (and other timeouts and time-based handlers),
- yes - they shall be surely monotonic (otherwise sporadic
"unexplainable" large hangs remain unavoidable). 

Regarding the resolution:
- my implementation accepts double by timers (e. g. `after 0.01` - sleep
for 10 microseconds);
- one could introduce new additional option e. g. -seconds, -micro,
-milli to adjust the base; 

Regards,
Sergey 

05.05.2025 20:45, Christian Werner wrote: 

> Hello all,
> 
> some points to discuss:
> 
> * the clock domain should be switched from wall clock to a monotonic clock source in POSIX speak
> * this should ideally not have an impact on time computations in Tcl core
> * however, POSIX monotonic clock must be used in both clock_gettime() and condition variables
> * maybe it's a good idea to detect availability of monotonic clock and fall back to wall clock if not available
> * the time bound on slave interp evaluations is unfortunately in wall time which is IMO a failure in design
> * what about virtual time, can this be ditched entirely, there ain't no test cases and no examples
> * the "after -at" form is a special case to allow for cron like requirements, is this ever a use case?
> * what is the resolution of "after -at", when it's like cron one second seems enough
> * for symmetry another "after -mono" can be imagined which is like "after -at" but in the monotonic clock domain
> * the resolution of "after -mono" should be near the tick rates of contemporary OSes (e.g. milliseconds)
> 
> Best regards,
> Christian
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core [1]
 

Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/tcl-core
[2] https://core.tcl-lang.org/tcl/tktview/fdfbd5e10

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Donald G P. <don...@ni...>]

On 5/5/25 15:39, Jan Nijtmans wrote:
> That's not possible due to binary compatibility. sizeof(struct Tcl_HashTable)
> must stay the same, otherwise all extensions need to be recompiled. We
> can only do that in a major release, not in Tcl 9.1.

This is one of the concerns I had when I mentioned I wanted a chance to review.

I hope when the time is right we will take some stronger steps to move away from
this brittle and limiting interface.  The arcane tinkering is frustrating and complexifying
when inventing something new and better from all the lessons learned over 30+ years
would lead to better long term outcomes.

I still have my suspicions about all the accreted special hooks in hash tables.  Will
check as I can when I can.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Jan N. <jan...@gm...>]

Op ma 5 mei 2025 om 19:54 schreef Ashok Nadkarni via Tcl-Core:
> I have questions about the implementation.
>
> I do not understand why the implementation does not simply define a new stub entry for Tcl_AttemptCreateHashEntry instead of introducing all that macro bloat.

That's not possible due to binary compatibility. sizeof(struct Tcl_HashTable)
must stay the same, otherwise all extensions need to be recompiled. We
can only do that in a major release, not in Tcl 9.1.

>
> Consider the compiled code from a single call to Tcl_CreateHashEntry from trunk versus the TIP717 implementation.

It's not as bad as you describe. If a file has multiple Tcl_CreateHashEntry()
calls, this 'bloat' will only occur once. If the linker has LTO, all the
'bloat'ed stuff will be merged into one. Did you compare the size
of tcl91.dll with and without TIP #717? It's at most a few kBytes
which are added.

More work will be done replacing all Tcl_CreateHashEntry()
calls with Tcl_AttemptCreateHashEntry(). So this 'bloat'
will gradually disappear while this work advances.

....
> I also do not understand the macro overloading of Tcl_FindHashEntry -> Tcl_CreateHashEntry. What is the new need in Tcl 9.1 that made this necessary when it was not present in 9.0?

It's just an optimization. See:
<https://core.tcl-lang.org/tcl/tktview/236d18f49b>

Hope this helps,
    Jan Nijtmans

[TCLCORE] To the best of my recollection regarding TIP#302

[Christian W. <Chr...@t-...>]

Hello all,

some points to discuss:

* the clock domain should be switched from wall clock to a monotonic clock source in POSIX speak
* this should ideally not have an impact on time computations in Tcl core
* however, POSIX monotonic clock must be used in both clock_gettime() and condition variables
* maybe it's a good idea to detect availability of monotonic clock and fall back to wall clock if not available
* the time bound on slave interp evaluations is unfortunately in wall time which is IMO a failure in design
* what about virtual time, can this be ditched entirely, there ain't no test cases and no examples
* the "after -at" form is a special case to allow for cron like requirements, is this ever a use case?
* what is the resolution of "after -at", when it's like cron one second seems enough
* for symmetry another "after -mono" can be imagined which is like "after -at" but in the monotonic clock domain
* the resolution of "after -mono" should be near the tick rates of contemporary OSes (e.g. milliseconds)

Best regards,
Christian

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Ashok N. <apn...@ya...>]

TIP 717 has two proposals that are really independent


  *
Tcl_AttemptCreateHashEntry is new API
  *
Allowing isNew to be NULL is an enhancement to the existing Tcl_CreateHashEntry

Both look reasonable to me.

I have questions about the implementation.

I do not understand why the implementation does not simply define a new stub entry for Tcl_AttemptCreateHashEntry instead of introducing all that macro bloat.

Consider the compiled code from a single call to Tcl_CreateHashEntry from trunk versus the TIP717 implementation.

Trunk:
240:  48 89 54 24 10          mov    %rdx,0x10(%rsp)
 245: 48 89 4c 24 08          mov    %rcx,0x8(%rsp)
 24a: 48 83 ec 28             sub    $0x28,%rsp
 24e: 4c 8b 44 24 38          mov    0x38(%rsp),%r8
 253: 48 8d 15 00 00 00 00    lea    0x0(%rip),%rdx        # 25a <CreateHash+0x1a>
 25a: 48 8b 4c 24 30          mov    0x30(%rsp),%rcx
 25f: 48 8b 44 24 30          mov    0x30(%rsp),%rax
 264: ff 50 58                call   *0x58(%rax)
 267: 48 83 c4 28             add    $0x28,%rsp
 26b: c3                      ret

The same call with TIP 717:

280:  48 89 54 24 10          mov    %rdx,0x10(%rsp)
 285: 48 89 4c 24 08          mov    %rcx,0x8(%rsp)
 28a: 48 83 ec 38             sub    $0x38,%rsp
 28e: 48 83 7c 24 48 ff       cmpq   $0xffffffffffffffff,0x48(%rsp)
 294: 74 2f                   je     2c5 <CreateHash+0x45>
 296: 4c 8b 44 24 48          mov    0x48(%rsp),%r8
 29b: 48 8d 15 00 00 00 00    lea    0x0(%rip),%rdx        # 2a2 <CreateHash+0x22>
 2a2: 48 8b 4c 24 40          mov    0x40(%rsp),%rcx
 2a7: 48 8b 44 24 40          mov    0x40(%rsp),%rax
 2ac: ff 50 58                call   *0x58(%rax)
 2af: 48 8d 15 00 00 00 00    lea    0x0(%rip),%rdx        # 2b6 <CreateHash+0x36>
 2b6: 48 8b c8                mov    %rax,%rcx
 2b9: e8 00 00 00 00          call   2be <CreateHash+0x3e>
 2be: 48 89 44 24 20          mov    %rax,0x20(%rsp)
 2c3: eb 1e                   jmp    2e3 <CreateHash+0x63>
 2c5: 4c 8b 44 24 48          mov    0x48(%rsp),%r8
 2ca: 48 8d 15 00 00 00 00    lea    0x0(%rip),%rdx        # 2d1 <CreateHash+0x51>
 2d1: 48 8b 4c 24 40          mov    0x40(%rsp),%rcx
 2d6: 48 8b 44 24 40          mov    0x40(%rsp),%rax
 2db: ff 50 58                call   *0x58(%rax)
 2de: 48 89 44 24 20          mov    %rax,0x20(%rsp)
 2e3: 48 83 c4 38             add    $0x38,%rsp
 2e7: c3                      ret

That's something like 4x code bloat (ignoring the function enter/exit boilerplate above) at every call site and probably a performance cost associated with the additional jumps. And that does not even include the additional bloat not shown above from the TclDbPanicIfNull call being added to every file where Tcl_CreateHashEntry is called (luckily the compiler ignores the inline directive else it would be even more code bloat).

So the question is, why the macro wrapper overloading Tcl_CreateHashEntry with the (int *)-1 argument instead of a simple additional stub entry?

I do not like this proliferation of macro use. Here, and in other cases, it makes the compiler generate code for runtime decisions for conditions that are known at compile time while losing some level of type safety.

I also do not understand the macro overloading of Tcl_FindHashEntry -> Tcl_CreateHashEntry. What is the new need in Tcl 9.1 that made this necessary when it was not present in 9.0?

In passing, I also believe the current implementation of the macro is broken but have not created a test case to prove it. That would however be presumably fixable so the real issue is why the macros instead of a stub entry?

/Ashok



________________________________
From: Jan Nijtmans
Sent: Thursday, May 1, 2025 2:52 PM
To: Tcl Core List
Subject: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

This is a CFV warning for TIP #717. for Tcl 9.1+:
    New function: Tcl_AttemptCreateHashEntry()
    <https://core.tcl-lang.org/tips/doc/trunk/tip/717.md>

If you think this is a bad idea, speak up now. If not,
I'll start the vote in a few days.

Regards,
         Jan Nijtmans


_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core
S

Re: [TCLCORE] TIP 716 ready for comments

[Ashok N. <apn...@ya...>]

Jan,

Let me first respond to your second reservation below regarding Tcl_GetEncodingNameForUser().

Since your objection merely stated "it's a bad idea" without elaborating as to why, I have to make some guesses as to what exactly you object to. Based on your TIP 718 which suggests a new function TclWinGetUserEncoding(), I assume you would prefer the function return a Tcl_Encoding as opposed to a character string for the encoding name. I did think about that too, but there are two reasons I went with the current function signature returning the encoding name as a string. The first is that it is consistent with the existing API Tcl_GetEncodingFromEnvironment() which also returns a string, not a Tcl_Encoding. There is something to be said for consistency when two API's have similar functionality. Secondly, while a Tcl_Encoding may be more convenient for Tcl_UtfTo* and friends, it is less so for channel operations. Tcl_SetChannelOption takes encoding names, not Tcl_Encoding as the values for the -encoding option, so you can say

Tcl_SetChannelOption(chan, "-encoding", Tcl_GetEncodingNameForUser(&ds))
(or something similar)

Given Tcl_Encoding and the encoding name can be converted in both directions, it is six of one and half-a-dozen of the other, one being easier for one set of Tcl functions and the other for another set. I went with the encoding name because it is the more fundamental operation and consistent with Tcl_GetEncodingFromEnvironment(). Having said that I have no objection to providing both.

Of course, the above does not apply if your comment about Tcl_GetEncoding... being a bad API was based on some other factor I have not considered. Can't really tell unless you are more specific.

Now, with regard to the mingw msvcrt comment...

It seems to me from your comment about GetACP() in MingW that you think I was suggesting the manifest would not work in MingW. That is not so. GetACP() will work the same way and return utf-8 in the presence of a manifest but the problem is MSVCRT does not support UTF-8.

I do not know if you read the link that I had referenced in the TIP https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt

To quote from there - It doesn't support the UTF-8 locale ("It" being MSVCRT)

When the official release document says MSVCRT does not support UTF-8, I take that at face value. That is why I did not bother to test it. Presuming the tests you reference are the ones you added for TIP 716, they indicate that UTF-8 works for one particular configuration of mingw for one version of gcc for two specific functions (fopen and chmod I think) for one specific west european character. You are free to presume that means msvcrt has no issues with UTF-8. I, however, prefer to go with the official statement and not presume success of one small test case is proof.

So I will keep that reference in the TIP. I can however add your comment that despite the official MSys position you believe MSVCRT works fine based on the tests you did.

As an aside, I do not understand why you are raising the issue of passing FILE* between different C runtimes? When did I ever raise that issue and what does it have to do with the current TIP 716 discussion? Don't we have enough confusion without adding completely irrelevant considerations?

/Ashok




________________________________
From: Jan Nijtmans
Sent: Monday, May 5, 2025 3:20 PM
To: apn...@ya...
Cc: tcl...@li...
Subject: Re: [TCLCORE] TIP 716 ready for comments

Op ma 14 apr 2025 om 06:52 schreef Ashok:
>
> TIP 716: New command "encoding user", remove UTF-8 manifest setting on Windows is ready for comments. It proposes reversion of a change made in 9.0 to tclsh and wish Windows manifests while keeping compatibility with 9.0.{0,1}.

Let me share two more reservations on the TIP text:
1) Two times in the TIP, "MingW msvcrt" builds are mentioned as
    behaving differently from ucrt builds. Quoting:
        "The key difference with respect to the current implementation
issue that this does not impact extensions that call GetACP solving
the first issue listed above, or using MingW msvcrt builds."
    "An example is components built with MingW64 gcc using the msvcrt runtime"

    This is not correct. I did test that (see ticket
           https://core.tcl-lang.org/tcl/tktview/8ffd8cabd1)
     which was done using a MingW msvcrt build. The
     The GetACP() function functions exactly the same.
     There is an issue mixing different runtimes, but that's
     related to using stdin/stdout: different runtimes each
     have their own FILE implementation. So, opening
     a FILE in an extension using UCRT and writing it
     from other extension using MSVCRT is expected
     to crash. My suggestion: remove it from the TIP
     text (or provide a testcase proving your point, I
     will be happy to try it in my environment)

2) There is no usecase for exporting Tcl_GetEncodingNameForUser()
     I tried to use it, but the way it is now it's a bad idea. I am
     thinking about a separate TIP for a more useful approach.
     Stay tuned.

The reason I suspect that you didn't do any tests in the
MinGW msvcrt environment is that compilation in this
environment failed:
    <https://github.com/tcltk/tcl/actions/runs/14725688360>
I corrected that here, as a free service ;-)
     <https://core.tcl-lang.org/tcl/info/479fc6ad0dff8cdd>

Hope this helps,
          Jan Nijtmans

[TCLCORE] TIP 719: ready for vote "new states to customize ttk::treeview and ttk::notebook widget images in dependency of the state of items"

[Harald O. <har...@el...>]

Dear Tk team,
TIP 719:
https://core.tcl-lang.org/tips/doc/trunk/tip/719.md
was seen as ready in the bi-weekly telco.

Purpose:
- new tk states to customize ttk::treeview and ttk::notebook images.
In Tk 8.6, the states user1/2 were used are abused. This was removed in 
Tk9.0, and now comes back in an extended way to allow:

ttk::style element create Treeitem.indicator \
               image [list $image_for_closed \
                   open $image_for_open \
                   leaf $image_for_no_children \
               ]

So, this is a kind request for comments.
I would specially appreciate a review by Csaba and Francois.

If there are no issues, expect a vote on:
12th of May for one week.
So, that it may be in Tk9.1a0.

Take care,
Harald

[TCLCORE] Notes of biweekly telco of 2025-05-05

[Harald O. <har...@el...>]

Dear Tcl/Tk team !

It is release time. TCL/Tk 9.0.2 and TCL/Tk 9.1a0 are planned this 
month. Please get your input ready now!

Thanks for participating at the great telco of today.
Here are the notes, which are mostly opinions and no decisions.

1) TIP 715: platforms for 9.1
Make a living document.
Vote on it when TCL9.1.0 is released.

Add comment in the beginning:
This is an active discussion.
Finalisation planned with release of the version.
Maintainers ok.

2) TIP 717: Tcl_AttemptCreateHashEntry
In favor.
Implementation ready. Please review.

3) TIP 716: encoding user and MS-Windows manifest removal
"Make the elephant back a mouse".
Many linked issues, partly bugs.
May have a switch solution with/without manifest

Proposed "exec -encoding xxx" is eventually not needed, if utf-8 is 
given in manifest.

4) TIP 698: Negative screen distances
Most positive, comes from TkInter

5) TIP 714: photo image format information
Clean way is new registration function.
Much work.

6) TIP 626: Command argument count > INT_MAX (2^31)
Most remarks are mostly bugs.
Many linked issues are WIP.
Great, that it is looked into.
Also, memory error instead panic is linked. TIP 717 is a consequence of 
this work.
May be voted later.

7) TIP 302: after independent on current time
It is a TIP for 20 years.
Technically it is a bugfix, but it has many consequences.

Don't disturb the function of a long time command.
A fully new command would be appreciated, not a new switch.
TIP: 302: new switch: after -robust
New command: intime (this is an example)

8) TIP 719: New tk states for ttk::treeview and ttk::notebook images
TIP ok.
Warning for vote to send.

9) TclLog2 improvements: https://core.tcl-lang.org/tcl/info/fd1585e2a1a8f890
Moving foreward just fine.
I don't like undefined behaviour? Define output for 0 input on all 
platforms.
Aim is performence. It is internal to TCL.

10) New bytecodes (Donal): 
https://core.tcl-lang.org/tcl/tktview/aa10216459cdfe0fd3eab0bbab949e611bd7336e
I like it!
It is more useful than I thought!
Performance boost is supposed.
Aim is not only performance but clearness.
It is for 9.1.
It should be in 9.1a0 to find issues.
It is an extension. Concurring byte-codes are deprecated, but not removed.

11) Floating point numbers overflow: 
https://core.tcl-lang.org/tcl/info/42d14c495a096159
May be a bug in Libtommath and may go there.
Free to merge.

12) Block cursor: https://core.tcl-lang.org/tk/info/5d0bc3cfec7c1adb
Others may test.

13) Orphan packages repository
Ongoing. Seen as good aproach.

13a) Release plan
Release this month.
9.0.2 first
Then 9.1a0

9.1a0 candidates:
- New bytecode is a good candidate
- TIP 712: Positive switches for subst
   -> pos/neg together? Error message prefered.

14) Conference status
15 participants. COnference will take place.

Other meetings:
13th of May 18:00 UTC: mothly meetup (I am available and may start)
19th of May 12:00 UTC: UTC Monthly Virtual Meetup on same jitsi (I am 
eventually not available)

---
Off meeting:

as sqlite was present:
- latest tickets were discussed
- Christian Werners dict proposal for tdbc::swqlite3 was discussed:
   https://core.tcl-lang.org/tdbcsqlite3/info/7822a89cda
  
https://sqlite.org/forum/forumpost/585ebac2c48f1411a81bb1e428bce3caf734e7c352521044bc383802cf734fb5
   More understanding is required.

---
Thanks for all !
Harald

Re: [TCLCORE] TIP 716 ready for comments

[Jan N. <jan...@gm...>]

Op ma 14 apr 2025 om 06:52 schreef Ashok:
>
> TIP 716: New command "encoding user", remove UTF-8 manifest setting on Windows is ready for comments. It proposes reversion of a change made in 9.0 to tclsh and wish Windows manifests while keeping compatibility with 9.0.{0,1}.

Let me share two more reservations on the TIP text:
1) Two times in the TIP, "MingW msvcrt" builds are mentioned as
    behaving differently from ucrt builds. Quoting:
        "The key difference with respect to the current implementation
issue that this does not impact extensions that call GetACP solving
the first issue listed above, or using MingW msvcrt builds."
    "An example is components built with MingW64 gcc using the msvcrt runtime"

    This is not correct. I did test that (see ticket
           https://core.tcl-lang.org/tcl/tktview/8ffd8cabd1)
     which was done using a MingW msvcrt build. The
     The GetACP() function functions exactly the same.
     There is an issue mixing different runtimes, but that's
     related to using stdin/stdout: different runtimes each
     have their own FILE implementation. So, opening
     a FILE in an extension using UCRT and writing it
     from other extension using MSVCRT is expected
     to crash. My suggestion: remove it from the TIP
     text (or provide a testcase proving your point, I
     will be happy to try it in my environment)

2) There is no usecase for exporting Tcl_GetEncodingNameForUser()
     I tried to use it, but the way it is now it's a bad idea. I am
     thinking about a separate TIP for a more useful approach.
     Stay tuned.

The reason I suspect that you didn't do any tests in the
MinGW msvcrt environment is that compilation in this
environment failed:
    <https://github.com/tcltk/tcl/actions/runs/14725688360>
I corrected that here, as a free service ;-)
     <https://core.tcl-lang.org/tcl/info/479fc6ad0dff8cdd>

Hope this helps,
          Jan Nijtmans

[TCLCORE] TCL/Tk biweekly telco on 5th of May, 2025 12:00 UTC on https://meet.jit.si/TclMonthlyMeetup (updated)

[Harald O. <har...@el...>]

(resent with updated agenda)

Dear Tcl/Tk team,

please allow me to invite anybody to the telco:
Where: https://meet.jit.si/TclMonthlyMeetup
When: 2025-05-05 12:00 UTC

Possible agenda:
1) TIP 715: platforms for 9.1
2) TIP 717: Tcl_AttemptCreateHashEntry
3) TIP 716: encoding user and MS-Windows manifest removal
4) TIP 698: Negative screen distances
5) TIP 715: photo image format information
6) TIP 626: Command argument count > INT_MAX (2^31)
7) TIP 302: after independent on current time
8) TIP 719: New tk states for ttk::treeview and ttk::notebook images
9) TclLog2 improvements: https://core.tcl-lang.org/tcl/info/fd1585e2a1a8f890
10) New bytecodes (Donal): 
https://core.tcl-lang.org/tcl/tktview/aa10216459cdfe0fd3eab0bbab949e611bd7336e
11) Floating point numbers overflow: 
https://core.tcl-lang.org/tcl/info/42d14c495a096159
12) Block cursor: https://core.tcl-lang.org/tk/info/5d0bc3cfec7c1adb
13) Orphan packages repository
14) Conference status

Other meetings:
13th of May 18:00 UTC: mothly meetup (I am available and may start)
19th of May 12:00 UTC: UTC Monthly Virtual Meetup on same jitsi (I am 
eventually not available)

Thank you all,
Harald

Re: [TCLCORE] New Bytecode Branch Ready for Review

[Harald O. <har...@el...>]

Donal,
I allowed me to put the provided information into a ticket:

https://core.tcl-lang.org/tcl/tktview/aa10216459cdfe0fd3eab0bbab949e611bd7336e

I just fear that we loose information when this stays in the core list.
It is IMHO important reference information.

Testers may contribute to the ticket...

THanks for all,
Harald

Am 04.05.2025 um 17:06 schrieb Donal Fellows:
> A side note: the INST_JUMP_TABLE_NUM instruction will enable the 
> addition of a new mode of operation for [switch] that I've been thinking 
> about for a while: switching on /integer /equality, which I've seen the 
> need for in handling things like switching on the number of arguments 
> passed to a procedure. (It can't be safely done now because we use the 
> wrong sort of equality testing.) I'll TIP that up once the instruction 
> to make it practical hits the trunk.
> 
> Donal.
> 
> ------------------------------------------------------------------------
> *From:* Donal Fellows
> *Sent:* Friday, May 02, 2025 17:24
> *To:* Tcl Core
> *Subject:* [TCLCORE] New Bytecode Branch Ready for Review
> 
> The branch for the new bytecodes (with the wonderfully wieldy name no- 
> variable-width-instruction-issue) is ready for someone to give it a bit 
> of a review.  It's quite a large one, so here's a summary:
> 
> [...]
> 
> The replacement for INST_RETURN_CODE_BRANCH is INST_JUMP_TABLE_NUM that 
> is a general numeric-keyed jump table. (Take note for the Tcl Compiler 
> and TBCLoad: there's a new AUX type).
> 
> [...]
> 
> Some of the operations are made available to 
> [tcl::unsupported::assemble]. Only the error prefix comparator isn't; 
> that's got safety requirements on its argument that I'm not bothering to 
> make the assembler understand.
> 

Re: [TCLCORE] New Bytecode Branch Ready for Review

[Donal F. <don...@ma...>]

A side note: the INST_JUMP_TABLE_NUM instruction will enable the addition of a new mode of operation for [switch] that I've been thinking about for a while: switching on integer equality, which I've seen the need for in handling things like switching on the number of arguments passed to a procedure. (It can't be safely done now because we use the wrong sort of equality testing.) I'll TIP that up once the instruction to make it practical hits the trunk.

Donal.

________________________________
From: Donal Fellows
Sent: Friday, May 02, 2025 17:24
To: Tcl Core
Subject: [TCLCORE] New Bytecode Branch Ready for Review

The branch for the new bytecodes (with the wonderfully wieldy name no-variable-width-instruction-issue) is ready for someone to give it a bit of a review.  It's quite a large one, so here's a summary:

[...]

The replacement for INST_RETURN_CODE_BRANCH is INST_JUMP_TABLE_NUM that is a general numeric-keyed jump table. (Take note for the Tcl Compiler and TBCLoad: there's a new AUX type).

[...]

Some of the operations are made available to [tcl::unsupported::assemble]. Only the error prefix comparator isn't; that's got safety requirements on its argument that I'm not bothering to make the assembler understand.

[TCLCORE] TIP 719: new states to customize ttk::treeview and ttk::notebook widget images in dependency of the state of items.

[Harald O. <har...@el...>]

Dear Tk team,
please find:
https://core.tcl-lang.org/tips/doc/trunk/tip/719.md

Ready for comments.

Thanks for Eric for the issue and Jan for the great proposal.

I think, in the ttk::notebook, there was Csaba involved.

Take care,
Harald

Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1

[Harald O. <har...@el...>]

Am 03.05.2025 um 01:53 schrieb Keith Nash:
> After 2033-01-01, Tcl 9.1 must write a warning to the system log and to
> stderr whenever Tcl starts, and also if commands such as [clock], [file
> mtime] are called with arguments corresponding to negative time_t or
> return a result with this property, in the following circumstances:
> 
> * On a host that has no system calls for 64-bit time (e.g. 32-bit Linux
> kernels earlier than 5.6)
> 
> * On a system on which the length of time_t has been tested and found
> to be 32-bit (N.B. even a libc that is nominally compliant may have
> been built with a compatibility option to use 32-bit time_t).
> 
> * On a system on which a 64-bit time operation has been tested at
> startup and has failed (e.g. creating a file and changing its mtime to
> a date in 2040).

Dear Keith,
thanks for volontaring to maintain, that is highly appreciated.
I have removed the 32 bit time_t requirement to 9.1.
I see also those points to make the code easier and to remove code for 
32 bit and 64 bit. If it is not the moment, that is ok.
I have put your text for a future version of TCL, as 9.1 will probably 
out of maintenance in 2033.

Dear Steve,
thanks for your contribution about tested Linux systems.
Could you correct the list?

Dear Pietro,
can you give me some wordings to describe the "FreeBSD" ? I have never 
heard this system, sorry. Is this the same as "BSD" ? Well, stupid 
questions, sorry. Or "Debian" ? My Proxmox server is running "Debian", 
another mystic Linux variant...
Do I need a version/platform with "FreeBSD", like Arm64 or 12.0 ?
Or can you directly correct the TIP?

Thanks for all,
Harald

Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1

[Keith N. <k.j...@us...>]

Hi All,

1. MAINTAINERS

On a different aspect of maintenance: the default assignees for Tcl
tickets could be updated.  The aim is that when a ticket is created, an
email is sent to an appropriate person.

I volunteer to be the default assignee for these Tcl categories:

[29] http Package
[33] Safe Base

If the ticket is more appropriate for somebody else (e.g. DKF for
cookies in [29], namespace ensembles in [33]) I will redirect the
ticket to them.

2. 2038 and 64-bit time_t

My main concern is to not make non-compliant systems unusable (yet). 
We have 13 years until the 2038 rollover, and for comparison we did not
decide to eliminate all Y2K-non-compliant systems as early as 1987.

I do not mind if the language is changed to avoid "may".

I suggest the following for Tcl/Tk on Linux/UNIX/BSD systems:

{
After 2033-01-01, Tcl 9.1 must write a warning to the system log and to
stderr whenever Tcl starts, and also if commands such as [clock], [file
mtime] are called with arguments corresponding to negative time_t or
return a result with this property, in the following circumstances:

* On a host that has no system calls for 64-bit time (e.g. 32-bit Linux
kernels earlier than 5.6)

* On a system on which the length of time_t has been tested and found
to be 32-bit (N.B. even a libc that is nominally compliant may have
been built with a compatibility option to use 32-bit time_t).

* On a system on which a 64-bit time operation has been tested at
startup and has failed (e.g. creating a file and changing its mtime to
a date in 2040).

We shall review this policy in 2032.
}

It is clearly a good thing to start thinking early about 2038, but I
hope that we do not yet need to exclude systems that use glibc older
than 2.34, or a 32-bit Linux kernel older than 5.6: the age of suchsystems can be less than four years or five years respectively.

Best wishes,

Keith.


On Fri, 2025-05-02 at 08:15 +0200, Harald Oehlmann wrote:
> I think, the main point is a maintainer, which commits to test
> releases 
> and to check failure tickets.
> 
> I have changed the TIP in this way and propose a wiki page with
> maintainers.
> 
> Is this a good idea?
> 
> About the time_t 64 bit, I did not do any modifications. For me, the 
> post had to many "may" like "a warning may be issued". Is this
> warning 
> implemented? Or shall a warning be required?
> I have no opinion on Linux and understand that it is a very moving 
> target. It may disqualify small platforms like controllers which 
> eventually do not have a RTC at all and the time is irrelevant.
> 
> Thanks for all,
> Harald
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] New Bytecode Branch Ready for Review

[Donal F. <don...@ma...>]

Hi everyone,

The branch for the new bytecodes (with the wonderfully wieldy name no-variable-width-instruction-issue) is ready for someone to give it a bit of a review.  It's quite a large one, so here's a summary:

The branch deprecates all operations that have a single byte for a jump offset, a variable index or an argument count (except for string concatenation). These are replaced with versions that use four-byte offsets/indices/counts. The affected instructions are:

  *
INST_PUSH1
  *
INST_INVOKE_STK1
  *
INST_LOAD_SCALAR1
  *
INST_LOAD_SCALAR_STK (wasn't issues by our compiler anyway)
  *
INST_LOAD_ARRAY1
  *
INST_STORE_SCALAR1
  *
INST_STORE_SCALAR_STK (another never-generated one)
  *
INST_STORE_ARRAY1
  *
INST_INCR_SCALAR1
  *
INST_INCR_ARRAY1
  *
INST_INCR_SCALAR1_IMM
  *
INST_INCR_ARRAY1_IMM
  *
INST_APPEND_SCALAR1
  *
INST_APPEND_ARRAY1
  *
INST_LAPPEND_SCALAR1
  *
INST_LAPPEND_ARRAY1
  *
INST_RETURN_CODE_BRANCH
  *
INST_TAILCALL
  *
INST_TCLOO_NEXT
  *
INST_TCLOO_NEXT_CLASS

Some of these are replaced with their existing 4-byte versions. Some have new versions (now with 4-byte args):

  *
INST_INCR_SCALAR
  *
INST_INCR_ARRAY
  *
INST_INCR_SCALAR_IMM
  *
INST_INCR_ARRAY_IMM
  *
INST_TAILCALL
  *
INST_TCLOO_NEXT
  *
INST_TCLOO_NEXT_CLASS

The replacement for INST_RETURN_CODE_BRANCH is INST_JUMP_TABLE_NUM that is a general numeric-keyed jump table. (Take note for the Tcl Compiler and TBCLoad: there's a new AUX type).

I also add these new opcodes:

  *
INST_SWAP - Swap the top two items on the stack.
  *
INST_ERROR_PREFIX_EQ - Special equality for [try/trap]
  *
INST_TCLOO_ID - Get the creation ID of an object; not common, but easy
  *
INST_DICT_PUT - [dict replace] as an opcode, simplifying [try]
  *
INST_DICT_REMOVE - [dict remove] as an opcode, to fill out the suite available
  *
INST_IS_EMPTY - access to Tcl_IsEmpty (and enhancements to bytecode optimiser to use it)

Some of the operations are made available to [tcl::unsupported::assemble]. Only the error prefix comparator isn't; that's got safety requirements on its argument that I'm not bothering to make the assembler understand.

As far as I can tell, the test suite is passing. At least on Windows and excluding some tests that don't run on this laptop.

I have not performance-tested the code!  This machine has aggressive speed-stepping forced on by institutional group policy. Sorry about that.

Donal.

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Jan N. <jan...@gm...>]

Op vr 2 mei 2025 om 14:05 schreef Harald Oehlmann:
> Nevertheless, Tcl_InitStringRep:
>     *   is not documented in the docs
>     *   the introducing TIP 445 documents the NULL as return on memory
> error.
>
> So, I think that this is ok and no "attempt" version of this call is
> required. If the function currently paniced, it was an error following
> the TIP.
...
> Does this sounds right?

Yes, that sounds right. I'll leave the TIP as it was.

Thanks for the insight!
       Jan Nijtmans

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Harald O. <har...@el...>]

Am 02.05.2025 um 13:22 schrieb Jan Nijtmans:
> Op do 1 mei 2025 om 11:22 schreef Jan Nijtmans:
>>
>> This is a CFV warning for TIP #717. for Tcl 9.1+:
>>      New function: Tcl_AttemptCreateHashEntry()
>>      <https://core.tcl-lang.org/tips/doc/trunk/tip/717.md>
> 
> Since it turns out that Tcl_InitStringRep() has the
> same problem, and can benefit from the same
> solution, the title changed:
>     New functions: Tcl_AttemptCreateHashEntry(), Tcl_AttemptInitStringRep()
>     <https://core.tcl-lang.org/tips/doc/trunk/tip/717.md>
> 
> If you think this is a bad idea, speak up now. If not,
> I'll start the vote in a few days.
> 
> Regards,
>           Jan Nijtmans
Jan,
I generally appreciate the "attempt" functions to get fails instead 
panic on memory issues.

Nevertheless, Tcl_InitStringRep:
    *   is not documented in the docs
    *   the introducing TIP 445 documents the NULL as return on memory 
error.

So, I think that this is ok and no "attempt" version of this call is 
required. If the function currently paniced, it was an error following 
the TIP.

Tcl_CreateHashEntry is different. It existed in Tcl 8.6 and a 
NULL-return on memory issues is not documented.
So, this is a good candidate to be member of the Atempt family.

Does this sounds right?

Harald

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Jan N. <jan...@gm...>]

Op do 1 mei 2025 om 11:22 schreef Jan Nijtmans:
>
> This is a CFV warning for TIP #717. for Tcl 9.1+:
>     New function: Tcl_AttemptCreateHashEntry()
>     <https://core.tcl-lang.org/tips/doc/trunk/tip/717.md>

Since it turns out that Tcl_InitStringRep() has the
same problem, and can benefit from the same
solution, the title changed:
   New functions: Tcl_AttemptCreateHashEntry(), Tcl_AttemptInitStringRep()
   <https://core.tcl-lang.org/tips/doc/trunk/tip/717.md>

If you think this is a bad idea, speak up now. If not,
I'll start the vote in a few days.

Regards,
         Jan Nijtmans