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: 19.05.10.3187 GPL Edition - macosx-x86-64)
Confidential: No
Status: Won't fix
Responsible:
Environment: mac
Synopsis: Runtime seeing wrong object types
Description
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. NUMERIC JJ_NATURAL NATURAL_8_REF -- my class NATURAL_8 NATURAL_16_REF -- my class NATURAL_16 NATURAL_32_REF -- my class NATURAL_32 NATURAL_64_REF -- my class NATURAL_64 JJ_NATURAL adds some bit operations and convenience features and allowed for generic classes that operate on NATURALs. (You can look at https://github.com/boxer41a/jj_sha 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... Questions: 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
Basic classes are handled by the compiler differently from non-basic ones. In other words, code generated for these classes is different. Adding a feature to such a class usually involves changes to the compiler. This explains why not everything works as expected. In theory, it might be possible to change code generation (including both classic and .NET) and to support arbitrary code in basic classes. However, this functionality is rather niche and is not needed by most customers. Therefore, at the moment there are no plans to extend the compiler to address this limitation.
Anyone there?
Any luck opening the zip file from over a month ago?
The archive seems to be broken. Would you upload it again, please?
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. ??
C compiler reports: Cannot open include file: 'gmp.h': No such file or directory
Any indication what is missing? Which library or file, class, or function?
There is a dependency on some external code. As of now, C compilation fails because of unknown functions, structures, etc.
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. ???
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?