Three strands of work.
Build warnings
--------------
Top-level build warnings are down from roughly 2700 to roughly 230, and
nothing fatal to GCC 14/15 remains -- those promote
-Wimplicit-function-declaration, -Wincompatible-pointer-types,
-Wint-conversion and -Wimplicit-int from warnings to errors, which is what
the Ubuntu 26.04 build reports were hitting.
Mostly noise (sign-compare, unused-but-set, missing prototypes, dead
declarations), but some real bugs came out of it, including several places
passing a long* where an int* was expected. On LP64 that leaves the top
four bytes of an XDR *_len uninitialised; 4GL 'integer' maps to C 'long'
while the XDR members are u_int, so it turned up five separate times.
Also added svn:keywords=Id to the modules that had lost it.
4GL object system
-----------------
Inheritance was broken in a way that made most of it unusable, plus two
older bugs found while testing the fix:
* objData->base.objectid is not a 4GL variable, so the root-scanning
collector could not see it and disposed of a parent while a live child
still pointed at it. The first inherited method call after that failed.
Objects now hold a counted reference on their parent: refCnt counts
references held by other objects, the generated constructor/destructor
inc/dec it, and the collector only disposes when no 4GL variable refers
to an object AND its refCnt is 0. Fixing this fixed inheritance, castTo
and polymorphism together.
* Destructors are registered as "<type>.~" but A4GL_destroy_object looked
for "<type>.-", so it had always been a silent no-op.
* Class methods pushed a call frame on entry but only popped it on an
explicit RETURN -- printPopFunction was commented out in the class
epilogue. Every call to a method that fell off the end leaked a frame,
giving "Function calls too deep" after ~2000 calls. Plain functions were
always correct; this was specific to classes.
* castTo could not be reached from 4GL at all. The lookup is a plain
strcmp and the compiler lowercases method names, but only ":X.castTo"
was registered, so "let r = s.castTo(...)" fell through to
RouteToParent and walked off the top of the chain. There are now two
registrations with different calling conventions: ".castTo" returns the
object id (what getObject needs for an implicit upcast like "let f = m")
and ".castto" pushes it (the normal 4GL convention).
* Polymorphic overloads resolved backwards. getSigForTopOfStack built the
signature from the top of the stack, which is the LAST argument, while
the compiler registers signatures in declaration order -- so
f(integer,char) dispatched to f(char,integer). Only visible with mixed
parameter types, which is why the existing sample never showed it.
New samples in tools/test/OO exercising a three-level chain (shape <-
rect <- square): method resolution, castTo, refcounts and object lifetime
under churn. tools/test/OO/README updated.
Embedded Python
---------------
Optional object(python), implemented in C but registered like a 4GL class,
so it is used the same way:
define p object(python)
let p = python.new()
call p.import("math")
display p.call("math.pow", 2, 10)
Methods: new, import, addpath, available, run, eval, call, set, get,
lasterror, version. Each object gets its own namespace. import/addpath
exist so module names and paths are passed as values rather than pasted
into Python source; available() reports whether a package could be
imported without importing it and without setting the error status, so a
Python package can be an optional dependency of a 4GL program.
configure detects an embeddable Python (pkg-config python3-embed, then
python3-config --embed) and link-tests it before enabling anything:
./configure --with-python / --without-python / (auto by default)
With no python3-dev the implementation compiles away, nothing links
against libpython, and object(python) reports that support was not built
in. Python's headers go on the include path for python.c alone, since it
ships object.h, token.h and compile.h which would otherwise shadow ours.
Documented in docs/README-Python.txt, example in
tools/test/OO/test_python.4gl.
Verified: full build clean in both configurations, tools/test builds, and
the OO samples pass.
