Aubit 4GL SVN-Code

P-code: register struct s_field_name and s_field_name_list

Same gap as sDependantTable - these are emitted into generated code for field
list handling but were not among the p-code compiler's predefined structs, so
any module using them stopped with "Structure s_field_name not found or
defined". Definitions taken from incl/a4gl_incl_4gldef.h.

Found by running the aubit4gltest corpus through the p-code pipeline using each
test's own run_* script for execution and comparison (the scripts invoke the
program as "$DBG ./prog.4ae" and diff the .out files the program writes against
their .expected). 42 of those tests are comparable that way and 21 now pass,
with multi-module tests linked by link_fgl - which did not fail once.

Make the P-code compiler and runner work; restore panel/form to the TUI link

P-code
------
P-code had never worked on a 64 bit build. bin/runner_fgl did not even get
built, and no 4GL module could be turned into p-code at all. It now compiles
and runs ordinary 4GL, and on the test programs used here its output is
byte-identical to the C backend.

The runner would not build: compilers/pcode/fgl_calls.h registered
&A4GLSTK_pushFunction, the v1 stack API, which was retired and is now a poison
macro in a4gl_4gl_callable.h. Updated to pushFunction_v2 / popFunction_nl - the
handlers for those shapes already existed. A4GL_swap_bind_stmt was also
declared char** in a4gl_sql.h and void** in a4gl_4gl_callable.h, so anything
including both headers could not compile; the implementation only saves and
restores an opaque struct BINDING *, so void** is correct.

Sizes and signs, all 64 bit issues:

* a4gl_htonl/a4gl_ntohl returned htonl()'s uint32_t as a long, which zero
extends on LP64, so every negative value written through the PACKED packer
came back positive - -1 read back as 4294967295. The x1element "no subscript"
marker was the first casualty. Fixed by sign extending through int32_t; the
bytes on disk are unchanged for values that fit in 32 bits, and readers only
look at the low 32 bits, so existing files still read correctly. The magic
numbers (0xa4fc2345 and friends) have their top bit set, so the two places
that compare them now do so at 32 bits.

* The p-code type model said a long and a pointer were 4 bytes while the runner
reads and writes both through a C long. Widening it alone was not enough:
get_var_ptr reported only a size, and the read/write dispatch keyed off it
with 4 meaning long and 8 meaning double - so an 8 byte slot looked like a
double and every variable read back as garbage. get_var_ptr now reports the
dtype as well, each width is read and written as itself, and DLONG/DDBL/DPTR
are sized from the real C types. This is what fixed accumulation across a
loop, char variables corrupting the heap, and the lost first element of an
array initialiser.

* A string literal's address was cast through (int) in common_eval.c, which
truncated it and crashed printf.

The p-code compiler skips every '#' line, so it never sees a #define. NULL,
LABEL_USED, fglvarchar, the 34 OP_* codes and the REPORT_* codes were all
unknown to it. The OP_* and REPORT_* values now come from the real macros via
compilers/pcode/op_lookup.c rather than being copied, so they cannot drift -
which is exactly what had happened to the predefined BINDING struct, six
members against the header's seven, and to REPORT_NOTHING.

A4GL_push_long and A4GL_push_int were still keyword-bound to constants, but
generated code pushes variables far more often. Retired the same way
A4GL_push_char and A4GL_push_variable already had been, so they resolve
through the runner's call table.

An unspecified array bound is held as -1, which was multiplied into a negative
total_size - and that is what the runner mallocs for a static, so loading any
module with a "char x[]=..." aborted. Sizes are now taken from the initialiser
where one is given.

On the generator side, several things emitted only for the C backend are not
parseable by p-code's cut down C grammar, and are now suppressed when
A4GL_doing_pcode(): forward declarations for functions, reports and MAIN;
the version helper (which lacks the A4GL_FUNCTION marker p-code requires);
and "(void) x;" between two declarations, which p-code's C89 grammar rejects.
_objData is emitted before the locals for the same reason. ERRCHK now passes
the module name as a string literal, which is what the grammar wants.
MARK_SCOPE_MODULE, which p-code switched on, prefixed declarations but not
uses, emitting "long L_total;" alongside "total=0;" in the same function.

Suppressing the MAIN prototype means an ordinary "MAIN ... END MAIN" program
now compiles to p-code, removing the constraint documented in
compilers/pcode/README.

TUI link
--------
m4/aubit_ui.m4 substituted CURSES_LIB_NAME="-lncurses". The old configure.in
set "-lform -lpanel -lncurses", and ui_curses/Makefile.in still expands
@CURSES_LIB_NAME@, so the rewrite alone dropped panel and form and left
libUI_TUI.so with an undefined update_panels - the TUI driver could not load,
which is why so much had to be run in CONSOLE mode. configure now detects
panel and form and lists them dependents-first.

Testing
-------
aubit4gltest, all 21 ranges, -esqli -tui, against a build of r12988 (the last
revision before the configure rewrite):

r12988 1098 run, 59 skipped, 35 failed
this 1098 run, 59 skipped, 33 failed

The two differences are tests 706 and 1413. Run individually, 706 passes on
both (it is flaky in batch), and 1413 - logical report layout - fails on
r12988 and passes here. No regressions.

For reference, with the TUI driver broken these runs managed 283 tests with
449 skipped and five ranges hanging on menu tests looping on EOF.

Build warning cleanup, object system fixes, embedded Python

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.

Fix the real bugs behind the remaining compiler warnings

These are the ones set aside earlier as "the interesting shortlist" - every
warning here was pointing at code that does not do what it was written to do.
A full clean build stays at exit 0 and drops from 754 to 721 warnings.

Memory:

- compilers/4glc/parsehelp.c: malloc(sizeof(expr_str)) followed by memcpy of
sizeof(l->list.list_val[a]) - the size of the *pointer*. It copied 8 bytes
and left the rest of the new expr_str uninitialised.
- lib/libaubit4gl/sql_common.c: A4GL_free_prepare() called
blank_any_cursors_using(sid) after free(sid). That function only compares the
pointer, so it now runs before the free - otherwise any cursor still holding
the sid keeps a dangling statement pointer.
- lib/libsql/odbc/sqlex.c: A4GL_debug("-%p", ptr) after free(ptr). Reading the
pointer value after the free is undefined even just to print it; logs first.
- lib/liblogical/processor/process_report.c: fclose() on a stream from popen().
Now pclose(), so the child is reaped and its status collected. The fwrite in
the copy loop was also inside an assert(), so a build with NDEBUG would have
dropped the copy entirely - it is now a separate statement.
- compilers/4glc/compile.c: two sprintf calls passing incl_path as both the
destination and the first argument. Overlapping source and destination is
undefined; they now format the suffix into a temporary and strcat it.

Logic that never ran, or always ran:

- compilers/4glc/lint.c: "whencode & 0x15 == WHEN_CALL" - 0x15 masks off bit 1
and WHEN_CALL is 2, so the WHENEVER ERROR CALL branch could never be taken and
lint never checked the named function existed. The action is the low nibble
(php.c uses & 0xf for the action, >> 4 for the condition), so it is now 0xf.
- compilers/4glc/lint.c: system_function_dtype() fell off the end without
returning. Callers test for -2, and the two other copies of this function
(calltree.c, prototypes.c) both end with return -2 - this one now does too.
- compilers/fcompile/dump_scr.c: get_attr_from_field() fell off the end when it
found nothing, returning whatever was in the register. Returns 0, which is
what its own "not applicable" path returns and what callers test for.
- lib/libaubit4gl/function_call_stack.c: "moduleName == '\0'" compared the
pointer against NULL, but its unset value is "" - so the no-module branch
never fired. Tests the string now.
- lib/libui/ui_xml/uilib/uilib.c and ui_json/uilib/uilib.c: "rval < 0" where
rval is the size_t returned by iconv(), which reports failure as (size_t)-1.
Conversion errors were silently ignored in both copies.
- compilers/4glc/variables_new.c: "if (idtype!=idtype)" - a self comparison, so
dead. What it meant is not recoverable; removed with a note.
- 16 -Waddress cases across sqlexpr.c, report.c, stack.c, mod.c, json.c, xml.c
and two generic_ui.c copies: tests on the address of a struct's char array,
which is never NULL. Each had a real test beside it (strlen, [0], or a
function call), so the redundant half is gone and the meaning is unchanged.

Format strings:

- compilers/4glc/prototypes.c: three fprintf calls passing arguments to format
strings with no conversions at all.
- tools/asql/parse.l: "%d" given strlen() and sizeof() results, ie size_t.

Left alone deliberately: compile_c.c's "arr_subscripts_len >= 0" was always true
on an unsigned member, but changing it to "> 0" would alter what happens for an
empty subscript list, so only the dead half was dropped.

Drop the Glade IDE from the default build

glade/ide and glade/ide/sqleditor are no longer built by "make". They have not
been used in years, and keeping them in the default target means everyone pays
for them: the sqleditor sources are a 2017 fork of the tools/asql ones that has
since drifted, and their generated code calls aclfgl_* functions in sibling
modules with no prototypes in scope - 32 diagnostics that GCC 14 and later
treat as errors rather than warnings. Fixing those properly means working out
why tools/asql does not have the same problem, which is not worth doing for a
component nobody runs.

Only the ALL list changes. The "glade" target itself is untouched, so "make
glade" still builds it for anyone who wants it, and "make clean" still cleans
it. Nothing else references it.

With this, a full clean build of the default target is free of every diagnostic
GCC 14+ turns into an error - in the compiler output and in the .warn files
4glpc writes, which is where the last few rounds of these were hiding. 49 .warn
files, none with a fatal diagnostic; build exits 0 at 754 warnings; asql,
adbload2 and the compiled 4gl test programs all still run.

Clear the GCC 14+ errors from the rest of corecompile: adbload2 and runforms

Continues r13011. The .warn files that 4glpc writes - which never reach the
build log - had the same class of problem in the two directories corecompile
reaches after tools/asql. Both are now free of diagnostics that GCC 14+ treats
as errors; a full clean build stays at exit 0.

tools/adbload2 (22 down to 0):

- process.ec and jtypes.c call runtime entry points with no prototype in scope.
Declared in a4gl_dbload_int.h rather than by including a4gl_libaubit4gl.h,
because that header defines A4GL_assertion as a two argument macro and
jtypes.c calls it with parenthesised arguments the preprocessor miscounts.
The block is guarded on _AUBIT_LIB_INCL_EXT_ so the translation units that do
include the header keep using its versions and do not get redundant
declarations.
- Forward declarations for the functions defined further down process.ec, and
for those in jtypes.c, which is #included near the bottom of it - so a
declaration in jtypes.c itself comes too late for callers above.
- Declaring A4GL_assertion turned up three calls that never matched it: one
passing no message at all, and two passing a printf-style format plus an
argument to a function that takes (int, char *) and does no formatting. They
now build the message with snprintf first.
- Three A4GL_assertion calls passed dbload->f->delim, a char *, as the int
condition; they mean "is it set", so they now say != NULL.

tools/asql/runforms (3 down to 0):

- A4GL_isnull, A4GL_read_columns and aclfgl_a4gl_get_info were declared only in
a4gl_libaubit4gl.h, which generated 4gl code does not include - it takes the
a4gl_incl_4glhdr.h path. Moved to a4gl_incl_4gldef.h, which is where CLAUDE.md
says shared declarations belong. Signatures checked against stack.c,
sql_common.c and helper.c rather than copied from the header.
- dbi.4gl passes &lv_dtype and &lv_size to A4GL_read_columns, which writes ints,
but 4gl integers are longs: the top four bytes were left uninitialised on
LP64. Same bug and same fix as the sqgetdbs calls in r13011.

Also in lib/libaubit4gl/ui.c: A4GL_open_gui_form declared its last parameter as
"void (*handler_c (int a, int b))", ie a function returning void *, while every
caller passes int (*)(void *, void *) and the function it forwards to,
A4GL_open_gui_form_internal, takes a plain void * - as does handler_e beside it.
Made it void *. That declaration moved to a4gl_incl_4gldef.h too, since the
callers are generated 4gl code.

Not done: glade/ide and glade/ide/sqleditor still have 32, mostly generated 4gl
code calling aclfgl_* functions from sibling modules without prototypes. glade
is a separate target from corecompile, built only when enable_minimal is not
set, so it does not block the core build.

One thing tried and reverted: declaring compat.c's bare trim() in
a4gl_libaubit4gl.h. The name is too common - lib/liblogical/txt/process has its
own static trim() - and it broke the build. Callers that want the library one
declare it themselves; there is now a comment in the header saying so.

Fix the GCC 14+ errors in tools/asql, and a real sqgetdbs/long bug with them

Reported building r13010: "Error compiling infx.ec" in tools/asql, with no
detail. The detail is in tools/asql/infx.warn, which 4glpc writes instead of
sending to stdout - that is why none of this showed up in the build log.

Three things in there are warnings under GCC 13 and errors from GCC 14 on:

- jtypes.c calls isxdigit, isspace, isalnum, isdigit, isalpha, ispunct and
tolower with only <unistd.h> included. Added <ctype.h>. There are two copies
of this file, tools/asql and tools/adbload2, and both had it.
- infx.4gl defines execute_select_free() and asql_explain() with no return
type. Both are used as int by their callers (execute.c) and declared int in
generic.c, so they are now written that way. asql_explain also had no return
statement at all while execute.c does "raffected=asql_explain(...)", so it
now returns 0 rather than whatever was in the register.
- sqgetdbs() is exported by the ESQL/C library but declared in none of the
shipped headers, so it was an implicit declaration. Added a prototype, the
same one added to lib/libsql/esqlc/esql.ec in r13002.

Declaring sqgetdbs then exposed a genuine bug at three of its four call sites.
It writes an int through its first argument, but they pass &ndbs where ndbs is
a 4gl integer, ie a long: on LP64 the top four bytes are left uninitialised and
the database count comes back wrong. The fourth call site already worked around
this with an int temporary; the other three now do the same.

Verified by rebuilding tools/asql: infx.warn goes from 10 GCC-14-fatal
diagnostics to 0, and a full clean build still passes.

Note for whoever picks this up next: a sweep of the .warn files this build
writes shows the same class of problem still present in tools/adbload2 (22),
glade/ide (about 26 across several files) and tools/asql/runforms (3) - all of
them functions called without a visible prototype. They are next in line to
stop a GCC 15 build.

Make bin/aubit POSIX sh, so it no longer depends on bash

The wrapper could not be parsed by a POSIX shell at all - dash stopped at line
39 on "function dummy ()". It coped by re-execing itself:

if [ -z "$BASH_VERSION" ]; then
exec bash "$0" "$@"
fi

which only works where bash exists. That is not everywhere we claim to build:
Alpine/musl images frequently have no bash, and FreeBSD keeps it in
/usr/local/bin. It also cannot help the case that matters most - incl/Makefile-
common sets SH=sh, so the makefiles run "${SH} .../bin/aubit fcompile ..." and
a shebang would be ignored there anyway. On any system where /bin/sh is dash,
those rules were relying on that exec finding a bash.

The script turned out to be very close to POSIX already - no [[ ]], no arrays,
no ${x//y}, no +=, no <<<, no brace expansion. What it used:

118 function NAME () -> NAME ()
44 let X=X+1 -> X=$((X+1))
6 echo -e -> printf '%b\n' (dash's echo expands escapes
itself and would have printed a literal "-e")
4 source F -> . F
4 declare X=Y -> local X=Y (matching the comment above them)

With those gone the re-exec is unnecessary and is removed, and the file gets a
real "#!/bin/sh" on line 1 - the one it had was on line 32, where it is just a
comment. The dummy() tripwire stays as a guard for a shell with no function
support at all, but its message no longer tells people to install bash, and it
no longer tries to run itself under a bash it may not have.

Verified rather than assumed: bin/aubit now parses under dash, bash and sh;
"aubit-config", "4glpc", "fcompile" and "amkmessage" all produce correct output
when driven by dash as well as bash; and tools/test builds end to end with
"make SH=/bin/dash SHELL=/bin/dash", which exercises the wrapper for form
compilation and message compilation. Before this change dash could not get past
parsing the file.

A full clean build is unaffected: 724 warnings, exit 0.

Stop using "which" to find commands - it is not guaranteed to exist

Follow-on audit after r13008. The flexml failure was one instance of a general
habit: asking the shell whether a command exists in a way that is not portable.

"which" is an external program, not a shell builtin, and Debian dropped it from
debianutils in 13 - so on the newest Debian and Ubuntu it may simply not be
installed. Every `which foo` then produces nothing, and the surrounding code
concludes the tool is absent (or, where the result is used as a path, gets an
empty one). That is the same shape of bug as r13008, just failing the other way
round: there, a missing tool looked present; here, a present tool looks missing.

Converted to "command -v", which is POSIX, is built into every shell, and
prints a path on stdout only when the command exists:

- bin/aubit: 26 call sites - the compiler wrapper's probes for gcc, make,
ldconfig, locate, xdg-open, xmessage, desktop-file-install, 4glc, 4glpc and
the rest. This is the script CLAUDE.md tells everyone to invoke, so it is the
one that matters most.
- Makefile: the check.exe.in.path target, which exists to refuse to install
when Aubit executables are still on PATH. With "which" gone that check
silently passes, which is exactly backwards for a safety check.
- bin/aubitbuild.sh.in: was deriving a script's path by picking field 3 or 4
out of "type" output, with a fallback because the field moves depending on
whether the command is hashed - and the wording differs between shells
anyway. command -v gives the path directly. Patched in the .in template, as
configure generates bin/aubitbuild.sh from it.

Two things found in passing and deliberately left alone, both worth a look:

- bin/aubit line 806 reads x="`command -v $prg >/dev/null 2>&1`" - stdout goes
to /dev/null, so x is always empty and the "Found in PATH" branch below it
has never run. Removing the redirect would switch on a branch that does
rm -rf on what it finds, under A4GL_FORCE_CLEAN, so that is a decision to
make deliberately rather than as part of a mechanical sweep.
- bin/aubit has no shebang: the "#!/bin/sh" in it is on line 32, not line 1.
It also does not parse under dash (bash-isms), so it relies on being started
by a bash-compatible shell. It works today because whatever runs it is bash;
it would break where /bin/sh is dash and something execs it directly.

The one remaining "type" probe is PKG_CONFIG_ROOT_CYGPATH in
incl/Makefile-install.mki, which parses type's output for a Cygwin path.
Cygwin is no longer a supported platform, so it is left as it is.

Detect optional build tools with "command -v", not "type"

Reported building r13007 on Ubuntu 26.04: the build stops in
lib/libui/ui_xml/uilib because it tries to run flexml, which is not installed.

It should never have tried. uilib/Makefile already falls back to the
checked-in xml/pregenerated/ copies of triggers.c, triggers_act.c and
triggers.h when flexml is missing:

HASFLEXML:=$(shell type flexml 2> /dev/null)
ifeq "$(HASFLEXML)" ""
TRIGGERS_O=xml/pregenerated/triggers.o xml/pregenerated/triggers_act.o

but the probe is not safe. "type" is a shell builtin whose behaviour for a
missing command differs: bash writes "flexml: not found" to stderr, so the
redirect hides it and HASFLEXML ends up empty, while dash - which is /bin/sh
on Debian and Ubuntu - writes it to stdout, where the redirect does not touch
it. HASFLEXML is then the non-empty string "flexml: not found", the makefile
concludes flexml is available, and make runs it and fails:

$ dash -c 'type flexml 2> /dev/null'
flexml: not found
$ dash -c 'command -v flexml 2>/dev/null'
$

"command -v" is the POSIX way to ask this and prints a path on stdout only
when the command exists, on either shell.

Fixed in all ten probes of this shape, not just the one that bit:
lib/libui/ui_xml/uilib/Makefile and uilib/xml/Makefile (flexml),
lib/libpacker/xml_best, xml_best2 and xml_best_plsql (flexml and a pregenerated
flex), and lib/extra_libs/mantisconnect (soapcpp2). All had the same latent
failure - each would have tried to run a tool that is not there.

Not reproduced end to end here: this box has bash as /bin/sh and GNU Make 4.3,
where the old probe happens to come back empty and the pregenerated files are
used, which is why the tree built fine for me at r13006. What is demonstrated
is the probe itself being unsafe under dash, and that both shells now select
xml/pregenerated/. The exact combination on the reporter's machine (dash plus a
newer make) is inferred.

The warnings quoted alongside the failure - comms.c sign-compare and unused
'p', uilib.c type-limits, attr.c redundant xml_yylex - are untouched; they are
warnings, not the reason the build stopped.