PR# 18670 {HASH_TABLE}.correct_mismatch fails to correct 'control' attribute

The HASH_TABLE class of EiffelStudio-5.7 used a 'control' attribute that was assigned to constants (e.g. Conflict_constant) whose values were assigned using "INTEGER is unique". In EiffelStudio-7.3, these constants are explicitly assigned (e.g. "conflict_constant: INTEGER = 1") to powers of 2 (e.g. 1, 2, 4, 8). Hence the acceptable values of the 'control' attribute have changed. No 'correct_mismatch' mechanism was put into place since this change to ensure that retrieved objects of type HASH_TABLE have their representation of 'control' corrected.

As a result, I cannot use my retrieved objects of HASH_TABLE because they now violate the class invariant 'special_status'.

I've looked at the history of HASH_TABLE and cannot find a trace of the change of values for the constants made by us. It seems to have originated from a misunderstanding between Eiffel Software's implementation at the time and the code we provided to the FreeELKS project on which EiffelBase is now built upon.

There are 2 solutions that I can see:
- revert the constants to their original value
- create a mismatch by adding another attribute. I could suggest renaming `hash_table_version_57' into `hash_table_version_57_bis' but then it would make it hard to recover those objects from the regular version of EiffelStudio as this would require changes in the `correct_mismatch' as well.

Sorry: I am using the compatible EiffelBase of 7.3. Perhaps that one is not structurally different from 5.7, even though the values attained by 'control' are different? They appear the same to me, except for syntax changes and a detachable added to a declaration.

I'm not sure to understand. The HASH_TABLE format in 5.7 is completely different from the existing one, so it should trigger a mismatch correction all the time.

Unfortunately, simply adding something to 'correct_mismatch' will not fix the problem because, as far as I can tell, the representation of the class did not change: 'control' is still and INTEGER. Thus, mismatch correction will not be triggered for non-compliant classes.

In my present case, my stored system uses a class which inherits from HASH_TABLE, so I may be able to accommodate the problem by changing that class to trigger mismatch correction. However, customers who have stored HASH_TABLE objects directly are going to be impacted. This might include me, as I have not worked through everything yet.

That's indeed correct we did not added `control' in `correct_mismatch' because this is a value that doesn't need to be persisted so the value is irrelevant. But we certainly overlooked the invariant.

So I recommend that in your local version of `correct_mismatch' you set `control' to `0'. This will be thus fixed in the next revision.

Do you need the fix also for the compatible mode?