Forum OpenACS Improvement Proposals (TIPs): template::data::validate::integer allows leading zeros

This integer validation proc allows numbers with leading zeros such as 000111 or +00123. Thanks to Jim for finding this bug.

regexp {^[+-]?\d+$} $value

I suggest making small tweak in the regexp to use this instead:

regexp {^[+-]?(?!0+)\d+$} $value

Collapse
Posted by Don Baccus on
Leading zeroes in the absence of an explicit sign should be allowed. They should only be disallowed in the presence of an explicit sign.

000111 is a legal integer in most programming languages.

-000111 or +000111 ... not so much so.

Be aware that 08 and 09 (with or without explicit sign) are invalid number-strings in Tcl. Don's example of 000111 is a valid number-string in Tcl, but its value is most likely not what an end user might expect (try e.g. [expr {000111 + 1}]).

The main question is against what kind of error a developer expects that template::data::validate::integer protects against: should be the number an integer number in the mathematical sense, is it an integer that can be used for computations in Tcl, or is it an integer in the sense of the database backend. As long there is a single validation function, only the intersection of the three definitions would be safe.

According to the documentation http://www.openacs.org/api-doc/proc-view?proc=template%3a%3adata%3a%3avalidate%3a%3ainteger, leading zeros are not excluded, neither with or without sign.

Collapse
Posted by Don Baccus on
Oh, Tcl implements the stupid leading-zero-is-octal convention? What hell hath C wrought. SQL, coming from the Pascal heritage, doesn't implement that devil-spawn of a convention :)

OK, then disallowing numbers with leading zeros is fine.

Collapse
Posted by Dave Bauer on
string is integer exists now, so that seems like a logical choice to validate integers now.
string is integer does not solve the discussed problem.

set x 0111; puts [expr {[string is integer $x] ? $x : 0}]

outputs 73

Cheers, -gustaf neumann