ModuleOption PolyRatFun with its inverse

[tueda]

Currently, the reference manual says:

polyratfun

Possibly followed by the name of a `polyratfun'. Is similar to the polyfun statement (see 7.114) but only valid for the current module. If there is second name, it refers to the inverse polyratfun. More complicated options of the polyratfun statement cannot be used here.

But the following program crashes:

CF rat,RAT;
ModuleOption polyratfun rat,RAT;
.end

FORM 5.0.0-beta.1 (Dec 19 2025, v5.0.0-beta.1-288-g73a6a14)  Run: Fri Jan  9 20:45:38 2026
    CF rat,RAT;
    ModuleOption polyratfun rat,RAT;
==42715== Conditional jump or move depends on uninitialised value(s)
==42715==    at 0x4065609: SkipAName (compiler.c:437)
==42715==    by 0x40AFD3A: CoModuleOption (module.c:157)
==42715==    by 0x4065E25: CompileStatement (compiler.c:663)
==42715==    by 0x4111458: PreProcessor (pre.c:1130)
==42715==    by 0x415399D: main (startup.c:1766)
==42715==
==42715== Use of uninitialised value of size 8
==42715==    at 0x4065615: SkipAName (compiler.c:445)
==42715==    by 0x40AFD3A: CoModuleOption (module.c:157)
==42715==    by 0x4065E25: CompileStatement (compiler.c:663)
==42715==    by 0x4111458: PreProcessor (pre.c:1130)
==42715==    by 0x415399D: main (startup.c:1766)

Actually, from the current implementation, the correct syntax seems to be:

CF rat,RAT;
ModuleOption polyratfun rat+RAT;
.end

[jodavies]

Maybe we can accept both, + to not (potentially) break existing scripts, but , to align with the manual and the PolyRatFun rat,RAT; notation?

[tueda]

Maybe we can accept both, + to not (potentially) break existing scripts, but , to align with the manual and the PolyRatFun rat,RAT; notation?

That sounds reasonable to me.

By the way, ModuleOption PolyRatFun doesn't accept formal names:

CF [🙂],[🙃];
ModuleOption polyratfun [🙂]+[🙃];
.end

test.frm Line 3 ==>   is not a properly declared function

Fixing this would be low priority, as it's unlikely that anyone actually uses [...] for PolyRatFun.

[tueda]

The syntax is ambiguous for

ModuleOption polyratfun,prf,parallel;

Should parallel be assumed to be a function? Or the keyword as the test of #313?

An option would be to check if parallel is a cfunction, and if not, consider it as a keyword.

[jodavies]

Right, maybe this is the reason for the +. Then we should resolve the crash and document the + in the manual I suppose.

[tueda]

The underlying problem (also for the crash) is that PolyFun (PolyRatFun) accepts 0 or 1 (0 to 2) functions, but the current implementation of DoPolyfun (DoPolyratfun) does not return how many tokens were consumed. (In contrast, DoModDollar returns a UBYTE * but can't return an error, except by returning null.)

Possible fixes:

1. Use a global variable to store the position in the input buffer up to which the input was consumed. Because the compiler is (currently) never executed in parallel, it should work. Easy, but ugly.

2. Change the function prototypes of DoPolyfun and similar functions (in the ModuleOptions array) to propagate the position in the input buffer. Because these functions are stored in the keyword array as type TFUN, this requires casts. Somewhat hacky.

3. Perform the argument checking twice, also in CoModuleOption. Messy and hard to maintain.