assertion failures when declaring native functions which return arrays

[YashasSamaga]

Issue description:

It turns out the compiler allows explicitly marking functions which return arrays in forward declarations. While the compiler is capable of figuring out the array size of functions which are defined, it cannot do so with native functions since they are not defined in the script. Hence, it is required to explicitly specify the returned array size.

This compiles fine in release build and appears to produce the correct (or at least useful) assembly but fails assertions in the debug build.

Minimal complete verifiable example (MCVE):

native [4]nfunc();
main () {
	nfunc();
}

Workspace Information:

• Compiler version:
• Command line arguments provided (or sampctl version):
• Operating System:

[YashasSamaga]

native [4]nfunc();
main () {
	nfunc();
}

generates

proc	; main
heap 10
push.alt
push.c 0
sysreq.c 0	; nfunc
stack 4
pop.pri
heap fffffff0
zero.pri
retn

---

native [4]nfunc();
main () {
	new arr[4];
	arr = nfunc();
}

generates

proc
stack fffffff0
zero.pri
addr.alt fffffff0
fill 10
addr.pri fffffff0
push.pri
heap 10
push.alt
push.c 0
sysreq.c 0	; nfunc
stack 4
pop.pri
pop.alt
movs 10
heap fffffff0
stack 10
zero.pri
retn

---

native [4]nfunc();
main () {
	new arr[3];
	arr = nfunc();
}

gives error 047: array sizes do not match, or destination array is too small

---

native [4]nfunc();
main () {
	new arr[100];
	arr = nfunc();
}

generates

proc	; main
stack fffffe70
zero.pri
addr.alt fffffe70
fill 190
addr.pri fffffe70
push.pri
heap 10
push.alt
push.c 0
sysreq.c 0	; nfunc
stack 4
pop.pri
pop.alt
movs 10
heap fffffff0
stack 190
zero.pri
retn

---

All of th above results are useful. It allows returning arrays from native functions. The compiler allocates space in the heap which is used to temporarily store the returned array. It pushes the address of the temporary array on to the stack before any arguments are pushed. Hence, the plugin/server can access that temporary location by checking past the end of the arguments in params array (params[params[0]/sizeof(cell) + 1]) and in turn can easily store the returned value there.

[YashasSamaga]

Assertion Failure I

In addvariable():

  assert(vclass!=sGLOBAL || (sym=findglb(name,sGLOBAL))==NULL || (sym->usage & uDEFINE)==0 || (sym->usage & uNATIVE)!=0
         || sym->ident==iFUNCTN && sym==curfunc
         || sym->states==NULL && sc_curstates>0);

When native functions are declared, the uDEFINE flag is automatically set to trick other parts of the compiler since native functions won't have a definition in the script. Hence, the above assertion fails.

Possible fix: add an exeception of native functions

Assertion Failure II (after fixing I)

In callfunction():

assert(symret==NULL || symret->ident==iREFARRAY);

For reasons I don't understand, funcstub attaches an iARRAY child to the function symbol instead of iREFARRAY (as done for regular functions that return arrays).

/* attach the array to the function symbol */
  if (numdim>0) {
    assert(sym!=NULL);
    sub=addvariable(symbolname,0,iARRAY,sGLOBAL,tag,dim,numdim,idxtag,0);
    sub->parent=sym;
    if (sym)
      sym->child=sub;
  } /* if */

It creates a global array at address 0 instead of the usual global reference array at (argcount + 3) * sizeof(cell) frame offset.

Assertion Failure III (after fixing II)

In deletesymbols():

for (parent_sym=sym->parent; parent_sym!=NULL && parent_sym->ident!=iFUNCTN; parent_sym=parent_sym->parent) 
        assert(parent_sym->ident==iREFARRAY);

After some investigation, I found that only of the depends has a invalid address in parent_sym->parent for some mysterious reason.

This is happening at the end, i.e. compiler is freeing up resources to exit. I remember some incident where similar corruption was happening in some other unrelated issue.

[stale]

This issue has been automatically marked as stale because it has not had recent activity.