headers
Tatsuo Ishii | 1 Jul 2008 18:01
Picon
Favicon

Re: [PHP-DEV] new PostgreSQL API

Sorry for delay. Here is the revised patches.

I marged pg_lo_import_with_oid() into pg_lo_import().
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> > On 17.04.2008 18:50, Tatsuo Ishii wrote:
> > > Here are the patches against 5.2 HEAD.
> > 
> > First of all, please use `diff -u`, not just `diff` - unified diffs are much more readable.
> 
> Ok. I'll do it next time.
> 
> > > Modified API's are:
> > > 
> > > 1) pg_lo_create now accepts an optional parameter (large object
> > >    id). This corresponds to lo_create() which is new in PostgreSQL 8.1.
> > > 
> > > 2) new API: pg_lo_import_with_oid. Same as pg_lo_import except that it
> > >    accepts large object id. This corresponds to lo_import_with_oid()
> > >    which is new in PostgreSQL 8.4 (current).
> > 
> > Is there a real need for a new function?
> > Can't we modify pg_lo_import() to accept one more argument?
> 
> There's no techinical reason to add lo_import_with_oid(). I just
> wanted to directly map the PostgreSQL API to PHP's API. If integrating
> to pg_lo_import() is the PHP's way, I would be happy to update my
> patches.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Wietse Venema | 2 Jul 2008 00:17

[PHP-DEV] PHP+taint, Windows binaries

This is an update on my preliminary implementation of support for
tainted variables in PHP. To get more feedback from developers with
Windows systems, I have built Win32 binaries. These are available
in ZIP and Windows installer format from http://wiki.php.net/rfc/taint/
and are compatible with the binaries from http://www.apache.org/

As a reminder, the goal of this project is to help PHP application
programmers find and eliminate opportunities for HTML code injection
(i.e. XSS), SQL or shell code injection, or PHP control hijacking,
before other people can exploit them. With 1% run-time overhead,
taint support may also be used as a safety net in production.  The
preliminary implementation provides taint support for basic operators,
for a selection of built-functions and extensions (pcre, mysql,
mysqli), and for the Apache server APIs.

For source, binaries and more please see http://wiki.php.net/rfc/taint/

        Wietse

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
Wietse Venema | 2 Jul 2008 00:22

[PHP-DEV] PHP+taint, Windows binaries

This is an update on my preliminary implementation of support for
tainted variables in PHP. To get more feedback from developers with
Windows systems, I have built Win32 binaries. These are available
in ZIP and Windows installer format from http://wiki.php.net/rfc/taint/
and are compatible with the binaries from http://www.apache.org/

As a reminder, the goal of this project is to help PHP application
programmers find and eliminate opportunities for HTML code injection
(i.e. XSS), SQL or shell code injection, or PHP control hijacking,
before other people can exploit them. With 1% run-time overhead,
taint support may also be used as a safety net in production.  The
preliminary implementation provides taint support for basic operators,
for a selection of built-functions and extensions (pcre, mysql,
mysqli), and for the Apache server APIs.

For source, binaries and more please see http://wiki.php.net/rfc/taint/

        Wietse

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
Ralph Schindler | 2 Jul 2008 00:55
Favicon

[PHP-DEV] Magic method visibility in PHP 5.3+

Well, I guess I blinked and missed the internal <at>  thread on this topic :)

Seriously though, if there was a thread on this subject, please point me 
in the right direction.

In PHP 5.3 snaps, it appears that magic methods __isset, __unset, __get, 
__set must have a public visibility or the engine will trigger a 
warning.  Why is this?  It works as expected in 5.x branches.

I am not sure why this should be enforced as it should be up to the 
developer as to which methods in the API should be exposed for direct 
invocation.

If a developer never intends on a user calling $obj->__set(...), then it 
should be allowed that the public call to that method be disallowed, but 
still allow the magic functionality (b/c of the presence of that magic 
function.)

Without getting too long winded, ill just put code and warnings below.

Cheers,
Ralph Schindler

script.php

<?php

class SomeMagic
{
(Continue reading)

Permalink | Reply | 4 comments |
headers
Stanislav Malyshev | 2 Jul 2008 01:18
Favicon

Re: [PHP-DEV] Magic method visibility in PHP 5.3+

Hi!

> In PHP 5.3 snaps, it appears that magic methods __isset, __unset, __get, 
> __set must have a public visibility or the engine will trigger a 
> warning.  Why is this?  It works as expected in 5.x branches.

I think it doesn't actually work as expected - because as far as I can 
see, visibility is ignored on these methods. Consider this code:

class Foo {
         private function __get($name) {
                 return 42;
         }
}

$z = new Foo();
echo $z->bar;

On 5.2, it happily prints 42, even though you should not have access to 
__get from outside the class, if it were true "private". Having 
"private" there actually is somewhat misleading - while it looks like 
internal API and thus can be changed by the class developer at will or 
dropped altogether, it is actually a public API which is exposed to the 
client.

> I am not sure why this should be enforced as it should be up to the 
> developer as to which methods in the API should be exposed for direct 
> invocation.

I don't think magic methods are meant to be directly invoked. That's why
(Continue reading)

Permalink | Reply | 1 comment |
headers
Scott MacVicar | 2 Jul 2008 02:12
Gravatar

[PHP-DEV] SQLite3

Hi All,

I've been working on sqlite3[1] as a replacement for the ageing sqlite  
extension, I've had a few people interested in getting this into 5.3  
and I think its definitely a possibility as the API is more or less  
finalised at this moment in time.

The reason that the current sqlite extension can't be modified is due  
to the libsqlite API changes, they just aren't compatible in any shape  
or form, they also use a different database format which would  
probably add to the confusion since this format isn't backwards  
compatible.

At the moment the only things left on my todo would be documentation  
and buffered queries.

I'd appreciate any feedback or comments about adding this.

Scott

[1] http://pecl.php.net/sqlite3

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
Alexey Zakhlestin | 2 Jul 2008 08:19
Picon
Gravatar

Re: [PHP-DEV] mac os x, test failure

some more details.
the return-chain in this case is following:

virtual_file_ex(..., path, ...) -> returns 1, because path_length >= MAXPATHLEN
expand_filepath(filepath, ...) -> returns null
_php_stream_fopen(filename, ...) -> returns null
php_plain_files_stream_opener(..., path, ...) -> returns null
_php_stream_open_wrapper_ex(path, ...) calls php_stream_display_wrapper_errors()
php_stream_display_wrapper_errors() checks errno-value

I don't see how any function here might set errno to any value. How
does this work on other operating-systems?

On Mon, Jun 30, 2008 at 12:29 PM, Alexey Zakhlestin <indeyets <at> gmail.com> wrote:
> On Mon, Jun 30, 2008 at 12:27 PM, Antony Dovgal <tony <at> daylessday.org> wrote:
>> On 30.06.2008 12:24, Alexey Zakhlestin wrote:
>>>>
>>>> It might also mean that the error message is different on Mac OS or the
>>>> error code is different.
>>>> I've seen that many times on different platforms.
>>>
>>> that's what I thought at first, but testing showed, that it is not that
>>> simple.
>>>
>>> plain fopen() in C on large file-name results in "File name too long"
>>> error.
>>> php never reaches open() call and error "Inappropriate ioctl for
>>> divice" is already set at the very first line of php_execute_script
>>> (probably even earlier)
>>> looks like there's some uncaught error during initialization of php
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexey Zakhlestin | 2 Jul 2008 08:52
Picon
Gravatar

Re: [PHP-DEV] mac os x, test failure

On Wed, Jul 2, 2008 at 10:19 AM, Alexey Zakhlestin <indeyets <at> gmail.com> wrote:
> some more details.
> the return-chain in this case is following:
>
> virtual_file_ex(..., path, ...) -> returns 1, because path_length >= MAXPATHLEN
> expand_filepath(filepath, ...) -> returns null
> _php_stream_fopen(filename, ...) -> returns null
> php_plain_files_stream_opener(..., path, ...) -> returns null
> _php_stream_open_wrapper_ex(path, ...) calls php_stream_display_wrapper_errors()
> php_stream_display_wrapper_errors() checks errno-value
>
> I don't see how any function here might set errno to any value. How
> does this work on other operating-systems?

Anyway, I am leading to this: it is wrong, to check errno-value
anywhere, except right after the call, which sets errno
The proper solution would be, to have a pointer to some structure
passed to the callchain above, and explicitly store error-code/string
in virtual_file_ex()

-- 
Alexey Zakhlestin
http://blog.milkfarmsoft.com/

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
Lokrain | 2 Jul 2008 09:21
Picon

Re: [PHP-DEV] Magic method visibility in PHP 5.3+

Hello there,

I don't have enough time to write more detailed example, but I still want to
write my opinion.

I totally agree with Stanislav, because for me magic functions should be
used in last leaf of some class extend tree. They are some kind of feature
when you are producing the non-framework, specific project coding stuff.
Which mean they should be not encapsulated and invisible.

If a developer never intends on a user calling $obj->__set(...), then it
> should be allowed that the public call to that method be disallowed, but
> still allow the magic functionality (b/c of the presence of that magic
> function.)
>

Giving the "user" ability to call $obj->__set() is just some kind of speed
optimization, you just miss the magic thing. Another point of view is that
this __set() is still a function why you want to disable the function calls
and enable the functionality? B/c of the presence of that magic function?
What a drama! This is not fairy world where magic should be wonderful thing
which just happens. Think of us (developers) as wizards, who know how/why
this magic works!

Nothing personal just some thoughts.

Regards, Dimitar Isusov
Permalink | Reply | 0 comments |
headers
Christian Seiler | 2 Jul 2008 13:41
Picon

[PHP-DEV] [RFC] Closures: updated proposal and patch

Hi,

After some discussion with Dmitry, he and I have continued to improve
the current closure patch. You can find the current proposal with
patches for 5_3 and HEAD here:

http://wiki.php.net/rfc/closures

(Please read it again, I've changed quite a lot.)

Basically, it's the syntax with use ($lexical) in the function
declaration, optional references, optional static keyword for functions
that don't need $this and support for __invoke. I know that there was
some disagreement on the syntax (including by me) but I think this is
the best compromise we can achieve while still staying consistent with
PHPs current semantics and not breaking BC at all.

I've spoken to Dmitry and he said the patch will be committed to HEAD
soon. Since both Dmitry and I still want to have it in 5_3 too, we'd
want to ask for opinions on this again - especially since after quite a
lot of thorough review and discussion on this list basically all the
side-effects have been addressed and there are now quite a few tests
that ensure the correct behaviour of closures. Also, the patch is now
built in a way that the main functionality remains inside
zend_closures.c, so any possible not yet encountered bug can be fixed
without breaking binary compability.

Regards,
Christian
(Continue reading)

Permalink | Reply | 24 comments |

Gmane