Ticket UUID: | 1031507 | |||
Title: | TIP #201 reference implementation | |||
Type: | Patch | Version: | None | |
Submitter: | rmax | Created on: | 2004-09-20 20:22:02 | |
Subsystem: | 45. Parsing and Eval | Assigned To: | msofer | |
Priority: | 5 Medium | Severity: | ||
Status: | Closed | Last Modified: | 2004-10-23 05:13:43 | |
Resolution: | Accepted | Closed By: | msofer | |
Closed on: | 2004-10-22 22:13:43 | |||
Description: |
Here is my first try on implementing TIP #201. While doing this I stumbled over a parser problem with alphanumeric operators. Initially it tried to parse 'int()' as 'in t()' after adding 'in'. This would already have happened with 'eq', and 'ne' if there had been a function that started with one of those character seqences. As a workaround I am accepting alphanumeric operands only if they are not followed by another alphanumeric character. I'd like this to be reviewed by people with more C experience than I for correctness, and whether there is a better way to do it. | |||
User Comments: |
msofer added on 2004-10-23 05:13:43:
Logged In: YES user_id=148712 TIP #201 has been committed on 2004-10-08 by dkf. Implementation evolved from this patch. rmax added on 2004-09-21 14:52:57: File Added - 102230: tip201-3.patch rmax added on 2004-09-21 14:52:56: Logged In: YES user_id=124643 I have moved the check for all alpha operators down to the place where boolean literals and function names are checked. I think it is better to have all alphanumeric parsing at one place. The only downside I can see is that it might be somewhat slower to have them there. The way it is implemented now implies that an operator or literal will never consist of anything but alphabetic caracters, and that there will never be a function name like in3() or true_42() that starts with alpha characters that look like an operator or a literal immediately followed by a digit or underscore. dgp added on 2004-09-21 03:39:05: Logged In: YES user_id=80530 test 25.4 fails -- just a copy/paste error writing the test. more seriously, the isalpha() tests should be moved a bit to avoid reading past the end of buffer. Tests in parseExpr.test (making use of the [testexprparser] command) would be best to verify those details. rmax added on 2004-09-21 03:25:38: File Added - 102170: tip201.patch |