# [PATCH] Deprecate use of stdio

- Thread: https://externals.io/message/1143
- Original archive: https://news-web.php.net/php.internals/1143
- Started by Sascha Schumann on 2003-05-01T23:04:47+00:00
- Messages: 7
- 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

---

## #1143 — Sascha Schumann — 2003-05-01T23:04:47+00:00

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

The following patches are aimed at deprecating the use of
    stdio by the script lexer in PHP 4, because certain stdio
    libraries impose restrictive limits on the number of open
    handles*.

    The patches have been split functionally for the benefit of
    the reviewer.

    Patch 1 adds a stream interface which fills in a
    zend_file_handle.  This is simply a modified copy of the
    open_as_file function.

    Patch 2 adds zend_open() which expects the implementation to
    fill in a zend_file_handle.

    Patch 3 makes PHP supply a zend_open implementation.

    Patch 4 modifies the lexer skeleton so that it can read using
    POSIX functions and stdio.  It also makes
    open_file_for_scanning use zend_open.

    * Background: Even the most modern Solaris ships with a stdio
      library which cannot handle fds over 255.  This severely
      limits any web server which may open more than 255 fds per
      process, because it won't be able to parse PHP scripts
      anymore.

      I've evaluated integrating sfio into the build process, but
      as it turns out, a full and complete integration would be a
      lot more complex than addressing the issue up-front.

    - Sascha

---

## #1157 — Wez Furlong — 2003-05-02T10:56:08+00:00

URL: https://externals.io/message/1143#1157 · In reply to: #1143

+1 from me, but we need to make an extra effort to stress test the
lexer (the ini file parser as well as the language parser) in our QA
process.

Also, for the sake of binary compatibility (not sure just how much of an
issue this is here), its "nicer" to add the zend_open function pointer
to the end of the utility functions structure, rather than in the
middle.

What do Zeev/Andi think of this?

--Wez.



>     The following patches are aimed at deprecating the use of
>     stdio by the script lexer in PHP 4, because certain stdio
>     libraries impose restrictive limits on the number of open
>     handles*.
>
>     The patches have been split functionally for the benefit of
>     the reviewer.
>
>     Patch 1 adds a stream interface which fills in a
>     zend_file_handle.  This is simply a modified copy of the
>     open_as_file function.
>
>     Patch 2 adds zend_open() which expects the implementation to
>     fill in a zend_file_handle.
>
>     Patch 3 makes PHP supply a zend_open implementation.
>
>     Patch 4 modifies the lexer skeleton so that it can read using
>     POSIX functions and stdio.  It also makes
>     open_file_for_scanning use zend_open.
>
>     * Background: Even the most modern Solaris ships with a stdio
>       library which cannot handle fds over 255.  This severely
>       limits any web server which may open more than 255 fds per
>       process, because it won't be able to parse PHP scripts
>       anymore.
>
>       I've evaluated integrating sfio into the build process, but
>       as it turns out, a full and complete integration would be a
>       lot more complex than addressing the issue up-front.
>
>     - Sascha

---

## #1162 — Sascha Schumann — 2003-05-02T11:41:09+00:00

URL: https://externals.io/message/1143#1162 · In reply to: #1157

> +1 from me, but we need to make an extra effort to stress test the
> lexer (the ini file parser as well as the language parser) in our QA
> process.

    In our what?

    A patched PHP inside of thttpd does not show any anomalies
    after 100K ab requests:

    test.php:

    <?php

    require "bar";
    include "foo";
    include "notthere";

    bar:

    <?echo "hi";

    foo:

    <?phpinfo();

    As I mentioned earlier, including from URLs appears to be
    broken even without my patches (we could call that a security
    feature).

> Also, for the sake of binary compatibility (not sure just how much of an
> issue this is here), its "nicer" to add the zend_open function pointer
> to the end of the utility functions structure, rather than in the
> middle.

    Moved.  It would only affect applications which statically
    initialize the structure.

    - Sascha

---

## #1163 — Sascha Schumann — 2003-05-02T13:10:59+00:00

URL: https://externals.io/message/1143#1163 · In reply to: #1157

Here is an updated version.  Patch 01/03 are unchanged.

    - Fixed fread argument order so that even my glibc likes it
    - Improved file_handle code in the ini scanner
    - Moved open_function struct member to the end

    - Sascha

---

## #1165 — Sterling Hughes — 2003-05-02T14:18:40+00:00

URL: https://externals.io/message/1143#1165 · In reply to: #1143

Just a note (didn't have time to review the patch, but I trust you :-),
that I'm +1 on the idea.

-Sterling


>     The following patches are aimed at deprecating the use of
>     stdio by the script lexer in PHP 4, because certain stdio
>     libraries impose restrictive limits on the number of open
>     handles*.
> 
>     The patches have been split functionally for the benefit of
>     the reviewer.
> 
>     Patch 1 adds a stream interface which fills in a
>     zend_file_handle.  This is simply a modified copy of the
>     open_as_file function.
> 
>     Patch 2 adds zend_open() which expects the implementation to
>     fill in a zend_file_handle.
> 
>     Patch 3 makes PHP supply a zend_open implementation.
> 
>     Patch 4 modifies the lexer skeleton so that it can read using
>     POSIX functions and stdio.  It also makes
>     open_file_for_scanning use zend_open.
> 
>     * Background: Even the most modern Solaris ships with a stdio
>       library which cannot handle fds over 255.  This severely
>       limits any web server which may open more than 255 fds per
>       process, because it won't be able to parse PHP scripts
>       anymore.
> 
>       I've evaluated integrating sfio into the build process, but
>       as it turns out, a full and complete integration would be a
>       lot more complex than addressing the issue up-front.
> 
>     - Sascha
> 
> ______________________________________________________________________
> 
> -- 
> 
> 
-- 
"First they ignore you, then they laugh at you,  
 then they fight you, then you win."  
    - Gandhi

---

## #1164 — Jay Smith — 2003-05-02T15:38:11+00:00

URL: https://externals.io/message/1143#1164 · In reply to: #1143

I've been playing with sfio on Solaris quite a bit recently and I've had our
site working on iPlanet with sfio for a couple of weeks. Seems to be doing
okay so far with something between 4.3.1 and 4.3.2. Getting sfio to link
was a bit of pain in the arse at first, but it came down to a couple of
simple LIBS arguments to get it going. 

As you say, fixing the problem at the root would be preferable, but sfio
might be a decent intermediary step. 

I can test the patches and such on Solaris 8 SPARC, and if you (or anybody
who needs it, within reason of course) would like access to a Solaris
shell, I can arrange it. (It's slightly limited by a 300 MB quota, but
that's pretty much it.)

J


Sascha Schumann wrote:

>     The following patches are aimed at deprecating the use of
>     stdio by the script lexer in PHP 4, because certain stdio
>     libraries impose restrictive limits on the number of open
>     handles*.
> 
>     The patches have been split functionally for the benefit of
>     the reviewer.
> 
>     Patch 1 adds a stream interface which fills in a
>     zend_file_handle.  This is simply a modified copy of the
>     open_as_file function.
> 
>     Patch 2 adds zend_open() which expects the implementation to
>     fill in a zend_file_handle.
> 
>     Patch 3 makes PHP supply a zend_open implementation.
> 
>     Patch 4 modifies the lexer skeleton so that it can read using
>     POSIX functions and stdio.  It also makes
>     open_file_for_scanning use zend_open.
> 
>     * Background: Even the most modern Solaris ships with a stdio
>       library which cannot handle fds over 255.  This severely
>       limits any web server which may open more than 255 fds per
>       process, because it won't be able to parse PHP scripts
>       anymore.
> 
>       I've evaluated integrating sfio into the build process, but
>       as it turns out, a full and complete integration would be a
>       lot more complex than addressing the issue up-front.
> 
>     - Sascha

---

## #1170 — Wez Furlong — 2003-05-02T16:52:36+00:00

URL: https://externals.io/message/1143#1170 · In reply to: #1164

Hi Jay,

This patch solves a lot of problems within PHP itself, but it is still a
good thing (tm) to link against sfio under Solaris in any case (third
party libs, and some of the less popular/maintained extensions will
still be using stdio).

So, the patch on its own is good, the patch combined with sfio is even
better. (Why can't Solaris fix their damned libc??).

If you can test it under iPlanet (initially, without using sfio), the
feedback would be much appreciated.

--Wez.



>
> I've been playing with sfio on Solaris quite a bit recently and I've had our
> site working on iPlanet with sfio for a couple of weeks. Seems to be doing
> okay so far with something between 4.3.1 and 4.3.2. Getting sfio to link
> was a bit of pain in the arse at first, but it came down to a couple of
> simple LIBS arguments to get it going.
>
> As you say, fixing the problem at the root would be preferable, but sfio
> might be a decent intermediary step.
>
> I can test the patches and such on Solaris 8 SPARC, and if you (or anybody
> who needs it, within reason of course) would like access to a Solaris
> shell, I can arrange it. (It's slightly limited by a 300 MB quota, but
> that's pretty much it.)
>
> J
>
>
> Sascha Schumann wrote:
>
> > […]