On 23/07/13 01:02, Dave Reisner wrote: > On Mon, Jul 22, 2013 at 10:58:55AM -0400, Andrew Gregory wrote: >> On 07/22/13 at 08:41am, Dave Reisner wrote: >>> On Jul 22, 2013 2:48 AM, "Andrew Gregory" <[email protected]> >>> wrote: >>>> >>>> Signed-off-by: Andrew Gregory <[email protected]> >>>> --- >>> >>> OK... I'll bite. Why? Is this really going to be used elsewhere? Seems like >>> an error case that should be handled by the like any other. >> >> My goal wasn't reusability so much as visibility. It's an artificial >> limitation we impose to prevent memory exhaustion in a recursive call, >> not a true error condition. I also did this with the thought of >> eventually trying to make the parser usable for pacman-related >> programs outside of pacman proper and making the limit configurable. >> I don't know if a macro is the best way to do that, though. >> >> apg >> > > Although minor, I'm against this. > > If you want this to be extensible and useful outside of pacman proper > (and this is indeed a noble goal), then you need to create an opaque > context that users would instantiate similar to alpm_handle_t. The > recursion limit would have get/set methods exposed in the API.
I do like the idea of increasing the visibility of this limitation. How about instead of using a macro, just make it a "static const int" at the top of the file? A
