Re: [PHP-DEV] Re: Proposal: Introduce a new macro:php_error_docref_ex()
Why not leave it as it is? I mean, really, those five strokes? Wherever it's going, I'm -1 on changing the meaning of the existing macro. On 11 Feb 2015 16:01, reeze re...@php.net wrote: Hi, On 11 February 2015 at 19:15, Dmitry Stogov dmi...@zend.com wrote: Hi, I don't think it'll improve something, and may complicate merging from PHP5 (this is not a big issue, because merging is already not simple). Yes it just makes code looks a little better and cleaner. I didn't realized the merging problem. that might affect diffs which changes php_error_docref() In any case, the names should be swapped, to be used as: php_error_docref(E_WARNING, recursion detected); or php_error_docref_ex(NULL, E_WARNING, recursion detected); Yes I prefer this too. But considering the merging problem, I think I should hold this idea of update all of those calls. We may provider a simple version with default null docref for external extesions, but I didn't have proper name for that. also macros with __VA_ARGS__ may be not portable, s it should be implemented differently. Yes I should use ##__VA_ARGS__ instead. Thanks. Dmitry. On Wed, Feb 11, 2015 at 11:41 AM, Xinchen Hui larue...@php.net wrote: Hey: On Wed, Feb 11, 2015 at 4:35 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Wed, Feb 11, 2015 at 5:21 PM, reeze re...@php.net wrote: I think it is a cleanup, it works but there are too many duplication. it is the time to make the code clean and easier to understand. I've never used other than NULL also. Everyone is going to remove TSRM macros, it's right time to clean up. fine, if you want to change.. please, _ex means extending, so the name should not be php_error_docref_ex... thanks Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- Xinchen Hui @Laruence http://www.laruence.com/ -- Reeze Xia http://reeze.cn
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Pavel, On 11 Feb 2015, at 07:41, Pavel Kouřil pajou...@gmail.com wrote: Also, I realized one thing why I think the strict version is a bad idea for PHP (in the state PHP is now - in an ideal world I would love to have nothing but strongly typed PHP, but that's offtopic) - PHP has many functions that return multiple types, so you cannot do foo(bar()) if bar() has multiple return types. :( You can’t do it with weak types either. Functions with multiple return type usually do so in order to use one type for success, and another return type on failure. In weak typing mode, PHP would just mangle the error value (like FALSE). -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
Hi, another one of my weird ideas: what about a script signing mode? - ini setting containing a HMAC key - first ?php tag in a file must then have a signature, a la ?php:Base64encodedstring - no parsing of files that fail the signature check - (maybe optional) disabling of eval Of course such an approach would need, in addition, a locally well defined place from where updated code is distributed to production servers, which would then need to implement the signing process. So it's only something for sane larger shops with a good dev/production split. best regards Patrick
Re: [PHP-DEV] Design by Contract
Hi! That one actually looks better to me, but: I'm not sure how annotation syntax is supposed to support expressions or closures, keep AST. So we'd have a zval type that is the raw AST? Would it also be available to user functions or internal functions/classes? It's an intriguing concept but I'm not sure we appreciate all the consequences of it - adding new type is a rather big change as everything should support it. Or did you mean something else? Is it some special form of annotation for this purpose only (meh)? yes. some special attributes. requires/ensures/invariant Ah, so require() annotation would work different than any other type of annotation? Then I don't see any use for it to use annotation syntax (whatever it would be) - same syntax should mean same or at least similar function. Maybe I am still missing what you meant. Oh, and syntax is *ugly* ;) It's from HHVM. I don't like it as well, please, propose the better one. Pretty much every other one is better: Java and the followers, Python: @foo C#: [foo] -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC][DISCUSSION] Script only includes
Hi all, On Tue, Feb 10, 2015 at 9:52 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Some of you are tired with this topic, but please take a look the RFC [RFC] Script only includes - this is 3rd version. https://wiki.php.net/rfc/script_only_include Please let me know what you like or dislike. This proposal has defect. I was excluding old proposals and it turned out old proposal was better. Thank you Stas. There was proposal that limit script execution only for certain filename extension(s). Currently, PHP has text script and phar script loader. If we limit script filenames, then all users has to do is checking filename extensions. We have null byte injection protection for filename already. This would be the simplest and works well against script inclusion. Comments are appreciated. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
Hi Stas,
On Wed, Feb 11, 2015 at 4:32 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
Some of you are tired with this topic, but please take a look the RFC
[RFC] Script only includes - this is 3rd version.
https://wiki.php.net/rfc/script_only_include
Please let me know what you like or dislike.
I think there are several issues with this RFC:
1. It does not protect against all the problems it purports to protect.
I.e. if you want to protect against local PHP code accessing evil
uploaded files, local PHP code can also do echo
file_get_contents('/etc/paswd') and still have a problem (actually, very
common LFI issue). Even if the application only allows to require
random file, it may be possible to inject data via other means - such as
data stream, URL, temp files, session files, etc. Upload is not the only
way inputs can be controlled.
File disclosure issue is not scope of this RFC.
2. Legitimate files can include ? as byte sequence - in fact, it is
almost guaranteed big enough binary file would contain it. Restricting
upload of such files would break uploading functionality on many sites.
Good point.
User needs compression/encryption to avoid issues.
I may make move_uploaded_file() more strict.
How about syntax check? If it detected as script and there is no syntax
errors,
then reject. This will never happens binaries.
However, this is not enough. User may upload text with PHP program sample.
So add and options that force to move embedded PHP script?
Another possibility is use of filename extension(s). It's going back to old
approach,
but register script extension and allow execution only for matched
extension.
This may be the way to go.
3. General approach of this RFC is, given site with glaring security
hole in their code, give them a measure of protection against some of
the consequences. This looks like safe_mode approach, and that proved
ineffective in the past.
I'm not trying to be perfect, but I would like to make PHP as secure as
other
languages from script inclusion attacks. It's too easy currently...
I hope we have consensus for a resolution.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
Hi! I'm not trying to be perfect, but I would like to make PHP as secure as other languages from script inclusion attacks. It's too easy currently... PHP is already as secure as the other languages. If you have code in Python that loads arbitrary file and executes it, you could upload Python file and execute it. If you have code in Ruby that loads arbitrary file and executes it, you could upload Ruby file and execute it. If you have code in C that... you get the idea. Same with PHP. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Proposal: Introduce a new macro:php_error_docref_ex()
Hi all, On Wed, Feb 11, 2015 at 8:15 PM, Dmitry Stogov dmi...@zend.com wrote: I don't think it'll improve something, and may complicate merging from PHP5 (this is not a big issue, because merging is already not simple). In any case, the names should be swapped, to be used as: php_error_docref(E_WARNING, recursion detected); or php_error_docref_ex(NULL, E_WARNING, recursion detected); also macros with __VA_ARGS__ may be not portable, s it should be implemented differently. It's even better. +1 Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Rasmus,
On 11 Feb 2015, at 06:36, Rasmus Lerdorf ras...@lerdorf.com wrote:
And in Drupal8 *without turning on strict*:
use Drupal\Component\Utility\String;
it dies with: Fatal error: string cannot be used as a class name in
/var/www/drupal/core/includes/bootstrap.inc on line 11
That String class is everywhere in Drupal. They are going to have a
fun time with that. See
https://gist.githubusercontent.com/anonymous/d9252deeeb2aae1a5af5/raw/053155130d22551b1404d0a9b94e27424544b6d1/gistfile1
Such classes will unfortunately have to be renamed. However, this is only true
if the code needs to run on PHP 7. For PHP 5 codebase compatibility, Drupal can
do this:
class StringHelper {
…
}
if (version_compare(phpversion(), “7.0) 0) {
class_alias(“Drupal\\Component\\Utility\\StringHelper”,
“Drupal\\Component\\Utility\\String”);
}
This way, only code made “PHP 7-ready will have to replace its references to
String with, say, StringHelper. Drupal can work on both PHP 5 and PHP 7, but
codebases using it can migrate at their own pace.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Design by Contract
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki Both D and Eiffel evaluates all contracts defined in parents/interfaces. That's not what I understand about pre-condition inheritance in D (check http://ddili.org/ders/d.en/invariant.html#ix_invariant.contract%20inheritance) : Upon entering a function, the in blocks are executed automatically from the topmost type to the bottom-most type in the hierarchy . If **any in block** succeeds without any assert failure, then the preconditions are considered to be fulfilled. And later : Derived types can define in blocks for overridden member functions. Preconditions of a derived type should not be stricter than the preconditions of its bases. (Note that not defining an in block means no precondition at all, which may not be the intent of the programmer.) The D documentation is not clear about interface inheritance, especially regarding pre-conditions. I am OK with the fact that post-conditions and invariants must verify the constraints defined in their ancestors (parent classes and interfaces), but, for pre-conditions, I would prefer an optional explicit reference to the parent's constraints. Cheers François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can we remove NEWS tag ?
On 02/11/2015 10:52 AM, Lior Kaplan wrote: Hi, I've been doing some editing to the NEWS files, and keep getting this problem $ git diff NEWS fatal: ambiguous argument 'NEWS': both revision and filename Use '--' to separate filenames from revisions Although I can do as it suggests, I would prefer to remove the NEWS tag we have since 2008 as part of the move from CVS to SVN. Any objections ? While I don't think anyone would actually be using that in the near future, can't you just rename it to NEWS-2008 or something? (Or manually retagging and then deleting if nothing else.) * still can be found * no historically important data is lost (just kidding) * problem solved Just because I've seen people argue in favor of keeping historical branches and stuff, and while I don't see a lot of value, it might be needed at some point. ~Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Design by Contract
Hi Lester, All of the current demands ... and I think they are demands! ... stamp on past history and load even more work on everybody to have to support all these new features. Even if dbc is wrapped in comment blocks to hide it it's potential presence in third party parts of a project means that all tools have to be modified and my use of phpdoc is further eroded. The proposal to embed DbC conditions in phpdoc is just defining new '@' keywords. That's the implicit way such a basic annotation system works : tools ignore the lines they don't understand. I ran phpDocumentor on DbC-commented script files, and it still produces the same documentation. It's supposed to be the same with everyone extending phpdoc syntax. So, I don't understand why you should modify any of your tools. Cheers François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
On 11/02/15 14:14, François Laupretre wrote: All of the current demands ... and I think they are demands! ... stamp on past history and load even more work on everybody to have to support all these new features. Even if dbc is wrapped in comment blocks to hide it it's potential presence in third party parts of a project means that all tools have to be modified and my use of phpdoc is further eroded. The proposal to embed DbC conditions in phpdoc is just defining new '@' keywords. That's the implicit way such a basic annotation system works : tools ignore the lines they don't understand. I ran phpDocumentor on DbC-commented script files, and it still produces the same documentation. It's supposed to be the same with everyone extending phpdoc syntax. So, I don't understand why you should modify any of your tools. While phpDocumentor can ignore elements it does not understand, that information would be useful to maintain, so some modification of it's parsing would be appropriate. But I was referring more to the other proposals for adding essentially the same information, and how that might be hidden in non-docblock comment packets. But currently some tools are lagging behind even current changes in PHP and phpDocumentor does not get everything right already. I can't get a clean set of documents currently with either the original version or the Mk2 version of phpDocumentor on code that has produced clean documents in the past. Just another area that needs time spending to work out what now need updating which does not affect the working code. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Proposal: Introduce a new macro:php_error_docref_ex()
Hi, On 11 February 2015 at 19:15, Dmitry Stogov dmi...@zend.com wrote: Hi, I don't think it'll improve something, and may complicate merging from PHP5 (this is not a big issue, because merging is already not simple). Yes it just makes code looks a little better and cleaner. I didn't realized the merging problem. that might affect diffs which changes php_error_docref() In any case, the names should be swapped, to be used as: php_error_docref(E_WARNING, recursion detected); or php_error_docref_ex(NULL, E_WARNING, recursion detected); Yes I prefer this too. But considering the merging problem, I think I should hold this idea of update all of those calls. We may provider a simple version with default null docref for external extesions, but I didn't have proper name for that. also macros with __VA_ARGS__ may be not portable, s it should be implemented differently. Yes I should use ##__VA_ARGS__ instead. Thanks. Dmitry. On Wed, Feb 11, 2015 at 11:41 AM, Xinchen Hui larue...@php.net wrote: Hey: On Wed, Feb 11, 2015 at 4:35 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Wed, Feb 11, 2015 at 5:21 PM, reeze re...@php.net wrote: I think it is a cleanup, it works but there are too many duplication. it is the time to make the code clean and easier to understand. I've never used other than NULL also. Everyone is going to remove TSRM macros, it's right time to clean up. fine, if you want to change.. please, _ex means extending, so the name should not be php_error_docref_ex... thanks Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- Xinchen Hui @Laruence http://www.laruence.com/ -- Reeze Xia http://reeze.cn
[PHP-DEV][RFC][VOTE] Group Use Declarations
Hi internals! Since no new discussion topics appeared, the voting on the Group Use Declarations RFC for PHP7 is now open: RFC: https://wiki.php.net/rfc/group_use_declarations#votes Patch: https://github.com/php/php-src/pull/1005 As requested I've split the vote into two slightly different syntax choices, so be sure to pick the right choice if you are going to vote yes. The voting will close in exactly 14 days counting from now. PS: Aknowledgements to Daniel Ackroyd for reviewing this RFC. Márcio Almada https://github.com/marcioAlmada
RE: [PHP-DEV] [VOTE] Scalar Type Hints
-Original Message- From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] Sent: Wednesday, February 11, 2015 8:37 AM To: Xinchen Hui; Andrea Faulds Cc: PHP Internals Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints On 02/10/2015 07:57 PM, Xinchen Hui wrote: am I wrong?! seems I am wrong with this, it's a false alarm... it can restore automatically. Yeah, declare() doesn't span files so that isn't a problem. My worry is still the lack of type coercion for internal calls. There's also some pretty interesting analysis on this proposal - based on some real world experimentation - from Benjamin Eberlei - bit.ly/1vl0UED If you've voted on this RFC or intend to vote - please spend the few minutes to read through his blog post. It does a good job at actually illustrating what life would look like if this rubber ends up meeting the road. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Fix foreach behavior
Le 05/02/2015 09:49, Dmitry Stogov a écrit : The RFC is turned into voting https://wiki.php.net/rfc/php7_foreach#proposed_voting_choices Hi, After discussing this RFC with other people at AFUP, it seems we are the +1 side, on both propositions. Thanks -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 11 February 2015 06:36:52 GMT, Rasmus Lerdorf ras...@lerdorf.com wrote: And in Drupal8 *without turning on strict*: use Drupal\Component\Utility\String; it dies with: Fatal error: string cannot be used as a class name in /var/www/drupal/core/includes/bootstrap.inc on line 11 That String class is everywhere in Drupal. They are going to have a fun time with that. See https://gist.githubusercontent.com/anonymous/d9252deeeb2aae1a5af5/raw/053155130d22551b1404d0a9b94e27424544b6d1/gistfile1 That could potentially be avoided if scalar types were reserved as some kind of pseudo-class rather than just keywords, because then they would follow namespace resolution rules. Theoretically, you could still have a class Drupal\Component\Utility\String, and \string would be available as a scalar typehint while you were in that namespace. I'm guessing it's not as simple as that, because the compiler needs to distinguish between scalar and classname typehints, but doesn't know what classes exist. In which case, perhaps string as a typehint could always mean \string, and if you want to typehint the class you should always use foo\string? Or you could ban string as a typehint, and require people to type \string. Either seems a little bit magic, though. Theoretically, I guess they ought to be php\string etc, which would accomplish the goal but make them rather unwieldy. It might be worth considering, though, given we know the situation's not just hypothetical. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can we remove NEWS tag ?
Renamed to NEWS-cvs2svn Kaplan On Feb 11, 2015 5:11 PM, Andrea Faulds a...@ajf.me wrote: Hi, On 11 Feb 2015, at 09:52, Lior Kaplan lio...@zend.com wrote: Hi, I've been doing some editing to the NEWS files, and keep getting this problem $ git diff NEWS fatal: ambiguous argument 'NEWS': both revision and filename Use '--' to separate filenames from revisions Although I can do as it suggests, I would prefer to remove the NEWS tag we have since 2008 as part of the move from CVS to SVN. Any objections ? Kaplan I swear this has come up before. Please, remove or rename it, I don't see anyone objecting. -- Andrea Faulds http://ajf.me/
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 11 Feb 2015, at 21:30, Zeev Suraski z...@zend.com wrote: -Original Message- From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] Sent: Wednesday, February 11, 2015 8:37 AM To: Xinchen Hui; Andrea Faulds Cc: PHP Internals Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints On 02/10/2015 07:57 PM, Xinchen Hui wrote: am I wrong?! seems I am wrong with this, it's a false alarm... it can restore automatically. Yeah, declare() doesn't span files so that isn't a problem. My worry is still the lack of type coercion for internal calls. There's also some pretty interesting analysis on this proposal - based on some real world experimentation - from Benjamin Eberlei - bit.ly/1vl0UED I disagree with some aspects of the blogpost: enabling strict mode completly defeats the purpose, because now we are forced to convert manually, reimplementing weak type hinting in our own code This isn’t true at all. The key difference between explicit conversions and implicit conversions is that they’re, well, *explicit*. You can see them, they are blatantly obvious, if you use grep you can find them. Implicit conversions, while they can sometimes be great, happen silently and automatically - if they screw up, it can be hard to track down where the conversion is taking place. With explicit conversions, you’re converting once and you know you’ve converted. With implicit conversions, you have no idea where and how often values are being converted. We write code with casts already, the scalar type hints patch is not necessary for that! Only a superficial level of additional safety is gained, one additional check of something we already know is true! Yet in the previous part he was explaining how existing code doesn’t use casts and would need them added… so therefore, this thing *isn’t* already known to be true, and the blogpost is self-contradictory. strict mode is useless for library developers, because I always have to assume weak mode anyways. I don’t really understand at all… either he doesn’t understand the proposal (which guarantees you get the types you ask for), or it’s a reference to the claim from the previous paragraph, which I’ve already responded to. In a well designed application or library, the developer can already trust the types of his variables today, 95% of the time, without even having type hints, using carefully designed abstractions (example Symfony Forms and Doctrine ORM): No substantial win for her from having strict type hints. Yet he was previously explaining how, actually, data coming in from web requests isn’t the correct types. In a badly designed application, the developer is uncertain about the types of variables. Using strict mode in this scenario she needs to start casting everywhere just to be sure. In an application using strict mode everywhere with scalar type hints everywhere, you can’t possibly be uncertain about the types of variables. … there’s a lot more in that blog post I could disagree with, but I won’t bother. Benjamin has his reasons for not liking strict mode. That’s fine. But if PHP adds strict mode, it has zero effect on him. If you've voted on this RFC or intend to vote - please spend the few minutes to read through his blog post. It does a good job at actually illustrating what life would look like if this rubber ends up meeting the road. Anthony Ferrara also had his own analysis which showed some of the problems with weak type hinting, and where strict types can be beneficial: http://blog.ircmaxell.com/2015/02/scalar-types-and-php.html I would suggest people read that blog post before voting, as well. It points out some real-world examples of where weak typing in PHP can be insufficient (div), or even downright dangerous (curlopt). -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Scalar Type Hints
I said numerous times that I think that v0.1 of Andrea’s RFC was right on the mark. I’d vote in its favor in a heartbeat. It gives the exact same value from an API author’s point of view. It gives the exact same value in terms of potential performance improvements/JITting/compilation insight. But unlike the current RFC, v0.1 doesn’t introduce an IMHO alien concept into a language that considered dynamic typing to be a core principle since its birth. Zeev *From:* guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com] *Sent:* Thursday, February 12, 2015 12:46 AM *To:* Andrea Faulds *Cc:* Zeev Suraski; Rasmus Lerdorf; PHP Internals *Subject:* Re: [PHP-DEV] [VOTE] Scalar Type Hints Hi all, @Zeev and @Rasmus: Seriously, you both mentioned that consider the idea of scalar type hint, but I've never seen which idea would you consider. Andrea built a very flexible way to operate and even though I don't fully agree either, it's the best so far. This approach does have headaches, but would you ever consider a strict or weak only approach?
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 11/02/15 21:46, Andrea Faulds wrote: Anthony Ferrara also had his own analysis which showed some of the problems with weak type hinting, and where strict types can be beneficial: http://blog.ircmaxell.com/2015/02/scalar-types-and-php.html What is the point of using a 'Better static analyzer' when the bulk of the material being worked with simply can't be processed 'statically'? The only result of this passing that I can see is that PHP will start to develop two completely different code bases. Anthony closes by saying that is EXACTLY what he will do ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
On Wed, Feb 11, 2015 at 5:16 PM, Michael Wallner m...@php.net wrote: On 06/02/15 17:44, Daniel Lowrey wrote: If you doubt that this is a solved problem in userland consider the performance of my own 100% userland HTTP client demonstrated here without the use of curl or any other extensions: https://gist.github.com/rdlowrey/54171625334670ccb9f5 I can replicate about 2.5s with artax/master on http://example.org, which is about the same pace like pecl_http. With pipelining enabled pecl_http/master peeks at about 0.7s, but what's the point? PS: I'm on an advertised 150/15 Mbit connection. -- Regards, Mike The point isn't *zomg this one thing I did in userland is super fast.* It's irrelevant. The point here is that HTTP transfers are an IO-bound operation and as such the benefit from compiling them is relatively small. Add that to the fact that we already have tools to do exactly this in the standard distribution (curl) and well-known, well-tested userland tools for any use-case you can imagine. In my opinion that adds up to not needing another way to do the same thing in the standard distribution. Who benefits from bundling another HTTP client? Why bring in two additional pecl dependencies for HTTP connections which *rarely* make sense to persist across web SAPI requests? Is there a plan to also deprecate ext/curl? These are questions that aren't resolved in a satisfactory way as far as I'm concerned. I honestly don't care that much, I just don't think because we can necessarily means we should when there's no obvious need for more of the same overlapping functionality. That's what pecl is for, right?
Fwd: [PHP-DEV] [VOTE] Scalar Type Hints
Forarding again, was rejected by the list because of spammy links :(
-- Forwarded message --
From: Benjamin Eberlei kont...@beberlei.de
Date: Thu, Feb 12, 2015 at 12:59 AM
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
To: Andrea Faulds a...@ajf.me
Cc: Zeev Suraski z...@zend.com, Rasmus Lerdorf ras...@lerdorf.com, PHP
Internals internals@lists.php.net
On Wed, Feb 11, 2015 at 10:46 PM, Andrea Faulds a...@ajf.me wrote:
On 11 Feb 2015, at 21:30, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
Sent: Wednesday, February 11, 2015 8:37 AM
To: Xinchen Hui; Andrea Faulds
Cc: PHP Internals
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 02/10/2015 07:57 PM, Xinchen Hui wrote:
am I wrong?!
seems I am wrong with this, it's a false alarm... it can restore
automatically.
Yeah, declare() doesn't span files so that isn't a problem.
My worry is still the lack of type coercion for internal calls.
There's also some pretty interesting analysis on this proposal - based on
some real world experimentation - from Benjamin Eberlei
I disagree with some aspects of the blogpost:
enabling strict mode completly defeats the purpose, because now we are
forced to convert manually, reimplementing weak type hinting in our own code
This isn’t true at all. The key difference between explicit conversions
and implicit conversions is that they’re, well, *explicit*. You can see
them, they are blatantly obvious, if you use grep you can find them.
Implicit conversions, while they can sometimes be great, happen silently
and automatically - if they screw up, it can be hard to track down where
the conversion is taking place. With explicit conversions, you’re
converting once and you know you’ve converted. With implicit conversions,
you have no idea where and how often values are being converted.
I agree with the benefits of strict typing and how they are explicit. I
even like programming in strict languages a lot.
But the default way to achieve this is in PHP is to add casts, and they
are done with the weak rules:
strict_func((int)$string); avoids the purpose of strict typing. And that
will probably be the most used way to get strict type compatibility.
Yes, i am probably using it wrong here, but features are not always used
the right way, most of the time they are not.
It got mentoined to me several times that a fix would actually be to have
$request-getInteger('status'); - i will add that to the post later. This
will actually improve the code, but as i mentoined in my post, someone with
a good abstraction for type juggling is already there today.
We write code with casts already, the scalar type hints patch is not
necessary for that! Only a superficial level of additional safety is
gained, one additional check of something we already know is true!
Yet in the previous part he was explaining how existing code doesn’t use
casts and would need them added… so therefore, this thing *isn’t* already
known to be true, and the blogpost is self-contradictory.
You got me there, but the code i showed doesnt actually need strict or
weak types. I use casting in PHP liberaly, as probably many others as well.
If i think I need it, I use it.
strict mode is useless for library developers, because I always have to
assume weak mode anyways.
I don’t really understand at all… either he doesn’t understand the
proposal (which guarantees you get the types you ask for), or it’s a
reference to the claim from the previous paragraph, which I’ve already
responded to.
I understand the proposal. As a library author i would use type hints to
help my users make the right input values, recieve the right return values.
But except when I have highly critical code that requires the right types
at all steps, but most of the time inside my library weak type hints would
a.) not step me in the way so much b.) still work out correctly all the
time.
In a well designed application or library, the developer can already
trust the types of his variables today, 95% of the time, without even
having type hints, using carefully designed abstractions (example Symfony
Forms and Doctrine ORM): No substantial win for her from having strict type
hints.
Yet he was previously explaining how, actually, data coming in from web
requests isn’t the correct types.
Well that example didn't show Symfony Forms nor Doctrine. I could show them
in the blog post, but since they cast all the request + db already, there
wouldn't be much to show. As the blog post says, this kind of code already
provides a lot of trust even without any kind of type hints.
In a badly designed application, the developer is uncertain about the
types of variables. Using strict mode in this scenario she needs to start
casting everywhere just to be sure.
In an application using strict mode everywhere with scalar type hints
everywhere, you can’t possibly
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 11 February 2015 22:41:21 GMT, Lester Caine les...@lsces.co.uk wrote: On 11/02/15 21:46, Andrea Faulds wrote: Anthony Ferrara also had his own analysis which showed some of the problems with weak type hinting, and where strict types can be beneficial: http://blog.ircmaxell.com/2015/02/scalar-types-and-php.html What is the point of using a 'Better static analyzer' when the bulk of the material being worked with simply can't be processed 'statically'? The only result of this passing that I can see is that PHP will start to develop two completely different code bases. Anthony closes by saying that is EXACTLY what he will do ... No, he closes by saying he will use the feature differently in different parts of one code base. Indeed, he makes a specific point about the advantage of having a weakly typed file and a strictly typed file working together. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hey Guilherme, On 11 Feb 2015, at 22:46, guilhermebla...@gmail.com wrote: @Andrea: I spent around 2-3 hours speaking with Anthony and the other half talking to Jordi (Composer, Symfony). I still think a few things are required to be fully usable. 1- Exceptions RFC (outside of your scope, but making the code under strict type impossible to recover in a library) Yeah, I agree that this is quite important. This could actually be fixed without exceptions (make type hint error skip the function call?), but they’re a nicer way to do it (possibly simpler within the engine?). 2- Lack of numeric scalar type There're others, but these ones are keys to make them fully usable. A number (or numeric, or num, or some other name) type hint is something I plan to propose in a future, follow-up RFC. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
On 06/02/15 17:44, Daniel Lowrey wrote: If you doubt that this is a solved problem in userland consider the performance of my own 100% userland HTTP client demonstrated here without the use of curl or any other extensions: https://gist.github.com/rdlowrey/54171625334670ccb9f5 I can replicate about 2.5s with artax/master on http://example.org, which is about the same pace like pecl_http. With pipelining enabled pecl_http/master peeks at about 0.7s, but what's the point? PS: I'm on an advertised 150/15 Mbit connection. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC][VOTE] Group Use Declarations
Hi Marcio, On 11 February 2015 at 20:50, Marcio Almada marcio.w...@gmail.com wrote: Hi internals! Since no new discussion topics appeared, the voting on the Group Use Declarations RFC for PHP7 is now open: RFC: https://wiki.php.net/rfc/group_use_declarations#votes Patch: https://github.com/php/php-src/pull/1005 I like the idea (reducing the repeated namespace parts), but am not too keen on the syntax. If I may offer a hastily thought out, and probably terrible, idea... how about something like from prefix use ... ? To adapt an example from the RFC: from Symfony\Component\Console\Question use ConfirmationQuestion, ChoiceQuestion as Choice, OptionQuestion, Question; That's my two cents. Best of luck! As requested I've split the vote into two slightly different syntax choices, so be sure to pick the right choice if you are going to vote yes. The voting will close in exactly 14 days counting from now. PS: Aknowledgements to Daniel Ackroyd for reviewing this RFC. Márcio Almada https://github.com/marcioAlmada
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi, 2015-02-12 0:08 GMT+01:00 Zeev Suraski z...@zend.com: It gives the exact same value from an API author’s point of view. But not from an api-consumers point of view. Without either introducing a new set of casting/conversion rules or changing existing behavior (**exclusively**) 'weak' typehints may be perceived as seriously crippled. Maybe up to a point where the addition of them wouldn't be justified. But unlike the current RFC, v0.1 doesn’t introduce an IMHO alien concept into a language that considered dynamic typing to be a core principle since its birth. It's not. PHP was always open to enforce strict typing in user created functions. If types didn't matter the way they do the current distinguishing between int/float or respectively array/stdClass/Objects shouldn't exist. But thankfully they are distinctive. The proposal offers a way to conditionally harmonize different usage patterns. (Across code bases and with internal functions) Having the ability to conditionally tighten rules in self written code but falling back to loose (in many cases good, in other cases disastrous) behavior is what modern PHP defines. To much new code already enforces strict types. Using if(!is_int) throw new WrongArgumentTypeException() or similar. The proposed RFC could unify such codebases. Having typehints in the proposed form would allow the api creator to drop most additional type checks as the method always receives what was asked for and shifts responsibility to the user. The way how an API is used would be determined by the user, allowing them to continue to use the weak behavior if they want but also offer them to enforce the rules that otherwise the api creator might force on everyone. Why don't you want to allow people to use (formerly your) language in the way they see fit as you have already given them the broader framework do to so. Having optional strict hints together with the performance improvements and the maturing php ecosystem (composer/fig/co. + enterprise-targeting frameworks) may even attract new users to php that don't want or require the mental burden or the ecosystem given by other languages(java,c#) but don't want to miss the additional safety and feeling of strict types. The other options (globally changing zpp rules and the behavior of implicit casts) sharing most of the advantages implied in the current proposal was already proposed as RFC and talked down as the BC break was considered to big. The concept behind the current RFC (not so much the syntax) is the only way to satisfy both camps without alienating a large part of the community. I'd even argue that weak hints alone wouldn't be able to reach a 2/3 majority as strict supporters (Over 1/3rd of what I've seen on this list) would need be afraid that their preference would never reach the required majority once weak hints are in. It's this proposal, semi-strict hints or changed conversion rules (The alternatives would either introduce yet another set of unconditional rules or require a considerable BC break as noted above). Everything else will either not reach the required majority or will alienate potentially large parts of the user land community (Which aren't necessarily known to the oss community, zend or similar). Thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC][VOTE] Group Use Declarations
Hi Peter, I like the idea (reducing the repeated namespace parts), but am not too keen on the syntax. If I may offer a hastily thought out, and probably terrible, idea... how about something like from prefix use ... ? [...] That's my two cents. Some people suggested the *from* ... *use *... syntax similar to Python, but this proposal would require the from keyword to be reserved. Also, during research phase most people preferred the block syntax similar to the trait conflict resolution syntax. So, in resume the current proposal seems the most appropriate for PHP because: 1. It looks a lot like the already implemented traits conflict resolution 2. It doesn't require to reserve new keywords 3. It's a very readable choice 4. During research phase it became clear that most people preferred it over the alternatives (including your suggestion) Best of luck! Thank you! Sincerely, Márcio Almada
Re: [PHP-DEV] Annotated PHP 5-7 extension diff
On Thu, Feb 12, 2015 at 10:05 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Wed, Feb 11, 2015 at 3:51 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Wed, Feb 11, 2015 at 3:27 PM, Xinchen Hui larue...@php.net wrote: The fails must be know... relates to key name checking the leaks needs to be take care, I will look into it. anyway, these should not affects your work, I think so. I'll start working :) Since my system isn't busy at all, there would be something wrong. Memcached is vanilla package from Fedora 21 without any turning. PHP/Apache are debug build. Anyway, current figure is lazy_write=On: Requests per second:2218.55 [#/sec] (mean) lazy_write=Off: Requests per second:24.58 [#/sec] (mean) I feel...that might be something wrong : thanks Session has rather large about 100KB data for benchmark purpose. I'll test a little more and send PR later. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
Hi Yasuo, Yasuo Ohgaki wrote: Hi Christoph, On Wed, Feb 11, 2015 at 10:45 AM, Christoph Becker cmbecke...@gmx.de wrote: We have been tried to educate users already and introduced some mitigations e.g. allow_url_include, open_basedir. However, enough time is passed to prove that wasn't enough, isn't it? PHP (many and these are _only_ few of them in the wild) http://www.exploit-db.com/search/?action=searchfilter_page=1filter_description=PHPfilter_author=filter_platform=0filter_type=0filter_lang_id=0filter_exploit_text=inclusionfilter_port=0filter_osvdb=filter_cve= I've arbitrarily checked the top most entry (u5CMS), and the LFI was caused by `echo file_get_contents($_GET['...'])` basically. There was neither include|require(_once) involved, nor move_uploaded_file(). From my, admittedly very limited, experience, this is a rather common source of LFI vulnerabilities in PHP applications. I'm afraid that educating developers is the only way to avoid this kind of vulnerability. It's not my point. These are only surface of them as you can see it contains only open source project's vulnerabilities. Script inclusion is common by evidence, unlike others. If you mean unlike other languages, I tend to agree. However, I'm still afraid that script inclusion vulnerabilities are *way* less common than vulnerabilities due to *reading* and *displaying* (*not* *executing*) arbitrary files in PHP applications. This is what I'm trying to change. Are PHP programmers are worse than others? I don't think they are. Certainly, there are many fine PHP programmers, but also there are many PHP programmers who are not sufficently educated with regard to security (I might still be part of the latter group). Regards, Regards, -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotated PHP 5-7 extension diff
Hi all, On Wed, Feb 11, 2015 at 3:51 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Wed, Feb 11, 2015 at 3:27 PM, Xinchen Hui larue...@php.net wrote: The fails must be know... relates to key name checking the leaks needs to be take care, I will look into it. anyway, these should not affects your work, I think so. I'll start working :) Since my system isn't busy at all, there would be something wrong. Memcached is vanilla package from Fedora 21 without any turning. PHP/Apache are debug build. Anyway, current figure is lazy_write=On: Requests per second:2218.55 [#/sec] (mean) lazy_write=Off: Requests per second:24.58 [#/sec] (mean) Session has rather large about 100KB data for benchmark purpose. I'll test a little more and send PR later. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
Hi Stas, On Thu, Feb 12, 2015 at 3:21 AM, Stanislav Malyshev smalys...@gmail.com wrote: I'm not trying to be perfect, but I would like to make PHP as secure as other languages from script inclusion attacks. It's too easy currently... PHP is already as secure as the other languages. If you have code in Python that loads arbitrary file and executes it, you could upload Python file and execute it. If you have code in Ruby that loads arbitrary file and executes it, you could upload Ruby file and execute it. If you have code in C that... you get the idea. Same with PHP. Python loads script like import foo where foo is foo.py. Ruby loads script like require 'foo' where foo is foo.rb. This is the origin of the difference. We may have something like this. We may check registered filename extension(s) or may allow to omit registered extension(s). We may take some benchmarks and decide, since these 2 are the same basically. Faster is better, but I guess checking is faster. What do you think? Comments are appreciated. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
[PHP-DEV] Re: Proposal: Introduce a new macro:php_error_docref_ex()
Hi,
On 12 February 2015 at 15:30, Dmitry Stogov dmi...@zend.com wrote:
We don't use macros with variable number of arguments in PHP.
this is not portable.
We could don't have to use variadic macros, we could try something like:
*+PHPAPI void php_error_doc0(int type, const char *format, ...)*
*+{*
*+* *va_list args;*
*+*
*+* *va_start(args, format);*
*+* *php_error_docref0(NULL, type, format, args);*
*+* *va_end(args);*
*+}*
*+*
*+#define php_error_doc php_error_doc0*
*+*
Thanks. Dmitry.
On Wed, Feb 11, 2015 at 6:01 PM, reeze re...@php.net wrote:
Hi,
On 11 February 2015 at 19:15, Dmitry Stogov dmi...@zend.com wrote:
Hi,
I don't think it'll improve something, and may complicate merging from
PHP5 (this is not a big issue, because merging is already not simple).
Yes it just makes code looks a little better and cleaner.
I didn't realized the merging problem. that might affect diffs which
changes php_error_docref()
In any case, the names should be swapped, to be used as:
php_error_docref(E_WARNING, recursion detected);
or
php_error_docref_ex(NULL, E_WARNING, recursion detected);
Yes I prefer this too.
But considering the merging problem, I think I should hold this idea of
update all of those calls.
We may provider a simple version with default null docref for external
extesions, but I didn't have proper name for that.
also macros with __VA_ARGS__ may be not portable, s it should be
implemented differently.
Yes I should use ##__VA_ARGS__ instead.
Thanks. Dmitry.
On Wed, Feb 11, 2015 at 11:41 AM, Xinchen Hui larue...@php.net wrote:
Hey:
On Wed, Feb 11, 2015 at 4:35 PM, Yasuo Ohgaki yohg...@ohgaki.net
wrote:
Hi all,
On Wed, Feb 11, 2015 at 5:21 PM, reeze re...@php.net wrote:
I think it is a cleanup, it works but there are too many
duplication. it
is the time to make the code clean and easier to understand.
I've never used other than NULL also.
Everyone is going to remove TSRM macros, it's right time to clean up.
fine, if you want to change..
please, _ex means extending,
so the name should not be php_error_docref_ex...
thanks
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
Reeze Xia
http://reeze.cn
--
Reeze Xia
http://reeze.cn
Re: [PHP-DEV] Annotated PHP 5-7 extension diff
Hey:
On Thu, Feb 12, 2015 at 1:35 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Xinchen,
On Thu, Feb 12, 2015 at 12:37 PM, Xinchen Hui larue...@php.net wrote:
lazy_write=On: Requests per second:2218.55 [#/sec] (mean)
lazy_write=Off: Requests per second:24.58 [#/sec] (mean)
I feel...that might be something wrong :
I do think so. It's Core i7 with 32GB memory and SSD. It did not use
much CPU and network bandwidth during benchmark. I'll wait your fix
(seems unrelated, though) and look into what's wrong. I cannot take
Memcached::setMultiByKey()
[ext/memcached/tests/experimental/setmulti_bykey.phpt]
Memcached::setMulti() [ext/memcached/tests/setmulti.phpt]
are fixed. the other one seems in libmemcached side(get_udp.phpt)
realistic benchmark because of this. I might try it on older machines :(
If you could take simple session benchmark, number of request / second,
it would be helpful for me to know my system's health.
hmm, I will try later
thanks
session.php
?php
//ini_set('session.save_path', '/home/tmp');
ini_set('session.save_path', 'PERSISTENT=1 127.0.0.1:11211');
ini_set('session.save_handler', 'memcached');
ini_set('session.lazy_write', 1);
ini_set('session.use_strict_mode', 0);
session_id('testid2');
session_start();
//$_SESSION['test'] = ++$_SESSION['test'];
$_SESSION['a'] = str_repeat('a', 102400);
echo 'pre';
var_dump(session_id(), ini_get('session.save_handler'), $_SESSION['test']);
?
I get about 15K Reqs/sec for files handler with debug build.
Regards.
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
Hi, On Wed, Feb 11, 2015 at 10:05 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! That one actually looks better to me, but: I'm not sure how annotation syntax is supposed to support expressions or closures, keep AST. So we'd have a zval type that is the raw AST? Would it also be available to user functions or internal functions/classes? It's an intriguing concept but I'm not sure we appreciate all the consequences of it - adding new type is a rather big change as everything should support it. Or did you mean something else? This is just an initial idea, and some research is required. I don't propose to add new ZVAL type. AST may be just stored internally and accesses through extended Reflection API. This API may provide some classes to represent AST nodes. Is it some special form of annotation for this purpose only (meh)? yes. some special attributes. requires/ensures/invariant Ah, so require() annotation would work different than any other type of annotation? Then I don't see any use for it to use annotation syntax (whatever it would be) - same syntax should mean same or at least similar function. Maybe I am still missing what you meant. I don't understand you as well. It should be clear, that annotation should allow declaration of any attributes, and some of them may be used for different purposes. some for DbC. Oh, and syntax is *ugly* ;) It's from HHVM. I don't like it as well, please, propose the better one. Pretty much every other one is better: Java and the followers, Python: @foo C#: [foo] [foo] is already a legal syntax in PHP - array with constant foo. Thanks. Dmitry. -- Stas Malyshev smalys...@gmail.com
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On Thu, Feb 12, 2015 at 1:13 AM, Andrea Faulds a...@ajf.me wrote: A number (or numeric, or num, or some other name) type hint is something I plan to propose in a future, follow-up RFC. Hello, wouldn't polymorphism (via method overloading) solve the use cases and be much more useful in the long run than introducing a something that's not a type into type hints? Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
On Tue, 10 Feb 2015, Yasuo Ohgaki wrote: Hi all, Some of you are tired with this topic, but please take a look the RFC [RFC] Script only includes - this is 3rd version. https://wiki.php.net/rfc/script_only_include Please let me know what you like or dislike. Con: - It introduces an INI option that changes PHP's behaviour. - How do you know what is a PHP script? Surely not be checking that the first 4 chars are ?php ? cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
On Wed, 11 Feb 2015, Yasuo Ohgaki wrote: Hi Markus, On Tue, Feb 10, 2015 at 5:59 PM, Markus Fischer mar...@fischer.name wrote: What constitutes first token in this context? Would this be detected as a PHP file? -8 root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin ?php phpinfo(); -8 Yes. Since we have custom script loader, file content cannot be used for pure PHP script detection. However, parser can detect if it's a pure PHP script. i.e. Detect ?php token at first, no ? in the file. That's arbitrary. The ? at the end of a file is not an error (or a mistake). cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Can we remove NEWS tag ?
Hi, I've been doing some editing to the NEWS files, and keep getting this problem $ git diff NEWS fatal: ambiguous argument 'NEWS': both revision and filename Use '--' to separate filenames from revisions Although I can do as it suggests, I would prefer to remove the NEWS tag we have since 2008 as part of the move from CVS to SVN. Any objections ? Kaplan
Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
On 11/02/15 09:34, Derick Rethans wrote: Some of you are tired with this topic, but please take a look the RFC [RFC] Script only includes - this is 3rd version. https://wiki.php.net/rfc/script_only_include Please let me know what you like or dislike. Con: - It introduces an INI option that changes PHP's behaviour. - How do you know what is a PHP script? Surely not be checking that the first 4 chars are ?php ? First 5? ... Yasuo ... I don't think this is going in the right direction. The principals are right, but we have been through a lot of this trying to secure included files in the past and nothing has worked yet. I don't think that anything implemented in a PHP distribution will change what is happening in practice? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 09/02/2015 22:29, Anatol Belski wrote: ext/imap ext/mcrypt ext/pdo_dblib Sorry if this was suggested already but if those are not maintained much and should not be used further ideally, shouldn't we add E_DEPRECATED to them at least? I understand that they are kept to avoid making the upgrade path harsher, but it's also not great to let they linger on forever with no notice to users that they are doing something wrong. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
Hi Joe, On Wed, Feb 11, 2015 at 4:54 PM, Joe Watkins pthre...@pthreads.org wrote: So it turns out that invariant is already deprecated in D, they have dropped it in favour of immutable properties. I guess I'll have to install an old version, or try to extract everything we need from their obviously outdated documentation ... That's too bad. Eiffel uses invariant. https://docs.eiffel.com/book/method/et-design-contract-tm-assertions-and-exceptions Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
[PHP-DEV] Proposal: Introduce a new macro:php_error_docref_ex()
Hi all, There are a lot of code use php_error_docref() macro, the first parameter mostly is NULL, before PHP7, it looks like: *php_error_docref(NULL TSRML, E_WARNING, recursion detected);* in PHP7 *php_error_docref(NULL, E_WARNING, recursion detected);* looks better, but the first parameter look dumb. I did a simple statics, there are: Null docref: 2530 Not Null docref: 51 I searched on Github, it seems that almost all of the extension use NULL docref. So I propose add a new macro, like: php_error_error_docref_ex(E_WARNING, xxx). this could make code looks better and the extension maintainer's easier. Another option would be just update the php_error_docref() macro to remove the docref parameter, default to NULL but not add a new macro. What do you think about it? [1] https://github.com/php/php-src/pull/1075 -- Reeze Xia http://reeze.cn
Re: [PHP-DEV] Design by Contract
Just a thought - what about something like __pre/__post? We own __*, so
no BC problems.
I'm not married to the words being used, at all.
I think this is a good idea, we would need __pre, __post , and __invariant,
or some combination of three.
Any objection to using __ prefixed names, and any other suggestion for
them, or just use the above ?
Cheers
Joe
On Wed, Feb 11, 2015 at 8:09 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
function foo($a)
require($a = 0)
{
}
This is a step better but still we have the similar issues with
readability, to which reuse of 'require' is added.
Just a thought - what about something like __pre/__post? We own __*, so
no BC problems.
OTOH, don't our new parsing improvements allow us to handle syntax like
this without introducing a keyword that would be forbidden as
class/function name? The context is pretty unambiguous here.
--
Stas Malyshev
smalys...@gmail.com
[PHP-DEV] Re: Proposal: Introduce a new macro:php_error_docref_ex()
PS: Github search result: https://github.com/search?l=cq=php_error_docrefref=searchresultstype=Codeutf8=%E2%9C%93 It seems that no one need the docref at all. On 11 February 2015 at 16:07, reeze re...@php.net wrote: Hi all, There are a lot of code use php_error_docref() macro, the first parameter mostly is NULL, before PHP7, it looks like: *php_error_docref(NULL TSRML, E_WARNING, recursion detected);* in PHP7 *php_error_docref(NULL, E_WARNING, recursion detected);* looks better, but the first parameter look dumb. I did a simple statics, there are: Null docref: 2530 Not Null docref: 51 I searched on Github, it seems that almost all of the extension use NULL docref. So I propose add a new macro, like: php_error_error_docref_ex(E_WARNING, xxx). this could make code looks better and the extension maintainer's easier. Another option would be just update the php_error_docref() macro to remove the docref parameter, default to NULL but not add a new macro. What do you think about it? [1] https://github.com/php/php-src/pull/1075 -- Reeze Xia http://reeze.cn -- Reeze Xia http://reeze.cn
[PHP-DEV] Re: Proposal: Introduce a new macro:php_error_docref_ex()
On Wed, Feb 11, 2015 at 4:07 PM, reeze re...@php.net wrote: Hi all, There are a lot of code use php_error_docref() macro, the first parameter mostly is NULL, before PHP7, it looks like: php_error_docref(NULL TSRML, E_WARNING, recursion detected); in PHP7 php_error_docref(NULL, E_WARNING, recursion detected); looks better, but the first parameter look dumb. I did a simple statics, there are: Null docref: 2530 Not Null docref: 51 I searched on Github, it seems that almost all of the extension use NULL docref. So I propose add a new macro, like: php_error_error_docref_ex(E_WARNING, xxx). this could make code looks better and the extension maintainer's easier. Another option would be just update the php_error_docref() macro to remove the docref parameter, default to NULL but not add a new macro. What do you think about it? No. I can't see any benefit from it, but lots of changes. everything works well now. thanks [1] https://github.com/php/php-src/pull/1075 -- Reeze Xia http://reeze.cn -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Proposal: Introduce a new macro:php_error_docref_ex()
I think it is a cleanup, it works but there are too many duplication. it is the time to make the code clean and easier to understand. I myself don't know why should I need the first NULL when I am a newcomer of writing extensions, it just seems everyone do that, before PHP7 there is a strange TSRML_CC macro, it is hard to maintain. On 11 February 2015 at 16:16, Xinchen Hui larue...@php.net wrote: On Wed, Feb 11, 2015 at 4:07 PM, reeze re...@php.net wrote: Hi all, There are a lot of code use php_error_docref() macro, the first parameter mostly is NULL, before PHP7, it looks like: php_error_docref(NULL TSRML, E_WARNING, recursion detected); in PHP7 php_error_docref(NULL, E_WARNING, recursion detected); looks better, but the first parameter look dumb. I did a simple statics, there are: Null docref: 2530 Not Null docref: 51 I searched on Github, it seems that almost all of the extension use NULL docref. So I propose add a new macro, like: php_error_error_docref_ex(E_WARNING, xxx). this could make code looks better and the extension maintainer's easier. Another option would be just update the php_error_docref() macro to remove the docref parameter, default to NULL but not add a new macro. What do you think about it? No. I can't see any benefit from it, but lots of changes. everything works well now. thanks [1] https://github.com/php/php-src/pull/1075 -- Reeze Xia http://reeze.cn -- Xinchen Hui @Laruence http://www.laruence.com/ -- Reeze Xia http://reeze.cn
[PHP-DEV] Re: Proposal: Introduce a new macro:php_error_docref_ex()
Hi all, On Wed, Feb 11, 2015 at 5:21 PM, reeze re...@php.net wrote: I think it is a cleanup, it works but there are too many duplication. it is the time to make the code clean and easier to understand. I've never used other than NULL also. Everyone is going to remove TSRM macros, it's right time to clean up. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Design by Contract
OTOH, don't our new parsing improvements allow us to handle syntax like
this without introducing a keyword that would be forbidden as
class/function name
Not that I am aware of, the AST stuff didn't touch the parser like that, it
has the same limitations it had before AFAIK.
Cheers
Joe
On Wed, Feb 11, 2015 at 8:12 AM, Joe Watkins pthre...@pthreads.org wrote:
Just a thought - what about something like __pre/__post? We own __*, so
no BC problems.
I'm not married to the words being used, at all.
I think this is a good idea, we would need __pre, __post , and
__invariant, or some combination of three.
Any objection to using __ prefixed names, and any other suggestion for
them, or just use the above ?
Cheers
Joe
On Wed, Feb 11, 2015 at 8:09 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
function foo($a)
require($a = 0)
{
}
This is a step better but still we have the similar issues with
readability, to which reuse of 'require' is added.
Just a thought - what about something like __pre/__post? We own __*, so
no BC problems.
OTOH, don't our new parsing improvements allow us to handle syntax like
this without introducing a keyword that would be forbidden as
class/function name? The context is pretty unambiguous here.
--
Stas Malyshev
smalys...@gmail.com
Re: [PHP-DEV] Design by Contract
http://dlang.org/deprecate.html#invariant as an alias for immutable It's not an alias, the most recent compiler emits an error if you try to use invariant contracts, and immutable isn't a kind of contract. immutable is a property modifier: immutable: http://dpaste.dzfl.pl/7e724b599640 invariant (won't compile using latest release): http://dpaste.dzfl.pl/102c5c5adef5 Isn't invariant good enough? Good enough for us, yeah. Cheers Joe On Wed, Feb 11, 2015 at 8:18 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Joe, On Wed, Feb 11, 2015 at 5:02 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Wed, Feb 11, 2015 at 4:54 PM, Joe Watkins pthre...@pthreads.org wrote: So it turns out that invariant is already deprecated in D, they have dropped it in favour of immutable properties. I guess I'll have to install an old version, or try to extract everything we need from their obviously outdated documentation ... That's too bad. Eiffel uses invariant. https://docs.eiffel.com/book/method/et-design-contract-tm-assertions-and-exceptions http://dlang.org/deprecate.html#invariant as an alias for immutable I think D folks would like to be more strict. Object is great, but state management can be complex. I like immutable also since it prevents modification by mistake. I'm not sure if we should go for it without having invariant. Even if we have invariant, we may have immutable object/scalar in the future. Both are good. Isn't invariant good enough? I don't think Eiffel will drop invariant support in favor of immutables. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Design by Contract
Stanislav Malyshev wrote in message news:54dafd32.3000...@gmail.com... Hi! Please steer clear of using the assert API, and in so doing avoid BC concerns with the current assert API. The operator can be called something other than assert, I'm sure the thesaurus has a lot of possibilities. How about pre_assert and post_assert? As Dbc is supposed to be about defining preconditions and postconditions the use of the word pre and post would seem appropriate. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
On 11/02/15 07:58, Stanislav Malyshev wrote: We've spent several years rejecting annotations because no information can be in comments, not even a little bit, not even a tiny. I find that a strange comment, since I've been using annotation in PHP from day one. The phpdoc material helped me get started all those years ago since every third party library had it as part of their coding style from PHP4 days. All of the current demands ... and I think they are demands! ... stamp on past history and load even more work on everybody to have to support all these new features. Even if dbc is wrapped in comment blocks to hide it it's potential presence in third party parts of a project means that all tools have to be modified and my use of phpdoc is further eroded. I see all these comments about 'D' and 'Effiel' and my ONLY thought is ... Then bloody use that! ... Even the people demanding strict typing! DbC does not have to modify the core code to be usable by those wanting it. In the same way that phpdoc has never needed that. BUT a means of expanding the /* */ wrapper to include extra types over the /** tag may be appropriate, then people can use their own preferred annotation system, and other tools can simply 'switch off' where appropriate. While I don't feel 'compiling' is the right way forward for PHP projects, the 'min' processing of files as applied to just about every other scripting element does make sense as a half way house to opcode caching. ( and some help with actually fixing php7 in code would be appreciated! ) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
Hi!
function foo($a)
require($a = 0)
{
}
This is a step better but still we have the similar issues with
readability, to which reuse of 'require' is added.
Just a thought - what about something like __pre/__post? We own __*, so
no BC problems.
OTOH, don't our new parsing improvements allow us to handle syntax like
this without introducing a keyword that would be forbidden as
class/function name? The context is pretty unambiguous here.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
Hi Joe, On Wed, Feb 11, 2015 at 5:02 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Wed, Feb 11, 2015 at 4:54 PM, Joe Watkins pthre...@pthreads.org wrote: So it turns out that invariant is already deprecated in D, they have dropped it in favour of immutable properties. I guess I'll have to install an old version, or try to extract everything we need from their obviously outdated documentation ... That's too bad. Eiffel uses invariant. https://docs.eiffel.com/book/method/et-design-contract-tm-assertions-and-exceptions http://dlang.org/deprecate.html#invariant as an alias for immutable I think D folks would like to be more strict. Object is great, but state management can be complex. I like immutable also since it prevents modification by mistake. I'm not sure if we should go for it without having invariant. Even if we have invariant, we may have immutable object/scalar in the future. Both are good. Isn't invariant good enough? I don't think Eiffel will drop invariant support in favor of immutables. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 11 Feb 2015 09:38, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 02/10/2015 07:57 PM, Xinchen Hui wrote:
am I wrong?!
seems I am wrong with this, it's a false alarm... it can restore
automatically.
Yeah, declare() doesn't span files so that isn't a problem.
My worry is still the lack of type coercion for internal calls. I tested
it on some apps and it will take quite a bit of tedious and rather
useless effort to fix these to run in strict mode. Some examples of
common things that are fatal errors in strict mode:
ini_set('precision', 14);
ini_set('display_errors', 1);
ini_set('display_errors', true);
ok, not common, but tan(4/2) fatal, tan(5/2) no error
Wordpress has this function, spot the error:
function add_magic_quotes( $array ) {
foreach ( (array) $array as $k = $v ) {
if ( is_array( $v ) ) {
$array[$k] = add_magic_quotes( $v );
} else {
$array[$k] = addslashes( $v );
}
}
return $array;
}
$v may not always be a string (it died with a float for me), so the
fix is to cast:
$array[$k] = addslashes( (string)$v );
Also from Wordpress:
$formatted = number_format( $number, absint( $decimals ),
$wp_locale-number_format['decimal_point'],
$wp_locale-number_format['thousands_sep'] );
Here number_format() is expecting a float but $number is a string. So
again, the only real fix is to cast.
And in Drupal8 *without turning on strict*:
use Drupal\Component\Utility\String;
it dies with: Fatal error: string cannot be used as a class name in
/var/www/drupal/core/includes/bootstrap.inc on line 11
That String class is everywhere in Drupal. They are going to have a
fun time with that. See
https://gist.githubusercontent.com/anonymous/d9252deeeb2aae1a5af5/raw/053155130d22551b1404d0a9b94e27424544b6d1/gistfile1
From Geeklog:
if (strtolower($topic) != strtolower($archivetid)) {
$sql .= AND ta.tid != '{$archivetid}' ;
}
$topic can be null there. Looking at the logic, not really a bug,
just a natural reliance on null being coerced to
Also from Geeklog:
if( empty( $date )) {
// Date is empty, get current date/time
$stamp = time();
} else if( is_numeric( $date )) {
// This is a timestamp
$stamp = $date;
} else {
// This is a string representation of a date/time
$stamp = strtotime( $date );
}
// Format the date
$date = strftime( $dateformat, $stamp );
strftime() expects an integer for the timestamp there, but as the
above logic shows, they are expecting a numeric string to be fine.
No bug, just another forced cast.
And another number_format() instance where arg1 is not necessarily
a float. Obviously not a bug, so we have to cast again:
return number_format( $number, $dc, $ds, $ts );
In Opencart:
$this-image = imagecreatetruecolor($width, $height);
imagecreatetruecolor() expects parameter 1 to be integer, string
given in /var/www/opencart/system/library/image.php on line 89
You could argue this is a bug, I guess, but the width and height are
coming from a database and are integers in the db, but since the db
returns strings. Another cast...
I was genuinely hoping to find some bugs with this exercise. I suppose
it is because I did it on mature projects and at this stage those sorts
of bugs have already been fixed. But I still fear that people are going
to want to be enable strictness everywhere and then they will quickly
learn that they better cast stuff to be safe which makes the whole thing
rather pointless. And I feel pretty sorry for the Drupal folks. That
list of 1000+ instances of their String class is going to suck to fix.
-Rasmus
Hi,
I believe all these projects wouldn't even want to enable strict types due
to the nature of their codebase and they probably don't need to, for sure
this feature is not for them...
What about Drupal, if they don't use dynamic instantiation for string
utility class then it can be fixed in most of IDEs out there with their
rename class feature. Plus keywords reservation is a matter of another
vote (the last one in the RFC) that can succeed even if type hints don't
pass.
Re: [PHP-DEV] Design by Contract
Hi Joe, On Wed, Feb 11, 2015 at 5:12 PM, Joe Watkins pthre...@pthreads.org wrote: Just a thought - what about something like __pre/__post? We own __*, so no BC problems. I'm not married to the words being used, at all. I think this is a good idea, we would need __pre, __post , and __invariant, or some combination of three. Any objection to using __ prefixed names, and any other suggestion for them, or just use the above ? It's very close to my original idea, but I like current definition like syntax. No objection from me... Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
[PHP-DEV] Re: Proposal: Introduce a new macro:php_error_docref_ex()
Hey: On Wed, Feb 11, 2015 at 4:35 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Wed, Feb 11, 2015 at 5:21 PM, reeze re...@php.net wrote: I think it is a cleanup, it works but there are too many duplication. it is the time to make the code clean and easier to understand. I've never used other than NULL also. Everyone is going to remove TSRM macros, it's right time to clean up. fine, if you want to change.. please, _ex means extending, so the name should not be php_error_docref_ex... thanks Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
Jordi Boggiano wrote on 11/02/2015 10:40: On 09/02/2015 22:29, Anatol Belski wrote: ext/imap ext/mcrypt ext/pdo_dblib Sorry if this was suggested already but if those are not maintained much and should not be used further ideally, shouldn't we add E_DEPRECATED to them at least? I understand that they are kept to avoid making the upgrade path harsher, but it's also not great to let they linger on forever with no notice to users that they are doing something wrong. I guess that's a discussion that can be had on a case-by-case basis, now we've bulk-voted the easy cases out of the way. Deprecation only really makes sense if there is a clear upgrade path for users, or a specific message to give them. For instance, I'm currently using PDO_DBLIB, and had no idea I was doing something wrong, or what I should be doing instead. And many people have already pointed out that ext/mcrypt needs some special thought, so just slapping a deprecation notice somewhere isn't really that useful. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new json, push generated file?
Hi Anatol, On Tue, Feb 10, 2015 at 3:35 PM, Anatol Belski anatol@belski.net wrote: Maybe it'd be worth it to move one step after another, see what features can be implemented and how do they improve? Maybe they'll be so crucial to even make a special case that one can say - yeah, don't care about flexibility? Not that one would restrict something without having the bare reason in the hand. I have been thinking about it and think that you have got a point. Let's wait when the implementation is ready and then we can make a decision if it's worthy breaking the flexibility. I have got few other things on my list before that so it will probably take some time to do the changes and test it... I would like to push the the bison tab files shortly as the majority of people in this thread (including me) are for having them in the repo. The only thing that I would like is to have a specific version in the repo to prevent big diffs for small changes in the source files. For now I would like to have there re2c 0.13.6 (thanks for regenerating it back ;) ) and bison 2.7.1 gen files. I will update Readme at some point as well and add there that info. I think that that all compat are types fixes are sort of done so it would be probably best to do PR for all json changes as it has lots of advantages (I'm sure that you all know them so I won't name them... :) ) I won't be adding the config.m4 stuff that is in the PR though. I realized that it would a bit of hack just for json which probably not good. However I still like the idea of removing re2c and bison dependency for all users that don't need to change parsers or scanners. That will require more changes to the build and probably RFC so it's a bit off-topic. I'll see if I get time to propose something like that in the future. Cheers Jakub
[PHP-DEV] A generic cryptographic framework for PHP core
I don't think there is time to get something finalised for 7.0, I certainly wouldn't want anything cryptography related to be rushed, so this is a pre-RFC discussion to gather ideas and opinions for something we can work towards in PHP 7.1 and that can live as a PECL extension between now and then. I would like to propose a generic cryptographic framework is added into core. We already have a generic hashing framework in ext/hash that we are comitted to supporting and I think our users would benefit from having a set of widely used cryptographic functions available without having a to depend on external libraries or extensions. However this framework should also be extensible by third-party extensions. The preferred behaviour of an extension that provides a cipher or hash function would be to register it with the framework and then it would become available through the same methods as any of the built-in algorithms. This also provides a way of swapping underlying libraries without changing the way they are called, hopefully making problems such as the ones we're facing with mcrypt a thing of the past. The framework should provide as core features (in my opinion): *A set of built-in widely used and accepted ciphers. *A set of built-in widely used and accepted hashes and MACs. (ext/hash becomes part of this framework) *A portable high quality random number generator *Built-in interfaces for crypto-providing extensions to implement. *Crypto contexts as objects with familar init/update/final type methods. *Stream filters for enc/dec/hash/mac etc. that can take a crypto context object. *Easy to use one-shot functions that handle the context behind the scenes. There is obviously no work on an implementation yet, but I know Jakub has already spent a lot of time on the php-crypto objective OpenSSL wrapper. I think a lot of his work would be very useful for bootstrapping a generic framework project. Lets try and avoid discussions on names and syntax, that can wait. I'd really welcome any and all feedback on this as a proposal, with a view to starting a project to give us a stable and maintainable foundation for the future. Would this be considered a valuable addition? Is it possible to provide a succinct API for the overwhelming majority of peoples crypto needs? Are there any major concerns about this type of framework being added? Does anyone think this is the wrong approach entirely (and have a better idea!)? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Proposal: Introduce a new macro:php_error_docref_ex()
Hi, I don't think it'll improve something, and may complicate merging from PHP5 (this is not a big issue, because merging is already not simple). In any case, the names should be swapped, to be used as: php_error_docref(E_WARNING, recursion detected); or php_error_docref_ex(NULL, E_WARNING, recursion detected); also macros with __VA_ARGS__ may be not portable, s it should be implemented differently. Thanks. Dmitry. On Wed, Feb 11, 2015 at 11:41 AM, Xinchen Hui larue...@php.net wrote: Hey: On Wed, Feb 11, 2015 at 4:35 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Wed, Feb 11, 2015 at 5:21 PM, reeze re...@php.net wrote: I think it is a cleanup, it works but there are too many duplication. it is the time to make the code clean and easier to understand. I've never used other than NULL also. Everyone is going to remove TSRM macros, it's right time to clean up. fine, if you want to change.. please, _ex means extending, so the name should not be php_error_docref_ex... thanks Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- Xinchen Hui @Laruence http://www.laruence.com/
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi, On Wed, Feb 11, 2015 at 12:40 PM, Jordi Boggiano j.boggi...@seld.be wrote: On 09/02/2015 22:29, Anatol Belski wrote: ext/imap ext/mcrypt ext/pdo_dblib Sorry if this was suggested already but if those are not maintained much and should not be used further ideally, shouldn't we add E_DEPRECATED to them at least? I understand that they are kept to avoid making the upgrade path harsher, but it's also not great to let they linger on forever with no notice to users that they are doing something wrong. I don't think it has been suggested already, but I agree - should be deprecated. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
On Wed, Feb 11, 2015 at 10:58 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
1) contracts in doc-commetns https://wiki.php.net/rfc/dbc
/**
* @requires ($a = 0)
*/
function foo($a) {
}
We've spent several years rejecting annotations because no information
can be in comments, not even a little bit, not even a tiny. Now we'd
have full-blown running code in comments? How would this code be
debugged/profiled/interpreted by tools? Writing PHP parser is not easy
right now, but this would turn it into nightmare (what if you have a
comment inside @requires? etc.)
I don't see how this can be implemented in PHP core as well.
This approach is for external tools.
2) contracts as part of the language https://wiki.php.net/rfc/dbc2
function foo($a)
require($a = 0)
{
}
This is a step better but still we have the similar issues with
readability, to which reuse of 'require' is added.
3) contracts in annotations
requires($a = 0)
function foo($a) {
}
That one actually looks better to me, but: I'm not sure how annotation
syntax is supposed to support expressions or closures,
keep AST.
yet more - how it
is supposed to share the scope with the function. I.e., if you define
annotation class/method/function/data structure/whatever it is, what it
is supposed to receive?
We may have AST transformation pass that would convert these annotations
into assert() and insert them into AST of the function.
Is it some special form of annotation for this
purpose only (meh)?
yes. some special attributes. requires/ensures/invariant
Oh, and syntax is *ugly* ;)
It's from HHVM. I don't like it as well, please, propose the better one.
Thanks. Dmitry.
--
Stas Malyshev
smalys...@gmail.com
Re: [PHP-DEV] zend_get_parameters_ex rework
On 10/02/15 14:31, Lester Caine wrote:
in interbase/ibase_blobs.c
zval *blob_arg, *string_arg;
ibase_blob *ib_blob;
RESET_ERRMSG;
if (ZEND_NUM_ARGS() != 2 || zend_get_parameters_ex(2, blob_arg,
string_arg) == FAILURE) {
WRONG_PARAM_COUNT;
}
ZEND_FETCH_RESOURCE(ib_blob, ibase_blob *, blob_arg, -1, Interbase
blob, le_blob);
I've got that if changes to
if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, rr,
blob_arg, string_arg)) {
return;
}
But I suspect I need to change the *string_arg to a character string so
'rc' and add a string_len field. At least that is what I think I'm
seeing from the samples I have found.
OK I've got a patch for master, but I know that the changes are not
complete!
http://hg.lsces.org.uk/hg/php-src/rev/8ec9101f59b6
I've still got a question about the string_arg on line 1.9 and if it
should be changed to a string but that change needs working through the
following code.
Also is what I'm doing here php7 only? so should there be wrappers for a
PHP5 build?
I think that all this leaves is all the complaints about 'NULL' and integer
initialization makes integer from pointer without a cast
and
assignment makes integer from pointer without a cast
--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
2015-02-11 13:25 GMT+02:00 Dmitry Stogov dmi...@zend.com:
yes. some special attributes. requires/ensures/invariant
Oh, and syntax is *ugly* ;)
It's from HHVM. I don't like it as well, please, propose the better one.
I like syntax, like a switch:
function add(int $a, int $b) : int
case $a 0:
case $b 0:
return($ret, $ret 0, something wrong)
{
return $a + $b;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Design by Contract
De : Dmitry Stogov [mailto:dmi...@zend.com] I think we should just repeat the related D semantic. It must be defined in contracts inheritance rules. What if we have contracts for prototype method in parent class and interface? Should we still validate contracts of parent and interface if we add our owns? etc. I would prefer contract inheritance to follow a logic more similar to what we use for PHP constructors/destructors (parent method is executed only if explicitely called). 'require(@parent)', for example, would mean 'check parent pre-conditions !'. The same for every constraint type. This is not exactly the D way but is is more consistent with the PHP way. And there's no real reason to follow D there. Not sure we should authorize constraints in interfaces, at least for a first version. Cheers François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Scalar Type Hints
-Original Message- From: Sebastian B.-Hagensen [mailto:sbj.ml.r...@gmail.com] Sent: Thursday, February 12, 2015 2:11 AM To: Zeev Suraski Cc: guilhermebla...@gmail.com; Rasmus Lerdorf; PHP Internals Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints Hi, 2015-02-12 0:08 GMT+01:00 Zeev Suraski z...@zend.com: It gives the exact same value from an API author’s point of view. But not from an api-consumers point of view. I didn't claim otherwise. I am claiming that piece is significantly less important, and that its negative implications outweigh its positive ones. Without either introducing a new set of casting/conversion rules or changing existing behavior (**exclusively**) 'weak' typehints may be perceived as seriously crippled. Maybe up to a point where the addition of them wouldn't be justified. I argued we should tweak the conversion rules. But unlike the current RFC, v0.1 doesn’t introduce an IMHO alien concept into a language that considered dynamic typing to be a core principle since its birth. It's not. PHP was always open to enforce strict typing in user created functions. Being able to do something in custom code - and having language-level syntax for it are a world a part in terms of condoned language principles. That's why proponents of this RFC are so much in its favor - and opponents are so much against. This new syntax would mean explosive growth and official encouragement for developers to place strict type checking throughout their code. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotated PHP 5-7 extension diff
Hi Xinchen,
On Thu, Feb 12, 2015 at 12:37 PM, Xinchen Hui larue...@php.net wrote:
lazy_write=On: Requests per second:2218.55 [#/sec] (mean)
lazy_write=Off: Requests per second:24.58 [#/sec] (mean)
I feel...that might be something wrong :
I do think so. It's Core i7 with 32GB memory and SSD. It did not use
much CPU and network bandwidth during benchmark. I'll wait your fix
(seems unrelated, though) and look into what's wrong. I cannot take
realistic benchmark because of this. I might try it on older machines :(
If you could take simple session benchmark, number of request / second,
it would be helpful for me to know my system's health.
session.php
?php
//ini_set('session.save_path', '/home/tmp');
ini_set('session.save_path', 'PERSISTENT=1 127.0.0.1:11211');
ini_set('session.save_handler', 'memcached');
ini_set('session.lazy_write', 1);
ini_set('session.use_strict_mode', 0);
session_id('testid2');
session_start();
//$_SESSION['test'] = ++$_SESSION['test'];
$_SESSION['a'] = str_repeat('a', 102400);
echo 'pre';
var_dump(session_id(), ini_get('session.save_handler'), $_SESSION['test']);
?
I get about 15K Reqs/sec for files handler with debug build.
Regards.
--
Yasuo Ohgaki
yohg...@ohgaki.net
[PHP-DEV] Re: Proposal: Introduce a new macro:php_error_docref_ex()
We don't use macros with variable number of arguments in PHP. this is not portable. Thanks. Dmitry. On Wed, Feb 11, 2015 at 6:01 PM, reeze re...@php.net wrote: Hi, On 11 February 2015 at 19:15, Dmitry Stogov dmi...@zend.com wrote: Hi, I don't think it'll improve something, and may complicate merging from PHP5 (this is not a big issue, because merging is already not simple). Yes it just makes code looks a little better and cleaner. I didn't realized the merging problem. that might affect diffs which changes php_error_docref() In any case, the names should be swapped, to be used as: php_error_docref(E_WARNING, recursion detected); or php_error_docref_ex(NULL, E_WARNING, recursion detected); Yes I prefer this too. But considering the merging problem, I think I should hold this idea of update all of those calls. We may provider a simple version with default null docref for external extesions, but I didn't have proper name for that. also macros with __VA_ARGS__ may be not portable, s it should be implemented differently. Yes I should use ##__VA_ARGS__ instead. Thanks. Dmitry. On Wed, Feb 11, 2015 at 11:41 AM, Xinchen Hui larue...@php.net wrote: Hey: On Wed, Feb 11, 2015 at 4:35 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Wed, Feb 11, 2015 at 5:21 PM, reeze re...@php.net wrote: I think it is a cleanup, it works but there are too many duplication. it is the time to make the code clean and easier to understand. I've never used other than NULL also. Everyone is going to remove TSRM macros, it's right time to clean up. fine, if you want to change.. please, _ex means extending, so the name should not be php_error_docref_ex... thanks Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- Xinchen Hui @Laruence http://www.laruence.com/ -- Reeze Xia http://reeze.cn
