Error reporting and the c-kona interface

[tavmem]

This issue was identified by @bakul.

In k2.8 (or in k3), when there is an error, k returns a null K-object(r) that has (r->t==6) and (r->n != 0) where r->n is a string (pointer to a character buffer) containing the error message. When k should return a null, then (r->t==6) and (r->n==0).
See https://a.kx.com/a/k/connect/c/CandK.txt

Currently, in src/k.c of kona:

extern K kerr(cS s){ if(strcmp(s,"(nil)"))fer=2; R snprintf(errmsg,256,"%s",s),(K)0; }

The signature of snprintf is

int snprintf(char *str, size_t size, const char *format, ... );

where snprintf returns the number of characters printed into the buffer.

So, when there is an error in kona, it seems that kona returns some sort of amalgam of an int and K(0).
Bakul's work on the c-kona interface demonstrates that this amalgam (upon error) will test equal to 0 in C.

K b = ksk("+/", a);
if (b == 0) { R 0; } // FIX this

My own experiments seem to show that b->t and b->n are indeterminate. Note that the c-kona interface crashes on an attempt to show b, or to access b->t or b->n if there was an error in kona.

This should all be fixed in kona, to bring kona into alignment with k2.8 and k3 and so that the c-kona interface can work as it should.

[tavmem]

Here's one complication:
At the time the error occurs, the null K-object (r) may have (r->n > 0). Changing that to point to the error message will mess up the reference counting on r.

[tavmem]

Also, when an error is reported from k to C as part of an ongoing dialogue, k has not necessarily closed. So it's probable that the null K-object is still in use in k. This all seems to indicate that reference counting may not be done on the the null K-object in k2 or k3.

[bakul]

You need to create a new null object with an embedded error string, not change the standard _n.

[tavmem]

Well ... that make sense. Thanks !!

[tavmem]

On the other hand, maybe not ...
When k should return the standard _n (and there is no error), standard _n normally has (r->n > 0).
If standard _n is returned with (r->n==0), it does seem to imply that either:

• standard _n gets special treatment, exempting it from normal reference counting, or
• every time (and every place) that standard _n is returned from k to C, it gets replaced by a new null object with (r->n==0).

[bakul]

Why does standard _n have r->n > 0?

Nothing special needed for refcounting a returned error or _n. The refcount is in r->_c. In k3, for a symbol value, r->n is used to store the string pointer. This is why CandK.txt keeps referring to ->n. Kona doesn’t use r->n to store string ptr. See the defn of macro Ks.

In case any K returning function has to return Some error “foo”, it should R kerr("foo"); And all that fn kerr() does is to get a new object r with type 6 and sets Ks(r) to the error string. To test if a returned value of type K is an error, check r->t ==6&&Ks(r)!=0.

[tavmem]

Thanks again ...
Must be my dyslexia kicking up.
I confused r->_c (ref count) with r->n (number of items)

[tavmem]

In k2.8, it is possible to easily show that an error condition returns null

$ rlwrap -n ./k
K 2.8 2000-10-10 Copyright (C) 1993-2000 Kx Systems
Evaluation. Not for commercial use. 
\ for help. \\ to exit.

  r: 1+`a
type error
r: 1+`a
    ^
>  \
  
  \v
r 
  
  r ~ _n
1

in Kona, you seem to get the correct behavior

$ rlwrap -n ./k
kona      \ for help. \\ to exit.

  r: 1+`a
type error
r: 1+`a
    ^
>  \
  
  \v
,`r
  
  r~_n
1

But that is because k2.8 is correctly parsing from right to left

$ rlwrap -n ./k
K 2.8 2000-10-10 Copyright (C) 1993-2000 Kx Systems
Evaluation. Not for commercial use. 
\ for help. \\ to exit.

  r: a
value error
a
^
parse error
  \v

and kona is erroneously parsing from left to right (and capturing the token to the left of an amend before attempting to capture any tokens to the right of the amend)

$ rlwrap -n ./k
kona      \ for help. \\ to exit.

  r: a
value error
a
^
  \v
,`r
  _n ~ r
1

See issue #481.

[tavmem]

This is not a bug. Kona was designed to return 0 to indicate an error (see Coding Guidelines).
Changing error handling to be consistent with k2.8 would be an enhancement to kona.

Both this issue and issue 481 concern how kona was designed to handle errors.
It seems to me that it may be best to fix issue 481 first.