<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 22, 2012 at 9:15 PM, Glynn Clements <span dir="ltr"><<a href="mailto:glynn@gclements.plus.com" target="_blank">glynn@gclements.plus.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
Paulo van Breugel wrote:<br>
<br>
> > To be honest, I'm not sure that it's worth increasing this value in<br>
> > the standard version. 5000 arguments in a function call is rather<br>
> > extreme, and probably a hint that alternative approaches should be<br>
> > considered.<br>
><br>
> What are the possible disadvantages of increasing this limit?<br>
<br>
</div>1. We have to decide upon a limit. If ~5000 arguments isn't enough, is<br>
10,000? 100,000? A million?<br></blockquote><div><br></div><div>Good point.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. If someone actually uses 5000 arguments, forcing them to seek help<br>
might be considered a good thing.<br></blockquote><div><br></div><div>I can hardly disagree of course :-). your help did help me for sure</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
> But you are right, there aren't probably many user cases where more<br>
> then 5000 arguments are used. And as my case illustrates, there<br>
> might be better alternatives. In any case, would it be possible to<br>
> change the error message when the limit is surpassed from the<br>
> generic 'memory exhausted', to something along the lines of "maximum<br>
> number of function arguments exceeded"?<br>
<br>
</div>Changing it would require a non-portable hack. The actual string is<br>
part of the parser skeleton, which is beyond our control. For bison,<br>
it's passed to the YY_() macro used for localisation. We could<br>
re-implement that macro, but that would affect other localised<br>
messages. And may cause problems for other versions of yacc.<br></blockquote><div><br></div><div>OK, that does sound the trouble out-weights the benefits</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
> And possibly, this limitation could be mentioned in the help file?<br>
<br>
</div>The current limit is implementation-dependent, i.e. if GRASS was built<br>
using a different version of yacc, the limit might be different. Also<br>
YYMAXDEPTH isn't specified by POSIX, so setting it wouldn't make the<br>
limit not implementation-dependent.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>The main purpose would be for the user to recognize the possible cause when confronted with an error message about 'memory exhausted'. The limit at which this happens is less important in that case. Of course, if there are other problems that will give the same error message, that would't help much. Anyway, we are talking about a limitation and corresponding error message that I reckon not many people will encounter anyway. </div>
<div><br></div><div>Thanks for all the explanation, it shows it clearly is easy to underestimate the complexity of the code :-/</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888">
--<br>
Glynn Clements <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>><br>
</font></span></blockquote></div><br></div>