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" <andrew.gregory.8@gmail.com> wrote:
Signed-off-by: Andrew Gregory <andrew.gregory.8@gmail.com> ---
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