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

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

Yes, I mistakenly said 9.0.2 when I should have said 9.1. That was not (clearly, I think) the core of my post though and not really relevant. The rest of my query still applies.

A Tcl extension built against 9.0 was assured Tcl_CreateHashEntry returned non-NULL. The same binary loaded into 9.1 is no longer offers that assurance.

To me that is an incompatibility. Whether it matters or not is a separate point discussed next.

Perhaps an incompatibility can be ignored because (a) it only occurs in very rare situations or (b) because in your words "shit already happened" in failures like memory allocation. The reason for preferring Tcl_Panic as opposed to just crashing at some later point on null pointer access is that the former gives a clear reason for failure on a crash as opposed to a null pointer at some random point in further execution. If that was not the case, Tcl would never do allocation checks and explicitly panic! Just continue and let the crash happen on the next attempted access to the returned null pointer!

In fact, by that logic, there really is no need for 717 and Tcl_AttemptHashEntry at all. You can just change Tcl_CreateHashEntry semantics to allow NULL returns. Callers that check can take appropriate action and those that don't will crash instead of panic'ing. But the "shit already happened" so how does it matter 🙂

Having said all that, this does not change my vote on 717 because of the (a) above - it will only happen for the case I laid out, not for an extension built against 9.1.

/Ashok
________________________________
From: Jan Nijtmans <jan...@gm...>
Sent: Thursday, May 8, 2025 1:18 PM
To: Ashok Nadkarni <apn...@ya...>
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

Op do 8 mei 2025 om 06:40 schreef Ashok Nadkarni:
> Now when the binary extension, *compiled against 9.0.0*, is loaded into 9.0.2 (with TIP 717), that will directly call CreateHashEntry which will then (potentially) return NULL instead of panicing thereby breaking the contract.
>
> Am I right or what am I missing?

You are missing 2 things:
1) TIP #717 is for Tcl 9.1, _not_ for 9.0.2. It's not a good idea to
add a stub entry in a patch release.
2) The difference in behavior only occurs in case of a memory
overflow, so the shit already happened.

Does that help? Or do you want me to explain through a realistic scenario?
What exactly is your worry?

Regards,
       Jan Nijtmans