A serious PHP design flaw – watch out!

by Ochronus on May 19, 2009

Hello there! If you are new here, you might want to subscribe to the RSS feed for updates on this topic.

Today I discovered a quite disturbing fact about the way php handles array indexing. Talk about bad language design…

When using strings that contain only numbers (and don’t start with ’0′ (zero)) as indexes, they are automatically and inevitably converted to integers. For example:

$arr = array();
$b = '1234';

$arr['xxxx'] = 'y';
$arr[$b] = 'whatever';

foreach ($arr as $key => $value) {
  echo gettype($key)."n";
}

The expected output would be:

string
string

But it is:

string
integer

Oh, wow. This is not a big thing, right? PHP does this all the time, converting numeric strings to integers and vica-versa. Right, and it’s very convenient sometimes, but array indexing is something that should be handled very sensitively. For example I discovered this inner workings of PHP while debugging a seemingly mysterious bug in my code. I was filling up an associative array keyed by strings coming from a VARCHAR field in MySQL. Nothing fancy so far. Some of these strings contained only numbers. Later on, I used some code like:

foreach ($my_arr as $str_key => $some_value) {
  if (strpos($some_string, $str_key) !== false) {
    .
    .
    .
  }
}

And it started producing strange results – strings being matched which evidently didn’t match – wtf is going on? Reading the docs of strpos I found that if the needle is an integer, it’s converted to characters by their ordinal values. But where did those integers come from? ARRGHH, those pesky autoconverted array keys!
To fix it:

foreach ($my_arr as $str_key => $some_value) {
  if (strpos($some_string, (string)$str_key) !== false) {
    .
    .
    .
  }
}

So if I ever need some facts to use in the “why I hate php” type arguments, this will be in my pocket.

Tagged as: bug, design flaw, php

http://www.hiveminds.co.uk Carl McDade

This is a well known trait of PHP. Though loosely typed it will always guess at the meaning of an integer or string based on the operation being performed.

This is why certain operations like comparison have so many operators for different levels of the same thing. = ,==, === all produce different output as each tells PHP which level of logic to use.

In your case having keys interpreted as integers is only a guess by PHP not a transformation. If you are going to use PHP you will have to get used to type casting or write your code so that it is strictly typed.

If I had one thing I could pick to hate about PHP it would be the semi-organic development of the language. There is no road map only types places that the developers would like to visit on the way.

http://www.iamnolegend.com ochronus

I’m (unfortunately) using PHP on a daily basis, and of course I knew of its guessing. But there’s a distinction there: when I see an arithmetic operation like 3 + ’445′ it’s evident that ’445′ should be treated as an integer, also the other way, when I echo a number, php can know that it should be converted to a string. But array keying doesn’t fit into this scenario at all. PHP arrays are associative by nature.

http://www.hiveminds.co.uk Carl McDade

Actually after looking at your code I see you have a couple of things that can be changed to give correct behaviour. First, setting ’1234′ will be a string. (‘) will set anything within them to string until an arithmetic operation is called or when type guessing is involved. 1234 (without ‘ ) is an integer all the time.

/** default keys are int starting at 0 */
$arr = array();

/** is int */
$b = 1234;

/** is string but all numbers, PHP will guess int when used as array key
since keys are int by default */

$c = ’1234′;

/** xxxx is string and changes $arr to associative array */
$arr['xxxx'] = ‘y’;

/** first key = 1234 int but remains incremental int */
$a[$b] = ‘whatever’;

$x[$c] = ‘whatever’; //incremental

$y[(string)$c] = ‘whatever’; associative

foreach ($arr as $key => $value) {
echo gettype($key).”n”;
}

http://www.iamnolegend.com ochronus

Thank you for taking time for this

$arr = array();
$arr['xxx'] = ‘yyy’;
$key1 = ‘1234′;
$key2 = 1234;

$arr[$key1] references the exact same item as $arr[$key2] and $arr[(string)$key1] and $arr[(string)$key2]

Following your guide I wrote this little test:
$arr = array();

$b = 1234;
$c = ‘1234′;

$arr['xxxx'] = ‘literal string item’;
$arr[$b] = ‘Coming from an integer’;
$arr[$c] = ‘Coming from a numeric string’;
$arr[(string)$c] = ‘Coming from a cast numeric string’;
$arr[(string)$b] = ‘Coming from a cast integer’;

foreach ($arr as $key => $value) {
echo gettype($key).’ – ‘.$value.”n”;
}

The output is:

string – literal string item
integer – Coming from a cast integer

So I still can’t force PHP upon array access to make a distinction between ‘1234′ and 1234, or maybe I’m missing something.

http://www.muhuk.com Atamert Ölçgen

Too much magic. *sigh*
http://twitter.com/nqbao nqbao

Another problem with #PHP typecast :-< http://bit.ly/OdO1o

This comment was originally posted on Twitter
http://www.iamnolegend.com ochronus

@Atamert Ölçgen
Oh boy, this is some serious black magic, and in the wrong sense.
http://www.goingson.be Rob

Here’s how to deal with and never have a problem regarding this stuff:

1) Stop programming like a jack ass
2) Code like a normal human being
3) Make code organized and readable

OR

You can switch to ASP.NET, get out of the PHP business and let professionals do the work.

Either way your code example above is making a mountain out of an ant hill. I am 100% certain if you take a pencil and piece of paper and you map out your problem calmly and correctly you’ll find a much better solution that doesn’t involve hackNslash voodoo.

http://www.iamnolegend.com ochronus

Thanks for the constructive comment

1. Have you seen any of my php codes? I doubt it. The code in the article is just a quick thrown-together example.
2. See 1.
3. See 1.

Using associative array keys coming from DB fields is not hackNslash voodoo but common practice.

http://www.hiveminds.co.uk Carl McDade

So I still can’t force PHP upon array access to make a distinction between ‘1234? and 1234, or maybe I’m missing something.

Sorry, for misleading you on that point. No, you cannot force the interpretation. But this should not be necessary because an array should not have both associative keys and incremental keys.

When using strings that contain only numbers (and don’t start with ‘0? (zero)) as indexes, they are automatically and inevitably converted to integers.

It does not matter if when importing strings to keys if they are numbers or not. You choose to make the keys alphanumeric from the start and PHP sees them all as such. The field in MySQL is alphanumeric and so the keys in the array match as alphanumeric.

gettype is also an unreliable way of testing for data types since it does not know the differences between data types. Gettype is only capable of categorizing what a variable contains. To properly test for data type you should use the is_* (is_int, is_string …etc.) functions.
http://twitter.com/ConstantChange ConstantChange

Reading: A serious PHP design flaw – watch out! >> http://bit.ly/19jeoP

This comment was originally posted on Twitter
http://www.iamnolegend.com ochronus

@Carl McDade
No, you weren’t misleading, I just wanted to state my point again And also really thank you for your time, I appreciate it a lot.

Coming back to my point: I really think that it sucks that $arr['1234'] and $arr[1234] mean the exact same thing to php. Those are two very different keys. One is a string, the other is an integer.
Andrej

I had some strange behaviour of PHP code, too. I am using function strlen for string length checking. I used it in if statement like this:

if (strlen() > 0) {
// do something
} else {
// do something else
}

Do you see anything wrong with my code? Well, PHP did not complain, but evidently code didn’t produce expected result. Before I figured out, that I used strlen() with no parameter, I was thinking of shooting my computer. But documentation on php.net (http://si2.php.net/manual/en/function.strlen.php) sais nothing of default value of parameter. This is why I prefere Java over PHP!

http://www.iamnolegend.com ochronus

Hi,

Actually PHP does notice you with a nice warning:
PHP Warning: Wrong parameter count for strlen() in …. line …
You really should turn warnings and notices on on your dev server. Of course it’s a no-go on a live system, but you should be testing stuff before going live

http://twitter.com/webdevlv webdevlv

A serious PHP design flaw – watch out! http://bit.ly/OdO1o

This comment was originally posted on Twitter
http://twitter.com/joe_carney joe_carney

A serious PHP design flaw – watch out! http://bit.ly/wcnuQ

This comment was originally posted on Twitter
http://twitter.com/BoltClock BoltClock

A serious PHP design flaw – watch out! http://bit.ly/wcnuQ (via @joe_carney)

This comment was originally posted on Twitter
http://twitter.com/katharnavas katharnavas

A serious PHP design flaw – watch out! http://tinyurl.com/oc2bzl

This comment was originally posted on Twitter
http://twitter.com/katharnavas katharnavas

A serious PHP design flaw – watch out! http://tinyurl.com/oc2bzl

This comment was originally posted on Twitter
http://twitter.com/devongovett devongovett

A serious PHP design flaw – watch out! http://tinyurl.com/oc2bzl (via @katharnavas)

This comment was originally posted on Twitter
http://twitter.com/devongovett devongovett

A serious PHP design flaw – watch out! http://tinyurl.com/oc2bzl (via @katharnavas)

This comment was originally posted on Twitter
http://twitter.com/IsaacVanName IsaacVanName

Essential read! RT @devongovett: A serious PHP design flaw – watch out! http://tinyurl.com/oc2bzl (via @katharnavas)

This comment was originally posted on Twitter
http://twitter.com/IsaacVanName IsaacVanName

Essential read! RT @devongovett: A serious PHP design flaw – watch out! http://tinyurl.com/oc2bzl (via @katharnavas)

This comment was originally posted on Twitter
http://www.hiveminds.co.uk Carl McDade

LOL , I get a feeling of deja vu with this. I think the same “bug/question” has been coming up over and over since PHP 4 first became popular. It is something that the core team seems to have put aside as “by design” in all cases. Probably because it leads to arguements for strong data typing.
http://www.iamnolegend.com ochronus

@Carl McDade
Ok, I can accept that this is a “feature”, not a bug, but I still feel it’s a bad design decision
Just a personal opinion, nothing more.
http://floatsolutions.com/blog Aidan McQuay

Shouldn’t you array index names _not_ start with a number anyways, seems like bad coding practices.

http://www.iamnolegend.com ochronus

What do you mean? An associative array should handle anything that can be represented as a string. I’m using the associative array as something like a cache for items coming from DB so that I don’t have to do a SELECT every time (some items need to be filtered and transformed in a way that’s not possible with joins and mysql functions). What’s bad practice in this?

http://twitter.com/beckleyworks beckleyworks

“1) Stop programming like a jackass.” http://bit.ly/10ZPbY

This comment was originally posted on Twitter
Dom

I think you guys are looking at this from the wrong side. The real bug is in the design magic of strpos. I mean, how often is the int mode useful, and is it enough that we can’t be burdened with calling chr() or to throw a warning? I mean, what happens if I pass an object, array, or boolean in as needle, are they converted to an int and then used as the ordinal value?

Sometimes things should just fail. Adding this kind of magic should only happen when it is beneficial for it to happen.

http://www.iamnolegend.com ochronus

You truly have a point there No good comes from the language/platform being too “smart”

Amir Laher

haha, sheesh, I remember php’s hellish typing. Glad to had moved on to other languages!

I agree, it’s a nasty problem. Solution: always use a prefix like ‘id_’ or ‘structurename_’, so as to prevent disappointment.

I remember one place this prob manifested itself for me was in an XML-RPC library, which could not differentiate my id-keyed hashes from normal arrays, so those keys got lost in the translation.

As an aside, there’s a similar issue in the XML spec regarding ID attributes. Arguably that issue has better justification, but it’s still very similar.
Amir Laher

Hi there, I wasn’t finished about the XML thing, but now I’ve had a few wines and I’d like to talk more … please accept my apologies if this doesn’t seem too relevant:

In an xml DTD you can specify an ID attribute for a given tag, and that ID needs to begin with non-numeric characters. Strange? Not really: that ID needs to be unique across a whole document, not just that tagname. Say, you have a some ‘company’ tags and nested inside those companies you have some ‘employee’ tags. If you’d specified id=’1′ for company 1, you could no longer use id=’1′ for an employee. Therefore, you would use id=’company_1′ for the first company and id=’employee_1′ for the first employee, whilst still being able to use document.getElementById() to isolate each of these.

So, if prefixes are good enough for XML ids, then why not for PHP hash keys?

Oh well, I’ll go back to my Java and C# and sleep soundly. Go Shatkar Donsetsk
spacebat

The real PHP gotcha is that you might find yourself using it, and rationalise this behaviour with notions like “it can’t be that bad, everyone’s doing it”. For reference, that’s how World War 2 got started.
http://www.reddit.com/user/tanglebones tanglebones

In other news: Water is wet.

This comment was originally posted on Reddit
http://www.reddit.com/user/FlySwat FlySwat

This is why loose typing sucks.

This comment was originally posted on Reddit
http://www.reddit.com/user/ochronus ochronus

Today I discovered a quite disturbing fact about the way php handles array indexing. Talk about bad language design…

This comment was originally posted on Reddit
http://www.reddit.com/user/toupeira toupeira

I was more disturbed when I found out that calling a function without a required argument only raises a E_WARNING, but still executes the function.

This comment was originally posted on Reddit
Ruben

Rob :
Here’s how to deal with and never have a problem regarding this stuff:
1) Stop programming like a jack ass
2) Code like a normal human being
3) Make code organized and readable
OR
You can switch to ASP.NET, get out of the PHP business and let professionals do the work.

That has got to be the most retarded comment ever. Switch to ASP.NET… pfft. If anything you should switch to Java not to some retarded technology for retarded programmers with retarded attitude.
http://www.reddit.com/user/geon geon

Actually, this is not so bad. You need to know your tools… If you have read any PHP array function documentation at all, you will know that PHP treats integer indices differently. A lot of the array functions will re-index your integer-indexed arrays. This is what you would expect for array concatenation, for example. Because of the loose typing, it is reasonable to cast numerical strings to integers when used for indexing.

This comment was originally posted on Reddit
mark

I am so glad that I left the PHP world 5 years ago in favour for (both) ruby and python.
Pingback: ??????? » [Web] ????
http://www.reddit.com/user/masklinn masklinn

tl;dr, the serious design flaw of PHP is PHP.

This comment was originally posted on Reddit
http://www.reddit.com/user/jkff jkff

Thanks for pointing out, I didn’t know PHP had any design flaws, let alone serious ones!

This comment was originally posted on Reddit
http://www.reddit.com/user/demizer demizer

PHP is the design flaw. Perl for life!

This comment was originally posted on Reddit
http://www.reddit.com/user/MSDN MSDN

PHP has a design?

This comment was originally posted on Reddit
http://www.reddit.com/user/f3nd3r f3nd3r

>PHP: A Serious Design Flaw fix’d

This comment was originally posted on Reddit
http://www.reddit.com/user/mattiasl mattiasl

> Because of the loose typing, it is reasonable to cast numerical strings to integers when used for indexing. No it isn’t.

This comment was originally posted on Reddit
Pingback: Pinderkent: Programming languages should not try to guess the programmer's intentions.
http://www.reddit.com/user/geon geon

Your argumentation technique is lacking something.

This comment was originally posted on Reddit
pestaa

It’s not PHP’s fault if you’re incompetent.
http://www.iamnolegend.com ochronus

pestaa :

It’s not PHP’s fault if you’re incompetent.

What would be my incompetence here?
http://www.reddit.com/user/geon geon

consider the alternative. Would you like to have arrays where $foo[123] and $foo['123'] have distinct values?

This comment was originally posted on Reddit
http://www.reddit.com/user/ochronus ochronus

I, for one, would like. 123 is an integer, which is a whole different animal than ‘123′ which is a string which just happens to be the textual representation of the same number. Or at least let me force php to use it as a string like $foo[(string)'123']

This comment was originally posted on Reddit
http://twitter.com/paviles paviles

[software] A serious #PHP design flaw – watch out! http://bit.ly/RIMuO

This comment was originally posted on Twitter
http://twitter.com/paviles paviles

[software] A serious #PHP design flaw – watch out! http://bit.ly/RIMuO

This comment was originally posted on Twitter
mnt

I find this piece of code even more amusing. And dont tell me you expect this to happen:

$a = false; // or ”
var_dump($a);
$b = &$a['foo'];
var_dump($a);

false
Array {
‘foo’ => null
}
Greg

@Rob What an astonishingly rude an ill-considered comment. No “professional” programmer would consider being so arrogant. PHP has serious typing problems and is seriously limited as an OO language. Some of us are professional programmers who have to work in PHP and work around its inadequacies every day. Comments like yours show a serious lack of understanding.
Pingback: blog@iamnolegend.com [ochronus] » A serious PHP design flaw - watch out!

Previous post: Continuations and ruby

Next post: Why ruby? part one – a classy class system

A serious PHP design flaw – watch out!

Magyar projektjeim

Recent Posts

Muhuk’s blog

A serious PHP design flaw – watch out!

Magyar projektjeim

Recent Posts

Tags

Muhuk’s blog