marpa_v_step() returns -2 on failure: http://jeffreykegler.github.io/Marpa-web-site/libmarpa_api/latest/Stepping-through-the-valuator.html
An error code is set, which can be retrieved with these methods: http://jeffreykegler.github.io/Marpa-web-site/libmarpa_api/latest/Error-methods.html#Error-methods Because I wanted (for portability reasons) Libmarpa to be entirely string-free there are, technically speaking, no error strings. But there are "suggested messages" and these are in the distribution in both the `marpa_codes.c` and `error_codes.table` files. One is for compiling them into your code, and the other is intended to be more convenient for custom processing. On Thu, Aug 17, 2017 at 9:50 PM, Andreas Kupries <[email protected]> wrote: > > > Not necessarily relevant but marpa_v_step() can return a negative > > number on failure, and I think this is not handled. In particular > > there are a number of cases of unexpected returns from > > marpa_v_step() which you handle via fall-through which probably are > > better treated as fatal errors. > > > Same with marpa_v_new() -- it can return NULL on failure and this is > > not checked for. I have no real evidence that this has anything to > > do with your problem, but this is C language so subtle stuff could > > be happening with memory overwrites, etc. > > Agreed. > > > And the checks *do* belong in your final code, so you might as well > > have them in for debugging. > > Agreed as well. > > Will definitely put in code to handle failures ... Oh, the bocage > wrapper needs them as well. If I remember correctly it does not handle > these things either. > > Are the negative numbers from marpa_v_step() regular marpa error > codes, or are they their own set ? > > Memory. Right. While I am mostly confident that I managed to avoid > issues, due to the lot of assertions I put in all over the place it > will definitely not hurt (except speed (*) of the system) to activate > the memory debugging Tcl's memory utility functions provide, and > should trip anything bad I may have in the code. > > Thank you for the reminder of that. > > (*) Especially if I have it check the entire set of allocations on > each and every malloc, realloc, or free, instead of just the > specific memory allocated or freed by the current call. > > > > > On Thu, Aug 17, 2017 at 6:55 PM, Andreas Kupries <[email protected]> > wrote: > > > > > >> > > >> > Looked some more at `rule` and `rslot` and I not 100% sure it's > wrong, > > >> but > > >> > I can't convince myself it's right. > > -- > See you, > Andreas Kupries <[email protected]> > <http://core.tcl.tk/akupries/> > Developer @ SUSE (MicroFocus Canada LLC) > <[email protected]> > > Tcl'2017, Oct 16-20, Houston, TX, USA. http://www.tcl.tk/community/ > tcl2017/ > EuroTcl 2017, Jul 8-9, Berlin/DE, http://www.eurotcl.tcl3d.org/ > ------------------------------------------------------------ > ------------------- > > > > > -- > You received this message because you are subscribed to the Google Groups > "marpa parser" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
