headers
Moriyoshi Koizumi | 2 Mar 2011 21:51
Picon

[PHP-DEV] Re: Reverting ext/mbstring patch

Hey,

I think I can fix it somehow.  Please don't be haste with it.  I am
going to look into it.

Moriyoshi

On Tue, Mar 1, 2011 at 11:35 PM, Dmitry Stogov <dmitry <at> zend.com> wrote:
> Hi,
>
> I'm going to revert Moriyoshi patch from December and some following fixes.
>
> I like the idea of the patch, but it just doesn't work as expected.
> It breaks 10 tests, but in general it breaks most things related to Unicode
> (declare statement, multibyte scripts, exif support for Unicode, multibyte
> POST requests).
>
> I tried to fix it myself, but I just can't understand how it should work
> (it's too big). It also has several places where integers messed with
> pointers, old API messed with new one and so on.
>
> I'm going to revert (apply the attached patch) on Thursday.
>
> Following is the list of failed tests:
>
> Shift_JIS request [tests/basic/029.phpt]
> Testing declare statement with several type values
> [Zend/tests/declare_001.phpt]
> Zend Multibyte and ShiftJIS
> [Zend/tests/multibyte/multibyte_encoding_001.phpt]
(Continue reading)

Permalink | Reply | 2 comments |
headers
Moriyoshi Koizumi | 2 Mar 2011 21:55
Picon

[PHP-DEV] RFC: built-in web server in CLI.

Hi,

Just to let you know that I wrote a RFC about built-in web server
feature with which PHP can serve contents without a help of web
servers.  That would be handy for development purpose.

If interested, have a look at http://wiki.php.net/rfc/builtinwebserver .

Regards,
Moriyoshi

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 28 comments |
headers
Rasmus Lerdorf | 2 Mar 2011 21:59

Re: [PHP-DEV] RFC: built-in web server in CLI.

On 3/2/11 12:55 PM, Moriyoshi Koizumi wrote:
> Hi,
> 
> Just to let you know that I wrote a RFC about built-in web server
> feature with which PHP can serve contents without a help of web
> servers.  That would be handy for development purpose.
> 
> If interested, have a look at http://wiki.php.net/rfc/builtinwebserver .

I like it. Need to go through it very carefully and look for
security-related issues though. Make sure all memory handling is safe.

-Rasmus

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 1 comment |
headers
Pierre Joye | 2 Mar 2011 23:38
Picon
Gravatar

Re: [PHP-DEV] RFC: built-in web server in CLI.

On Wed, Mar 2, 2011 at 9:59 PM, Rasmus Lerdorf <rasmus <at> lerdorf.com> wrote:
> On 3/2/11 12:55 PM, Moriyoshi Koizumi wrote:
>> Hi,
>>
>> Just to let you know that I wrote a RFC about built-in web server
>> feature with which PHP can serve contents without a help of web
>> servers.  That would be handy for development purpose.
>>
>> If interested, have a look at http://wiki.php.net/rfc/builtinwebserver .
>
> I like it. Need to go through it very carefully and look for
> security-related issues though. Make sure all memory handling is safe.

Same here, very handy. I would not worry too much about security
related issues as such builtin server should really be used for
development purposes only (yes, users do bad things even if we say to
do not it :).

-- 
Pierre

 <at> pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
Ángel González | 3 Mar 2011 00:05
Picon

Re: [PHP-DEV] RFC: built-in web server in CLI.

Moriyoshi Koizumi wrote:
> Hi,
>
> Just to let you know that I wrote a RFC about built-in web server
> feature with which PHP can serve contents without a help of web
> servers.  That would be handy for development purpose.
>
> If interested, have a look at http://wiki.php.net/rfc/builtinwebserver .
>
> Regards,
> Moriyoshi
I like the idea.

Regarding the patch (https://gist.github.com/835698):
I don't see a switch to disable the internal parse on configure.

I'd expect the files to be on its own folder inside sapi, even being
able to
bundle them in a single binary.

Why is this needed on WIndows?

+ ADD_FLAG("LIBS_CLI", "ws2_32.lib");

Surely php will already link with the sockets library for its own functions.

The http parser code seems copied from https://github.com/ry/http-parser and
it may not be a good idea to modify it downstream, but it  seems to do more
things than strictly needed by php (eg. there are more methods than those a
php server would take use).
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ángel González | 3 Mar 2011 00:20
Picon

Re: [PHP-DEV] Volnitsky substring search algo

Stas Malyshev wrote:
> Hi!
>
>> http://volnitsky.com/project/str_search/
>
> I'm not sure it'd be easy to integrate this into PHP codebase as-is,
> provided it relies on C++ standard libraries which PHP makes no use of
> (and thus potentially introduces a world of dependencies and
> complexities into the build process). I'm sure it can be re-done in
> pure standard C, then it can be tested in PHP and if it's better - I
> don't see why it can't be integrated.
>
Not really. It only uses std::search, which would be equivalent to the
current zend_memnstr(). And std::numeric_limits can be replaced with a
limits.h macro.
I'd be more concerned about the "only for little-endian platforms and
where access to misaligned W is allowed" remark. php is also available
for big endian architectures, but that seems easy. Some architecture
supported by php won't probably accept that, so it would also need some
configure test to disable it.

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
Damien Tournoud | 3 Mar 2011 01:27

Re: [PHP-DEV] Volnitsky substring search algo

On Sun, Feb 27, 2011 at 12:50 PM, Jordi Boggiano <j.boggiano <at> seld.be> wrote:

> http://volnitsky.com/project/str_search/

The algorithm seems flawed to me, at least in its reference implementation.
There does not seem to be any guarantee that the returned position is really
the *first* occurrence of the needle in the haystack.

It's easy to see with needle being a repetition of the same character:
  SS = 'a' * 1000
  W_size = 4

The hash map build will be clogged, with the value 1 stored in the first
slot for SS. As a consequence, the algorithm will step through the haystack,
trying to confirm a match for the needle at the step position. If a match is
found there, it will discard any previous matches that could be valid at
this position. All those haystack will return the same position 998:
  S = 'bbbb' * 997 + 'a' * 1000 (correct)
  S = 'bbb' * 996 + 'a' * 1001 (incorrect, should return 997)
  S = 'bb' * 995 + 'a' * 1002 (incorrect, should return 996)
  S = 'b' * 994 + 'a' * 1003 (incorrect, should return 995)

The implementation could be fixed (by adding an explicit string matching
when building the hash table, and by storing *all* the occurrences of a
given W in SS), but that will increase the overall cost (both computing and
memory) of the algorithm.

Damien Tournoud
Permalink | Reply | 1 comment |
headers
Moriyoshi Koizumi | 3 Mar 2011 04:47
Picon

Re: [PHP-DEV] RFC: built-in web server in CLI.

2011/3/3 Ángel González <keisial <at> gmail.com>:
> Moriyoshi Koizumi wrote:
>> Hi,
>>
>> Just to let you know that I wrote a RFC about built-in web server
>> feature with which PHP can serve contents without a help of web
>> servers.  That would be handy for development purpose.
>>
>> If interested, have a look at http://wiki.php.net/rfc/builtinwebserver .
>>
>> Regards,
>> Moriyoshi
> I like the idea.
>
> Regarding the patch (https://gist.github.com/835698):
> I don't see a switch to disable the internal parse on configure.

I don't see any obvious reason it should be able to be turned off
through the build option.  The only problem is binary size increase,
which I guess is quite subtle.

> I'd expect the files to be on its own folder inside sapi, even being
> able to
> bundle them in a single binary.
>
> Why is this needed on WIndows?
>
> + ADD_FLAG("LIBS_CLI", "ws2_32.lib");
>
> Surely php will already link with the sockets library for its own functions.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alexey Zakhlestin | 3 Mar 2011 07:35
Picon
Gravatar

Re: [PHP-DEV] RFC: built-in web server in CLI.

On Wed, Mar 2, 2011 at 11:55 PM, Moriyoshi Koizumi <mozo <at> mozo.jp> wrote:
> Hi,
>
> Just to let you know that I wrote a RFC about built-in web server
> feature with which PHP can serve contents without a help of web
> servers.  That would be handy for development purpose.
>
> If interested, have a look at http://wiki.php.net/rfc/builtinwebserver .

Interesting, indeed.

I noticed, that you hardcode mimetypes and index_files.
Mimetypes can probably be obtained from the system — we even had some
extension doing that.
And index_files should be configurable, because there are some
situations when people don't want any mime-types at all.

Also, it would be good to be able to configure which files are
actually parsed by php, not just served. Currently, these are only
".php" files

-- 
Alexey Zakhlestin, http://twitter.com/jimi_dini
http://www.milkfarmsoft.com/

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dmitry Stogov | 3 Mar 2011 08:44
Favicon
Gravatar

[PHP-DEV] Re: Reverting ext/mbstring patch

Hi Moriyoshi,

OK, I thought the email was lost, so ignore the email I just resent.

In general I like your patch and I would glad to see it fixed.

I already tried to make some fixes.
See the attached patch.

Thanks. Dmitry.

On 03/02/2011 11:51 PM, Moriyoshi Koizumi wrote:
> Hey,
>
> I think I can fix it somehow.  Please don't be haste with it.  I am
> going to look into it.
>
> Moriyoshi
>
> On Tue, Mar 1, 2011 at 11:35 PM, Dmitry Stogov<dmitry <at> zend.com>  wrote:
>> Hi,
>>
>> I'm going to revert Moriyoshi patch from December and some following fixes.
>>
>> I like the idea of the patch, but it just doesn't work as expected.
>> It breaks 10 tests, but in general it breaks most things related to Unicode
>> (declare statement, multibyte scripts, exif support for Unicode, multibyte
>> POST requests).
>>
>> I tried to fix it myself, but I just can't understand how it should work
(Continue reading)

Permalink | Reply | 1 comment |

Gmane