Handling TRUE,FALSE,NULL,ON,OFF, etc

Consider: {blockfunc somevar=true othervar=TRUE} .. {/blockfunc} At present, $somevar will be set to boolean(TRUE) while $othervar gets set to string("TRUE"). (It's within a block function I came across this, I assume it affects other places too?) Clearly (??) this is wrong, and easy to fix in Smarty_Comiler::_parse_attrs() by making the two regexps case insensitive (case 2 of switch). Additionally, the check for "null" should accomodate "NULL". [The following is basedon Smarty 2.6.2/libs/Smarty_Compiler_class.php.] However, there seems to be some duplication here, in that there is a subsequent call to _parse_var_props which does most of the same job again in the last elseif, and which suffers the same case sensitive limitation. Indeed, if the compiler property $_permitted_tokens were changed from var $_permitted_tokens = array('true','false','yes','no','on','off','null'); to var $_permitted_tokens = array( 'true'=>'true','false'=>'false', 'yes'=>'true','no'=>'false', 'on'=>'true','off'=>'false', 'null'=>'null'); .. and _parse_var_props modified along the lines of: ... elseif(isset($this->_permitted_tokens[strtolower($val)])) { return $this->_permitted_tokens[strtolower($val)]; } elseif(is_numeric($val)) { return $val; } return $this->_expand_quoted_text('"' . $val .'"'); .. then the list of permitted tokens could be more easily maintained, and code duplication reduced, whilst fixing the case problems? Does all that make sense? Changing the use of $_permitted_tokens should not impact anything (it isn't used elsewhere in Smarty, as far as I can tell). If not, then the regexps should at least be case insensitive? -- Mark Rogers, More Solutions Ltd :: Tel: 0845 45 89 555