# PHP 5.2 Branched

- Thread: https://externals.io/message/23169
- Original archive: https://news-web.php.net/php.internals/23169
- Started by Ilia Alshanetsky on 2006-05-06T22:27:40+00:00
- Messages: 23
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #23169 — Ilia Alshanetsky — 2006-05-06T22:27:40+00:00

URL: https://externals.io/message/23169#23169

I've just created the PHP 5.2 branch from which future 5.X release  
will be made, so please update your local trees to this branch. The  
5.1 branch is dead to patches except for those fixing security issues  
or critical regressions, once 5.2.0 is released, the 5.1 branch will  
be discontinued.  Over the last week a list of planned changes for  
the 5.2 have been compiled on Lukas' wiki (http:// 
oss.backendmedia.com/PhP52). I've broken down the list into two  
sections "confirmed" and "pending discussion" the latter being  
changes I am not certain about and would like to hear everyone's  
feedback.

Confirmed:

* new functions: ext/date: date_sun_info (derick)
* Switch for disabling/enabling materialized cursors in mysqli (georg)
* add support for files >2GB (wez)
* Engine and Language optimizations.

DOM:
         * Add the registerNodeClass() function currently in HEAD
         * Add Canonical functionality (still trying to figure out  
best method signature for this one)
         * Update IsID? functionality (code currently in HEAD)

PCRE (MFH)
         * cache hooks
	* make it possible to set runtime limits on backtracking and  
recursion and add `preg_last_error()`

PDO
         * Add PDO::defaultFetchMode attribute (partially done,  
remains only fetch_object) (pierre)
         * Allow the DSN to be passed as array, proposal phase. An  
initial proposal was done here (pierre, lukas)
         * PDO: FETCH_PROPS_LATE

SOAP
         * SOAP Cache optimizations (Dmitri and Andrei) (technically  
it is already in)

SPL
         MFH
         * SPL: RegExIterator?
         * SPL: SplFileObject?: read csv, skip empty lines
         * SPL: ArrayIterator?: overload ArrayAccess? support and  
array functions
         NEW
         * SPL: RegExIterator?: ability to pregsplit the matches
         * SPL: SplFileObject?: ability to set the CSV separator per  
object
         * streams (SPL?): leverage memory/temp streams so that a  
string can be converted to a stream easily, some registration  
interface is nec

PDO SQLite
         * Upgrade bundled SQLite 3 library (Ilia)

XSL:
         * Add property to perform XInclude during transformation

XMLWriter:
         * Synch code with HEAD (code is cleaner and shorter in HEAD)  
contains 2 new methods (fullEndElement? and writeRaw)
         * Add writeNote([xmlreader obj]), allow to create a push/ 
pull parser

XMLReader:
         * Merge functionality from HEAD
         * xmlReader::readInnerXml?
         * xmlReader::setSchema
         * passing libxml options when loading reader
         * add readInnerXML?, readOuterXML?, readString, setSchema  
(all require libxml2-2.6.20+)
         ( use xmlreader const functions (lowers memory usage and  
runs faster)

Zend Engine and langages:
         * Zend: __toString()
         * Zend: interfaces with constructors
         * Zend: exception functions TSRM signature (compatible with  
HEAD)
         * Drop ZE1 compatibility
         * `E_RECOVERABLE_ERROR` 

* PostgreSQL
         * MFH pg_field_table() (edin)


Pending Discussion:

* Add input filter extension via a symlink from pecl into core as  
experimental (derick)
* Add json extension via a symlink from pecl into core as experimental
* on-the-fly static properties (mike)
* 'strict class' to disable dynamic member variable addition, see  
above (marcus)
* main: spprintf 'v' (maybe the zstr stuff?)
* Output Buffering rewrite (mike) (uncertain as of yet)


As far as the release plan, the hope is to have 5.2 released within 3  
months, with major changes completed within the 1st month and the  
remaining 2 month used to get things stable. The tentative date for  
RC1 is June 22nd.

Ilia

---

## #23170 — Wez Furlong — 2006-05-06T23:24:56+00:00

URL: https://externals.io/message/23169#23170 · In reply to: #23169

I'd like to add a function that returns tsrm_thread_id().  It would be
present in ZTS builds only, and could be used by code that needs to
generate "unique" identifiers.

I'm open for ideas on what to name it; sys_get_thread_id() or something?

--Wez.


> I've just created the PHP 5.2 branch from which future 5.X release
> will be made, so please update your local trees to this branch. The
> 5.1 branch is dead to patches except for those fixing security issues
> or critical regressions, once 5.2.0 is released, the 5.1 branch will
> be discontinued.  Over the last week a list of planned changes for
> the 5.2 have been compiled on Lukas' wiki (http://
> oss.backendmedia.com/PhP52). I've broken down the list into two
> sections "confirmed" and "pending discussion" the latter being
> changes I am not certain about and would like to hear everyone's
> feedback.
>
> Confirmed:
>
> * new functions: ext/date: date_sun_info (derick)
> * Switch for disabling/enabling materialized cursors in mysqli (georg)
> * add support for files >2GB (wez)
> * Engine and Language optimizations.
>
> DOM:
>          * Add the registerNodeClass() function currently in HEAD
>          * Add Canonical functionality (still trying to figure out
> best method signature for this one)
>          * Update IsID? functionality (code currently in HEAD)
>
> PCRE (MFH)
>          * cache hooks
>         * make it possible to set runtime limits on backtracking and
> recursion and add `preg_last_error()`
>
> PDO
>          * Add PDO::defaultFetchMode attribute (partially done,
> remains only fetch_object) (pierre)
>          * Allow the DSN to be passed as array, proposal phase. An
> initial proposal was done here (pierre, lukas)
>          * PDO: FETCH_PROPS_LATE
>
> SOAP
>          * SOAP Cache optimizations (Dmitri and Andrei) (technically
> it is already in)
>
> SPL
>          MFH
>          * SPL: RegExIterator?
>          * SPL: SplFileObject?: read csv, skip empty lines
>          * SPL: ArrayIterator?: overload ArrayAccess? support and
> array functions
>          NEW
>          * SPL: RegExIterator?: ability to pregsplit the matches
>          * SPL: SplFileObject?: ability to set the CSV separator per
> object
>          * streams (SPL?): leverage memory/temp streams so that a
> string can be converted to a stream easily, some registration
> interface is nec
>
> PDO SQLite
>          * Upgrade bundled SQLite 3 library (Ilia)
>
> XSL:
>          * Add property to perform XInclude during transformation
>
> XMLWriter:
>          * Synch code with HEAD (code is cleaner and shorter in HEAD)
> contains 2 new methods (fullEndElement? and writeRaw)
>          * Add writeNote([xmlreader obj]), allow to create a push/
> pull parser
>
> XMLReader:
>          * Merge functionality from HEAD
>          * xmlReader::readInnerXml?
>          * xmlReader::setSchema
>          * passing libxml options when loading reader
>          * add readInnerXML?, readOuterXML?, readString, setSchema
> (all require libxml2-2.6.20+)
>          ( use xmlreader const functions (lowers memory usage and
> runs faster)
>
> Zend Engine and langages:
>          * Zend: __toString()
>          * Zend: interfaces with constructors
>          * Zend: exception functions TSRM signature (compatible with
> HEAD)
>          * Drop ZE1 compatibility
>          * `E_RECOVERABLE_ERROR` 
>
> * PostgreSQL
>          * MFH pg_field_table() (edin)
>
>
> Pending Discussion:
>
> * Add input filter extension via a symlink from pecl into core as
> experimental (derick)
> * Add json extension via a symlink from pecl into core as experimental
> * on-the-fly static properties (mike)
> * 'strict class' to disable dynamic member variable addition, see
> above (marcus)
> * main: spprintf 'v' (maybe the zstr stuff?)
> * Output Buffering rewrite (mike) (uncertain as of yet)
>
>
> As far as the release plan, the hope is to have 5.2 released within 3
> months, with major changes completed within the 1st month and the
> remaining 2 month used to get things stable. The tentative date for
> RC1 is June 22nd.
>
> Ilia

---

## #23171 — Brian J. France — 2006-05-07T00:01:41+00:00

URL: https://externals.io/message/23169#23171 · In reply to: #23169

Could the curl_multi_info_read patch be considered for the 5.2 branch?

Thanks,

Brian



> I've just created the PHP 5.2 branch from which future 5.X release  
> will be made, so please update your local trees to this branch. The  
> 5.1 branch is dead to patches except for those fixing security  
> issues or critical regressions, once 5.2.0 is released, the 5.1  
> branch will be discontinued.  Over the last week a list of planned  
> changes for the 5.2 have been compiled on Lukas' wiki (http:// 
> oss.backendmedia.com/PhP52). I've broken down the list into two  
> sections "confirmed" and "pending discussion" the latter being  
> changes I am not certain about and would like to hear everyone's  
> feedback.
>
> Confirmed:
>
> * new functions: ext/date: date_sun_info (derick)
> * Switch for disabling/enabling materialized cursors in mysqli (georg)
> * add support for files >2GB (wez)
> * Engine and Language optimizations.
>
> DOM:
>         * Add the registerNodeClass() function currently in HEAD
>         * Add Canonical functionality (still trying to figure out  
> best method signature for this one)
>         * Update IsID? functionality (code currently in HEAD)
>
> PCRE (MFH)
>         * cache hooks
> 	* make it possible to set runtime limits on backtracking and  
> recursion and add `preg_last_error()`
>
> PDO
>         * Add PDO::defaultFetchMode attribute (partially done,  
> remains only fetch_object) (pierre)
>         * Allow the DSN to be passed as array, proposal phase. An  
> initial proposal was done here (pierre, lukas)
>         * PDO: FETCH_PROPS_LATE
>
> SOAP
>         * SOAP Cache optimizations (Dmitri and Andrei) (technically  
> it is already in)
>
> SPL
>         MFH
>         * SPL: RegExIterator?
>         * SPL: SplFileObject?: read csv, skip empty lines
>         * SPL: ArrayIterator?: overload ArrayAccess? support and  
> array functions
>         NEW
>         * SPL: RegExIterator?: ability to pregsplit the matches
>         * SPL: SplFileObject?: ability to set the CSV separator per  
> object
>         * streams (SPL?): leverage memory/temp streams so that a  
> string can be converted to a stream easily, some registration  
> interface is nec
>
> PDO SQLite
>         * Upgrade bundled SQLite 3 library (Ilia)
>
> XSL:
>         * Add property to perform XInclude during transformation
>
> XMLWriter:
>         * Synch code with HEAD (code is cleaner and shorter in  
> HEAD) contains 2 new methods (fullEndElement? and writeRaw)
>         * Add writeNote([xmlreader obj]), allow to create a push/ 
> pull parser
>
> XMLReader:
>         * Merge functionality from HEAD
>         * xmlReader::readInnerXml?
>         * xmlReader::setSchema
>         * passing libxml options when loading reader
>         * add readInnerXML?, readOuterXML?, readString, setSchema  
> (all require libxml2-2.6.20+)
>         ( use xmlreader const functions (lowers memory usage and  
> runs faster)
>
> Zend Engine and langages:
>         * Zend: __toString()
>         * Zend: interfaces with constructors
>         * Zend: exception functions TSRM signature (compatible with  
> HEAD)
>         * Drop ZE1 compatibility
>         * `E_RECOVERABLE_ERROR` 
>
> * PostgreSQL
>         * MFH pg_field_table() (edin)
>
>
> Pending Discussion:
>
> * Add input filter extension via a symlink from pecl into core as  
> experimental (derick)
> * Add json extension via a symlink from pecl into core as experimental
> * on-the-fly static properties (mike)
> * 'strict class' to disable dynamic member variable addition, see  
> above (marcus)
> * main: spprintf 'v' (maybe the zstr stuff?)
> * Output Buffering rewrite (mike) (uncertain as of yet)
>
>
> As far as the release plan, the hope is to have 5.2 released within  
> 3 months, with major changes completed within the 1st month and the  
> remaining 2 month used to get things stable. The tentative date for  
> RC1 is June 22nd.
>
> Ilia

---

## #23172 — Rasmus Lerdorf — 2006-05-07T05:10:46+00:00

URL: https://externals.io/message/23169#23172 · In reply to: #23169

Ilia Alshanetsky wrote:
> Pending Discussion:
> 
> * Add input filter extension via a symlink from pecl into core as 
> experimental (derick)
> * Add json extension via a symlink from pecl into core as experimental

Haven't we discussed these two enough?  Does someone actually disagree 
with pushing these in as soon as possible?

-Rasmus

---

## #23173 — Marcus Boerger — 2006-05-07T10:11:37+00:00

URL: https://externals.io/message/23169#23173 · In reply to: #23172

Hello Rasmus,

Sunday, May 7, 2006, 7:10:46 AM, you wrote:

> Ilia Alshanetsky wrote:
> > […]

> Haven't we discussed these two enough?  Does someone actually disagree 
> with pushing these in as soon as possible?

I was also under the impression that we agreed already.

Best regards,
 Marcus

---

## #23174 — Pierre — 2006-05-07T12:10:30+00:00

URL: https://externals.io/message/23169#23174 · In reply to: #23172

On Sat, 06 May 2006 22:10:46 -0700
rasmus@lerdorf.com (Rasmus Lerdorf) wrote:

> Ilia Alshanetsky wrote:
> > […]
> 
> Haven't we discussed these two enough?  Does someone actually
> disagree with pushing these in as soon as possible?

Yes we already agreed on these two additions.

-- Pierre

---

## #23176 — Ilia Alshanetsky — 2006-05-07T14:57:47+00:00

URL: https://externals.io/message/23169#23176 · In reply to: #23172

I am +0 on these two extensions, hence the "to be discussed", as long  
as they are not enabled by default I see no problem with symlinking  
them in.




> Ilia Alshanetsky wrote:
> > […]
>
> Haven't we discussed these two enough?  Does someone actually  
> disagree with pushing these in as soon as possible?
>
> -Rasmus
>

Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

---

## #23177 — Ilia Alshanetsky — 2006-05-07T14:58:24+00:00

URL: https://externals.io/message/23169#23177 · In reply to: #23171

Yeah, feel free to MFH that patch.




> Could the curl_multi_info_read patch be considered for the 5.2 branch?
>
> Thanks,
>
> Brian
>
> 
>
> > […]
>
>

Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

---

## #23178 — Rasmus Lerdorf — 2006-05-07T15:02:07+00:00

URL: https://externals.io/message/23169#23178 · In reply to: #23176

Ilia Alshanetsky wrote:
> I am +0 on these two extensions, hence the "to be discussed", as long as 
> they are not enabled by default I see no problem with symlinking them in.

I'd like to see the json extension enabled by default.  It's a trivially 
small extension with no external deps and pretty much required for 
modern Web apps.

And I think the filter extension should be enabled as well, but without 
the default filter turned on to make the filtering functions available.

-Rasmus

---

## #23179 — Pierre — 2006-05-07T15:08:58+00:00

URL: https://externals.io/message/23169#23179 · In reply to: #23178

On Sun, 07 May 2006 08:02:07 -0700
rasmus@lerdorf.com (Rasmus Lerdorf) wrote:

> Ilia Alshanetsky wrote:
> > […]
> 
> I'd like to see the json extension enabled by default.  It's a
> trivially small extension with no external deps and pretty much
> required for modern Web apps.
> 
> And I think the filter extension should be enabled as well, but
> without the default filter turned on to make the filtering functions
> available.

I also like to have it enabled by default and without default filter.

In case some of you never tested pecl/filter, the default filter
is a SAPI filter. It filters each inputs and replaces the raw values by
the filtered values in all superglobals, like _POST/_GET. Enable it by
default now will break every applications, as soon as it is set to
something else than raw. STRING is the default mode (remove every tags,
new lines, special chars,...).


-- Pierre

---

## #23180 — Marcus Boerger — 2006-05-07T15:09:37+00:00

URL: https://externals.io/message/23169#23180 · In reply to: #23178

Hello Rasmus,

  same here, i see nothing that speaks against enabling by default. Indeed
didn't we all want to have ext filter as default enabled from the start?
And i can only second Rasmus that json is necessary for Web 2.0 to name the
beast.

marcus

Sunday, May 7, 2006, 5:02:07 PM, you wrote:

> Ilia Alshanetsky wrote:
> > […]

> I'd like to see the json extension enabled by default.  It's a trivially 
> small extension with no external deps and pretty much required for 
> modern Web apps.

> And I think the filter extension should be enabled as well, but without 
> the default filter turned on to make the filtering functions available.

> -Rasmus




Best regards,
 Marcus

---

## #23181 — Derick Rethans — 2006-05-07T15:11:28+00:00

URL: https://externals.io/message/23169#23181 · In reply to: #23178

> Ilia Alshanetsky wrote:
> > […]

...

> And I think the filter extension should be enabled as well, but without the
> default filter turned on to make the filtering functions available.

Yeah, me too.

Derick

---

## #23182 — Ilia Alshanetsky — 2006-05-07T15:23:07+00:00

URL: https://externals.io/message/23169#23182 · In reply to: #23178

> Ilia Alshanetsky wrote:
> > […]
>
> I'd like to see the json extension enabled by default.  It's a  
> trivially small extension with no external deps and pretty much  
> required for modern Web apps.
>

That's stretching it a bit, don't you think? I don't deny that JSON  
extension is useful, but "required" for modern apps, c'mon...

> And I think the filter extension should be enabled as well, but  
> without the default filter turned on to make the filtering  
> functions available.
>

What impact would it have on the speed of input processing if it is  
always there, but not doing anything? I'd prefer to avoid adding  
extra overhead for something that does nothing by default, we have  
enough performance issues as is in 5.X. Pierre and Derick are telling  
me that if the RAW filter is enabled it won't touch the data so  
perhaps that's the route we should take, but I'd definitely like to  
see before & after benchmarks.

Ilia

---

## #23183 — Rasmus Lerdorf — 2006-05-07T15:53:17+00:00

URL: https://externals.io/message/23169#23183 · In reply to: #23182

Ilia Alshanetsky wrote:
> 
> 
> 
> > […]
> 
> That's stretching it a bit, don't you think? I don't deny that JSON 
> extension is useful, but "required" for modern apps, c'mon...

I can't think of anything I have written, or anybody around me has 
written in the past 6 months that didn't need json.  Yes, I guess if you 
have no Javascript at all, then you don't need json, but if you do any 
Javascript, it is the only sane way to transfer data from PHP to 
Javascript.  Even if you don't use Ajax-like backend requests, a simple:

  <script>
    var data = <?php echo json_encode($php_data)?>;
  </script>

Is so much easier, cleaner and safer than any other mechanisms you can 
throw at this.  The fact that we didn't get this into PHP sooner is 
actually a bit sad as far as I am concerned.

> > […]
> 
> What impact would it have on the speed of input processing if it is 
> always there, but not doing anything? I'd prefer to avoid adding extra 
> overhead for something that does nothing by default, we have enough 
> performance issues as is in 5.X. Pierre and Derick are telling me that 
> if the RAW filter is enabled it won't touch the data so perhaps that's 
> the route we should take, but I'd definitely like to see before & after 
> benchmarks.

It won't touch the data, but that doesn't mean it isn't useful.  Being 
able to do:

   echo input_get(INPUT_SERVER, "SCRIPT_URI", FILTER_SANITIZE_URL);

or using the new input_get_args() function to completely and safely 
specify all your input parameters to a page is also a big win.

-Rasmus

---

## #23184 — Pierre — 2006-05-07T15:54:38+00:00

URL: https://externals.io/message/23169#23184 · In reply to: #23182

Hello,



> What impact would it have on the speed of input processing if it is
> always there, but not doing anything? I'd prefer to avoid adding
> extra overhead for something that does nothing by default, we have
> enough performance issues as is in 5.X. Pierre and Derick are telling
> me that if the RAW filter is enabled it won't touch the data so
> perhaps that's the route we should take, but I'd definitely like to
> see before & after benchmarks.

The current code calls the sapi filter, no matter if the filter is set
to UNSAFE_RAW (data unchanged) or not.

I already tested an alternative solution. It is possible to do not
register the sapi filter and use  PG(http_globals)[...] directly in
input_get (and input_get_args). Doing so will minimize any possible
performance impact.

--Pierre

---

## #23185 — Ilia Alshanetsky — 2006-05-07T16:18:33+00:00

URL: https://externals.io/message/23169#23185 · In reply to: #23183

> Ilia Alshanetsky wrote:
> > […]
>
> I can't think of anything I have written, or anybody around me has  
> written in the past 6 months that didn't need json.  Yes, I guess  
> if you have no Javascript at all, then you don't need json, but if  
> you do any Javascript, it is the only sane way to transfer data  
> from PHP to Javascript.  Even if you don't use Ajax-like backend  
> requests, a simple:
>
>  <script>
>    var data = <?php echo json_encode($php_data)?>;
>  </script>
>
> Is so much easier, cleaner and safer than any other mechanisms you  
> can throw at this.  The fact that we didn't get this into PHP  
> sooner is actually a bit sad as far as I am concerned

Well, I have written quite a few application in the past few years  
and many of them have used JavaScript in one way or another and only  
in few instances did the amount of data involve required something as  
evolved as JSON. Every extension in PECL exists because someone out  
there has a need for the functionality no matter how obscure it may  
seem to the rest of us. JSON certainly seems like something that  
could be of use to a large group from what I am hearing on and off  
the list, so lets link it in.

> > […]
>
> It won't touch the data, but that doesn't mean it isn't useful.   
> Being able to do:
>
>   echo input_get(INPUT_SERVER, "SCRIPT_URI", FILTER_SANITIZE_URL);
>
> or using the new input_get_args() function to completely and safely  
> specify all your input parameters to a page is also a big win.

Well that can still work, we can access the data from PG 
(http_globals) without having to duplicate the data at the onset.

Ilia

---

## #23186 — Rasmus Lerdorf — 2006-05-07T16:20:33+00:00

URL: https://externals.io/message/23169#23186 · In reply to: #23185

Ilia Alshanetsky wrote:
> Well that can still work, we can access the data from PG(http_globals) 
> without having to duplicate the data at the onset.

Not if we don't enable the extension which is what we are talking about.

-Rasmus

---

## #23187 — Derick Rethans — 2006-05-07T16:27:30+00:00

URL: https://externals.io/message/23169#23187 · In reply to: #23186

> Ilia Alshanetsky wrote:
> > […]
> 
> Not if we don't enable the extension which is what we are talking about.

Well, we should enable it by default with the default filter set to 
raw... otherwise folks still don't have the input_get functionality 
which is the basic point of this extension to me. For me this is much 
more useful then JSON...

Derick

---

## #23191 — Lukas Smith — 2006-05-08T07:11:43+00:00

URL: https://externals.io/message/23169#23191 · In reply to: #23169

Ilia Alshanetsky wrote:

> discontinued.  Over the last week a list of planned changes for the 5.2 
> have been compiled on Lukas' wiki (http://oss.backendmedia.com/PhP52). 

I have updated the wiki page with Ilia's list. I added a few items that 
I still marked as todo in my email client into the "open for discussion" 
list.

regards,
Lukas

---

## #23196 — Antony Dovgal — 2006-05-08T18:14:48+00:00

URL: https://externals.io/message/23169#23196 · In reply to: #23187

> 
> 
> > […]
> 
> Well, we should enable it by default with the default filter set to 
> raw... otherwise folks still don't have the input_get functionality 
> which is the basic point of this extension to me. For me this is much 
> more useful then JSON...

Agree, we need to enable it by default, otherwise including it in the core doesn't make much sense.

-- 
Wbr, 
Antony Dovgal

---

## #23197 — Pierre — 2006-05-08T18:28:26+00:00

URL: https://externals.io/message/23169#23197 · In reply to: #23196

> Agree, we need to enable it by default, otherwise including it in the core doesn't make much sense.

Please read my answers in this thread and my post from today about the
current filter status.

--Pierre

---

## #23230 — Sara Golemon — 2006-05-10T16:30:58+00:00

URL: https://externals.io/message/23169#23230 · In reply to: #23170

> I'd like to add a function that returns tsrm_thread_id(). 
> It would be present in ZTS builds only, and could be used
> by code that needs to generate "unique" identifiers.
>
> I'm open for ideas on what to name it; sys_get_thread_id()
> or something?
>
How about zend_thread_id()? (Present since 5.0.0)

I hadn't seen this one until just now either...

-Sara

---

## #23237 — Wez Furlong — 2006-05-11T00:23:14+00:00

URL: https://externals.io/message/23169#23237 · In reply to: #23230

Oooo.  Would be nice if that could make it into the manual.

--Wez.


> > […]
> How about zend_thread_id()? (Present since 5.0.0)
>
> I hadn't seen this one until just now either...
>
> -Sara