Re: Re: [PHP-DEV] 6.0 And Moving Forward
When Adobe moved from Actionscript 2 to Actionscript 3 they placed all existing functions into a legacy namespace. Similarly, I believe that may be PHP's best shot for smoothing out the API. Basically, the current function library is moved to the legacy namespace. The default setting is import the functions of the legacy namespace into the root namespace for BC. But with that setting turned off all the existing functions go away to be replaced with a designed API, instead of a grown one, correcting the mistakes that have accumulated over the years. On Sat, Jul 14, 2012 at 11:49 PM, Morgan L. Owens pack...@nznet.gen.nz wrote: On 2012-07-14 04:12, jpauli wrote: On Fri, Jul 13, 2012 at 5:33 PM, Anthony Ferrara ircmax...@gmail.com wrote: 4. Rewrite the entire parser completely. I keep hearing about how bad PHP's parser is, and how it's growing out of control. Perhaps this is a good time to rewrite it (perhaps changing semantics slightly) to be better adapted towards future changes... We have an RFC and a patch playing with lemon parser. Actually, just a conversion, reentrant. Refer to Pierrick or Felipe about it :-) Will the conversion include writing a formal definition of the language from the perspective of someone planning to write a PHP parser? Right now the only way to get such a definition is to reverse-engineer the Bison source. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] 6.0 And Moving Forward
I don't understand this 100% but it sounds awesome. +1 On Sun, Jul 15, 2012 at 12:14 PM, Michael Morris dmgx.mich...@gmail.comwrote: When Adobe moved from Actionscript 2 to Actionscript 3 they placed all existing functions into a legacy namespace. Similarly, I believe that may be PHP's best shot for smoothing out the API. Basically, the current function library is moved to the legacy namespace. The default setting is import the functions of the legacy namespace into the root namespace for BC. But with that setting turned off all the existing functions go away to be replaced with a designed API, instead of a grown one, correcting the mistakes that have accumulated over the years. On Sat, Jul 14, 2012 at 11:49 PM, Morgan L. Owens pack...@nznet.gen.nz wrote: On 2012-07-14 04:12, jpauli wrote: On Fri, Jul 13, 2012 at 5:33 PM, Anthony Ferrara ircmax...@gmail.com wrote: 4. Rewrite the entire parser completely. I keep hearing about how bad PHP's parser is, and how it's growing out of control. Perhaps this is a good time to rewrite it (perhaps changing semantics slightly) to be better adapted towards future changes... We have an RFC and a patch playing with lemon parser. Actually, just a conversion, reentrant. Refer to Pierrick or Felipe about it :-) Will the conversion include writing a formal definition of the language from the perspective of someone planning to write a PHP parser? Right now the only way to get such a definition is to reverse-engineer the Bison source. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- *Brandon Wamboldt* Programmer / Web Developer StackOverflow Careers Profilehttp://careers.stackoverflow.com/brandonwamboldt- GitHub Profile https://github.com/brandonwamboldt - LinkedInhttps://github.com/brandonwamboldt - My Blog http://brandonwamboldt.ca/
[PHP-DEV] RFC Proposal - Attributes read/write visibility
Hi,
Here is an RFC proposal about a syntax extension for PHP. The purpose is to
manage precisely the visbiliy of attributes, by separating reading and
writing access.
First of all, I know there is already an RFC about attributes (Property
get/set syntax [1]). Its goal is mainly different, but I'll discuss it
lower.
THE PROBLEM
In my experience, one of the major usage of getters is when you want to
have an attribute, readable (but not writable) from outside the object.
More, the attribute's visibilty is then chosen between private and
protected, depending on your inheritance design.
The result is not really satisfying:
1. You have to write getter's code. Maybe, it's just a simple return, but
every line of code should be useful, not a workaround.
2. You ended with 2 syntaxes; $obj-attr when the attribute is public, but
$obj-getAttr() when you must use a getter. It's a bit schizophrenic.
THE IDEA
I suggest to be able to separate reading visibility and writing visibility,
using a colon to separate them. If only one visibility is given, it will be
used for both reading and writing access.
For example:
class A {
public $a; // public reading, public writing
public:public $b;// the same
public:protected $c; // public reading, protected writing
public:private $d; // public reading, private writing
public:const $e; // public reading, no writing allowed
protected $f; // protected reading, protected writing
protected:protected $g; // the same
protected:private $h; // protected reading, private writing
protected:const $i; // protected reading, no writing allowed
private $j; // private reading, private writing
private:private $k; // the same
private:const $l; // private reading, no writing allowed
}
As you can see, I think that writing access should be more restrictive than
reading access (or equivalent to it). A private:public visibility would
make no sense.
SOURCE CODE
I did a patch. It kinda works, but I'm still working on it (because I'm
still learning Zend Engine's internals).
The code on GitHub: https://github.com/Amaury/php-src
All advises are welcome.
PRIOR WORK
As I said before, the Property get/set syntax RFC is in discussion. My
proposal doesn't focus on the same goals, but they could be fully
compatible.
Thus, we would be able to write this kind of code:
class A {
// $str has public reading and private writing,
// and manage french quotes
public:private $str {
get { return « . $this-str . »; }
set { $this-str = trim($value, «»); }
}
}
Maybe you saw that the Property get/set syntax RFC has an intended syntax
for read-only and write-only attributes. From my point of view, there is a
deep and clean separation between a getter/setter syntax and an extended
visibility syntax. It shouldn't be in the same RFC.
More, the proposed read-only and write-only keywords are less precise
and powerful than what I'm suggesting.
I would be happy to discuss all that with you guys.
Best regards,
Amaury Bouchard
[1] : https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
[PHP-DEV] Whats the status of the RFC for Scalar Type Casting Magic Methods
https://wiki.php.net/rfc/object_cast_to_types What's the status of this RFC? I see it has a patch associated with it, and was wondering if it would be something we'd see in 5.5 or 5.6. Does it need to go through any sort of voting process? I'm sorry if this is the wrong question for this mailing list, I'm new to it
Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility
This seems pretty useful, but could technically be accomplished using the
get/set syntax already proposed. Obviously this is a cleaner implementation
however.
On Sun, Jul 15, 2012 at 12:46 PM, Amaury Bouchard ama...@amaury.net wrote:
Hi,
Here is an RFC proposal about a syntax extension for PHP. The purpose is to
manage precisely the visbiliy of attributes, by separating reading and
writing access.
First of all, I know there is already an RFC about attributes (Property
get/set syntax [1]). Its goal is mainly different, but I'll discuss it
lower.
THE PROBLEM
In my experience, one of the major usage of getters is when you want to
have an attribute, readable (but not writable) from outside the object.
More, the attribute's visibilty is then chosen between private and
protected, depending on your inheritance design.
The result is not really satisfying:
1. You have to write getter's code. Maybe, it's just a simple return, but
every line of code should be useful, not a workaround.
2. You ended with 2 syntaxes; $obj-attr when the attribute is public, but
$obj-getAttr() when you must use a getter. It's a bit schizophrenic.
THE IDEA
I suggest to be able to separate reading visibility and writing visibility,
using a colon to separate them. If only one visibility is given, it will be
used for both reading and writing access.
For example:
class A {
public $a; // public reading, public writing
public:public $b;// the same
public:protected $c; // public reading, protected writing
public:private $d; // public reading, private writing
public:const $e; // public reading, no writing allowed
protected $f; // protected reading, protected writing
protected:protected $g; // the same
protected:private $h; // protected reading, private writing
protected:const $i; // protected reading, no writing allowed
private $j; // private reading, private writing
private:private $k; // the same
private:const $l; // private reading, no writing allowed
}
As you can see, I think that writing access should be more restrictive than
reading access (or equivalent to it). A private:public visibility would
make no sense.
SOURCE CODE
I did a patch. It kinda works, but I'm still working on it (because I'm
still learning Zend Engine's internals).
The code on GitHub: https://github.com/Amaury/php-src
All advises are welcome.
PRIOR WORK
As I said before, the Property get/set syntax RFC is in discussion. My
proposal doesn't focus on the same goals, but they could be fully
compatible.
Thus, we would be able to write this kind of code:
class A {
// $str has public reading and private writing,
// and manage french quotes
public:private $str {
get { return « . $this-str . »; }
set { $this-str = trim($value, «»); }
}
}
Maybe you saw that the Property get/set syntax RFC has an intended syntax
for read-only and write-only attributes. From my point of view, there is a
deep and clean separation between a getter/setter syntax and an extended
visibility syntax. It shouldn't be in the same RFC.
More, the proposed read-only and write-only keywords are less precise
and powerful than what I'm suggesting.
I would be happy to discuss all that with you guys.
Best regards,
Amaury Bouchard
[1] : https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
--
*Brandon Wamboldt*
Programmer / Web Developer
StackOverflow Careers
Profilehttp://careers.stackoverflow.com/brandonwamboldt- GitHub
Profile https://github.com/brandonwamboldt -
LinkedInhttps://github.com/brandonwamboldt -
My Blog http://brandonwamboldt.ca/
[PHP-DEV] 回复： [PHP-DEV] installing from source on mac osx 10.7.3
Hi, I guess /usr/local/bin is writable. then: which version of php and autoconf? it may set the EXEEXT=.dSYM if so /usr/local/bin/php may becomes /usr/local/bin/php.dSYM will you take a look at the generated Makefile is there any value of this variable EXEEXT = ? -- reeze | reeze.cn 在 2012年7月15日星期日，上午11:45，Yader Hernandez 写道： I can't seem to get a vanilla php binary from a simple $ ./configure make make install The last few lines indicate that everything went well: Installing PHP SAPI module: cgi Installing PHP CGI binary: /usr/local/bin/ *Installing PHP CLI binary: /usr/local/bin/* Installing PHP CLI man page: /usr/local/man/man1/ Installing build environment: /usr/local/lib/php/build/ Installing header files: /usr/local/include/php/ Installing helper programs: /usr/local/bin/ program: phpize program: php-config Installing man pages: /usr/local/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/local/lib/php/ [PEAR] Archive_Tar - installed: 1.3.7 [PEAR] Console_Getopt - installed: 1.3.0 [PEAR] Structures_Graph- installed: 1.0.4 [PEAR] XML_Util - installed: 1.2.1 [PEAR] PEAR - installed: 1.9.4 Wrote PEAR system config file at: /usr/local/etc/pear.conf You may want to add: /usr/local/lib/php to your php.ini include_path when I look into /usr/local/bin the php cli binary is not there. Doing a locate does not find any php binary (even after an updatedb). There is one output that can be interpreted as an error but I don't think it has anything to do with not compiling php: Generating phar.php Generating phar.phar PEAR package PHP_Archive not installed: generated phar will require PHP's phar extension be enabled. I'm running on mac osx 10.7.3. I have no problems on Ubuntu 11.04. Has anyone ran into this issue? Is there some output I should be paying attention to?
Re: [PHP-DEV] bug #49510
On Jul 14, 2012, at 22:58, Stas Malyshev smalys...@sugarcrm.com wrote: The question is - should we apply it to 5.3/5.4? It is a behavior change, even though current code behavior does not match documented behavior. I understand the concerns of BC, but I don't understand our general reluctance to break BC to fix a bug. What bug fix is *not* going to also be a behavior change? So long as everything is well-documented, I think most bug fixes should go through right away. And in cases like this, where there is a clear deviation from the documentation, it's all the more important to fix it, IMHO, because a lot of folks have probably written code that relies on the documented behavior such that their code is now broken and they don't even realize it. Those who identified the deviation in testing and incorporated a workaround probably also notated their code as such so that it's an easy fix later when the bug is fixed - which takes us back to simply documenting fixes very well. The only time I think holding a bug fix should be a consideration is when the docs aren't clear on the correct behavior, and the behavior is extensively relied upon. By itself, extensive use is not an excuse, IMHO. Other than in the embedded world, code should never be a write-it-and-forget-it-affair... things change in the language, things change in the OS, features are added that are useful, under-used features are removed, security issues are fixed, requirements change, etc., etc. This industry is all about change, and I think most reasonable people are okay with bug fixes that affect BC so long as they're well-documented; they may grumble a bit, but they properly recognize it as a necessary evil. Plus, that's why automated testing is pushed so hard :-). Those programmers who have code where bug fixes will extensively break things without their knowing it have code that's already a maintenance nightmare, and they probably aren't doing regular PHP upgrades until such time as they get their code under control. Similarly, those who have code that may be fairly lean but is not well-maintained also probably aren't doing regular PHP upgrades. So who, exactly, are we servicing by withholding bug fixes? All we're really doing is making it that much harder to upgrade to future major versions by turning them as much into giant collections of accumulated, BC-breaking bug fixes as they are collections of cool new features. -- Bob Williams Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility
2012/7/15 Brandon Wamboldt brandon.wambo...@gmail.com
This seems pretty useful, but could technically be accomplished using the
get/set syntax already proposed. Obviously this is a cleaner implementation
however.
As I said, the get/set syntax RFC propose a read-only and a write-only
keywords.
For example, it will not allow you to have an attribute readable only by
descendant classes (and by the current class, of course), and at the same
time only writable by the current class.
PHP is an object-oriented language with public/protected private
visibility. Visibility conveys meanings, and we shouldn't loose these
meanings when we add new functionalities.
Once again, the purpose of the get/set syntax RFC is to define getters and
setters directly where attributes are defined. Attributes' visibility is a
distinct question, which deserve a distinct answer (even if there is some
obvious connections).
On Sun, Jul 15, 2012 at 12:46 PM, Amaury Bouchard ama...@amaury.net wrote:
Hi,
Here is an RFC proposal about a syntax extension for PHP. The purpose is
to
manage precisely the visbiliy of attributes, by separating reading and
writing access.
First of all, I know there is already an RFC about attributes (Property
get/set syntax [1]). Its goal is mainly different, but I'll discuss it
lower.
THE PROBLEM
In my experience, one of the major usage of getters is when you want to
have an attribute, readable (but not writable) from outside the object.
More, the attribute's visibilty is then chosen between private and
protected, depending on your inheritance design.
The result is not really satisfying:
1. You have to write getter's code. Maybe, it's just a simple return, but
every line of code should be useful, not a workaround.
2. You ended with 2 syntaxes; $obj-attr when the attribute is public, but
$obj-getAttr() when you must use a getter. It's a bit schizophrenic.
THE IDEA
I suggest to be able to separate reading visibility and writing
visibility,
using a colon to separate them. If only one visibility is given, it will
be
used for both reading and writing access.
For example:
class A {
public $a; // public reading, public writing
public:public $b;// the same
public:protected $c; // public reading, protected writing
public:private $d; // public reading, private writing
public:const $e; // public reading, no writing allowed
protected $f; // protected reading, protected writing
protected:protected $g; // the same
protected:private $h; // protected reading, private writing
protected:const $i; // protected reading, no writing allowed
private $j; // private reading, private writing
private:private $k; // the same
private:const $l; // private reading, no writing allowed
}
As you can see, I think that writing access should be more restrictive
than
reading access (or equivalent to it). A private:public visibility would
make no sense.
SOURCE CODE
I did a patch. It kinda works, but I'm still working on it (because I'm
still learning Zend Engine's internals).
The code on GitHub: https://github.com/Amaury/php-src
All advises are welcome.
PRIOR WORK
As I said before, the Property get/set syntax RFC is in discussion. My
proposal doesn't focus on the same goals, but they could be fully
compatible.
Thus, we would be able to write this kind of code:
class A {
// $str has public reading and private writing,
// and manage french quotes
public:private $str {
get { return « . $this-str . »; }
set { $this-str = trim($value, «»); }
}
}
Maybe you saw that the Property get/set syntax RFC has an intended
syntax
for read-only and write-only attributes. From my point of view, there is a
deep and clean separation between a getter/setter syntax and an extended
visibility syntax. It shouldn't be in the same RFC.
More, the proposed read-only and write-only keywords are less precise
and powerful than what I'm suggesting.
I would be happy to discuss all that with you guys.
Best regards,
Amaury Bouchard
[1] : https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
--
*Brandon Wamboldt*
Programmer / Web Developer
StackOverflow Careers
Profilehttp://careers.stackoverflow.com/brandonwamboldt- GitHub
Profile https://github.com/brandonwamboldt -
LinkedInhttps://github.com/brandonwamboldt -
My Blog http://brandonwamboldt.ca/
Re: [PHP-DEV] bug #49510
hi!
On Sun, Jul 15, 2012 at 7:57 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
We've got a bit of a discussion on bug #49510 in the comments. The
problem is this: filter_var('', FILTER_VALIDATE_BOOLEAN, array(flags
= FILTER_NULL_ON_FAILURE)) returns null (i.e. failure) while docs say
boolean filter will return false on ''. I think we need to sync with the
docs.
The question is - should we apply it to 5.3/5.4? It is a behavior
change, even though current code behavior does not match documented
behavior.
The question is more about the correctness of the doc, and to what I
remember (I implemented that NULL on failure thing), the doc is wrong.
And the null on failure was mainly implemented for this exact case
(boolean validation).
Cheers,
--
Pierre
@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
[PHP-DEV] New String Function: str_replace_limit
Hey, I'm proposing to add a new function str_replace_limit, this will be identical to str_replace() with one key difference, you can specify how many times you want the replace to occur. Currently this isn't possible with any functions in the /ext/standard/string.c stack, the only easy workaround is using preg_replace() which requires of course the pcre library and regex patterns. I would have added this as a 4th param to str_replace(), but it already has a 4th by-ref param to tell you how many times it done the replacement. mixed str_replace_limit ( mixed $search , mixed $replace , mixed $subject [, int $limit ] ) Thoughts? Paul Dragoonis. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New String Function: str_replace_limit
Hi, 2012/7/15 Paul Dragoonis dragoo...@gmail.com: Hey, I'm proposing to add a new function str_replace_limit, this will be identical to str_replace() with one key difference, you can specify how many times you want the replace to occur. Currently this isn't possible with any functions in the /ext/standard/string.c stack, the only easy workaround is using preg_replace() which requires of course the pcre library and regex patterns. I would have added this as a 4th param to str_replace(), but it already has a 4th by-ref param to tell you how many times it done the replacement. mixed str_replace_limit ( mixed $search , mixed $replace , mixed $subject [, int $limit ] ) Thoughts? Surely a 5th param is preferred. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New String Function: str_replace_limit
The 4th param to str_replace is a by-ref param, so you can't just skip over it, can you ? On Sun, Jul 15, 2012 at 8:54 PM, Felipe Pena felipe...@gmail.com wrote: Hi, 2012/7/15 Paul Dragoonis dragoo...@gmail.com: Hey, I'm proposing to add a new function str_replace_limit, this will be identical to str_replace() with one key difference, you can specify how many times you want the replace to occur. Currently this isn't possible with any functions in the /ext/standard/string.c stack, the only easy workaround is using preg_replace() which requires of course the pcre library and regex patterns. I would have added this as a 4th param to str_replace(), but it already has a 4th by-ref param to tell you how many times it done the replacement. mixed str_replace_limit ( mixed $search , mixed $replace , mixed $subject [, int $limit ] ) Thoughts? Surely a 5th param is preferred. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions
2012/7/14 Andrew Faulds ajf...@googlemail.com: Well... if people have poorly configured servers spitting out debug info in production mode, I don't think it is our problem. It is theirs. Do you want to make it secure or do you want to discuss? -- Greetings Alex Aulbach -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions
Hi Anthony: I want exceptions here too. But PHP doesn't use exceptions in its standard library (aside from SPL) DateTime uses exceptions. --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions
On 15/07/12 22:07, Alex Aulbach wrote: 2012/7/14 Andrew Faulds ajf...@googlemail.com: Well... if people have poorly configured servers spitting out debug info in production mode, I don't think it is our problem. It is theirs. Do you want to make it secure or do you want to discuss? Seems Andrew mail didn't get to the list. Yes, production servers shouldn't be showing debug info. But we know that a large fraction of them do. As coder of a php application, I often can't set the configuration of the system where it will be installed. Sometimes not even the person installing it can set it correctly (eg. shared hostings), it can be changed under your foot (eg. an update, someone did so to debug a different application...) or even be set explicitely (I want my users to warn me when they see errors !). If spitting out errors prevented XHTML validation, I wouldn't care that much (obviously, the code shouldn't generate the warning to begin with, but it's not a big deal if users were briefly shown it). But we are talking about passwords and password hashes. Not something you want to risk exposing. Specially when we are trying to make a good interface to encourage secure handling of passwords. PS: Alex, your non-displayable exception would indeed work (although I would make it a class property). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug #49510
Hi! The question is more about the correctness of the doc, and to what I remember (I implemented that NULL on failure thing), the doc is wrong. Well, the question is if '' is an acceptable boolean expressing false or an error. I could see an argument for either, e.g. if you're having a config file you could say for boolean config var 'foo_bar=0' and 'foo_bar=' means the same thing, or you could choose the second to be invalid. It is a bit complicated by the fact that people are somewhat confused about the idea that filter_var works on strings, so they think boolean 'false' should be OK with it. Again, if we say foo_bar= is OK, then false will be OK too, though not because of the reasons some people think of. And the null on failure was mainly implemented for this exact case (boolean validation). Yeah I understand that, the question is then if '' can be sought as a valid boolean string meaning false, or as an error. I lean slightly to the side of '' being accepted, but if somebody has any argument against it, please let it be heard. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions
Ok. I think, I go too much off topic. Sorry. But I want to repeat - we never know in which context the program will run. And good security means, thait it shouldn't care, in which context it runs. - everything, which can go wrong will go wrong (Murphy); if there is any chance to make it wrong, there will be someone, which make it wrong. (and in this case they will point to PHP: see, I have said it is unsecure... :) ). - in security context this means: The hashes will be stolen/we can login without password etc. - No documentation or any other thing can prevent that - So we need to do everything, which is possible to avoid it. The best thing would be, that we can guarantee, that it is not possible. - As positive side-effect we can have more possibilities in PHP :) More off topic: Let me explain that last sentence: I dont know exactly how this can be implemented, but I think every warning, error and so on could be an exception instead. Just an idea, but I think this can remove complexity, because - even if I think the current error-handling is quite well designed - it is a source of sercurity-problems (and some other more or less ugly things). I think about a default exception-handling which can be overridden (like the error-handlers). Could be an interesting concept. :) And of course its something which needs time. -- Sevus Alex Aulbach -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 回复： [PHP-DEV] installing from source on mac osx 10.7.3
On Sun, Jul 15, 2012 at 9:50 AM, Reeze reeze@gmail.com wrote: Hi, I guess /usr/local/bin is writable. then: which version of php and autoconf? it may set the EXEEXT=.dSYM if so /usr/local/bin/php may becomes /usr/local/bin/php.dSYM will you take a look at the generated Makefile is there any value of this variable EXEEXT = ? Yes you are right, it seems that a php.dSYM was created instead. I renamed it to php and it works as expected. thank you -- reeze | reeze.cn 在 2012年7月15日星期日，上午11:45，Yader Hernandez 写道： I can't seem to get a vanilla php binary from a simple $ ./configure make make install The last few lines indicate that everything went well: Installing PHP SAPI module: cgi Installing PHP CGI binary: /usr/local/bin/ *Installing PHP CLI binary: /usr/local/bin/* Installing PHP CLI man page: /usr/local/man/man1/ Installing build environment: /usr/local/lib/php/build/ Installing header files: /usr/local/include/php/ Installing helper programs: /usr/local/bin/ program: phpize program: php-config Installing man pages: /usr/local/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/local/lib/php/ [PEAR] Archive_Tar - installed: 1.3.7 [PEAR] Console_Getopt - installed: 1.3.0 [PEAR] Structures_Graph- installed: 1.0.4 [PEAR] XML_Util - installed: 1.2.1 [PEAR] PEAR - installed: 1.9.4 Wrote PEAR system config file at: /usr/local/etc/pear.conf You may want to add: /usr/local/lib/php to your php.ini include_path when I look into /usr/local/bin the php cli binary is not there. Doing a locate does not find any php binary (even after an updatedb). There is one output that can be interpreted as an error but I don't think it has anything to do with not compiling php: Generating phar.php Generating phar.phar PEAR package PHP_Archive not installed: generated phar will require PHP's phar extension be enabled. I'm running on mac osx 10.7.3. I have no problems on Ubuntu 11.04. Has anyone ran into this issue? Is there some output I should be paying attention to?
Re: [PHP-DEV] Whats the status of the RFC for Scalar Type Casting Magic Methods
Check out the conversation around it. Specifically: http://marc.info/?t=13308247243r=1w=2 But also: http://marc.info/?t=13302683324r=1w=2 So basically it just stopped. But that doesn't mean that it can't be resurrected or continued... Anthony On Sun, Jul 15, 2012 at 11:48 AM, Brandon Wamboldt brandon.wambo...@gmail.com wrote: https://wiki.php.net/rfc/object_cast_to_types What's the status of this RFC? I see it has a patch associated with it, and was wondering if it would be something we'd see in 5.5 or 5.6. Does it need to go through any sort of voting process? I'm sorry if this is the wrong question for this mailing list, I'm new to it
Re: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions
Alex, On Sun, Jul 15, 2012 at 7:19 PM, Alex Aulbach alex.aulb...@gmail.comwrote: Ok. I think, I go too much off topic. Sorry. But I want to repeat - we never know in which context the program will run. And good security means, thait it shouldn't care, in which context it runs. Could you explain what you mean by context here? I'm not following... - everything, which can go wrong will go wrong (Murphy); if there is any chance to make it wrong, there will be someone, which make it wrong. (and in this case they will point to PHP: see, I have said it is unsecure... :) ). - in security context this means: The hashes will be stolen/we can login without password etc. - No documentation or any other thing can prevent that You can not make something idiot proof. If you try, the universe will just invent better idiots. Instead, as long as the function works in a sane manner, and the documentation reflects the edge-cases and concepts, I think it's fine. - So we need to do everything, which is possible to avoid it. The best thing would be, that we can guarantee, that it is not possible. If that was the case, there would be no PHP or any other language for that matter. You can't stop people from being stupid. What you can do however is make the documentation and implementation so bloody easy to use that *I didn't know* becomes the only sane excuse... - As positive side-effect we can have more possibilities in PHP :) More off topic: Let me explain that last sentence: I dont know exactly how this can be implemented, but I think every warning, error and so on could be an exception instead. Just an idea, but I think this can remove complexity, because - even if I think the current error-handling is quite well designed - it is a source of sercurity-problems (and some other more or less ugly things). I think about a default exception-handling which can be overridden (like the error-handlers). Could be an interesting concept. :) And of course its something which needs time. The default exception handling can be overriden today: http://us2.php.net/set_exception_handler But I agree with your larger point. The only problem with it is that it would take an engine wide shift to do. Which I think is out of scope for a point release, and there's no reason (that I can see) to tie this implementation to that shift. Let's implement this with the normal error handling methods, and then handle it uniformly later... Anthony
Re: [PHP-DEV] zend_execute_internal hook missing from PHP 5
Hi! Nowadays (since PHP 5.0) the code was moved from call_user_function_ex to zend_call_function and just looks like this: ((zend_internal_function *) EX(function_state).function)-handler(fci-param_count, *fci-retval_ptr_ptr, fci-retval_ptr_ptr, fci-object_ptr, 1 TSRMLS_CC); While this has no immediate impact for average PHP users, it basically kills the possibility for an extension like Suhosin to catch all function starts. This should also be a problem for your DTRACE support. And IIRC Xdebug was hooking this point (at least in the past), too. My suggestion is to change the code to call the hook again. There's a bit of a problem there. The problem is that execute_internal looks like this: zval **return_value_ptr = (*(temp_variable *)((char *) execute_data_ptr-Ts + execute_data_ptr-opline-result.var)).var.ptr; ((zend_internal_function *) execute_data_ptr-function_state.function)-handler(execute_data_ptr-opline-extended_value, *return_value_ptr, (execute_data_ptr-function_state.function-common.fn_flags ZEND_ACC_RETURN_REFERENCE)?return_value_ptr:NULL, execute_data_ptr-object, return_value_used TSRMLS_CC); You note it takes return values from opline. Which is fine when running PHP code, but when running internal function from internal function, there's no opline. So zend_call_function calls this: ((zend_internal_function *) EX(function_state).function)-handler(fci-param_count, *fci-retval_ptr_ptr, fci-retval_ptr_ptr, fci-object_ptr, 1 TSRMLS_CC); I.e. it uses data from fci. But if we use zend_execute_internal we have only execute_data_ptr to work with, which has wrong return values. So we need to either make fake opline somehow or find a way to pass correct return vars to the handler via execute_internal. I'll see how it can be done but that'd be probably in 5.5 since it may require some engine changes, which is not an option for stable versions. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions
Hi Anthony: But I agree with your larger point. The only problem with it is that it would take an engine wide shift to do. How does using exceptions in this new extension require an engine wide shift? DateTime already uses exceptions, no problem. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions
Daniel, On Sun, Jul 15, 2012 at 8:20 PM, Daniel Convissor dani...@analysisandsolutions.com wrote: Hi Anthony: But I agree with your larger point. The only problem with it is that it would take an engine wide shift to do. How does using exceptions in this new extension require an engine wide shift? DateTime already uses exceptions, no problem. DateTime only uses the generic Exception class. If I was going to support this implementation, it would use typed exceptions so the handling code could have a chance to determine the type of the error... http://lxr.php.net/xref/PHP_TRUNK/ext/date/php_date.c#2448 Not a show stopper, but from my perspective it would be inconsistent and not much better to do that than leave the default error handling in place until we take a larger look at errors vs exceptions for the core as a whole... Additionally, DateTime is a class in core. Do any functions throw exceptions? Anthony
Re: [PHP-DEV] Internal iteration API
On 07/13/2012 07:35 PM, Stas Malyshev wrote: Hi! So, I've not been inside the engine so in practice this may make no sense at all, but what about looking at it the other way around? Vis, instead of making objects more and more like arrays, make arrays an object that happens to implement ArrayAccess, Iterator, and whatever That'd be very nice idea if we were implementing new PHP. I think the fact that arrays are not objects in PHP is a source of many problems. However, right now it probably won't be possible to do it without breaking BC in many places dealing with array copy/assignment/passing semantics. Hm, valid point. Is there no way that we could setup one object to pass the old way? I suppose that would result in just as many special case exceptions... Perhaps that's a change that could be considered for whatever version does get called PHP 6? PHP 5 changed the passing semantics for objects and we survived that, and it was a big boon to the language. Perhaps that could be rolled into bigger changes later? (There's a PHP 6 thread right now I've not looked at yet...) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Internal iteration API
forwarding. On 16 July 2012 02:11, Larry Garfield la...@garfieldtech.com wrote: I think you meant to send that to the list. :-) --Larry Garfield On 07/15/2012 08:07 PM, Andrew Faulds wrote: It would be nice if PHP 6 unified the semantics of string/int/float/bool, arrays, and objects. For those first three you could use immutable objects, and arrays are just objects implementing ArrayAccess etc. On 16 July 2012 02:05, Larry Garfield la...@garfieldtech.com wrote: On 07/13/2012 07:35 PM, Stas Malyshev wrote: Hi! So, I've not been inside the engine so in practice this may make no sense at all, but what about looking at it the other way around? Vis, instead of making objects more and more like arrays, make arrays an object that happens to implement ArrayAccess, Iterator, and whatever That'd be very nice idea if we were implementing new PHP. I think the fact that arrays are not objects in PHP is a source of many problems. However, right now it probably won't be possible to do it without breaking BC in many places dealing with array copy/assignment/passing semantics. Hm, valid point. Is there no way that we could setup one object to pass the old way? I suppose that would result in just as many special case exceptions... Perhaps that's a change that could be considered for whatever version does get called PHP 6? PHP 5 changed the passing semantics for objects and we survived that, and it was a big boon to the language. Perhaps that could be rolled into bigger changes later? (There's a PHP 6 thread right now I've not looked at yet...) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Andrew Faulds (AJF) http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions
On 07/15/2012 06:03 PM, Anthony Ferrara wrote: Additionally, DateTime is a class in core. Do any functions throw exceptions? Nope, and note that if you call those same DateTime functions procedurally they don't use exceptions. So yes, changing PHP to start throwing exceptions from procedurally-called functions would be a major change. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] [proposal + pull request] Replace logo GUIDs with data URIs
On 2012-07-15 09:48, Stas Malyshev wrote:
Hi!
And I actually know of websites using the functions to display the logo..
Is there some way we could provide a BC function for it somehow?
Maybe rather then removing the functions, make then return the data uris?
Having the functions to get the images sounds like a good idea, some
sites may want to use them to display the logos. However, I don't think
we should use the same function, as then deciding what the function
actually does is complicated. I'd rather prefer doing something like:
if(function_exists('php_logo_guid')) {
$url = /index.php?=.php_logo_guid();
} else if(function_exists('php_logo_url')) {
$url = php_logo_url();
}
if(!empty($url))
echo img src=\$url\ alt=\php logo\;
it's clear what each function gives me then.
There are three of these functions: one for the PHP logo, one for the
Zend logo, and one easter egg.
If php_logo_guid()/php_logo_url() could take an argument ('php', 'zend',
'easteregg') all three could be handled by the one function.
By itself this wouldn't change anything because the other functions
would need to stay around for BC - at least for a while. But it opens up
the possibility of extending the mechanism to the authors of third-party
extensions: a ready source of site badges, and a visual identifier on
phpinfo() pages.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] qa.php.net pulls screen does not display all the pulls
Hi: I have made a patch here: https://gist.github.com/3120879 maybe some one can merge it. thanks On Sun, Jul 15, 2012 at 1:46 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! When I go to qa.php.net to see pulls for php-src, I only see pulls down to number 56, but earlier ones are not displayed for some reason. Does anybody know what's wrong with it and could fix it? Thanks, -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
