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 <akupr...@shaw.ca> 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 <akupr...@shaw.ca> > 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 <akupr...@shaw.ca> > <http://core.tcl.tk/akupries/> > Developer @ SUSE (MicroFocus Canada LLC) > <andreas.kupr...@suse.com> > > 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 marpa-parser+unsubscr...@googlegroups.com. > 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 marpa-parser+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
