headers
David Soria Parra | 24 May 2013 23:28
Picon

[PHP-DEV] About fileinfo test.mp3

Hi Anatol,

I saw your commit 74555e7c26b2c61bb8e67b7d6a6f4d2b8eb3a5f3 added a 4mb
mp3 file. Is it possible to create a much smaller mp3 that helps to
reproduce the same bug? The file blows up the taball file for the final
release, which I hope to keep as small as possible.

Thanks in advance,
David

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 1 comment |
headers
Ferenc Kovacs | 24 May 2013 17:26
Picon
Gravatar

Re: [PHP-DEV] Proposal for better UTF-8 handling

On Fri, May 24, 2013 at 3:09 PM, Nikita Popov <nikita.ppv <at> gmail.com> wrote:

> On Fri, May 24, 2013 at 3:17 AM, Rouven Weßling <me <at> rouvenwessling.de
> >wrote:
>
> > Hi Internals!
> >
> > First let me introduce myself, my name is Rouven Weßling, I'm a student
> at
> > RWTH Aachen University and I'm one of the maintainers of the Joomla!
> > Framework (née Platform). I've been following the internals list for a
> few
> > months and started brushing of my C skills for the past couple of months
> so
> > I can start contributing.
> >
> > To me one of the most annoying things about working with PHP is the (lack
> > of) unicode support. In Joomla! we've been discussing switching from PHP
> > UTF-8 to Patchwork UTF-8 for our needs of handling UTF-8. Both are
> > libraries abstracting the multibyte extension and supplementing it with a
> > number of functions. They also provide userland replacements for when
> > multibyte is not available (Patchwork will also use iconv and intl if
> > available). All of this is a huge pain.
> >
> > To ease this situation I'd like to make a new start at better unicode
> > support for PHP, this time focusing on UTF-8 as the dominant web
> encoding.
> > As a first step I'd like to propose adding a set of functions for
> handling
> > UTF-8 strings. This should keep applications from implementing these
(Continue reading)

Permalink | Reply | 1 comment |
headers
Julien Pauli | 24 May 2013 10:04
Picon
Gravatar

[PHP-DEV] PHP5.5 RC2 has been tagged

Hi Internals,

Our RC2 of PHP 5.5.0 has been released for testing. It fixes some bugs and
improves stability against RC1 code.
You'll find details in the NEWS file.

The packages can be found at:

  http://downloads.php.net/dsp

and windows packages at

  http://windows.php.net/qa

Please test the release carefully and report any bugs.

This second RC could be the last one. Depending on bug reports, expect
another RC or a stable release to be announced for June 6th.

Thank you.

Regards
  Julien and David
Permalink | Reply | 0 comments |
headers
Rouven Weßling | 24 May 2013 03:17
Picon
Gravatar

[PHP-DEV] Proposal for better UTF-8 handling

Hi Internals!

First let me introduce myself, my name is Rouven Weßling, I'm a student at RWTH Aachen University and I'm
one of the maintainers of the Joomla! Framework (née Platform). I've been following the internals list
for a few months and started brushing of my C skills for the past couple of months so I can start contributing.

To me one of the most annoying things about working with PHP is the (lack of) unicode support. In Joomla!
we've been discussing switching from PHP UTF-8 to Patchwork UTF-8 for our needs of handling UTF-8. Both
are libraries abstracting the multibyte extension and supplementing it with a number of functions. They
also provide userland replacements for when multibyte is not available (Patchwork will also use iconv
and intl if available). All of this is a huge pain.

To ease this situation I'd like to make a new start at better unicode support for PHP, this time focusing on
UTF-8 as the dominant web encoding. As a first step I'd like to propose adding a set of functions for
handling UTF-8 strings. This should keep applications from implementing these algorithms in PHP (also
many of these are quite a bit faster, see benchmark results below). Once the algorithms are in place I'd
like to look into creating a class for unicode strings and eventually Python like unicode literals.

Before I write an RFC I'd like to get some feedback what you think about adding the following functions to PHP
5.6 (possibly more to follow): utf8_is_valid, utf8_strlen,  utf8_substr, utf8_strpos, utf8_strrpos,
utf8_str_split, utf8_strrev, utf8_recover, utf8_chr, utf8_ord, string_is_ascii.

Most of them (exceptions are utf8_chr, utf8_is_valid, utf8_recover and string_is_ascii) are currently
written in a way that they emit a warning when they encounter invalid UTF-8 and return with null. This
should encourage applications to check their input with utf8_is_valid and either stop further
processing or to fall back to utf8_recover to get a valid string. This should improve security since there
are attack vectors when malformed sequences get interpreted as another encoding.

You can find the code I've written so far here: https://github.com/realityking/pecl-utf8
You can find benchmark results here: http://realityking.github.io/pecl-utf8/results.html
(Continue reading)

Permalink | Reply | 2 comments |
headers
Richard Lynch | 23 May 2013 23:24

[PHP-DEV] Cannot call constructor

Consider this common scenario:

I use some OOP library, that is a "black box" and I like it that way.

As part of the integration, I need to extend one of the library's
classes:

class App_bar extends Library_foo{
  function __construct(){
    //do whatever I need to do here.
  }
}

So I write this code, and it works, and I'm happy.

Years go by and new releases of the library come out, steadily
improving features and fixing bugs etc.

But at some point, the library needed a resource in a __construct()
somewhere in the ancestry of Library_foo, to perform something at the
time of construction.

So they re-factored or re-implemented the black box library to have a
constructor in Library_foo class, or any of its numerous ancestors.

Suddenly my code doesn't work. Maybe the resource is only needed under
certain conditions. So their __construct doesn't get called, but
nothing bad happens until the circumstances where they need the
__construct called.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Nikita Popov | 23 May 2013 22:31
Picon

[PHP-DEV] Re: hash_pbkdf2 vs openssl_pbkdf2

On Sat, May 18, 2013 at 11:48 AM, Nikita Popov <nikita.ppv <at> gmail.com> wrote:

> Hi internals!
>
> I just noticed that we added the PBKDF2 algorithm two times in PHP 5.5.
> Once in the hash extension, once in the OpenSSL extension.
>
> The hash_pbkdf2 function was added via this RFC:
> https://wiki.php.net/rfc/hash_pbkdf2
>
> The openssl_pbkdf2 function probably was not noticed at that time because
> it was just commited, but not mentioned anywhere else (NEWS, UPGRADING,
> etc). Only saw it in vrana's documentation updates just now. The relevant
> commit is here: https://github.com/php/php-src/commit/f4847ef
>
> It would be nice if we could have only one of those functions. I'm
> currently tending towards the hash_ variant because of the commit message
> of the openssl_ function:
>
> > No easy way to put these in the hash extension since we don't really
> support optional
> > parameters to certain algorithms. Implemented in openssl for now since
> it has it already
> > and is pretty stable.
> >
> > Only SHA1 is confirmed to work as an algorithm but openssl has a
> parameter so it can be
> > changed in the future.
>
> It seems that the author already would have preferred it in the hash
(Continue reading)

Permalink | Reply | 3 comments |
headers
Sebastian Bergmann | 23 May 2013 22:18
Picon
Gravatar

[PHP-DEV] Bug #64910: Line number of $e = new Exception vs. line number of throw $e

 Hi!

 The error message that is created for an uncaught exception as well
 as the stacktrace of an exception list the number of the line on which
 the exception object was created. I would expect this to be number of
 the line on which the exception is raised using the throw statement.

 Derick agrees with me that this is a bug. We propose to update the file
 and line properties of the exception object in the
 zend_throw_exception_internal() and zend_throw_exception() functions.

 Would such a change be accepted? Does it require an RFC?

 Thanks!
Sebastian

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 10 comments |
headers
Daniel Lowrey | 23 May 2013 20:40
Picon
Gravatar

[PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

I'm probably not the typical PHP user; I spend 99% of my PHP time
using the CLI (and not web SAPIs).
This means that I frequently run PHP without an .ini file. As a
result, when I use any of the date/time
functionality I invariably end up with this awesomeness:

> Warning: date(): It is not safe to rely on the system's timezone settings blah blah blah.

Could I run `$ php -d date.timezone=UTC myfile.php`? Of course, but
should that really be necessary?
It seems to me this warning caters to the very lowest common
denominator among PHP devs who can't
be bothered to understand how PHP handles timezones. The warning also
seems to assume that people only
use PHP as a web framework and not as an actual programming language
(otherwise I wouldn't have to
explain to the CLI which timezone I want to use). I don't need php.ini
... I want to use PHP to *program*.

If it's going to default to UTC anyway should there really be an
E_WARNING? Can't PHP just quietly use UTC?
The "U" in UTC *does* stand for "Universal," after all. It's a
sensible default and as such shouldn't
merit a warning. Besides, if someone doesn't understand what's
happening and gets unexpected date/time
results the first thing they're going to do (I hope) is hit their
favorite search engine for "set PHP timezone."

Perhaps I'm the only person to experience ongoing annoyance at the
hands of this protective
(Continue reading)

Permalink | Reply | 17 comments |
headers
Sara Golemon | 21 May 2013 19:45
Picon

[PHP-DEV] ZEND_NS_NAMED_FE is clearly a frequently used macro

It's time to play "Spot the double quoting!"

#define ZEND_NS_FENTRY(ns, zend_name, name, arg_info, flags)
 ZEND_RAW_FENTRY(ZEND_NS_NAME(ns, #zend_name), name, arg_info, flags)

#define ZEND_NS_NAMED_FE(ns, zend_name, name, arg_info) ZEND_NS_FENTRY(ns,
#zend_name, name, arg_info, 0)

ZEND_NS_NAMED_FE("foo", bar, ...)

Gets exported to userspace as: foo\"bar" which is obviously fail.

Any objections to my fixing ZEND_NS_NAMED_FE as: s/#zend/zend/ ?

-Sara
Permalink | Reply | 1 comment |
headers
Erik Nedwidek | 18 May 2013 16:50
Favicon
Gravatar

[PHP-DEV] [Proposal] Add method to shmop ext to retrieve OS shmid

This grew out of a question I answered on StackOverflow.com:
http://stackoverflow.com/questions/16501707/working-with-shared-memory-in-php/

The gist is that a user was converting a C program to PHP and wanted
the shmid as reported by ipcs. The user assumed that the id returned
by shmop_open would be the shmid, and was confused by the shmop
resource identifier. (I explained to him what the return actually was)

I suggested he use his own unique key to be able to identify the
shared memory created for his script, but he said that it had to be
0x0.

I've added a function to retrieve shmop->shmid in my own fork of PHP.
You can see the changes here and the commit message contains a quick
usage/test script:
https://github.com/nedwidek/php-src/commit/832e77fce15de926b562b6dcc28d1864bb7c348b

So I guess the questions are:
Is there a particular reason that the shmid is hidden from PHP scripts?
Is there any reason not to move this to a formal RFC?
Should similar methods be added to the sysv* extensions where applicable?
Assuming this is an acceptable change to consider, anyone have a
better function name than shmop_sys_shmid?

Regards,
Erik Nedwidek
Permalink | Reply | 0 comments |
headers
Nikita Popov | 18 May 2013 11:48
Picon

[PHP-DEV] hash_pbkdf2 vs openssl_pbkdf2

Hi internals!

I just noticed that we added the PBKDF2 algorithm two times in PHP 5.5.
Once in the hash extension, once in the OpenSSL extension.

The hash_pbkdf2 function was added via this RFC:
https://wiki.php.net/rfc/hash_pbkdf2

The openssl_pbkdf2 function probably was not noticed at that time because
it was just commited, but not mentioned anywhere else (NEWS, UPGRADING,
etc). Only saw it in vrana's documentation updates just now. The relevant
commit is here: https://github.com/php/php-src/commit/f4847ef

It would be nice if we could have only one of those functions. I'm
currently tending towards the hash_ variant because of the commit message
of the openssl_ function:

> No easy way to put these in the hash extension since we don't really
support optional
> parameters to certain algorithms. Implemented in openssl for now since it
has it already
> and is pretty stable.
>
> Only SHA1 is confirmed to work as an algorithm but openssl has a
parameter so it can be
> changed in the future.

It seems that the author already would have preferred it in the hash
extension and that the openssl variant only works with sha1 (or was only
tested with it? not sure).
(Continue reading)

Permalink | Reply | 0 comments |

Gmane