This function in transcode.c:
static enum st_retval
asciicompat_encoding_i(mrb_state *mrb, st_data_t key, st_data_t val, st_data_t arg)
...which is called as:
st_foreach(table2, asciicompat_encoding_i, (st_data_t)&data);
However, st_foreach() doesn't pass an "mrb" pointer to its callback (in fact, "mrb" doesn't even get passed to st_foreach)
This might have been a mis-conversion from encoding.c (where st_foreach() is wrapped in a function called st_foreachNew() that does use mrb) I'm not sure how that function could be possibly working
It's broken, and to be removed soon.
Is all of st.c/st.h going to be removed soon? I've been staging some changes to fix the fast-and-loose conversion of function pointers (C++ compilers reject it and it's dubiously portable besides) However if all of that stuff is about to die anyways I might as well work on something else.
Is there a list somewhere of what code is going to disappear so I know where to focus my porting efforts?
encoding.[ch], transcode.ch and st.[ch] are going to be removed.
encoding.c : Removed on 64fc4ac
encoding.h : Still living.
transcode.c, trancecode_data.h : Removed on 50d18a8
st.c, st.h : Still living.
encoding.h: Removed on b1a5146
st.c, st.h are still living. But we can close this issue, I think.
@matz and @mitchblank, how do you think?
I guess since this bug's title is explicitly about asciicompat_encoding_i and that is fixed already it can be closed.
Hopefully Pull Request #892 will be merged soon so then none of the things mentioned on this bug will be relevant any more
I've been away from mruby for a while.. hopefully in a few months I'll have time to play with it again.