PR# 19648 Runtime seeing wrong object types

Problem Report Summary
Submitter: jimmy.johnson
Category: Compiler
Priority: Medium
Date: 2020/06/04
Class: Support
Severity: Serious
Number: 19648
Release: GPL Edition - macosx-x86-64)
Confidential: No
Status: Analyzed
Environment: mac
Synopsis: Runtime seeing wrong object types

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...

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/06/14    Status: Analyzed    Download   
Okay, I removed the external library.

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.  ??

Attachment:     Size:77086
From:alexk_es    Date:2020/06/12    Status: Analyzed    Download   
C compiler reports:
   Cannot open include file: 'gmp.h': No such file or directory

From:jimmy.johnson    Date:2020/06/09    Status: Analyzed    Download   
Any indication what is missing?  Which library or file, class, or function?

From:alexk_es    Date:2020/06/08    Status: Analyzed    Download   
There is a dependency on some external code. As of now, C compilation fails because of unknown functions, structures, etc.

From:jimmy.johnson    Date:2020/06/04    Status: Analyzed    Download   
Not really.  I think I included all the libraries needed (except base, of course), didn't I?

A week ago I made a small change to a previous iteration of the project and suddenly half the tests (even simple ones) were failing.  The faults seemed to be totally unrelated to the changes.

I suspect the problem has to do with my assumption that I can change the way NATURAL and NATURAL_REF classes work.  I say this because the two failures I pointed out fail in odd ways.  In `is_negative' I pass an agent with closed target which is a local variable just created, but when `is_negative' is run in the debugger, the type reported for the closed target is NOT the local but is the type of the enclosing class.  ???

From:alexk_es    Date:2020/06/04    Status: Analyzed    Download   
Would it be possible to prepare an example that does not require an external library and has only classes that do not work as you expect, please?

From:jimmy.johnson    Date:2020/06/04    Download   
Attachments for problem report #19648

Attachment:     Size:187663