PR# 19669 Runtime [?] seeing wrong object types

Problem Report Summary
Submitter: jimmy.johnson
Category: Compiler
Priority: Medium
Date: 2020/09/08
Class: Support
Severity: Critical
Number: 19669
Release: GPL Edition - macosx-x86-64
Confidential: No
Status: Analyzed
Environment: mac
Synopsis: Runtime [?] seeing wrong object types

Reposted here because the original report posted on 2020/06/04 disappeared.  I also removed references to external library and hopefully attached a working zip file.

This started as an academic exercise to develop an Eiffel-only solution for big numbers.  My jj_big_numbers library depends on another set of classes called jj_naturals.  Cluster jj_naturals contains a set of classes which override the NATURAL_xx_REF classes.  The idea was to get a common ancestor to all the natural classes, setting between NUMERIC and the NATURAL_xx classes.  
          NATURAL_8_REF      -- my class
          NATURAL_16_REF    -- my class
          NATURAL_32_REF    -- my class
          NATURAL_64_REF    -- my class
JJ_NATURAL adds some bit operations and convenience features and allowed for generic classes that operate on NATURALs.  (You can look at for a project that seems to work just fine when using these classes.)

Class JJ_BIG_NATURAL [G -> JJ_NATURAL] tests that assumption, but seems to be failing in ways that I cannot understand.  So,
1)  Can the above inheritance structure work?  I know that sometimes things will compile but not work as a layman might think.  (e.g. a few years ago I tried to modify ANY by adding attributes which seemed okay but failed during runs)
2)  What is the cost of the above?  Is it slower?  How much?
To Reproduce
Run autotest on BIG_NATURAL_8_TESTS.  I am only concerned about two failing tests:  1) `is_negative' and 2) `from_array'.  I think my generics and override classes confuse the runtime...

Under demo run big_natural_demo and run autotest.

In BIG_NATURAL_TESTS see feature `run_all'.  It describes the failures in `set_with_array' and `is_negative'.
Notice that `is_negative' follows same format as `is_zero' which does not fail.  ??

4) Test `is_negative' fails on my precondition "target_closed".  Why?  Other tests that follow the same pattern work just fine?
5) Test `set_with_array' gives incorrect results.  In fact, feature `set_with_array' from JJ_BIG_NATURAL shows funny results when paused in the debugger.  After executing the line "d := a_array [i] ",  `d' shows a different value than what the debugger shows to be in `a_array [i]'  ???
Problem Report Interactions
From:jimmy.johnson    Date:2020/09/13    Status: Analyzed    Download   
First, let me apologize for not seeing the filter buttons at the top of the page.  I now see the response.  I suspected that modifying the basic types may be causing problems.  Too bad, because it allowed me to test [manually] with 8-bit numbers and easily change an implementation to 32- or 64-bit numbers (and I thought a common ancestor for all the natural numbers was more elegant, even if the work-arounds were not.)  I guess I can put the additional functionality in a utilities class.

Second, sorry my email changed.  I tried to update it but I never got an email response with an activation-code.  Maybe I can call.

Third, EiffelStudio 20.05 on my iMac keeps crashing, so I am still using the 19.05 version.

Fourth, I attached  a new file which I believe has no externals and simplified ecf file;  It does (and must) use  the override files.

Now to the original problem, for what it is worth:
1)  The test routine 'is_negative' still violates the precondition "target_closed" in the call t
Output truncated, Click download to get the full message

Attachment:     Size:640057
From:jfiat_es    Date:2020/09/09    Status: Analyzed    Download   
By the way, do you confirm you get the answer from the support team by email ?
Such email should be sent to 

Apart from that, I've just tried to run the autotest cases, for the jj_naturals_demo.ecf and nothing bad happened.
I also took time to update to EiffelStudio 20.05 

See the output, and the archive for 20.05

I had to modify the various .ecf to test, and then I was not able to compile the jj_big_numbers/demo project due to missing classes (MPZ_FUNCTIONS, ...).

Attachment: autotest_output.png     Size:174105
Attachment:     Size:68256
From:jfiat_es    Date:2020/09/09    Status: Analyzed    Download   
For info, the previous report did not disappeared, see  (the status was set to "won't fix", and by default in the reports list, the "closed" and "won't fix" report was not displayed. You can however display them by checking the related checkbox and press Filter).
I also confirm your archive is valid.

But I fear the answer you got on previous report remains the same.

From:jimmy.johnson    Date:2020/09/08    Download   
Attachments for problem report #19669

Attachment:     Size:77085