Re: [PHP-DEV] password_hash() deprecate salt option - thoughts?
No objections here either. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reserve even more type hints RFC
On 30/04/15 00:41, Christoph Becker wrote:
Hi everybody!
I've noticed that the "Reserve Even More Types in PHP 7" RFC[1] has been
moved to "Process and Policy" with the comment "needs no impl".
However, the RFC states:
| This RFC does not fully reserve them as keywords; it only prohibits
| their usage as class, interface and trait names.
In my opinion, this has to be enforced by throwing a fatal error
("Cannot use '*' as class name as it is reserved"), whenever one of the
reserved identifiers (resource, object, mixed, numeric) is used as
class, interface or trait name.
Relying on documentation only seems to be insufficient to me. Consider
a developer not reading the documentation and facing the issue that
his/her code might break with PHP 7.1 (i.e. a minor version).
+1
If not a fatal, it should be at least a warning. Doc-only keyword
reservation
won't be noticed.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Announcing PHP 5.5 security-only
On 22/06/15 23:40, Anatol Belski wrote: Hi, Actually I was relying on that page as well. While it would be great if 5.4 branch were blocked, as we would branch 7.0 ... disregarding were it wrong or not, IMHO 14th September should be the date. Even if the page is wrong, the info is public, people might rely on it. It doesn't enforce 5.4 to release without the reason, but it gives room to announce the EOL properly. Regards Anatol +1 If a page says "Security Support Until 14 Sep 2015", it may receive support for longer, but it's really wrong to short it (at least without exceptional reasons). And, if that's not how it really works, the page wording should be changed ASAP, and before 5.4 EOL (when people will hurry to see next one time frame). @Adam, I was expecting the "gory details" to involve a of PHP commiters with black robes, faces hidden behind their hoods meeting overnight and an absurdly complex algorithm involving lunar cycles. instead you point to a manual override, but no descripcion on how it gets changed. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Failing Tests
On 10/12/11 16:30, Clint M Priest wrote: > I've got 122 tests that are failing on a full run, if I write the failed > tests to a file and re-run just those tests, all of them pass. Any ideas > whats up? A previous test breaking them? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
On 14/12/11 22:53, Will Fitch wrote: > I believe he's referring to sys/time.h, but this introduces portability > issues. If it were just unix, that would be one thing. But maintaining this > and a Windows alternative, and I have no idea what that is, is not worth it > IMO. is present in *nix, Windows, and probably everywhere php runs. As it provides mktime/gmtime/localtime, it should be possible to portably deal with timezones. At least when it's not multithreaded. And if the host doesn't contain timezone data (embedded systems, perhaps), that "System" zone could simply default to UTC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
On 15/12/11 00:10, Oleg Oshmyan wrote:
> PHP internally already has php_localtime_r and php_gmtime_r in
> main/php_reentrancy.h, implemented in main/reentrancy.c, and they are
> already used in various places in the code, including the guessing
> algorithm that is being removed in PHP 5.4. So at the very least
> thread-safety (and in fact portability too) should not become worse than
> it is now.
Oh, nice. I thought thet would be doing its own argument passing, based
on timelib, but turns out they do retrive the value from the system
{local,gm}time, even on those without a _r version.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Constant arrays
On 19/12/11 21:23, Paul Dragoonis wrote:
> Barbu,
>
> This is how constants work in all viable languages such as C/++.
I disagree. In C you can have:
const data foo[] = { { "Data1", 2 }, { "Data2", 78 } };
It's not unusual in php to have a complex structure that won't change
in a variable. It should be an array, but as array is not allowed as
content,
you need to leave it as a static variable that you won't never change.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Your examples only show class methods with visibility qualifyiers, and looking at the changes to zend_language_parser.y it seems as if would only be available for methods. Wouldn't return hints be available for plain functions? In functional programming, it is common to return nullable types: returns an instance of class Foo or null, an array or false, etc. This is supported in normal arguments with the "= null" hint, and I think there should be something equivalent for return types. Does the proposed implementation allow null everywhere? (there's an example of returning null from a return hint of array) That seems wrong to me. Unless there's a way to make it strict (eg. array! for only arrays). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On 23/12/11 00:08, Will Fitch wrote:
> Sent from my iPad
> On Dec 22, 2011, at 5:51 PM, "Ángel González" wrote:
>
>> Your examples only show class methods with visibility qualifyiers, and
>> looking at the changes to zend_language_parser.y
>> it seems as if would only be available for methods. Wouldn't return
>> hints be available for plain functions?
> Right now, it's only available for methods. Personally, I'm not a fan
> of return types for functions. Adding this for functions in its form
> today will also introduce shift/reduce issues.
Yes, it's much easier for the parser for methods with explicit
visibility (note that public is optional).
I'm ok on requiring the public for methods with a return hint, but if
methods can get return hints,
normal functions must, too.
If it's hard with your proposed syntax, it should be discarded and a
better one developed.
Else we would end up with different syntaxes for return hints depending
on the kind of function.
For instance, the return hint could go at the end of the prototype:
function foo (Class1 $a, Class2 $b) => Class3 {
return new Class3($a, $b);
}
(I'm unsure about the T_DOUBLE_ARROW, although for parsing, I feel there
should be some token there
before the class name, though I'm unconvinced on which)
>> In functional programming, it is common to return nullable types:
>> returns an instance of class Foo or null, an array or false, etc.
>>
>> This is supported in normal arguments with the "= null" hint, and I
>> think there should be something equivalent for return types.
>> Does the proposed implementation allow null everywhere? (there's an
>> example of returning null from a return hint of array)
>> That seems wrong to me. Unless there's a way to make it strict (eg.
>> array! for only arrays).
> Most modern languages allow returning null in any case. This is a hail
> Mary in the event something happens, but throwing an exception is
> inappropriate. I see no reason to diverge from that.
I disagree with you, but Stas already provided a compelling case.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On 23/12/11 01:00, Will Fitch wrote: > On Dec 22, 2011, at 6:28 PM, Stas Malyshev wrote: >> In PHP, returning object if everything is OK and false if not is a very >> common pattern. >> Also, you understand that always allowing null means that this construct: >> >> $foo = $this->returnsFoo(); >> $foo->fooMethod(); >> >> is no longer safe as you wanted it to be when you made returnsFoo use strict >> typing? You'd have to check $foo anyway. > Are you suggesting not allowing null to be returned, or provide an > indicator within the syntax that it may return null? It should be possible to allow it. Either with a generic syntax for allowing many types of return types or through a specific one (eg. in C# a ? marks an internal type as nullable: int? ) > PHP would be the > first language I'm aware of that would do so in either case. It already barfs at you if you pass null to a parameter expecting a given class (though you can allow it). > The point isn't to restrict a type hint to always be returned. The > goal is to guarantee that if a value is returned, it will be of type > X. In the event it is inappropriate to return the value back, would > you rather receive null or a bogus class instance, empty array or a > random function name back? Because that's what will happen. It will > become the "workaround" for not being able to return null. As it would support both ways, it's up to the framework to choose if they want to return null or a fake-class interface. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
> (I'm unsure about the T_DOUBLE_ARROW, although for parsing, I feel there
> should be some token there
> before the class name, though I'm unconvinced on which)
What about this?
function foo (Class1 $a, Class2 $b) return Class3 {
/* Do something */
return new Class3($a, $b);
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Proposal] Remove the tail ws in codes
On 24/12/11 15:55, Lester Caine wrote: > I'm with Derek ... having commits that are just WS corrections can be > irritating when tracking changes ... but it would most definitely > better to get them fixed before moving to git which would lump mass > commits like that together in a change set and make rolling back > changes a nightmare. Perform that as the last svn commit? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug 60596 - With Patch
On 24/12/11 18:22, Anthony Ferrara wrote: > It's really simple, and would likely be optimized away by the compiler > anyway, but I figured it was worth cleaning up... Yep, it's straightforward. I'm not sure if it makes a difference or not. IS_DOUBLE is between IS_LONG and IS_BOOL so the compiler could be choosing in the range instead, with the if. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature Request
On 04/01/12 17:18, Keloran wrote:
which can if your doing lots of checking alot of extra code for no reason,
or if you want to use variables, lots of louse variables just for something
that could be pulled from the request
I don't think it would mean 'a lot of code', but if it bothers you in
your app, just create a wrapper:
function keloran_file_exists($filename) {
return file_exists($filename) ? $filename : false;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64bit Windows builds
On 18/01/12 20:35, Pierre Joye wrote: Actually, no. There are any number of free mechanisms to build 64 bit code. None of them are part of what we support tho' (we do not support mingw for example, and won't support it). Actually, why couldn't mingw be supported one day? (supposing someone did the work to change half the PHP_WIN defines to PHP_MSVC) Such binaries wouldn't be compatible with IIS, but mingw seems preferible to the legacy VC6 for use with the oficial Apache binaries. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Shebang parsing
On 26/01/12 00:22, Robert Eisele wrote: My specific problem could be tackled in two ways: - Scan "." every time cli is called for a php.ini file or - Try to make argv interpretation more intelligent and parse/merge shebang parameters. There are |.user.ini files, but only for CGI/FastCGI http://es2.php.net/manual/en/configuration.file.per-user.php | The second solution, would also open the possebility to define constants or make use of all other cli parameters. Well, there's also a quick hack. We could change php_getopt() in order to make this a valid argument: php -c=/var/www/php.ini What's wrong with (currently working) php -c/var/www/php.ini ?
Re: [PHP-DEV] Shebang parsing
On 26/01/12 11:35, Kiall Mac Innes wrote: Surely you can detect which operating system you're running on, and have PHP act accordingly? (Note: on my phone, haven't read the link!) Kiall It's probably not reliable. Note that a simple and completely reliable solution would be instead of having two files (php file + custom php.ini), to use a third one as launcher: #!/bin/sh exec php -dextension=foo.so -c /path/to/myphp.ini /path/to/myfile.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A potential patch for Bug#60668
About Kiyoto's patch:
Some servers would read as new headers if the newlines were just \n or \r
(which would be illegal per HTTP spec). I think the characters to ban
are: \n \r \0
Just replace your call to zend_trim_after_carriage_return with:
+ strtok(new_value, "\r\n"); // Truncate on \n, \r and \0
+ new_value_length = strlen(new_value);
Chris Stockton wrote:
As for the "feature" of \r\n working in user-agent init set, my main
point is that is a BC break, since it is slightly advocated to use it
as a hack in the docs here [1].
Adding a new header by inserting it with user_agent is a really buggy hack.
It should be documented as "in php < 5.4 it used to be possible to add a
new
header modifying the ini user-agent. On newer versions you need to use
stream_context_set_params(, array('header' => $headers) )"
(plus a good example).
The proper stream_context_set_params way has apparently been available at
least since PHP 5.0. It's just hard to find.
At the end of the day passing _any_
user input to literally any php function without sanitization can be
dangerous given the right context.
Sure, but that's no reason to not improve it, specially if you do it on
a major
release (eg. PHP 5.4).
Even though it works, it should be obvious that it isn't expected to be
used that way.
So there should be little problem with it going away,
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Uploading a patch fails...
On 28/01/12 03:05, Rasmus Lerdorf wrote: There is a 100k limit, but the error message you are getting indicates that you aren't actually hitting that limitation. The server config has a 2M limit, so you should be fitting well within that. I'm not sure how your 200k patch is hittig that "file is empty" condition in the code. You mean upload_max_filesize is 2M? What about post_max_size ? That could well lead to that condition. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Stefan Esser wrote: > And there are many many good reasons, why Suhosin must be external to PHP. > The most obvious one is that the code is clearly separated, so that not > someone of the hundred PHP commiters accidently breaks a safe guard. That's not a justification to keep it as a patch. Safe guards could prefectly be skipped by a commit which changed near code, reestructures the function or creates a different path, *even if the patch still applies*. So you would still need to check for all kind of unexpected changes anyway. If it were in core, at least anyone changing the related code would realise that it's there, and could take that into account for not breaking it. If it's maintained by someone else as a patch, that simply won't happen. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The case of HTTP response splitting protection in PHP
On 03/02/12 15:01, Gustavo Lopes wrote: > I've committed a different version that also forbids \0 (since, as > Stefan says, a NUL byte can result in the truncation of the rest of > the header) and that accepts a CRLF: > > http://svn.php.net/viewvc/php/php-src/trunk/main/SAPI.c?r1=323043&r2=323042&pathrev=323043 > Looks good. But given that the goal is to make this robust, I would go further: a) Replace any CRLF + [ \r] with SP (rfc2616 allows us "A recipient MAY replace any linear white space with a single SP before forwarding the message downstream.", and this also protects UAs not following the spec) b) Bail out on any header_line[i] < ' ' (ie. fail on any special char) > If you or anyone else find any problem, please report a bug; otherwise > I'll merge to 5.3 and 5.4 once 5.4 is out of code freeze. > > Thanks As it's a security patch and of small scope, I would consider it for 5.4. Stas, David? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The case of HTTP response splitting protection in PHP
On 03/02/12 23:00, Stas Malyshev wrote: > Hi! > >> As it's a security patch and of small scope, I would consider it for >> 5.4. Stas, David? > > Do we have unit tests for this code? The fix involves changes in header > sending so it may have impact on lots of code. Changes like this can be > dangerous. I'm thinking maybe we should wait with it until 5.4.1. PHP_5_4 already contains code banning \n or \r newlines. The one which could be bypassed by the "\n Header: Foo\r Foo". Gustavo patch is fixing it to do what was meant to do. I think that any good application relying on header() to send multiple ones would fail with the incomplete fix, so I see little difference in compatibility with using the full one. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The case of HTTP response splitting protection in PHP
On 03/02/12 21:44, Ángel González wrote:
> On 03/02/12 15:01, Gustavo Lopes wrote:
>> I've committed a different version that also forbids \0 (since, as
>> Stefan says, a NUL byte can result in the truncation of the rest of
>> the header) and that accepts a CRLF:
>>
>> http://svn.php.net/viewvc/php/php-src/trunk/main/SAPI.c?r1=323043&r2=323042&pathrev=323043
>>
> Looks good. But given that the goal is to make this robust, I would go
> further:
> a) Replace any CRLF + [ \r] with SP
> (rfc2616 allows us "A recipient MAY replace any linear white space
> with a single SP before forwarding the message downstream.", and
> this also protects UAs not following the spec)
>
> b) Bail out on any header_line[i] < ' ' (ie. fail on any special char)
I've gone ahead and written code for that feature. Comments welcome.
Index: main/SAPI.c
===
--- main/SAPI.c (revision 323049)
+++ main/SAPI.c (working copy)
@@ -710,27 +710,30 @@
efree(header_line);
return SUCCESS;
} else {
- /* new line/NUL character safety check */
- int i;
- for (i = 0; i < header_line_len; i++) {
- /* RFC 2616 allows new lines if followed by SP or HT */
- int illegal_break =
- (header_line[i+1] != ' ' && header_line[i+1] != '\t')
- && (
- header_line[i] == '\n'
- || (header_line[i] == '\r' && header_line[i+1] != '\n'));
- if (illegal_break) {
-efree(header_line);
-sapi_module.sapi_error(E_WARNING, "Header may not contain "
- "more than a single header, new line detected");
-return FAILURE;
+ /* Forbid new lines or control characters in the headers */
+ int i, j;
+ for (i = 0, j = 0; i < header_line_len; i++, j++) {
+ header[i] = header[j];
+ if (i < header_line_len - 2 &&
+header_line[i] == '\r' && header_line[i+1] == '\n' &&
+(header_line[i+2] == ' ' || header_line[i+2] == '\t')) {
+
+/* This is a line continuation. Collapse this little-known
+ * feature into a single SP, as allowed by RFC 2616
+ */
+header_line[i] = ' ';
+j = i + 2;
}
- if (header_line[i] == '\0') {
+
+ if (header_line[i] < 32) {
efree(header_line);
-sapi_module.sapi_error(E_WARNING, "Header may not contain NUL bytes");
+sapi_module.sapi_error(E_WARNING, "header() accepts only a single header, "
+ "new lines and control characters are forbidden");
return FAILURE;
}
}
+ header_line[j] = '\0';
+ header_line_len = j;
}
sapi_header.header = header_line;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The case of HTTP response splitting protection in PHP
Gustavo Lopes wrote:
> On Sat, 04 Feb 2012 00:06:45 +0100, Ángel González wrote:
>> I've gone ahead and written code for that feature. Comments welcome.
>
> The comparison has a problem: if char is signed (the most common
> scenario), you'll be making a signed comparison, so any character over
> 0x7f will match (if it's an unsigned char, though, it will work,
> because of the integer promotions and usual arithmetic conversions).
> It suffices to replace ' ' with 0x20U.
Yes. I woke up this morning thinking on it. That the line should have been
if ((unsigned char)header_line[i] < 32) {
I wouldn't have thought on using 0x20U instead of 32, but it seems that
it would work, too.
> Other than that, I am a little uncertain about the impact of this
> strictness could have on current applications, even if if correct.
In my humble opinion, there won't be applications using header
continuation. PHP could even define that header() would only
accept a single header with no line continuation with very little impact.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] When is PHP6 Beta going to be available ;)
On 02/07/12 14:18, Reindl Harald wrote: > Am 07.02.2012 13:39, schrieb Matti Bickel: >> According to >> http://hilfe-center.1und1.de/hosting/scripte_datenbanken/php/6.html the >> advertised PHP6 is probably PHP5.4RC6... > what has this do do with PHP6? That page seem to list all php configurations they support. So their PHP6 would be a PHP-next reference, if they are keeping up with 5.4 RCs. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] how to debug a php script ( the C code beneath it)
On 13/02/12 21:48, Adi Mutu wrote: > Hello, > > Perhaps this is a stupid question, but i haven't coded in C in years and i'm > not very familiar with development/debugging tools. If I have a php script > say 20 lines, > How can I see a path of the corresponding C code which is executed? What If i > would like to break at a certain php line in the script, is it possible? > > Thanks, Why do you want to do it? It looks to me like that you are trying to solve a problem the hard way by doing that. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Internal server error on PHP syntax error?
On 13/02/12 22:11, Jakov Sosic wrote: > On 02/13/2012 06:10 PM, Reindl Harald wrote: > > >> yes, but the more important is the status code so that search >> engines do not index you broken page, apache SHOULD NOT provide >> his own error-page because you can also send 500 status code >> within your script for whatever reason and want your output >> not supressed in such cases > > OK but I would like it provide it's own error page... Is it possible > somehow without patching php code and maintaining/compiling my own > version? Maybe there is an easier way. This extension allows to show your own page on PHP errors: http://svn.wikimedia.org/viewvc/mediawiki/trunk/php/wmerrors/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] file_get_contents from HTTPS on Slackware 13.1
On 21/02/12 15:54, Bostjan Skufca wrote: > Hi all, > > we've bumped into a possible bug where file_get_contents() returns empty > string if we try to get contents from HTTPS source. This error only occurs > if PHP is compiled with --with-curlwrappers. > > Funny thing is this only happens on slackware 13.1, but not on 13.0 or > older. I've checked ./configure and make output and they are almost > identical, strace does not return anything meaningful. > Environment is highly controlled by configuration management, software is > built in the same way, except underlying OS versions (and very basic libs > and tools versions) differ. > > Two questions: > 1. Do any of you guys have any idea about this? > 2. How to continue exploring deeper to discover what actually this error is > all about? > > Regards, > b. Have you checked it's not a failure verificating the certificate? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
On 21/02/12 17:06, Ralf Lang wrote:
> Am 21.02.2012 16:55, schrieb Martin Amps:
>> Could you not implement such functionality within your class as follows:
>>
>> class Family {
>> public function getMother() {
>> if ($this->hasMother())
>> return $someObj;
>> else
>> throw new BadMethodCallException(...);
>> }
>> }
>>
>> try {
>> $granny_name = $baby->getMother()->getMother()->getName();
>> } catch (BadMethodCallException $ex) {
>>
>> }
>>
>> Martin
>
> Hi Martin,
>
> First of all, thank you for your rapid response but it doesn't address
> my question (or at least the question I intended to ask)
>
> of course there is always a way to script around issues rather than
> adressing them. I just want to know if the change would be desired. I
> have code around which does exactly this, check on all levels of all
> possible combinations. Semantically, this is nonsense and it bloats
> the code. It's just a requirement because currently PHP handles this
> as non-recoverable fatal.
>
> I see no reason why it would be not desirable to have PHP raise the
> exception rather than putting more or less repeating code snippets all
> around the place. That is why I am asking.
You must be returning false/null somewhere. It's the same effor to
instead throw an exception or to return a Ghost family member.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
On 21/02/12 19:03, Ralf Lang wrote: >>> I see no reason why it would be not desirable to have PHP raise the >>> exception rather than putting more or less repeating code snippets all >>> around the place. That is why I am asking. >> >> You must be returning false/null somewhere. It's the same effort to >> instead throw an exception or to return a Ghost family member. > > The $baby->mother() method cannot know if the using code just wants to > collect the $mother object or execute code on it. It can also not know > if having no $mother is a problem or just a fact to deal with. > Unconditionally raising an exception is a bit overkill here, at least > if we would get an exception for trying to access (null)->mother(); > > Currently the user code must check each link of the chain if it is > available, although it is only interested if it can get the final > result or not. > > I'll follow the suggestion and write an RFC. return new NoMother; -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
On 22/02/12 09:37, Sebastian Krebs wrote:
> class MyEnum {
> const FOO = 'foo';
> const BAR = 'bar';
> private $value;
> public function __construct ($value) {
> if (!in_array($value, array(self::FOO, self::BAR)) throw new
> UnexpectedValueException;
> $this->value = $value;
> }
> public function __toString () { return $this->value; }
> }
>
>
> function doSomething (MyEnum $foo) { /* code */ }
>
>
> What I wanted to say: I don't see, what is not possible already?
I want to call it doSomething(FOO) or doSomething(MyEnum::FOO),
not doSomething(new MyEnum(MyEnum::FOO));
+1 for adding enums (although I'm open to variations from that exact
proposal).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On 22/02/12 15:57, Michael Morris wrote: > Before writing up a full RFC I want to put out a feeler on something. > Currently we have several input parameter objects, chief among them > $_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All > of them are arrays and legacy code sometimes writes to them. Locking > them as read only objects would cause a major BC break. Why would you want to set them read-only? I agree that they should represent the input parameters, but there are times where modificating them is very useful. For instance, a framework code could be modifying $_GET on index.php to strip magic quotes before passing it down to another module. Even better, that code would work even for modules written before supporting that configuration. If the module had used directly such $_PARAMETERS, it would get wrong results. I guess we will start seeing the opposite behavior with 5.4, though: Code doing addslashes() on input parameters before running code which expected magic quotes (maybe at auto_prepend_file, even). But still, it's good to have such ability even if it's something to be avoided. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
Am 22.02.2012 22:30, schrieb Sebastian Krebs:
> Am 22.02.2012 22:22, schrieb Ángel González:
>> I want to call it doSomething(FOO) or doSomething(MyEnum::FOO),
>> not doSomething(new MyEnum(MyEnum::FOO));
>
>
> // The class file
> class MyEnum {
> public static $FOO;
> public static $BAR;
> const FOO = 'foo';
> const BAR = 'bar';
> private $value;
> public function __construct ($value) {
> if (!in_array($value, array(self::FOO, self::BAR)) throw new
> UnexpectedValueException;
> $this->value = $value;
> }
> public function __toString () { return $this->value; }
> }
> /* static code block */ {
> // As long as PHP doesn't support "constant references" (;))
> // (--> constants with objects or arrays)
> MyEnum::$FOO = new MyEnum(MyEnum::FOO);
> MyEnum::$BAR = new MyEnum(MyEnum::BAR);
> }
> // End class file
This gets even much more ugly.
Your workaround could have been acceptable if PHP autoconverted into a
class, though (á la C++).
> // Somewhere deep within some other code
> doSomething (MyEnum::$FOO);
>
>
> However, I can't see, what is the big thing, that isn't currently not
> possible (except any "I want"-argumentation :X)
If we are going to have only features which aren't possible in other
ways, then we can begin by removing loops, as
you can replace them with if + goto.
Some parser features are important because they allow to implement
things that wouldn't otherwise be possible. Others, just provide a way
to do things which would have "only" been very complex.
> Sidenote, according your examples above on how you want call
> functions: Considered using normal constants?
How can I do type hinting with them?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
On 22/02/12 23:13, Kris Craig wrote: > While I'm a huge fan of Github, why did you decide to host your RFC there > instead of on the PHP wiki? (...) Samuel doesn't have a wiki accout. I agree he should get one and continue the proposal there. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
On 23/02/12 00:09, Stas Malyshev wrote:
> Hi!
>
>>> Sidenote, according your examples above on how you want call
>>> functions: Considered using normal constants?
>> How can I do type hinting with them?
>
> You should not. PHP is not a strictly typed language, so if you want
> strictly typed function you'll get in trouble, for the same reasons
> why strict scalar typing wasn't a good idea - you may want to re-read
> these discussions.
I disagree.
It is arguable whether having
> enum Databases { MySQL, Postgres, Oracle }
> enum Colors { Red, Green, Blue }
>
> database_select(Colors::Red, $sql);
should give an error for a Databases type hint on the first parameter,
as it can be converted (that's a soft vs strict typing issue).
However, such typehint should avoid a call like:
> database_select(1024, $sql);
with which the function can't do anything sensible with (other than
returning an error if it does its own checking).
Best regards
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
I don't see your point, Sebastian. > And > > | $studipNamedVariable = Databases::Mysql; > | // ... much code > | database_select($stupidNamedVariable, $sql); > > is better? The problem here seems to be more the developer, that > avoids the use of constants, then less the missing enums. You can obviously do weird things, as with in any feature. In this case you bring up, I see little sense in passing enums in variables, unless that comes itself from a parameter for that function, or comes from an external source, like a configuration data. > If you use a constant like > > | Databases::Mysql = 1024; > > the call > > | database_select(Database::IDontExists, $sql); > > will fail too. Other examples, that supports type hints, can be found > in other mails around here. Yes. With a parser error as IDontExists doesn't belong to Database enum. How does it relate with assigning 1024 to Databases::Mysql ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
On 23/02/12 22:59, Kris Craig wrote: > Could you elaborate on this? So long as that setting cannot be changed > midway through a script or its includes (i.e. the stack must be "all > strict" or "all dynamic"), I can't think of any reason why that would not > be feasible. > > --Kris I'm afraid that would create a split between code-for-config-A and code-for-config-B. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
On 23/02/12 23:49, Kris Craig wrote: > Yeah I agree, that was one of the things I listed under > "disadvantages" lol. > > I guess my question is: Does this constitute a prohibitive problem, > or is it something that we can stomach? > > I mean, if you think about it, that's really what we're talking about > anyway, right? After all, when you're writing any application, you're > either going to be writing it with strict typing or you're going to be > writing it with dynamic typing. The only difference here is that > coders with either preference will both find PHP accommodating to > their style. > > > Similarly, a somewhat weaker argument could be made that, in PHP 5, > you're either coding for procedural design or for OO design > (technically you could do both, but I wouldn't wanna touch that > codebase with a ten foot poll lol). The only difference here is that > there would be a config setting to tell the interpreter which is which. > > --Kris I think you would get developers coding for strict, and hostings set to weak. Makes more sense to have it as a per file / per function attribute, so the author can choose if they want the values passed to it to be coerced or act as if they were doing a manual check and throwing an exception. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
On 24/02/12 00:36, Kris Craig wrote: > Hmm that's a fascinating idea! So, and please correct me if I'm > wrong, you're saying that it might be a better approach to determine > strict vs. dynamic typing on a per file or function basis instead of > on a per stack basis? In other words, blah.php could contain two > functions, one using strict typing and the other using traditional > dynamic typing? Yes. Two functions in the same file with different conventions may be a strange use case, I'd expect differences to come from eg. using two libraries, each with different typing. > Theoretically, I think that approach could work. Perhaps we'd have it > specified in the function declaration itself; i.e. "function whatever( > $text, $number )" would be a traditional, dynamically-typed PHP > function, whereas "strict function whatever( string $text, int $number > )" would use strict typing. I'm not keen with that syntax, but that could be discussed. I remember something similar was already mentioned in another types thread, with ideasl like string! or string? to mark the types as strict or weak. > The obvious question then would be, what if dynamic function A makes a > call to dynamic function B, passing to it a dynamically-typed > variable? There are three viable approaches that come to mind: This > count not be allowed; this could be allowed but only if the variables > being passed to function B are cast first (i.e. B( (string) $text, > (int) $number );); or, this could be allowed without casting, in which > case PHP would attempt to pass the variable and then throw an > exception if it cannot be parsed as the required type. Personally, my > vote would be for Option 2. I was envisioning it just as an interface for the call. Thus, if funtion A used strict or dynamic types would be irrelevant. You seem to be bringing up another option however, which is that funcion A could specify the behavior on functions it calls. It can look appealing, but I don't think that's desirable. After all, it's the callee interface what is important, not the kind of caller (you could have a setting to force an stricter behavior, but that seems more appropiate for an extension, like xdebug scream option). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: internals Digest 22 Feb 2012 22:13:24 -0000 Issue 2561
On 24/02/12 17:46, Dmitri Snytkine wrote:
> In order to intoduce the enum into php, 'enum' will have to be a keyword like
> 'class', 'interface', etc.
>
> Just a thought, but could there be a problem with using the new keyword
> 'enum' in php. I don't think it's currently a reserved word, so it could
> potentially cause problems if a script uses the word enum for existing
> variable name or a function or a class name?
>
>
> Dmitri Snytkine
I think it would be _possible_ to handle it in a completely backwards
compatible way, as no valid usage would conflict with new one, and
context could disambiguate them.
A variable called enum would be $enum, so no problem there, but
currently you could have enum in these contexts:
function enum (...) {
class enum {
interface enum {
and the new usage would be like:
enum {
Also, you could have defined a constant called enum, but makes no sense
to use it at the beginning of a sentence.
That said, it would be hard to support such usages compared to the given
gain, so I suppose it would just produce a parser error about T_ENUM in
the above scenarios.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
On 24/02/12 19:35, Kris Craig wrote:
> Could you elaborate on that a little? I.e. "as an interface for the
> call". I'm not sure what you mean by that. If you could provide a
> quick example, that would be awesome! =)
>
> --Kris
Hi Kris,
You're right it wasn't clearly expresseded. Lets see if I can improve it.
A function call is a connection between two pieces of code. The
prototype is the interface through which they communicate (a contract
between caller and callee if you prefer, although I'm only dealing with
the terms provided by the prototype, not those documented in any other way).
This interface can be quite general, "just pass two variables of any
kind", may contain several rules "the first one shall be an object of
type Cat and the second an iterator", of varying complexity "you can
provide a third parameter, but you don't need to".
Although it's a contract between two pieces, I see them as really
"belonging" to the callee, just like a mortgage, which although
negotiated by two parts, the bank has more power deciding the
conditions, and can reuse the offer to several customers.
Similarly, the prototype is defined with the function code, can be
called from multiple places, etc.
A client need may change the interface, but that ends up as a change in
the callee file.
The contract between the two pieces of code, can be quite complex, and
there are interfaces out there which shouldn't exist^W^W include doing
completetely different things if receiving an array, an object, false or
null.
Most contracts however are much more sane, expecting perhaps a User
object, a number or an array of properties.
Still, there's the possibility that the contract isn't honored, such as
being given a cheque with non-sufficient funds.
There are several approaches to that. The easier one is to assume it is
always followed, and let things break if they were not ("It was clear in
the manual that you needed to provide 50 gallons of fuel to the plane
for traveling there, as you did not, we are now in the air with an empty
tank"), but the consequences of a violation a can be quite bad, and also
hard to determine who first violated the contract.
Thus, functions -specially library code expected to be called by
careless programmers- can check by themselves that their arguments "make
sense" before proceeding on, as a way to ensure -as far as they can
assert- that the contract was followed. The equivalent would be phoning
the bank to verify that the cheque is indeed valid before handing the
three apples to the customer. It can be cumbersome, but unlike the
previous approach, you bear no risks.
Finally, typehints are like using a prepaid card, for which the bank
automatically endorses the transaction. If you were given an object for
that parameter, you know that it is the class the prototype required it
to be, because otherwise the engine (the bank) wouldn't have let it pass.
This greatly reduces verifiying work, while still asserting the
prototype prerequisites, and thus makes many people think that type
hinting is a Good Thing™.
Then there are several schools of think on what should happen when you
hand a debit card with insufficient money. Some people think that you
should be escorted out of the shop (without any items) if there's not
enough money there to pay them. Others favour that if you have enough
money in your bank account, the bank should let you continue the
transaction by drawing your money from there.
There are also those who think that the bank should also be able to
mediate for coins (non-objects).
This is just a banker list, where discussion of what should the bank do
with the very different customers (pieces of code), that pass through
it, if it's more important to let the shopping suceed or it's better to
leave the shop empty and keep hard-earned savings for the holidays :)
And that's the end of the story.
The conflict and wars over hinting will continue as breaking the
contracts is in human and such is the fate of this list, until one of
them finally wins.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting
On 26/02/12 15:57, Anthony Ferrara wrote: > I've gone back and re-read a bunch of the old posts on Type Hinting, > and have come to the conclusion that it won't be done any time soon. > Not because it doesn't have merit, but because there are at least a > few fundamental difficulties that are non-trivial to figure out while > still keeping the usefulness. Can you provide a list? Having clear objectives of what we are intending to fix will help to find a good solution. I suspect that the __cast solution is more complex than needed. And specifically, I forsee having both __castTo() and __castFrom() as a source of conflicts. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
On 26/02/12 05:11, Arvids Godjuks wrote: > Kris Craig > > I usually just read the list, sometimes add if I have something to say and > I had voiced my opinion on typehinting before. And you know, just from the > stand of a userland developer who has 7-8 years of experience and devoting > myself to the excelence at PHP, i see this discussion about adding strict > typehinting to PHP as ridicilous. I cannot express my thrustration, because > i would probably be kicked out of the list permanently. > The problem is that those, who are actually advocating for this, come from > all sorts of languages (or have moved to them some time ago) and now what > to "make php better". Sorry folks, but I have picked up a script language > not because it has strict type hinting, but actually because it does not > have it. And because in web we are working with text. Almost any data we > get is text and in critical places we just check that data we have is > actually a number and not a random string. Or is an object of certain type. > Or is an array. Or a valid string. And we let the PHP to handle routine > conversions. And it's good because there can be tons of them per single > script call. String to number and vice-verse conversions are all over the > place in almost any script. They are so common, that if you would add > strict typehinting - you would probably need a type conversion on every > function/method call. I'm not so sure about that. In a well-written web application, you would typically convert them on the first layer, when receiving from the web. On next usages, your int variables are usually ints already. Anyway, you seem to think that people is advocating to add strict typing to the language, while I haven't seen that in this thread. Only to add type hinting (and this all began with an enum proposal!), which could be either strict or weak. Some people positioned against typehints, have been much more vocal against strict, of course, as that has much more ground. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting
I just realised that if it were going to add magic casting, it could as well be done with a spl_autocast_register(), so that you could either cast things when they match, throw an exception, etc. (there should be some default value dynamic typing, so the perfomance wouldn't hurt) . I don't think that's the perfect solution, though. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting
On 27/02/12 16:12, Richard Lynch wrote: > Oh, and string is a reserved word, so this won't work as-is, though > that's obviously picuyane. It's not, you can perfectly define your own class called 'string'. I'd be much easier if it were, though. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
On 27/02/12 01:33, Kris Craig wrote:
> Exactly, hence why I'm still on the fence with that. I was hoping for some
> further discussion though to see if anyone can think of a way around that,
> though admittedly nothing comes to my mind.
>
> --Kris
That's why I mentioned the possibility of having such option per file.
declare(stricttypes=1) {
// Code here
}
Or just
declare(stricttypes=1);
to apply to the whole file
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
On 27/02/12 02:44, John Crenshaw wrote:
> If we can agree on some basic terminology I think it would move things
> forward considerably. I propose these terms:
> - "Strict Typing" means the super strict old C style typing that has been
> proven to be ridiculous in this environment because of the obvious problems
> inherent in the fact that almost every input is a string.
> - "Weak Typing" means types in the same sense that the PHP documentation uses
> types (for example, the docs indicate substr(string, integer), and
> substr(12345, "2") == "345".)
> - "No Scalar Typing" should be used to indicate the current system (where
> there is no provision for hinting at scalar types.)
I'd add a fourth class, in between weak and strict typing, where a
diagnostic is issued when the requested conversion doesn't make sense.
Let's call it sane weak typing. The following would work:
function score(int $number) {
global $points, $total;
$points += $number;
$total++;
}
score(42);
score(1.0);
score("7");
but these would generate a diagnostic:
score(" Mary had a little lamb");
score( array(3, 27, 45) );
score( new stdclass );
score( fopen("myfile.txt", "w") );
(note that in some of these cases, the += operator would already produce
a fatal error)
Re: [PHP-DEV] Scalar type hinting
On 27/02/12 17:19, Richard Lynch wrote: > PRESUMPTION: > > *ANY* strict datatype could also be NULL, to represent a failure > condition... > > Otherwise, when you are out of RAM: > strict $o = new Object(); //violates strict, because Object HAS to be > NULL, as there is no RAM left for it to be an object. Uh? No. You would get a fatal error because PHP exceeded maximum allowed memory. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
On 27/02/12 16:47, Paul Dragoonis wrote: > 2012/2/27 Johannes Schlüter >> Hi, >> >> PHP is no strickt-typed language. Changing this is a massive change, if >> you want to go there: There are plenty of other languages. >> >> If you want this to be an optional feature: >> a) It's not optional (one has to maintain code written by others, uses >> libraries, frameworks, ...) >> b) It causes a hell lot of trouble with copy-on-write. going from >> fixed-typed to non-fixed-typed variables (in a funciton call or >> assignment or such) will always have to cause a copy. This will hurt the >> performance in hardly predictable ways. >> >> johannes >> > Big +1 from me. Thanks for the post Johannes! I also agree with Johannes, that would be too much trouble. > It makes sense to have a type hint for the different type of data > structures. > 1) array > 2) object ( class name for OOP ). > > The scalar values (int, string, double) are type-less, flexible and should > remain that way. If you want strict typehinting then move to another > language. But I disagree with you in that string is always a scalar. int and double being the same thing, that's ok, even though I usually have to deal and verify for just natural numbers, but the consideration that it's a variable of numeric type which could hold many types of numbers is acceptable. Both are also implemented inside the zval. Now strings. There are two different kinds of strings. The first one $age = $_POST['age'] is the kind of string that you want to treat as a number. And that's fine. But you also have $name = $_POST['name'] // 'John Doe' which is wrong to treat as a the same as $age. --- Hello, I see you were born in . You look older. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
On 27/02/12 20:05, Richard Lynch wrote: > You are correct. > > I'd have to come up with some OTHER scenario not involving fatal > error, such as: > > strict $db = new DB(); > > and your database being down, unavailable, or connection parameters > being wrong. > > The principle remains. > > You probably still want $db to be NULL in that situation, rather than > an unusable DB object. > > Otherwise, you'll have to write a lot more sanity checking code > elsewhere, which is what you are trying to avoid in the first place... > > Or, perhaps not. > > Perhaps you really do want this case to just plain bomb out with a > failure that the $db is not strictly an object, with no recourse to > try again, or deal with the error in application logic... It could be throwing an exception. You usually want it to be just what you want. In some cases you may want to accept NULLs. You should provide a different qualifier in that case, such as "strict?" Yes, you may end up with things like nullable strict DB $db = DB::factory(); which doesn't look like PHP at all. But I suppose that's what you wanted? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
On 27/02/12 19:22, Richard Lynch wrote: >>> I'm not so sure about that. In a well-written web application, you >>> would >>> typically convert them on the first layer, when receiving from the >>> web. >>> On next usages, your int variables are usually ints already. > Afraid not. > > It turns out that PHP, on 32-bit hardware, converting large BIGINT > using (int) $ID ends up as a negative number, and then when you pass > it in to the database if a string query, you get a negative ID, not at > all what was intended. > > (Been there, done that, got burned) > > At least, that's been my experience with some versions of PHP and some > database drivers. > > So at least the database IDs have to remain as strings, if you are > using BIGINT. > > You could, of course, only convert the values known to be in range of > PHPs positive integers, and leave the others as strings. > > This is just a simple example of how the super strict typing simply > doesn't work out too well in PHP. That's a good example from experience. Although if you want to keep ids as strings, you can simply keep them as a string type. I was thinking on input coming from a web browser, btw. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
On 27/02/12 22:52, Anthony Ferrara wrote: > Ferenc, > > Thanks for the comments! Thanks from me, too. And thanks to you, Anthony if you get to summarise that. >> There were ideas, but they didn't have enough traction. >> IMO we can't have a proper solution without changing the existing behavior >> for complex types, if you implement strict typing for scalars that turns the >> language strict typed, if you add dynamic/weak typing for the scalars, you >> will have an inconsistent implementation. > What behavior would need to be changed for complex types? Adding the > ability to hint/cast between trees? I'm kind of confused by this > bit... I suspect one of the scalars should be complex (= objects?) > I think that's my biggest problem with the dynamics of this list. > Ideas aren't really nurtured as well as they could be. If the idea is > solid, and has an implementation, then it's great. But there are > plenty of seedling ideas that get lost or down trodden-ed simply > because it's not bulletproof... Yes, the noise ratio of this list is quite high. Probably related to its high volume. That makes people faster in discarding ideas as "been there" and generates friction. And low-quality discussions like that don't attract smart people insights, precisely. It's a vicious circle. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Kris, go out for a walk. We don't need fake stress after the real one :) Yes, it's midnight here, but who cares? That you are afraid of going out at night? Because you had a bad experience with a serial killer? Oh, well... PS: This is what I called 'sane weak typing' in the other thread before you proposed 'strong'... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4.0 released!
On 02/03/12 01:00, Simon Schick wrote: > Hi, all > > When will the documentation be ready? > > For example you wrote that something has changed to the keywords *continue > *and > *break *- but I dont get what and it's not defined in here: > http://www.php.net/manual/en/control-structures.continue.php > > Bye > Simon The option to use a variable as target for the break/continue. Ie. you no longer can do break $var; or continue $var; It's not telling you that you can do that, so the docs don't seem wrong. :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] get_magic_quotes_* != deprecated?
On 02/03/12 02:56, Philip Olson wrote: > Hello! > > Please clarify whether or not get_magic_quotes_gpc() and > get_magic_quotes_runtime() > are deprecated, because I do not think they are. Deprecated means people > should not > use them while writing new code, but they are perfectly sensible functions. > > I propose that we do not describe get_magic_quotes_* as deprecated, and that > they > exist forever, and always return false. > > Regards, > Philip They are not. magic quotes are deprecated, get_magic_quotes will just return false which is what was agreed (there was a bug in the beta making them throw deprecation notices, but they were wrong). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Providing sandboxed versions of include and require language constructs
On 06/03/12 14:04, Adam Jon Richardson wrote:
> The sandbox I'm considering would only impact the ability to directly call
> internal functions. The idea rests on the hope that the framework or CMS
> provides a security model that protects the integrity of their own
> environment. The framework can for example hand off whatever state
> variables are deemed appropriate and necessary to a plugin. The framework
> can make public whatever methods are appropriate and necessary. However,
> the framework can't currently limit the direct calls to internal functions
> (without parsing the PHP source and it's dependencies), which could allow
> the plugin developer to circumvent the security policies of the framework.
>
> Indeed, the complexity is extreme, even for the limited scope of this idea.
> And, avoiding complexity for the developers using the sandboxed version
> would be difficult, too.
>
> I'm wondering if it would be easier to allow constants representing entire
> classes of functionality. For example:
>
> include_restricted('file/path', $whitelist = array('SANDBOX_FILE',
> 'SANDBOX_PDO', 'SANDBOX_MYSQL', 'SANDBOX_SOCKET'));
>
> If an error was raised because an included file required additional access,
> the error message could detail the exact constant(s) that would have to be
> whitelisted for the include to be allowed.
>
> Thank you for the feedback, Stas. The questions and concerns raised in this
> discussion help considerably.
>
> Adam
It's not that easy. The internal functions could be splitted to
safe/unsafe (according
tosome definition, which would itself be a controversial one) but all
functions defined
outside would be injection candidates, too. Suppose you modified the
function
hash table to store if it's a limited function or it should be run with
high privileges.
Now, you need to audit the whole framework so that no can be tricked
into doing more
things than it should, if called from low-privilege code.
Which is pretty hard when that code could be corrupting your variables.
For instance, a safe framework function to perform database queries,
could become
unsafe by changing the db configuration (usually stored on globals),
allowing connections
to arbitrary servers.
Or a malicious plugin could register a class with the same name as a
framework one, before
the autoloader loads the right one, and have it used by privileged code.
PHP is not designed to use it that way, so unless there is an high level
way to do it, it's probably
impossible to do right. Maybe you can perform a full global replacement
when calling
untrusted code. That might work.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] consider reverting E_ALL with E_STRICT
On 06/03/12 17:08, Alan Knowles wrote: > I just got caught on a production server with the 5.4 upgrade on > debian, pretty much everything works fine, except the E_ALL change. > > I have to admit I missed the discussion where it was added, and > searching for E_ALL or E_STRICT on marc is pretty difficult (it > removes the E_ bit..) > > Anyway, this change is a bit of an bomb on the code on the first > server to get hit with this, While i've never cared for E_STRICT (it's > more like E_ANAL) - most of the warnings are pointless code tidy up's > that only have pretty much zero cost/return in fixing. > > However, this change really kills code written by third parties, All > our servers run with E_ALL on (eg. E_NOTICE is printed to end users) > and we fix instantly any errors that the end users see, as they are > frequently issues that should have been addressed. These applications > are intra/extranet apps, not public websites. > > However with E_STRICT included we have to run around and find all the > code, and change it to stuff like this: > > error_reporting(E_ALL & E_STRICT ? E_ALL ^ E_STRICT : E_ALL); error_reporting(E_ALL & ~E_STRICT); will work everywhere. You could even do a global search and replace of E_ALL to (E_ALL & ~E_STRICT), assuming it never appears in eg. a string. PS: I also consider E_STRICT a mostly helpful resource, and not using display_errors on production the sensible thing to do. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] '
On 06/03/12 19:36, Kris Craig wrote: >> FIRST: >> do NOT top post after get a reply below your text >> or how do you imagine that anybody can follow a >> thread where answers randomly before and after >> the quotet text? > Sorry. Sometimes I forget that there are some people out there who still > use legacy non-threaded inboxes. I would recommend you consider switching > to Gmail or some other email client/service that supports threaded views. > That will make it a lot easier for you to follow these threads. =) Threaded MUAs won't help when fragments appear as 3 1 2 4 In such cases, the people breaking the thread convention should the very least remove all the other content. And yes, his MUA does support threading. > To clarify again, I was under the mistaken impression that alias for short_open_tag. My argument was (and still is) against > short_open_tag. I do see some use in this new echo alias for templating > purposes. > > --Kris http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Namespace and Parse tags on Include and Require
On 06/03/12 15:45, Michael Morris wrote: > I have made a wiki account with user name MichaelMorris - I don't > think I have permissions to submit an RFC as of yet. I'll post this > here for now. I've brought this up before, but can now simplify the > original proposal since the decision to always have addresses much of the original problem. > > These changes apply to include, require, include_once and > require_once. Two new arguments for these functions are proposed for > introduction. > > (...) > > Problems > The largest problem is with IDE's. There is no current convention to > warn them that the file is pure PHP. However, I think this can be > mitigated by adopting an extension for php include files -- *.pif, > *.iphp are two possibilities. The language itself doesn't need to > give a care about this directly. Tagless files interpreted as php is the wrong way to go. I think you should instead propose it as: * A file included in that mode MUST begin with is forbidden in such mode unless followed by EOF. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Namespace and Parse tags on Include and Require
On 06/03/12 23:08, Michael Morris wrote: > 2012/3/6 Ángel González : >> Tagless files interpreted as php is the wrong way to go. >> I think you should instead propose it as: >> * A file included in that mode MUST begin with > * ?> is forbidden in such mode unless followed by EOF. > Ever work with older versions of subversion or vi? (Many editors will > put a carriage return after the last character of the file). So no, > you're wrong. Requiring ?> at EOF would just be stupid. Good point. I only wanted to restrict, ?> + ?>\n doesn't produce an empty line, so it's fine So it'd be either * No ?> * ?> * ?>\n -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Providing sandboxed versions of include and require language constructs
On 07/03/12 00:04, Adam Jon Richardson wrote: > It would be the responsibility of the framework or CMS or application > to protect against this type of attack (which they do quite well.) > When you can force a plugin to work through your API, you can take > appropriate measures. When the plugin can avoid working through, say, > a file API that protects against misuse by using the internal file > functions, this is a much more difficult issue to mitigate. The key point is precisely, how do you ensure they can only call your API? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] '
El 07/03/12 00:15, Kris Craig wrote: > > > To clarify again, I was under the mistaken impression that was a new > > alias for short_open_tag. My argument was (and still is) against > > short_open_tag. I do see some use in this new echo alias for > templating > > purposes. > > > > --Kris > > > And your point is? I initially thought this thread was saying > that this alias had been removed and instead made to replace the > short_open_tag. I stood corrected and we moved on. What does PHP 3 > have to do with any of this? I think you've officially crossed the > line from correcting somebody's error to beating a dead horse. ;P > > --Kris Sorry. I understood from your mail that you didn't know
Re: [PHP-DEV] hash / tiger regression in PHP 5.4.0
On 09/03/12 02:05, Adam Harvey wrote: > On 9 March 2012 00:11, Remi Collet wrote: >> Le 08/03/2012 09:03, Michael Wallner a écrit : >>> Sorry for the delay, but I already explained the issue in >>> the bug report: https://bugs.php.net/bug.php?id=61291 >> Thanks, for the explanation. > I'm still concerned about the idea that the output of a hash function > would change from one minor release to another, frankly, whether the > old output was right or wrong. That seems like the sort of thing users > would rely on being very, very stable. It'd be worse to keep the wrong behavior, providing as tiger what it is not. What can be done is to add a "tiger192,3-broken php5.4" hash for BC of those which may have used the new one. It's serious enough so I'd consider it a factor for a new minor in short time, but not for setting in stone a wrong behavior. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] hash / tiger regression in PHP 5.4.0
On 11/03/12 22:55, Michael Wallner wrote: > wat? > > The new hashes are correct. I'm awfully sorry that there has been so much > trouble with the tiger hashes, but it happened and cannot be undone. > Whops, sorry. I got confused on this thread. Change the order of what I said, then. Let the correct implementation stay and add a legacy option for reversed tiger (although reversing 8 byte chunks seem easy to do in userland). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] default charset confusion
On 12/03/12 20:51, Stas Malyshev wrote: > Hi! > >> But you can't necessarily hardcode the encoding if you are writing >> portable code. That's a bit like hardcoding a timezone. In order to >> write portable code you need to give people the ability to localize it. > > No, it's not like timezone at all. I have to support all timezones in > a global app, but I don't have to internally support every encoding on > Earth - having everything internally in UTF-8 works quite well, and a > lot of applications do exactly that - they have everything internally > in UTF-8 and only may convert when importing or exporting the data. I > don't see anything in using UTF-8 throughout the app/library that > makes it non-portable. However, if we allow to change defaults in > htmlspecialchars() etc. that essentially makes having defaults useless > as I'd have so explicitly specify UTF-8 each time - otherwise it's a > gamble what encoding I'd actually get. If you are a framework developer, and really want to shield against a bad php.ini setting, you could ini_set() to your prefered charset at the beginning of the request. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CURL file posting
On 12/03/12 20:36, Richard Lynch wrote: > On Sun, March 11, 2012 6:29 pm, Stas Malyshev wrote: >> This doesn't look good. Documentation does say the @ prefix exists, >> but >> it has very high potential of creating security holes for unsuspecting >> people. open_basedir would help limit the impact, but still it's not a >> good thing. Any ideas on fixing it without breaking the BC? > Ouch. > > Issue an E_NOTICE when it happens? > > Add a new CURLOPT_FILEFIELDS that takes an array of the parameters > that are supposed to be files, so the ones that are expected to have > "@..." do not fire the E_NOTICE. > > Issuing E_NOTICE is a BC, I suppose, but you'd think people would > appreciate an alert about a potential security threat... That would only trigger the notice when you transfer data beginning with an @, which would end up being only when finally attacked. I'd make it need another option to make @ options work (eg. CURLOPT_AT_TRANSFERS_FILES) which default to false. Similar to SO_BROADCAST, where binding a socket to a broadcast address is not enough to send the packets there. It *is* a BC break, but the current API is badly provided. I don't see a way to work around that. A one-line fix to get the previous not-too-used(?) behavior back seems as good as can be achieved. It is also possible to make a completely new option API without those problems, and deprecate the old one, but that's still a BC break. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] default charset confusion
On 12/03/12 22:30, Stas Malyshev wrote: > Hi! > >> If you are a framework developer, and really want to shield against a >> bad php.ini setting, you could ini_set() to your prefered charset at the >> beginning of the request. > > That assuming "the request" is completely processed by your framework > and you never call any outside code and any outside code never calls > you - otherwise your messing with INI setting may very well break that > code or that code's messing with INI settings may very well break yours. Sure. That's a setting to be kept the same for the request unless you like trouble. If you need to call a library function which uses a different html charset convention you could do so through a wrapper, which sets and restores the setting. Still, that API is likely wrong: a library function written by someone completely unrelated to the main application shouldn't be echoing anything through the output. And if it's not generating the html, the htmlspecialchars is better done from the return at the calling application (probably after converting the internal charset). Such interfaces may be well served by switching the setting many times. I was only advocating the usage of ini_set() once in the request, for the case of a server with two applications having different needs (equivalent to configuring it on .user.ini or .htaccess). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let parse_str() parse more than max_input_vars args
On 14/03/12 20:42, Rasmus Lerdorf wrote: > It is somewhat unintuitive that parse_str() is subject to the > max_input_vars limitation and there are sites that use parse_str() to > parse things that aren't directly coming from user query args. > There arr two ways to solve this. We could add an optional max_vars arg > something along these lines: > > https://gist.github.com/2038870 > > The other way to solve this would be to make max_input_vars PHP_INI_ALL > and then just let people ini_set() their way around the limit. > > The one drawback with the optional arg approach is that since > parse_str() is a thin layer on top of the query string parser, the error > if you exceed the passed max_vars talks about the ini setting which in > this case wouldn't really be correct and fixing that would be complicated. > > -Rasmus Configuring it through ini_set would be a hack. +1 for doing it by a new str_parse() parameter. I'm not really keen of implementing that setting and restoring PG(max_input_vars), but as a fast fix, it's ok. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] default charset confusion
On 13/03/12 00:25, Stas Malyshev wrote: > Hi! > >> Still, that API is likely wrong: a library function written by someone >> completely unrelated to the main application shouldn't be echoing >> anything through the output. And if it's not generating the html, the >> htmlspecialchars is better done from the return at the calling >> application (probably after converting the internal charset). > > Again, you making a huge amount of assumptions about how ALL the > applications must work, which means you are wrong in 99.(9)% of cases, > because there's infinitely many applications which don't work exactly > like yours does, and we have no idea how they work. No. I'm saying how I consider they should work, saying that an API doing otherwise is likely* wrong (aka. has a bad design), very much as I'd consider insane a company policy stating "PHP function arguments shall be named $a, $b, $c...". That's obviously my opinion, but I think most applications will conform to that, just as most apps will use more descriptive argument names than "$c"**. * There might be some very very special application where it turns out to be an appropiate design, but that would be the exception. ** Even though there are 26!/(26-n)! ways to name so badly the arguments of a n-ary function. > The main point is that having global state (and yet worse, changeable > global state) significantly influence how basic functions are working > is dangerous. It's like keeping everything in globals and instead of > passing parameters between functions just change some globals and > expect functions to pick it up. I agree with you, in the general case. Yet, I consider the html charset to be a global state. And passing the global variables as parameters on each function call would be nearly as bad as passing parameters as globals. I just positioned the opposite way for parse_str(), while being fully aware of that. >> Such interfaces may be well served by switching the setting many times. > That's exactly what I am trying to avoid, and you are just > illustrating why this proposal is dangerous - because that's exactly > what is going to happen in the code, instead of passing proper > arguments to htmlspecialchars people will start changing INI settings > left and right, and then nobody would know what htmlspecialchars() > call actually does without tracking all the INI changes along the way. That's assuming people would need to use different output charsets, which I don't consider to be the case. How many people is using now the third htmlspecialchars() parameter? What makes you think that they would need to change the default global, *several times per request*? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: laltin
On 16/03/12 18:45, Lütfi Altın wrote: > I want to read PHP source and help PHP for further development. > You don't need a svn account to read the php source. You can just download the source from http://php.net/downloads.php#v5 view the development version at http://svn.php.net/viewvc/php/php-src/trunk/ Or download through svn with svn checkout https://svn.php.net/repository/php/php-src/trunk/ You can then provide patches through the Bug Tracking System at https://bugs.php.net/ And only after having proved that you are a valuable contributor, would be appropiate to request svn access. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Randomize hash-function in php
On 18/03/12 06:56, Tjerk Anne Meesters wrote: > On Sun, Mar 18, 2012 at 8:12 AM, Stas Malyshev wrote: >> Obvious solution would be to use a salt for the hash, which prevents blind >> pre-computing of hash collisions. However, due to the fact that PHP hash >> values can be reused in different processes by bytecode caches, implementing >> it properly is not trivial. > What if php uses salts for specific hashes only, such as GPC (or all > hashes whose lifetime is limited to the current reuqest), and use a > zero-value salt for all others? We'll need to have at least two kind of hashes, at that point, I think it makes sense to place the salt as a member of the HashTable struct. Bytecode caches would just store the salt with the hash. We can also mt_rand() the salt of each hash, for further randomization. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php-src is now on git
El 20/03/12 21:45, David Soria Parra escribió: > On 03/20/2012 09:48 PM, Ángel González wrote: > > El 19/03/12 21:29, David Soria Parra escribió: > >> On 2012-03-19, Kris Craig wrote: > >>> The workflow page currently recommends the "git:" one for > >>> cloning (which doesn't work for me, either). > >> git:// is recommended when you can use it. The access is limited > >> due to port limiations, but the protocl itself is superior to > >> https for the purpose. > >> > >> http is a fallback when you cannot use ssh (developers only) or > >> git > > Actually, the provided url is wrong. It lists > > http://git.php.net/repository/php-src.git but that returns "ERR > > access denied or repository not exported: /repository/php-src.git" > > (that's an error given by the server) > > http://git.php.net/repository/php-src.git > works for me Sorry David. I managed to paste the wrong url there. :/ The bad url is git://git.php.net/repository/php-src.git If you replace the protocol in my above mail, it will begin to make sense, specially how it becomes in the working git://git.php.net/php-src.git after dropping "repository" from the path. Best regards -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php-src is now on git
El 19/03/12 21:29, David Soria Parra escribió: > On 2012-03-19, Kris Craig wrote: >> The workflow page currently recommends the "git:" one for cloning (which >> doesn't work for me, either). > git:// is recommended when you can use it. The access is limited due to > port limiations, but the protocl itself is superior to https for > the purpose. > > http is a fallback when you cannot use ssh (developers only) or git Actually, the provided url is wrong. It lists http://git.php.net/repository/php-src.git but that returns "ERR access denied or repository not exported: /repository/php-src.git" (that's an error given by the server) If you remove "repository" from the path and use just git://git.php.net/php-src.git it works :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about parser implementation details
On 01/04/12 14:19, Florian Anderiasch wrote: > I'd appreciate any hints on how to tackle this serious concern. You should launch a new thread to tackle them. You could then buy foreign slaves to schedule them on their cores. > Btw, in the spirit of x for hex and b for binary I thought about using > this syntax: > > $a = 0spqrMMXII; //set $a to 2012 > ?> > > unless anyone has any better suggestions? Romans didn't have 0 in their keyboards. You should use a different approach which didn't need such character. Also, date extension needs to be extended to support ab urbe condita dates. I think that's a more pressing concern. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without
On 07/04/12 16:06, Reindl Harald wrote: > Am 07.04.2012 16:00, schrieb Tom Boutell: >> That's a good point too. >> >> I think this is a better proposal: >> >> include_code, require_code, and require_code_once would work just like >> include, require and require_once, except that the parser would start >> out in PHP mode. > would you please leave this world in peace? This is a much better proposal than magic-extensions, and a backwards-compatible one. You may not like it (I'm not convinced about it), but your criticism here is wrong. > what do you think happens with hundret thousands of existing > include-files out there which are containing only HTML? They would obviously continue working as they would be using the old require code. Moreover, including a HTML files is bad coding, readfile() works much better. > why do you simply not realize that you have way too few knowledge > and tchnical education to partly understand the side effects > small changes in a general behavior are having and that the > benefit has to be a REAL LARGE ONE for everybody to accept > the possible damage - which is not the case here This is a backwards compatible change. The benefit of not typing ' where are your proposals for bash and other unix shells > hwo they have to work if there is a whitespace before > #!/bin/sh? what have you got as answer there? He is only doing a proposal for php, not for bash. > again: please leave the world in peace with your poorly > thought proposals - and yes this is a really polite answer > compared with the thoughts running through my mind > while reading your stuff Please keep trying, it can still be improved. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without
On 07/04/12 17:22, John Bafford wrote:
> On Apr 7, 2012, at 10:53, John Crenshaw wrote:
>> What if you have just ONE function with a variety of options? Something like:
>>
>> execute_file('path/to/foo.php', array(
>>'require'=>true,
>>'once'=>true,
>>'begin_code'=>'>'shorttags'=>array(''),
>>'autoescape'=>function($str){return htmlentities($str, ENT_QUOTES |
>> ENT_HTML5, 'UTF-8');},
>>...
>> ));
> While there's some elegance with your execute_file (there'd definitely be
> benefits to one function instead of the four we have now), the extra options
> would spawn so much Daily WTF material it wouldn't be funny, and I think most
> people would just stick with include/require/*_once because there'd be a lot
> less effort in the common case.
I agree that the free-form tags could lead to much Daily WTF material,
but there's a simplett reason to reject it: The tags are hardcoded in
the lexer.
Making it anything can drop perfomance.
However, they could be possible as booleans, just as many of them are
now in php.ini.
And I like the idea of providing a function for auto escaping http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without
On 07/04/12 16:56, John Bafford wrote: > On Apr 7, 2012, at 10:00, Tom Boutell wrote: >> .phpc is then just a convention for naming PHP files that start out >> with code - a convention that autoloaders should respect, just as they >> now respect the .php convention. "The user asked for the Monkey class, >> and I see Monkey.phpc is out there; I'll grab that with >> require_code_once." > … I think this isn't quite as simple as you make it out to be. Any autoloader > that cared about bc would have to have code like > > if(file_exists(.phpc)) require_code() else if(file_exists(.php)) require() > else HCF() > > There's a reason everyone settled around a single extension, and not the > plethora we used to have (php, phtml, php3/php4, others?). There's .php5 too :) The extension used would be just dictated by the framework. If it wants .phpc files they wouldn't test for .php files. You could even have everything at .zort files if you wanted to. But placing it as a choice of the autoloader, removes the burden of magic extensions from the engine, which is a Good Thing (TM). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without
On 07/04/12 19:29, Rasmus Lerdorf wrote: > On 04/07/2012 10:23 AM, Ángel González wrote: > >> And I like the idea of providing a function for auto escaping Turn on your default input filter and all data that comes from the user > will automatically be escaped. > > -Rasmus I'm not interested in filtering *input* but *output*. I'm of the opinion that variables should hold their real values up to the last step before being used in the context which needs escaping (hmtl,, sql...). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without
On 07/04/12 22:48, Yasuo Ohgaki wrote: > Hi, > > The only valid reason for removing security. > > Since the null byte detection for fopen, remote/local script inclusion > became much harder than before. However, it's still possible and very > easy compare to other languages. Script execution is critical security > problem and it's worth to make it better. > > If there is a switch that turns off PHP's template engine nature, PHP > could be more secure than now. > > php.ini > template_mode = on ; INI_ALL On by default > > php -t foo.php # template mode by default > php -T foo.php # template mode off > > People has option to make their code a little secure than now > or stick with current behavior. > > Regards, How does it help security? If any, requiring 'http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without
2012/4/8, Yasuo Ohgaki:
> 2012/4/8 Ángel González :
>> How does it help security?
>> If any, requiring '> out malicious files on apps with uploads in case there's a local
>> inclusion vulnerability somewhere.
>>
> Attackers may inject PHP script almost anything/anywhere since
> PHP code may be embed anywhere in a file.
>
> For example, malicious PHP script may be in GIF something like
>
> gif89a ...any data..
>
> and all attacker have to do is include/require the data somehow.
> Attacker cannot do that this for other languages, since they are
> not a embedded language. I know case that attackers may inject
> malicious perl/ruby script in data files, but PHP is too easy
> compare to these languages.
>
> Regards,
>
> --
> Yasuo Ohgaki
Yes, but if I properly check that there's no ' exec("rm -rf"); // Example of what not to do
And was happily uploaded as "plain text".
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without
On 08/04/12 14:31, Tom Boutell wrote: > This is an attempt to protect people who have written inherently insecure > code anyway. One should never do a dynamic require to any untrusted location, > if ever at all, yes? > Obviously. But that include vulnerabilty seems a precondition to the scenario Yasuo tries to protect. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: source files without opening tag
On 09/04/12 13:29, Tom Boutell wrote: > I would like to clarify what this RFC actually says. Let's try to keep > this thread to the pros and cons of this specific proposal. > > The following new keyword would be introduced: > > require_path I don't like the keyword name. Too confusing with the include_path configuration option for something very different. What about require_file ? > This keyword has two parameters of which the second is optional. The > first parameter is the path (filename or URL) to be required, and > behaves exactly as the sole parameter of the require keyword behaves. > The second parameter is an associative array. Does it require brackets? > If 'warn' is present and true, a loading or compilation error results > in E_WARNING (per the current behavior of the include keyword). If > warn is absent or false, a loading or compilation error results in > E_COMPILE_ERROR (per the current behavior of the require keyword). What if I want to silently ignore a missing-file condition? Ie. no warning or compile error if there file is not there (presumably to skip the need of a file_exist), yet receive all warnings generated by the included code. What about 'missing'=> 'error' / 'warn' / 'ignore' ? > If 'code' is present and true, the parser begins reading the file as > if a false, the parser reads the file beginning in “HTML mode,” exactly as > the require keyword does today. I think "reading the file as if a http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
On 09/04/12 20:23, Chris Stockton wrote:
> Hello,
> Although I am not very interested in this feature, if it is
> implemented I like the idea of flags instead of introducing new
> keywords. Maintaining backwards compatibility would be great
> considering the benefit to the feature to be completely honest (and in
> disagreement to many people, but I do understand the reasoning for
> everyone's interest in it) is extremely minor in my eyes.
>
> In addition I would suggest maybe using PHP_INCLUDE_* as a place for
> these constants to live.
>
> -Chris
That would still be a parse error.
Either
include "file.php", 5;
or
include ("file.php", 42);
Fails with a parse error about unexpected ','
On the other hand, a new keyword can be written in a backwards
compatible way by making it look like a function call in a non-taken branch:
*if ( version_compare(PHP_VERSION*, '5.5', '<') )
include_once $file;
else
require_code($file, array( 'once'=>true, 'warn' => 'ignore' ) );
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
On 09/04/12 19:36, Luke Scott wrote: > On Apr 9, 2012, at 10:23 AM, Tom Boutell wrote: >> Also, your objection - that 'require_code' is confusing - would most >> likely be an issue for a handful of people who write autoloaders. >> Those clean PHP class files are almost always autoloaded. > Not really. Has nothing to do with auto loaders. > > require_code - A literal string? Is this eval? > > require_path - A directory? > > require_file - What kind of file? A php file, of course :) > You have to look at the keywords you're proposing and try to explain > then without prior knowledge or documentation. But if you come accross them you'd see something like: require_code "setup.php"; Which is much more clear. > These keywords are also ambiguous. require/include are well understood > for including code not templates. Not just for PHP. PHP has allowed to require HTML forever. Given it's php developers the main target, it is not a huge argument that they may get confused by require_file doing what require has always done. I admit require_code for a full HTML file* may be slightly odd, but require_file is completely aseptic about that. * Which should instead have been loaded with readfile()... > require_template on the other hand is clear and to the point. It's > hard to make the same kind of assumptions as you can with the other > keywords. And with those who know PHP it's readily apparent > require_template could mean short tags whereas the other leave you > scratching your head. Except that you're breaking compatibility by designing it the opposite way. It may have been the perfect idea if we were designing PHP from scratch, but we're not. This is a 17 years old language. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without
On 09/04/12 21:17, Yasuo Ohgaki wrote: > Please do not tell me that programmer should > learn not to, since it's not a protection but education. Hire a more competent programmer? If he writes such code, he will be completely unaware of the subtleties of XSS, or how SQL should be escaped, and his code is probably beyond "protection". You're better served by rewriting it. > If programmers/administrators could disable embed mode, > then systems will be protected from vulnerable codes. How do you enforce that the application you need doesn't rely on it? Note: 'education' is also forbidden as you restricted it in the previous question. :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
Luke Scott wrote:
>> if ( version_compare(PHP_VERSION, '5.5', '<') )
>> include_once $file;
>> else
>> require_code($file, array( 'once'=>true, 'warn' => 'ignore' ) );
> I'm fairly certain that wouldn't work either. Require and friends are
> constructs, not functions.
>
> Luke
I had assumed require_code would work with brackets around the parameters.
Someone mentioned it, but you raise a good point in that it's not stated
by the
rfc, and would need to be explicitely supported.
There are people calling require and friends with brackets, but that
likely (ie.
not looking at the lexer) works because the parameter is ('foo') which
resolves
as 'foo'. That wouldn't work when there are two of them.
I think it should be something to consider when making the patch, though.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
Hello Chris,
Chris Stockton wrote:
> I am not sure I am following you here Angel, are you confusing
> backwards and forward compatibility?
It can probably be termed both ways, depending on which version you stay.
I'm refering to the ability of a php file to work in both version 5.4
and 5.5 yet
take advantage of a 5.5 feature if available.
> I wouldn't expect a feature to ever work forward compatibly.
> I.E. Can't use traits in php 4 and can't
> play a blu ray disc in a dvd player.
The introduction of a new function is a good example of compatibility. The
code can easily detect and fall back
function getRandomNumber() {
if (function_exists('rand'))
return rand();
else
return 4; // chosen by fair dice roll, guaranteed to be random
}
or even show a graceful error message (instead of a cryptic php error):
if ( version_compare(PHP_VERSION, '5.4', '<') )
die("This program requires the awesome 5.4 version of PHP");
class Foo {
use Bar;
...
}
The later one is an example of what would *not* work, since even though
the developer tried to show a clear error to the end user unexpectedly
installing in an older php version than supported, he would get
"PHP Parse error: syntax error, unexpected T_USE, expecting T_FUNCTION"
which in no way leads them to the "You need to update PHP" conclusion.
> The goal here is that if you have
> a large code base which has a hand rolled include_code function
> already, your change is backwards compatible with that code base. Same
> to be said for any constants, which is why I recommended using the
> reserved PHP_* space.
The goal is to allow use of the new characteristics without having to drop
support for old PHP versions, which is something typically done quite
conservately.
In this case, it would even be possible to make a userland include_code on
old versions by falling back to an eval(). Not as good, but the codebase
is still
supporting the old PHP engines (back to X version).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
On 10/04/12 19:22, Chris Stockton wrote: > Hello, > I understand your point that you are trying to make, but forward > compatibility I am not sure shares the same critical nature as > backwards. Sure, but if we can help with that when designing the feature, that's much better, and I think would also ecourage into using it. > I think a software provider who is aiming at supporting a > wide variety of php versions is likely going to code around the lowest > common denominator. If they can easily work around it, it's much easier they start using it soon than waiting for when common web hostings stop providing 5.4. > Even still, if they chose to they could have two > bootstrap files, one that included files with the new features and one > with the old. Of course, they still could, but is more troublesome. Specially if as you suggest, they need to keep two files in sync. In that case it's probably easier to keep without the new features. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] get_magic_quotes_gpc() returns false instead of 0
On 24/04/12 18:11, Paul Dragoonis wrote: > Happy to patch this once someone confirms this is a bug and not > "changed behaviour" in 5.4. > > - Paul. Why would such behavior change be desired? get_magic_quotes_gpc() is kept only for compatibility with scripts which did magic quote detection. As such, it should return its 'traditional' value. get_magic_quotes_gpc() got wrongly deprecated in 5.4, then restored... I think that when implementing it to always return that there are no magic_quotes, it was just inadvertedly changed to false. Which is the "logical" thing as those 0/1 work as booleans, but that should have been done long ago, when designing it, not now. Regards -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
On 05/05/12 20:08, Sanford Whiteman wrote: > This presupposes that your users don't expect embedded metadata to be > preserved when people redownload the images. > > Not only do photo professionals/hobbyists expect you to keep the > metadata, you also should leave it in for reasons of legality. Hosting > a bunch of stripped images can make you look really bad. We only strip > metadata that is known to cause browser display problems (mostly old > IE6/Adobe comment bugs). > > Bottom line is you have to make sure PHP never parses the files. > > -- S. Moreover, that still doesn't protect you, as it would be possible to make a valid image where the payload happened in the image data. I haven't tried to create such malicious image, but I have found legit images that tripped bad-image-detection heuristics looking for a 4-byte magic. Image contents are "a bunch of random bytes", but 'DROP TABLE Students;' is binary data, too. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
On 06/06/12 12:20, Ivan Enderlin @ Hoa wrote: > On 05/06/12 19:35, Nikita Popov wrote: >> Hi internals! > Hi Nikita, > >> Before going any further I'd like to get some comments about what you >> think of adding generator support to PHP. > I have always hoped to see the “yield” keywork introduced in PHP. Me too! It's syntactic sugar around iterators, but a very welcome one. I'm not sure about the usage as coroutine, though. It looks odd that ->send() which appears into yield. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
On 11/06/12 23:12, Tom Boutell wrote: > Can you really use setjmp and longjmp in that way safely? I thought it > was only safe to longjmp "back," not "forward" - you can use them to > fake exception support but that's it because you'll smash the stack > otherwise. Something like that... My first reaction was also "How do you return to the mid-running function?" However, given that the running function is in PHP-land, I think you could (in non-zts, it's direct in zts), save EG() contents and replace with new values, and then continue the execution. As it's treating "threads" non-preemtively, that should work. The C code would also view a different thread, but because it is viewing different globals (some extensions might need changes). Not really involving setjmp() / longjmp(). You could make userland context switches (adding arch-specific code) for the C code by switching the stack under your ESP, but it's highly likely to produce some obscure bugs by missing to keep a register... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding a simple API for secure password hashing?
On 14/06/12 16:26, Peter Lind wrote: > I would say it really depends upon the project. The salt can not only > protect against rainbow tables and password hash collisions, if it is > unknown to an attacker then it essentially acts to further strengthen > the hash by vastly expanding the keyspace. Supposing an attacker is > trying to get at the password for just one user account (say, admin) > and the hashed password is available - if the salt can be > predicted/guessed, then the keyspace is reduced to that of an unsalted > password and you can run a dictionary attack on the hash. If, on the > other hand, the salt is unpredictable and you don't have access to it, > there is no way to run a dictionary attack (offline, that is). The > security here depends upon storage as well, but the point remains - a > salt isn't by default something you can make public knowledge. > > It might be a theoretical concern for most people and the people > really wanting the extra level of security would probably know well > enough how to get exactly what they need - but if provisions are made > so you could reuse the same function you might also be able to educate > developers better. I.e. make it easy to do the right thing and more > people will do it. May I ask how would you end up at the situation where the attackers have the password hashes but not the salt? Any process which needs to read the password hashes will also need knowledge of the salt. Thus an attacker would most likely also know both. That's precisely how salts are designed to work. I admit you could have a common salt for all users stored in php and only a leak of the database. But such salt would most likely be provided by the user, generated using a different program... expected to be secure. Using a shared salt is worse than a uniqe salt per user, so that's not something to promote either. You wouldn't be "educating in the right way". -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] concatenation operator
On 13/06/12 05:26, Morgan L. Owens wrote: > After reading the performance improvements RFC about interned strings, > and its passing mention of a "special data structure (e.g. > zend_string) instead of char*", I've been thinking a little bit about > this and what such a structure could be. > > But rather than interned strings, I thought that _implicit_ > concatenation would be a bigger win in the long term. Like interning, > it relies on strings being immutable. > > This zend_string is a composite type. Leaves are _almost_ identical to > existing string zvals - char* val, int len - but also an additional > "child_count" field. For leaves, child_count is zero (not incidentally > indicating that it _is_ a leaf). For internal nodes, "val" is a list > of zend_strings (child_count of them). "len" still refers to the total > string length (the sum of the len fields of its children). > > So a string that has been built up through concatenation is > represented by a tree (actually a dag) of zend_strings. The edges in > this dag are all properly reference-counted; discarding a string > decrements the reference counts of its children. How do you list then? As a single-linked list? That would avoid reuse of the component strings in different superstrings except from matching ends... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Confusion on how to exclude embedded sqlite3 during make/build
On 14/06/12 00:58, Michael Felt wrote: > Hi. > > I am trying to compile php against httpd 2.4.2 - but before it gets > interesting I think I am having a different problem. > > The sqlite3 embedded in ./ext/sqlite3 returns a syntax error against vac.C > v11 compiler. > > data/prj/php-5.3.13/ext/sqlite3/sqlite3.c -o ext/sqlite3/sqlite3.lo > "/data/prj/php-5.3.13/ext/sqlite3/sqlite3.c", line 893.9: 1506-046 (S) > Syntax error. > "/data/prj/php-5.3.13/ext/sqlite3/sqlite3.c", line 894.41: 1506-045 (S) > Undeclared identifier i. > "/data/prj/php-5.3.13/ext/sqlite3/sqlite3.c", line 894.51: 1506-277 (S) > Syntax error: possible missing ';' or ','? > "/data/prj/php-5.3.13/ext/sqlite3/sqlite3.c", line 894.65: 1506-045 (S) > Undeclared identifier or. > make: 1254-004 The error code from the last command is 1. ext/sqlite3/sqlite3.c in php-5.3.13 only has comments at lines 893-894. (That's a big comment from 846 to 906). What do you have at those lines? As it mentions "Undeclared identifier or.", perhaps it's (wrongly) taking the slash at "and/or " as a "*/" ?? That would be very broken of a compiler... > Rather than try and solve that I compiled a separate sqlite3 version > root@x104:[/]sqlite3 -version > 3.6.22 > > However, even after make distclean and a new run of configure with the > following arguments - make still continues to try to compile the embedded > sqlite3. > > root@x104:[/data/prj/php-5.3.13]cat php_configure.ksh > #!/usr/bin/ksh > > set -x > > ./configure \ > --prefix=/opt \ > --sysconfdir=/etc \ > --mandir=/usr/share/man \ > --with-libdir=/opt/lib \ > --with-sqlite3=/opt \ > > build/aix/configure.out > > What am I doing wrong? Many thanks! Seems a problem in the sqlite3 extension config.m4, in that it has a depends rule on the libsqlite/sqlite3.c copy. A simple fix would be to copy the sqlite amalgamation that works for you over the php copy. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding a simple API for secure password hashing?
On 16/06/12 15:39, Pierre Joye wrote: > However the point here is not the implementation but the APIs. > > To be honest I am not a big fan of providing such an API in the core > as no matter the default implementation, it will become obsolete soon > or later. And changing the default brings its lot of issues and BC > problems. > > That being said, it seems that we may not have the choice anyway so > having a well designed and implemented API for password (and related > or similar areas) generations may be a good thing. The generated password hash should contain versioning information (such as the $1$ for crypt), so password_verify() of later PHP versions will be able to correctly verify it, even after the default password hash changes (set an older type in php.ini if you don't want to use the new format). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding a simple API for secure password hashing?
On 18/06/12 18:54, Anthony Ferrara wrote: > Pierre, > >> There is sadly only state-of-art-right-now password hashing methods. >> We have to keep that in mind :) > That's why the crypt() return format was designed. All of the options > that are needed to validate the hash (algorithm, cost parameter, salt, > etc) are fit right into the outputted string. > > I'd suggest that's what's done here. In fact, I'd make the functions > just a thin wrapper around crypt(). Basically, just where it sets sane > defaults that we can update every minor (or major) release (to > compensate for faster servers). It handles salt generation, error > checking, etc. > > Here's what I have in mind in php: https://gist.github.com/2949382 I don't think the code is the most appropiate one, but I suppose that's not a final proposal. The interfaces look good to me. I'd maybe set the default $algo to PASSWORD_DEFAULT_HASH or similar, being a value bumped on each next revisions. I would consider preferable to have the $ ofpassword_register_algoprefix implicit. Regards -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
On 27/06/12 18:13, Pierre Joye wrote:
> Changing default value forces code change if you have to keep a given
> hash, for one obvious side effect.
>
> If you disagree or does not like the idea, that's all fine, but you
> can't really say that it is not an argument (nothing to justify, this
> is a draft and it is being discussed).
>
> Cheers,
Precisely the point of such constant is to allow the applications to
magically
change to use more secure hashes, without needing to parform a recursive
sed in the codebase to change HASH_SHA2015 with HASH_SHA2048.
If you want to be in precise control of the actual hash used in a newer
version
(such as an hereogeneous deployment), you could set it to the lower
denominator
in php.ini.
Obviously, any such bump -which I would expect to happen on major releases-
would hold an entry in the NEWS file explaining that PASSWORD_DEFAULT_HASH
is now md5 by default instead of crc32 (still, I would expect a new hash
to have
been available on several releases -they could easily be added on minor
ones-
before becoming the PASSWORD_DEFAULT_HASH).
Remember that the goal was to make the next-generation password hasing api.
An (almost) foolproof way to make the applications secure. If you expect
them to
timely realise the problems of md5() and go back to change all their
functions,
you will replace the current function with password_hash('password',
SILLY_HASH, ...).
Developers with higher security knowledge (few of them, you'd almost
need to be a
cryptographer yourself) can use the advanced parameters to tweak it to
their needs.
Regards
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Asking for a review of crypt() allocation changes
On 29/06/12 14:43, Nikita Popov wrote:
> Hi internals!
>
> Anthony and me have been looking a lot at the crypt() code recently
> and noticed that there are some strange things going on in the buffer
> allocations for the sha algorithms.
>
> We did two commits to fix them up a bit:
>
> http://git.php.net/?p=php-src.git;a=commitdiff;h=7e8276ca68fc622124d51d18e4f7b5cde3536de4
It took me a while to realise the problem being fixed. The bug is not
the memset (as reported in bug 62443),
which is using needed (got fixed in e6cf7d), or php_sha{256,512}_crypt_r
(uses a null-terminated string), but the salt[salt_in_len] = '\0';
after allocating only strlen(salt).
So that you would be accessing the position PHP_MAX_SALT_LEN of the
array but have reserved only a few bytes.
Just*sizeof*(sha512_rounds_prefix
)
+ 9 + 1 seem enough for not making bug62443.phpt segfault.
I have been able to crash it with var_dump( crypt("foo", '$6$'.chr(0).
str_pad('', 500, '*') . '$abc') );
but only if it's the first call.
Re: [PHP-DEV] Re: Adding Simplified Password Hashing API
On 03/07/12 18:21, Anthony Ferrara wrote:
>> 2) I'd like to be able to check wether a stored password uses an outdated
> algorithm and update the hash in that case. For that I'd need either a
> function to extract the salt from a hash to pass it to password_hash() and
> compare the result with the old hash. Or preferably a separate function
> password_hash_outdated($hash) => bool or something similar. Or maybe
> someone can come up with yet a better solution for this.
>
> Well... I don't know about that. Outdated is a very odd concept here.
> Perhaps, a password_hash_get_algo($hash) call would suffice. That way, you
> could do if (PASSWORD_BCRYPT == password_get_hash_algo($hash)) { //upgrade
> hash }. Or even if (PASSWORD_DEFAULT != password_get_hash_algo($hash))...
What about:
> /bool password_rehash(string &$hash, string $password, int $flags, int
> $algo, array $options = array())/
With /$flags allowing the values: //PASWORD_REHASH_ALWAYS,
//PASWORD_REHASH_IF_WEAKER/, ///PASWORD_REHASH_NEW_SALT/
(I thought about having $flags inside $options, but seems better to have
it explicit)
The return value is true iif $hash has been changed
/
The usage would be like:
//$hash = //database select password from user where username =$user;
if (//password_verify($password, $hash)) {
if (//password_rehash($hash, $password,
PASWORD_REHASH_IF_WEAKER,/PASSWORD_MOST_SECURE/)//) {
database update user set password=$hash where username=//$user;/
/ }
// User is logged in
}
/
