-3

I've just wasted 3 hours of my life because of Magento's use of an (int) typecast in PHP. To be fair, the typecast is more than fair on their part... It seems to be unexpected behavior by the interpreter which ruined my afternoon.

$sString = '123 Sesame Street'; $iNumber = (int)$sString; var_dump($iNumber); // int(123) 

Is this intentional? Obviously it can be caught with an is_numeric check up-front, but really?

3
  • Thanks for the downvote... I'll file a bug with PHP for an answer! Commented Sep 11, 2016 at 0:14
  • 2
    From docs: The value is given by the initial portion of the string. If the string starts with valid numeric data, this will be the value used.. It's documented. I didn't downvote you, but you could have found this in about.. 5 sec of googling. Commented Sep 11, 2016 at 0:18
  • You're right @N.B., I asked this question in haste out of frustration and deserve the downvotes. The fact that it's documented is great, however the behavior itself is still spurious IMO! Commented Sep 12, 2016 at 19:40

1 Answer 1

3

What do you expect the result to be? the (int) works exactly as intended.

If you care to read the PHP manual documentation it states:

The value is given by the initial portion of the string. If the string starts with valid numeric data, this will be the value used. Otherwise, the value will be 0 (zero). Valid numeric data is an optional sign, followed by one or more digits (optionally containing a decimal point), followed by an optional exponent. The exponent is an 'e' or 'E' followed by one or more digits.

Emphesis mine


And because this is such a fundamental realisation of the PHP Type Juggling, I would suspect the issue lies less with Magento's type handling and more with your own interpretion of their type handling abilities. There will be better Magento methods you can employ for a more accurate response.

I would suggest the following pseudo code as a work around for your issue:

if((string)$sString != (int)$sString) { //This string is not a number or not only a number. } 
Sign up to request clarification or add additional context in comments.

6 Comments

My bad, I was on that page in the documentation, just needed to read a bit further...
To your update, there is some goofy usage of a foreach that leads up to the typecast. I'm working on a patch for Magento 2 now.
@quickshiftin I have added some pseudo code for a work around. I would expect Magento developers to know this activity with PHP Type juggling, but, there may of course be oversight on their part...
It's actually pretty bad, they have a foreach that expects an associative array with keys being ids and values being, well values, but moreover strings. For new objects, they pass a non-associative array, so the id is taken to be the value. Subsequently an (int) typecast is used to determine whether an insert needs to be performed. So if the value starts with a number it thinks there's already a record in the database! What would be really bad is if it stumbled into a record that actually existed lol.
@quickshiftin I could only guess that where this foreach occurs that they already expect a Magento parsed value/key pair. It's been a few years since I've worked on Magento, but whenever I've had issues with it it's been I've been using the wrong methods for the given data (documentation has been (still is?) an issue for Mage, I felt)
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.