TYPO3 Core

stumbled across problems that also a positive and negative sign need to be handled special as well.

Patch set 1 of change I61cbe743851fd5f837a16ac7f8129c33225435a4 has been pushed to the review server.
It is available at http://review.typo3.org/3944

Also affects t3lib_div::testInt() for versions 4.5.x and before. Added note to the gerrit-review to also backport this once accepted for master.

This must not be "fixed" because existing code relies on the behaviour of t3lib_div::testInt() or now t3lib_utility_Math::canBeInterpretedAsInteger().
Look at RFC #15685, RFC #15020, RFC #15021. Unit tests were made to ensure that the behaviour of this function stays the way it should be.
Both names are somewhat misleading.

Then please see
https://review.typo3.org/#change,3855

It contains an array-hierarchy with 10., 20. and 030. (to test if the index is used numeric or compared as strings). I agree that the leading zero is somewhat an "unusual" case but that's where I stumbled across it. For the stdWrap this lead to 10 and 20 being executed and 030 being left out since it wasn't recognised "as an integer".
Would you say I should adjust the testcase there to work around it? Or do a preg_match-comparision on '^[0-9]+$'?

joking Or how about about a canReallyBeInterpretedAsInteger() (to mimic the real part of mysql_real_escape_string()).

For reference: The numbers Jigal mentioned refer to the old bugtracker. The corresponding forge-issues are #23525, #23113 and #23114.

Jigal: Just for clarify: I was refering to patch set #4 of gerrit-review 3855. I'd personally still say that 030. as a numeric value is fine, but I have changed the testcase to "avoid" this problem and test the scenario different.

I now see from the comments that it would be a backward-incompatible change. But would it "really" break things? How about if we fix this now on the step towards 4.6 maybe, especially since the old testInt() has been deprecated anyhow etc.?

@Stefan: 3 things:
1. testInt was optimized for performance while keeping the "old" behaviour. With your change all performance gain is lost.
2. Please execute the unit tests after your change and the rethink your question "would it really break things?" ;)
3. If you need to test for numeric values in your code, use is_numeric(), reading from what you expect it would rather be is_numeric(trim($var))

Just for fun here but 030 is in fact an octal number which is 24 in decimal format, I'm not sure you would expect that from a TS showing:

10 = ...
20 = ...
25 = ...
030 = ...

and having 030 put before 25 :-)

Anyway, this has been rejected and I don't see the point either. As said, if you need some special handling for edge cases such as those, you should make your own tests even allowing "numbers within strings" to be somehow extracted and allowed...

I still don't get why valid integers are not supposed to validate using a function that has a name like that. But be it.

Xavier: Octal? Hmm, that's one other way to read it :I didn't yet think of. But thinking about integers, it stays an int even with leading zeros. And a "-0" equals "0" equals "+0". That was my point about this testing-function.