Re: Bison and embedded systems
At 02:26 -0400 2005/04/26, Alfonso Urdaneta wrote: Paul Eggert wrote: If by "dynamic memory" you mean "malloc or alloca", then yes, it's easy: #define YYSTACK_ALLOC(size) 0 that _is_ easy. ;] Strictly speaking, one needs some additional information, fixing the initial parser stack size at a suitable value. I am not sure why alloca isn't usable in embedded systems; perhaps it is not available. And, if the parser stack is fixed, how is overflow handled. And if it is set too a high value, isn't that a poor use of the scarce memory? -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
You're Billing Information
Title: PayPal You're Billing Information! Dear PayPal Member, It has come to our attention that your PayPal Billing Information records are out of date. That requires you to update the Billing Information. Failure to update your records will result in account termination. Please update your records within 24 hours. Once you have updated your account records, your PayPal session will not be interrupted and will continue as normal. Failure to update will result in cancellation of service, Terms of Service (TOS) violations or future billing problems. You must click the link below and enter your login information on the following page to confirm your Billing Information records. Click here to activate your account You can also confirm your Billing Information by logging into your PayPal account at https://www.paypal.com/us/. Thank you for using PayPal! The PayPal Team Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page. To receive email notifications in plain text instead of HTML, update your preferences here. PayPal Email ID PP468 Protect Your Account Info Make sure you never provide your password to fraudulent websites. To safely and securely access the PayPal website or your account, open a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (https://www.paypal.com/us/) to be sure you are on the real PayPal site.PayPal will never ask you to enter your password in an email. For more information on protecting yourself from fraud, please review our Security Tips at https://www.paypal.com/us/securitytips Protect Your Password You should never give your PayPal password to anyone, including PayPal employees. ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
%destructor and stack overflow
Hi, I've been using bison for the C parser in one of my perl modules for a couple of years now. (http://search.cpan.org/~mhx/Convert-Binary-C/) I recently noticed the %destructor feature and it looks as it would solve a problem that has long been on my todo list. Right now I'm collecting all objects that I don't reference otherwise in various lists so I can free them when the parser exits (when it exits normally, the lists are usually empty). However, maintaining these lists is time-consuming (both in programming time and execution time). I've now rewritten my parser to make use of %destructor, and it works fine generally. The only case where it doesn't work is when a parser stack overflow is detected. I can see from the generated parser code that a parser stack overflow error bypasses yydestruct(). My question: Is there a reason why the %destructor code isn't called upon parser stack overflow? I don't see a reason, because when the stack overflow is detected, the whole stack is still valid and even the items about to be pushed on the stack are valid and known to the parser. So it should at least be possible to do a correct cleanup of the parser stack. Thanks, Marcus -- One of the most overlooked advantages to computers is... If they do foul up, there's no law against whacking them around a little. -- Joe Martin ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %destructor and stack overflow
Again, this is probably a question for Paul to answer, who wrote the current C-parser. I thought that the C-parser was dynamic, except when free store runs out, in which case one is toast anyway. What version of Bison are you using? Is it Bison 2.0? If you have disabled parser stack dynamic reallocation, and gets stack overflow, how do you intend to recover. I mean, then the parser cannot handle the input semantics properly anyway. At 22:39 +0200 2005/04/26, Marcus Holland-Moritz wrote: Hi, I've been using bison for the C parser in one of my perl modules for a couple of years now. (http://search.cpan.org/~mhx/Convert-Binary-C/) I recently noticed the %destructor feature and it looks as it would solve a problem that has long been on my todo list. Right now I'm collecting all objects that I don't reference otherwise in various lists so I can free them when the parser exits (when it exits normally, the lists are usually empty). However, maintaining these lists is time-consuming (both in programming time and execution time). I've now rewritten my parser to make use of %destructor, and it works fine generally. The only case where it doesn't work is when a parser stack overflow is detected. I can see from the generated parser code that a parser stack overflow error bypasses yydestruct(). My question: Is there a reason why the %destructor code isn't called upon parser stack overflow? I don't see a reason, because when the stack overflow is detected, the whole stack is still valid and even the items about to be pushed on the stack are valid and known to the parser. So it should at least be possible to do a correct cleanup of the parser stack. Thanks, Marcus -- One of the most overlooked advantages to computers is... If they do foul up, there's no law against whacking them around a little. -- Joe Martin ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %destructor and stack overflow
Hi Hans, thanks for the quick response! On 2005-04-26, at 23:46:10 +0200, Hans Aberg wrote: > Again, this is probably a question for Paul to answer, who wrote the > current C-parser. I thought that the C-parser was dynamic, except > when free store runs out, in which case one is toast anyway. What Yes, it is dynamic. Up to YYMAXDEPTH. Besides, I don't think that anyone will ever get the parser to exhaust its stack. But my test suite checks the "parser overflow" error and that test will leak memory if any stray objects aren't cleaned up. Which is bad for the memory leak checker... My current keep-unreferenced-objects-in-lists method handles the overflow without any leaks, and I'd like to keep that behaviour if I switch to using %destructor. > version of Bison are you using? Is it Bison 2.0? If you have disabled Yes, Bison 2.0. > parser stack dynamic reallocation, and gets stack overflow, how do > you intend to recover. I mean, then the parser cannot handle the > input semantics properly anyway. Sure. I don't want to recover. I just don't want to leak memory. As I mentioned, the parser is embedded in a Perl module, and the module shouldn't leak memory as the code using the module may run for long periods of time. Marcus > At 22:39 +0200 2005/04/26, Marcus Holland-Moritz wrote: > >Hi, > > > >I've been using bison for the C parser in one of my perl modules for a > >couple of years now. (http://search.cpan.org/~mhx/Convert-Binary-C/) > > > >I recently noticed the %destructor feature and it looks as it would solve > >a problem that has long been on my todo list. Right now I'm collecting > >all objects that I don't reference otherwise in various lists so I can > >free them when the parser exits (when it exits normally, the lists are > >usually empty). However, maintaining these lists is time-consuming (both > >in programming time and execution time). > > > >I've now rewritten my parser to make use of %destructor, and it works > >fine generally. The only case where it doesn't work is when a parser > >stack overflow is detected. I can see from the generated parser code > >that a parser stack overflow error bypasses yydestruct(). > > > >My question: Is there a reason why the %destructor code isn't called > >upon parser stack overflow? > > > >I don't see a reason, because when the stack overflow is detected, > >the whole stack is still valid and even the items about to be pushed > >on the stack are valid and known to the parser. So it should at least > >be possible to do a correct cleanup of the parser stack. > > > >Thanks, > >Marcus > > > >-- > >One of the most overlooked advantages to computers is... If they do > >foul up, there's no law against whacking them around a little. > > -- Joe Martin > > > > > >___ > >Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %destructor and stack overflow
At 00:09 +0200 2005/04/27, Marcus Holland-Moritz wrote: On 2005-04-26, at 23:46:10 +0200, Hans Aberg wrote: Again, this is probably a question for Paul to answer, who wrote the current C-parser. I thought that the C-parser was dynamic, except when free store runs out, in which case one is toast anyway. What Yes, it is dynamic. Up to YYMAXDEPTH. Besides, I don't think that anyone will ever get the parser to exhaust its stack. But my test suite checks the "parser overflow" error and that test will leak memory if any stray objects aren't cleaned up. Which is bad for the memory leak checker... Why don't you define YYMAXDEPTH to the MAXINT or something? Then you can only get overflow by memory running out. > parser stack dynamic reallocation, and gets stack overflow, how do you intend to recover. I mean, then the parser cannot handle the input semantics properly anyway. Sure. I don't want to recover. I just don't want to leak memory. As I mentioned, the parser is embedded in a Perl module, and the module shouldn't leak memory as the code using the module may run for long periods of time. There I do not see exactly what you need. Perhaps Paul can help. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
