Re: [PHP-DEV] Notes from the PDM in Chicago

[Keisial]

Elizabeth M Smith wrote:
> yes Hannes - interfaces for userland implemented streams would help
> people trying to figure out if they have all the methods they need for a
> particular stream type (SeekableStream et al) - this would be backward
> compat (you wouldn't HAVE to implement the interfaces IIRC, at least not
> right away) but would help things along - Sara had the general ideas for
> how this would be done.
>
> rough draft sounds good - code?
>
> Thanks
> Elizabeth Smith
>   
While dealing with the streams interfaces, what about making the api
saner, too?
All those bucket and brigade functions make streams unnecessarily complex
to deal with.
http://www.php.net/manual/en/ref.stream.php


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

Re: [PHP-DEV] set_magic_quotes_runtime is still E_DEPRECATED

[Keisial]

Pierre Joye wrote:
> On Tue, Jun 16, 2009 at 12:33 PM, Hannes
> Magnusson wrote:
>   
>>> Because in PHP 6 (or next) the function "set_magic_quotes_runtime()" will be
>>> removed, so calling it without checking ini_get() will trigger a fatal
>>> error, no ?
>>>   
>> And there is the problem.
>> The recommended way is:
>> if(get_magic_quotes_runtime()) {
>>set_magic_quotes_runtime(false);
>> }
>>
>> So, if MQ runtime is enabled - even "Doing The Right Thing" (turning
>> it off) will throw deprecated warnings.
>> 
>
> And as get_magic_quotes_runtime() always returns FALSE,
> set_magic_quotes_runtime(false) will never be called.
>
> Cheers,
>   
Hannes refers to 5.3. It will work on PHP 6, but on 5.3 it will throw a
the warning despite you doing
the right thing.
I propose the following behavior: "Throw a deprecated warning unless
magic quotes are currently enabled and the
parameter is to disable them".


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

Re: [PHP-DEV] seems 5.3RC3 is too unstable

[Keisial]

I tried compiling 5.3RC3 on SunOS (i386 32bit) and it seem to compile
fine but
_something_ is segfaulting.

$ rm -rf php-5.3.0RC3 && tar xf php-5.3.0RC3.tar && cd php-5.3.0RC3 &&
./configure --with-libxml-dir=/opt/csw/ && make; ls -l core

A core file is generated.

However, it isn't when doing a make clean
$ rm core && make clean && make && ls -l core


On both cases the phar.phar process produce the same output.
Generating phar.php
Generating phar.phar
sh: pear: not found
Pear package PHP_Archive or Archive.php class file not found.
directorytreeiterator.inc
directorygraphiterator.inc
...

The core claims to have been produced by expr !?:

Core was generated by `expr
XABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDA'.
Program terminated with signal 11, Segmentation fault.
#0  0xfef17f41 in _rt_boot () from /usr/lib/ld.so.1


$ uname -srvmpi
SunOS 5.10 Generic_118855-14 i86pc i386 i86pc


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

Re: [PHP-DEV] PHP 5.3.0RC4

[Keisial]

Lester Caine wrote:
> Lukas Kahwe Smith wrote:
>> Some additional links to get started:
>> http://cvs.php.net/viewvc.cgi/php-src/NEWS?view=markup&pathrev=PHP_5_3
>> http://cvs.php.net/viewvc.cgi/php-src/UPGRADING?revision=PHP_5_3
>
> While I know that ...
> - All ereg functions are deprecated and emit E_DEPRECATED errors.
>   Use PCRE (preg_*()) instead.
>
> ... is accurate, I think a little more detail would help here, since
> many of us probably did not know that 'split' was an ereg function -
> for instance?
>
> I THINK that split() maps to explode() without needing any mapping of
> the parameters?

split() splits a string using a regular expression. explode() splits
using a fixed string.
While it's likely many people is using split() for cases where explode()
should be used*, usages really using regex can't be replaced by
explode()  (preg_split()
 is the equivalent
function... with the other regexes)

*Including one in the split manual page.





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

Re: [PHP-DEV] shebang skipping in 5.3.0

[Keisial]

Andi Gutmans wrote:
> Shebang is for command line scripts (php-cli). It does not make sense to
> support it for Web server scripts. It just adds unnecessary
> code/complexity to that code base. Removing the support from php-cgi was
> really a remnant of the old days when cli and cgi were the same SAPI.
> I think we are better off this way.
>
> Andi
>   
Why doesn't is make sense? It is a legitimate usage, and if novody used
it, it wouldn't have noticed.

>
> Case 4: PHP parser outside of web tree
>
> A very secure option is to put the PHP parser binary somewhere outside
> of the web tree of files. In /usr/local/bin, for example. The only
> real downside to this option is that you will now have to put a line
> similar to:
>
> #!/usr/local/bin/php
>   
>
> as the first line of any file containing PHP tags. You will also need
> to make the file executable. That is, treat it exactly as you would
> treat any other CGI script written in Perl or sh or any other common
> scripting language which uses the /#!/ shell-escape mechanism for
> launching itself.
>

http://php.net/manual/en/security.cgi-bin.shell.php


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

Re: [PHP-DEV] shebang skipping in 5.3.0

[Keisial]

Andi Gutmans wrote:
> If this is indeed a use-case for CGI then I think it's a valid argument
> and we are probably better off supporting it. I did not remember shebang
> works for real CGI.
> There are still plenty of use-cases for running CGI (as opposed to
> FastCGI) in the industry.
> Question now is whether this should be done in the scanner or in the
> SAPI.  I'll check with Dmitry who made this change.
>
> Andi
>   
Probably in sapi, so it only affects cgi and cli, and doesn't
reintroduce bug 46844.
OTOH, skipping shebang on included files could be a feature, if someone
uses cgi and uses
files both as entrypoint and included scripts.
A compromise might be skipping shebang line only when it's followed by
http://www.php.net/unsub.php

Re: [PHP-DEV] Detecting share violations over cifs with PHP? Feature request

[Keisial]

Ian Tighe wrote:
> Hi. I hope this has been sent to the right place.
> I am using files that are mount.cif share files. My client is a samba linux 
> box but acting as a client over cifs to an XP box (several in fact). 
> I am descending the share recursively with opendir and readdir detecting 
> files ( and of course directories ) before doing my processing.
> I note from a wireshark trace I am getting errors - sharing violations 
> reported by XP. I would very much like to detect these events to take action 
> - ignore the file for instance - but right now I have a true or false return 
> from readdir, is_dir, is_file or is_link which is not very helpful during a 
> fault condition such as a sharing violation. In other words a sharing 
> violation looks like a readdir saying no more files!
>
> It seems that once the error condition comes about all my reads of a 
> directory and tests of file types fail until I reach the end of that 
> directory and all of its parent directories. This is not so good.
>
> Am I missing a trick here? If not is it possible to bring out more error 
> information so that I can detect these events. An error array as an 
> additional overloaded argument to readdir, opendir (indeed any I/O) where the 
> first element has the normal true/false perhaps but a second element has a 
> return code for smb/cifs/file_system failure/error/warning condition?
>
> Thanks
>
> Ian
>   
What are you doing that triggers that error? I would expect a sharing
violation to be related to trying to read/write files opened exclusively
by other program, not by traversing a directory tree. Do you know how to
reproduce it?



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

Re: [PHP-DEV] Detecting share violations over cifs with PHP? Feature request

[Keisial]

Ian Tighe `wrote:
> Hi ,
> I am using readdir with a view to selecting files for opening and
> reading or just taking a stat of them. I am doing this recursively. I
> test the output from readdir to see if its a file or dir or link etc
> and this works well. This suddenly changes though and an item is
> returned by readdir (that is a filename) but its type cannot be
> determined - it is not of any type at all! So looking at a wireshark
> trace revealed there had been a sharing violation but I was blissfully
> unaware of this.
>
> I am seeking to have such an error condition made available so that
> ANY i/o op can be tested not just for true or false but to further
> establish the i/o outcome and hence track sharing violations amongst
> other errors. Apart from the type issue above, my substantive point
> about readdir was this: If I get a false reply I am not sure if I had
> a failed i/o operation or I had come to the end of a directory list.
> As far as I can see ( and I may be wrong of course ) there is for PHP
> no difference between the two but the impact is significantly
> different. It was more to demonstrate that error reporting is fairly
> clumsy in these circumstances.
The readdir() system call doesn't have a better error checking. It will
return a null pointer on error, just as on eof. The only way to check if
it had an error is by setting errno to 0 before the call and checking
its status after it. And the reported shouldn't happen anyway, since
they are application errors (passing a bad fd...) not reading problems.

Perhaps the sharing violation should be reported by stat() instead of
readdir()?

> It is certainly true all the files I have seen so far that cause this
> problem related to either iTunes or Microsoft - especially internet
> explorer 8 recovery files. It must be they are exclusively locked and
> any attempt by my software makes to read them brings about a violation
> which cannot be detected, cannot be recovered from and thus not
> handled by me.
>
> I cannot reliably repeat it as I can barely detect it other than my
> software will carry on looking for files and directories and not being
> able to recognise types and actions I wanted are not carried out.  I
> have a wireshark trace of the smb protocol exchanges if that helps but
> it basically says trans2 query path request, trans2 query path
> response , create_andx request (which is probably a stat), which is
> retried several times and finally a create andx response indicating a
> sharing violation. If I could get hold of that in PHP I could
> react.
> Thanks
> Ian



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

Re: [PHP-DEV] Where is the EG macro defined?

[Keisial]

Mark Skilbeck wrote:
> I'd like to check out how the EG macro (I assume it's a macro) works.
> However, I cannot find it :(
>
Zend/zend_globals_macros.h

EG means executor_globals. This macro provides access to the value named
in the parameter.
If running without multi-thread support, it's just a call to the struct,
else it expands for accessing the one
for the current instance (via the hidden __tsrm parameter).


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

Re: [PHP-DEV] PHP 5.3.1 reference parameter regression

[Keisial]

Tim Starling wrote:
> Since 5.3.1 it's impossible to have a reference parameter passed to a
> __call() function. 

> This change causes bugs in MediaWiki, where an attempt by a proxy object
> to pass a call through to a function that accepts reference parameters
> will always fail, due to the exacerbating change made to reference
> argument semantics in PHP 5.3.0.
>
> If we want MediaWiki to support PHP 5.3.1, we'll have to do some major
> changes, like abandoning __call entirely, or rewriting all the relevant
> interfaces to not use reference parameters. I'm not too keen about doing
> this without getting some indication from the PHP dev team as to whether
> this change is permanent or whether it will be fixed in an imminent PHP
> 5.3.2 release. If it's going to be fixed soon, we can just blacklist PHP
> 5.3.1 in our installer.
>
> I've tried emailing stas but I didn't get a reply.
>
> -- Tim Starling
It's also broken in PHP 5.2.11 and 5.2.12 RC4. Works in 5.2.10 and
5.2.11RC1.
Whatever change broke it, was backported and got into 5.2.11RC2.

PS: Did mediawiki opt-out for release candidate announcements? It didn't
receive emails about RCs
for 5.2.12 branch.


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

Re: [PHP-DEV] Implementing fdopen in PHP

[Keisial]

Dennis Hotson wrote:

Hi all,

It's my first post, so go easy on me. :-)

I'm trying to implement PHP support for github's erlang RPC server called
ernie.
So basically I've been porting the following ruby code to PHP:
http://github.com/mojombo/ernie/blob/master/lib/ernie.rb

The problem I'm having is on line 127-128:
   input = IO.new(3)

I believe this is equivalent to fdopen() in C, but there doesn't appear to
be any way to do this in PHP.

So basically, I'm a bit stuck and looking for advice on how to proceed.
Should I implement this in core PHP or as an extension? What's the best way
to get a function like this into PHP?

Regards,
Dennis Hotson
   

You perform a fdopen() in C where you have a low level file descriptor and
make it a stdio on. In php there's only one kind of file descriptor, and 
all file

functions work with them.

Creating a fdopen call is useless, since it needs a previous descriptor to
work from, and all descriptors are equal. Where's that file descriptor 
coming

from?
Since it's an RPC server I suspect you will create it somehow with 
fsockopen.



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

Re: [PHP-DEV] [RFC] Removal of deprecated features

[Keisial]

Kalle Sommer Nielsen wrote:
> enable_dl
>  - Is this really worth keeping, since dl() was disabled on almost all
> SAPIs except for CLI/CGI/Embed?
>   

Although it is not the most widespread use of PHP, people using things like
PHP-GTK probably take advantage of it.


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

Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c

[Keisial]

Pierre Joye wrote:
> On Tue, Jan 25, 2011 at 4:10 PM, Derick Rethans  wrote:
>> On Tue, 25 Jan 2011, Pierre Joye wrote:
>>
>>> Now, as this extension is in the core and had a couple of issues that
>>> need to be fixed and without affecting the behavior, then I will fix
>>> them. Features addition or major changes will obviously need review,
>>> as usual.
>>if (! tzid)
>>
>> is *not* an issue. You made it inconsistent with the rest of the code.
>> Stop changing it.
> Exactly and you made it a super important problem. Where this change
> actually changed nothing in this code from an implementation and
> helped three different analyzer to identify a possible issue. 
This thread went on bikeshedding about if it's legal C or not.
If this change helped three different analyzers, just naming them should
have cleared things.

> But heh, who am I to make changes so the overall code quality can be improved
> in a more easy way. Now stop committing bad things, check return
> values of functions, be sure to use the right type(s), do the casting
> correctly and I may stop to change things, ok? Oh wait...
The change was unrelated to types or castings. Calm down. Paragraphs
like this
are best when not sent.


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