#44808 [Opn->Csd]: Accessing string offsets (array notation)

From: Date: Wed, 05 Nov 2008 17:17:42 +0000
Subject: #44808 [Opn->Csd]: Accessing string offsets (array notation)
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-1390@lists.php.net to get a copy of this message
ID: 44808 Updated by: vrana@php.net Reported By: florian dot ember at gmail dot com -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Windows XP PHP Version: Irrelevant New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. " Writing to an out of range offset pads the string with spaces. Non-integer types are converted to integer. Illegal offset type emits E_NOTICE. Negative offset emits E_NOTICE in write but reads empty string. Only the first character of an assigned string is used. Assigning empty string assigns NUL byte. " Previous Comments: ------------------------------------------------------------------------ [2008-04-23 14:11:18] florian dot ember at gmail dot com Description: ------------ While messing around with the feature mentioned in the summary, I came across some undocumented results and/or bugs which should be documented (or fixed respectively). Offsets - When using an out of range offset, the string is padded with spaces. - When using a floating point number as offset, it is *always* rounded down. - When using an illegal type (such as an array) as offset, a warning is emitted and 0 is assumed. - When using a negative offset, PHP reports an uninitialized offset in read context, but reports an illegal offset in write context. Insert strings - When using a string which length is greater than 1, only the first character is used. (Fairly obvious but not documented) - When using a string which length is 0 ("", that is), a \0 character is inserted at that position instead. The last result is the strangest one. Might be a bug. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=44808&edit=1

« previous php.doc.bugs (#1390) next »