Re: [PHP-DEV] Re: namespace RFC
Hi! The problem is that the loading/unloading of the scanner and parser can be significant overhead, and by cramming all code into a single file, can result in a 10%-30% performance improvement over code in separate files, even with an opcode cache. This has been verified independently Not only this, but the fact that executing 50 different op-arrays, with all setup and teardown that happens on the way, is definitely slower than 1 op-array, and also the fact that early binding on compile stage may be a bit faster when we are dealing with a lot of classes and carefully arrange them. As always, note that the benchmark was loading huge amount of classes and doing nothing but, so don't expect your real-life app to get anywhere near 30% on that. Actually, I have no idea how hard it would be to make big app using a lot of modules and lot of different classes in different modules to work this way, so I'm not even sure it's practical or will give any benefit - since you might be loading a bunch of code you'd never need. But the effect does exist. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace RFC
Hi! So I ask you all to review the RFC and provide feedback. If you feel Here's my feedback on the RFC. 1. The RFC seems to assume or imply that PHP programmers have extensive C++ experience. IMHO it is not true for the majority of PHP programmers. 2. Phar has nothing to do with file concatenation, as if was noted, and concatenation's use is entirely unrelated to phar (and, before you mention it, to bytecode caches - they can be used together, but one does not preclude the other). 3. Namespaces are *NOT* code flow control structure. Giving it a syntax of a control structure is misleading, requiring endnamespace at the end of each file makes no sense and just adds busywork for people. It also is awfully ugly - braces at least have some decent looks... Namespace also is not like a label in any way - it does not specify point in code and you can not jump to it using either conditional (like switch/case:) or unconditional (like goto) branch. 4. I did not understand first paragraph of part named Statements outside namespaces - what is has to do with caches? Could somebody explain it to me (private mail/IRC/IM OK). 5. I am not sure which exactly code RFC proposes to allow outside namespaces, in any case I don't see why it is necessary to allow any code to be put outside namespaces in namespaced files. For include, it doesn't matter anyway, since included file has its own namespace, for the rest I'm just unclear what else is proposed, please explain. 6. Comment about we kind of allow nested namespaces because we allow namespace in included file is wrong. These namespaces live absolutely separately and are not nested in any meaningful way. All files in PHP except for the head script are obtained by means of include(), so it is only natural that namespace is allowed inside include - it would be useless otherwise. Included file, however, creates it own namespacing scope, and just as we do not say we allow nested classes because file defining class can be included from inside any other class, same holds for namespaces. 7. Nested namespaces. I see that RFC authors chose to completely ignore all my comments about namespace nesting, so I repeat them again for the record. Nesting namespaces implies hierarchy, hierarchy implies hierarchical resolution, so if you inside namespace A::B::C::D::E::F, then name G is expected to resolve when it means either A::G, A::B::G, A::B::C::G, etc. Combined with autoloading, this makes resolution process prohibitively expensive, and not resolvable in runtime by any means - since even if you wrote A::B::C::D::E::F::G it could still mean A::B::C::A::B::C::D::E::F::G - since you have not one-level resolution but hierarchical resolution, even qualified name could be partial name. Making nesting without hierarchy doesn't make any sense - why nest then, what purpose would it serve? Another objection for nesting would be that there's actually no practical use for it in real code - as you could not nest across file boundaries, only use would be if you pack substantial number of classes from different modules into a single file, which usually is a bad idea. If you follow standards accepted by many common applications and separate classes in different files, nesting is completely useless, so it is if you group closely related classes (they would probably then be in the same hierarchy level). So, summarily, right now I see serious technical challenge for nesting (hierarchical lookups) and I don't see real use case for it. Regards, -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] BUG #45392
Hi,
Attached is a proposed fix for http://bugs.php.net/bug.php?id=45392 for
PHP_5_3. I don't know output buffering part very well, and I'm not
completely sure about this fix, so please review it.
The patch changes behavior of output buffering a bit. In case of fatal
error all output buffers opened by ob_start() with zero (or omitted)
chunk_size argument are discarded. The fix brakes two tests:
Test session_module_name() function : variation
[ext/session/tests/session_module_name_variation3.phpt]
Test session_set_save_handler() function : error functionality
[ext/session/tests/session_set_save_handler_error3.phpt]
We need to make a decision about #45392.
1) Fix it with proposed (or similar) patch
2) Make it bogus because any fix requires output buffering behavior change
Thanks. Dmitry.
Index: NEWS
===
RCS file: /repository/php-src/NEWS,v
retrieving revision 1.2027.2.547.2.965.2.305
diff -u -p -d -r1.2027.2.547.2.965.2.305 NEWS
--- NEWS1 Sep 2008 20:51:57 - 1.2027.2.547.2.965.2.305
+++ NEWS2 Sep 2008 08:31:03 -
@@ -1,6 +1,9 @@
PHPNEWS
|||
?? ??? 200?, PHP 5.3.0 Alpha 3
+- Fixed bug #45392 (ob_start()/ob_end_clean() and memory_limit. In case of
+ fatal error active output buffers with zero chunk_size (the default value of
+ the second argument to ob_start()) are discarded). (Dmitry)
02 Sep 2008, PHP 5.3.0 Alpha 2
- Removed special treatment of /tmp in sessions for open_basedir.
Index: main/main.c
===
RCS file: /repository/php-src/main/main.c,v
retrieving revision 1.640.2.23.2.57.2.32
diff -u -p -d -r1.640.2.23.2.57.2.32 main.c
--- main/main.c 26 Aug 2008 23:26:07 - 1.640.2.23.2.57.2.32
+++ main/main.c 2 Sep 2008 08:31:03 -
@@ -852,6 +852,19 @@ static void php_error_cb(int type, const
}
}
+if (!SG(request_info).headers_only) {
+ /* Discard output buffers with zero chunk_size on fatal error */
+ switch (type) {
+ case E_CORE_ERROR:
+ case E_ERROR:
+ case E_RECOVERABLE_ERROR:
+ case E_PARSE:
+ case E_COMPILE_ERROR:
+ case E_USER_ERROR:
+ php_discard_ob_buffers(TSRMLS_C);
+ }
+ }
+
/* display/log the error if necessary */
if (display (EG(error_reporting) type || (type E_CORE))
(PG(log_errors) || PG(display_errors) ||
(!module_initialized))) {
Index: main/output.c
===
RCS file: /repository/php-src/main/output.c,v
retrieving revision 1.167.2.3.2.4.2.9
diff -u -p -d -r1.167.2.3.2.4.2.9 output.c
--- main/output.c 18 Aug 2008 07:46:31 - 1.167.2.3.2.4.2.9
+++ main/output.c 2 Sep 2008 08:31:03 -
@@ -341,6 +341,45 @@ PHPAPI void php_end_ob_buffers(zend_bool
}
/* }}} */
+typedef struct _php_ob_calc_discard_rec {
+ int count;
+ int last;
+} php_ob_calc_discard_rec;
+
+/* {{{ php_ob_list_each
+ */
+static int php_ob_calc_discard(php_ob_buffer *ob_buffer,
php_ob_calc_discard_rec *discard)
+{
+ discard-count++;
+ if (!ob_buffer-chunk_size) {
+ discard-last = discard-count;
+ }
+ return 0;
+}
+/* }}} */
+
+
+/* {{{ php_discard_ob_buffers
+ * Discard output buffers with zero chunk_size */
+PHPAPI void php_discard_ob_buffers(TSRMLS_D)
+{
+ if (OG(ob_nesting_level)) {
+ php_ob_calc_discard_rec discard;
+
+ discard.count = 0;
+ discard.last = 0;
+ php_ob_calc_discard(OG(active_ob_buffer), discard);
+ if (OG(ob_nesting_level)1) {
+ zend_stack_apply_with_argument(OG(ob_buffers),
ZEND_STACK_APPLY_TOPDOWN, (int (*)(void *element, void *)) php_ob_calc_discard,
discard);
+ }
+ while (discard.last) {
+ php_end_ob_buffer(OG(active_ob_buffer).chunk_size != 0,
0 TSRMLS_CC);
+ discard.last--;
+ }
+ }
+}
+/* }}} */
+
/* {{{ php_start_implicit_flush
*/
PHPAPI void php_start_implicit_flush(TSRMLS_D)
Index: main/php_output.h
===
RCS file: /repository/php-src/main/php_output.h,v
retrieving revision 1.53.2.1.2.1.2.1
diff -u -p -d -r1.53.2.1.2.1.2.1 php_output.h
--- main/php_output.h 31 Dec 2007 07:17:17 - 1.53.2.1.2.1.2.1
+++ main/php_output.h 2 Sep 2008 08:31:03 -
@@ -37,6 +37,7 @@ PHPAPI int php_start_ob_buffer(zval *out
PHPAPI int php_start_ob_buffer_named(const char *output_handler_name, uint
chunk_size, zend_bool erase
Re: [PHP-DEV] BUG #45392
IIRC, there was some sort of OB rewrite done in HEAD..is this bug only present in PHP_5_3? If so, I'd say the OB rewrite should be done in PHP_5_3 already.. --Jani Dmitry Stogov wrote: Hi, Attached is a proposed fix for http://bugs.php.net/bug.php?id=45392 for PHP_5_3. I don't know output buffering part very well, and I'm not completely sure about this fix, so please review it. The patch changes behavior of output buffering a bit. In case of fatal error all output buffers opened by ob_start() with zero (or omitted) chunk_size argument are discarded. The fix brakes two tests: Test session_module_name() function : variation [ext/session/tests/session_module_name_variation3.phpt] Test session_set_save_handler() function : error functionality [ext/session/tests/session_set_save_handler_error3.phpt] We need to make a decision about #45392. 1) Fix it with proposed (or similar) patch 2) Make it bogus because any fix requires output buffering behavior change Thanks. Dmitry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] BUG #45392
Jani Taskinen wrote: IIRC, there was some sort of OB rewrite done in HEAD..is this bug only present in PHP_5_3? If so, I'd say the OB rewrite should be done in PHP_5_3 already.. The bug occurs in both 5.3 and HEAD. Thanks. Dmitry. --Jani Dmitry Stogov wrote: Hi, Attached is a proposed fix for http://bugs.php.net/bug.php?id=45392 for PHP_5_3. I don't know output buffering part very well, and I'm not completely sure about this fix, so please review it. The patch changes behavior of output buffering a bit. In case of fatal error all output buffers opened by ob_start() with zero (or omitted) chunk_size argument are discarded. The fix brakes two tests: Test session_module_name() function : variation [ext/session/tests/session_module_name_variation3.phpt] Test session_set_save_handler() function : error functionality [ext/session/tests/session_set_save_handler_error3.phpt] We need to make a decision about #45392. 1) Fix it with proposed (or similar) patch 2) Make it bogus because any fix requires output buffering behavior change Thanks. Dmitry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] BUG #45392
Dmitry Stogov wrote: Hi, Attached is a proposed fix for http://bugs.php.net/bug.php?id=45392 for PHP_5_3. I don't know output buffering part very well, and I'm not completely sure about this fix, so please review it. The patch changes behavior of output buffering a bit. In case of fatal error all output buffers opened by ob_start() with zero (or omitted) chunk_size argument are discarded. The fix brakes two tests: Test session_module_name() function : variation [ext/session/tests/session_module_name_variation3.phpt] Test session_set_save_handler() function : error functionality [ext/session/tests/session_set_save_handler_error3.phpt] We need to make a decision about #45392. 1) Fix it with proposed (or similar) patch 2) Make it bogus because any fix requires output buffering behavior change Sorry for top-posting. Anyway, reading the patch made me think that maybe in the user/recoverable cases the output buffer should not be discarded like this..? And IMO, it's a bug, bugs should be fixed even if it means changing the behaviour in an _edge_ case. How do those session tests fail..? They expect output with fatal errors? (actually those tests failed without your patch too, IIRC :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] BUG #45392
Jani Taskinen wrote: Dmitry Stogov wrote: Hi, Attached is a proposed fix for http://bugs.php.net/bug.php?id=45392 for PHP_5_3. I don't know output buffering part very well, and I'm not completely sure about this fix, so please review it. The patch changes behavior of output buffering a bit. In case of fatal error all output buffers opened by ob_start() with zero (or omitted) chunk_size argument are discarded. The fix brakes two tests: Test session_module_name() function : variation [ext/session/tests/session_module_name_variation3.phpt] Test session_set_save_handler() function : error functionality [ext/session/tests/session_set_save_handler_error3.phpt] We need to make a decision about #45392. 1) Fix it with proposed (or similar) patch 2) Make it bogus because any fix requires output buffering behavior change Sorry for top-posting. Anyway, reading the patch made me think that maybe in the user/recoverable cases the output buffer should not be discarded like this..? And IMO, it's a bug, bugs should be fixed even if it means changing the behaviour in an _edge_ case. I'm not so sure as http://www.php.net/manual/en/function.ob-start.php doesn't make difference between successful and unsuccessful request and assumes output buffer is flushed to the browser at the end of the request. How do those session tests fail..? As they have ob_start() at top, the output is discarded and only error message is printed. They expect output with fatal errors? (actually those tests failed without your patch too, IIRC :) They works for me without the patch. Thanks. Dmitry. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace RFC
Hi! I am sorry but I absolutely fail to see how the following is in any way whatsoever unclear: This is clear, I understand that and think it is completely wrong and misguided, for reasons I described in my last email. What I did not understand is what code you wanted to allow outside namespaces and what all that include part and strings/not strings distinction talks about. namespace A::B::C::D::E::F; $obj = new G; Now what? Now G is either A::B::C::D::E::F::G or ::G, but never A::B::G etc. Do you understand the difference? No hierarchy. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: namespace RFC
Hi! My guess is that it allows for development with heavy __autload usage and then doing deployment based on static analysis where each target page results in one large php file generated from that analysis. So there won't be any overhead and each script target would be a single target of its own. So each target (like each page, MVC action, etc.) would have its own huge PHP file that has all classes used there? I guess for some applications that could work, for others, more dynamic, that would fail miserably. The maintainability of such thing is also challenging. It would be nice to have some real-life examples of how such things work out - so far I have seen only theory and synthetic benchmarks, which are interesting, but not necessary what would happen on real project. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Cases in which loadHTML doesn't exit
I've been debugging a case where a PHP installation doesn't have DOMDocument-loadHTML, but phpinfo reports that HTML is enabled (the normal reason why loadHTML would not be available) and that the API version of 20031129. Is there any other way to check for the compile-time constant LIBXML_HTML_ENABLED, and are there any known bugs with regards to its display? Thanks, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cases in which loadHTML doesn't exit
On 02.09.2008 21:40, Edward Z. Yang wrote: I've been debugging a case where a PHP installation doesn't have DOMDocument-loadHTML, but phpinfo reports that HTML is enabled Ugh? It's the same #ifdef. Is there any other way to check for the compile-time constant LIBXML_HTML_ENABLED What do you mean? Is there a way to do this #ifdef in a different way? and are there any known bugs with regards to its display? None that I know of. And even if there are, I don't believe they are on our side, since it's the same #ifdef used in two different places, no chance to get different values. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cases in which loadHTML doesn't exit
Antony Dovgal wrote: And even if there are, I don't believe they are on our side, since it's the same #ifdef used in two different places, no chance to get different values. Yep. I did more source diving and this should not be possible. Which means that whoever deployed this PHP (i.e. the hosting company) has been monkeying around with the source. :-( -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha2 scheduled
Hi! Wasn't it you who said it is all about simple replacement? In current model, yes. With nesting in hierarchy, it ceases to be so, that's exactly my point. However, you always said we shouldn't compare PHP features to other languages and that for that reason we should not worry about the I didn't say that. I said that we should not take decisions based only on the fact that other languages have it so. Of course we can look on other languages and import whatever we feel is useful, however we should not import stuff *just* because C++ and Java does so, contrary to how it would work in PHP. PHP is its own language, and there's no obligation to mimic any other one. keyword naming for instance. And that for the same reason we should not take a specific implementation of another language. Why are you suddenly taking Ruby's behavior as the thing to implement, if we were going that route? [1] I definitely don't take Ruby's behavior, as Ruby's namespacing is hierarchical, AFAIK. For instance on 17th July Greg, who was very much involved in the whole namespce implementation, summarized the open discussion points and you simply turned the discussion dead immediately [2]. If people I was and still am indeed somewhat sick of endless discussion about braces and fixation on it. But OK, you won and we are having another 2 threads about it. I accept that and I again explained why I think it is a bad idea - last time it was today. I think the positions on the braces as syntax are more or less clear, and we all heard all arguments from all sides multiple times, so I do not see much use in repeating them over and over - unless you think I could explain something better or you could bring some new idea, in which case I am ready to do what I can and hear anything new anybody has to say. constantly start mailing about issues they have, then we need to address that or even get rid of the feature but we cannot say: this I find it very disturbing that you again and again raise the question of getting rid of namespaces - what are you trying to do? Why would you want namespaces not exist in PHP? is it, live with it as it is or not use it at all. None of that would be the PHP way where we always have been trying to come to a simple solution that works for everyone. I did and do try to find the simplest solution possible (possible is important here!). Having weird syntaxes and additions that have multiple problems (like hierarchy) do not help. I try to accommodate as much stuff people want as could be accomodated - namespaced functions (IMHO abomination, but people wanted it - they got it), multiple files, etc. But there has to be some conceptual integrity, otherwise it just turns into a mess. Personally, my take is that I don't need nesting but simply see it as the natural thing to add. And text replacement, which is what the As I explained, it is not natural addition - it makes the model much more complex and resolution be O(N) instead of O(1). It also is not appears to be useful for any practical purpose. not really matter to me. But seems to matter to other people. What OK, I would be happy to hear these other people - what are they use cases and what they try to do with namespace nesting. Other people, please speak. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] BUG #45392
Hi, On Tuesday 02 September 2008 12:15:02 Dmitry Stogov wrote: Jani Taskinen wrote: Dmitry Stogov wrote: Hi, Attached is a proposed fix for http://bugs.php.net/bug.php?id=45392 for PHP_5_3. I don't know output buffering part very well, and I'm not completely sure about this fix, so please review it. The patch changes behavior of output buffering a bit. In case of fatal error all output buffers opened by ob_start() with zero (or omitted) chunk_size argument are discarded. The fix brakes two tests: Test session_module_name() function : variation [ext/session/tests/session_module_name_variation3.phpt] Test session_set_save_handler() function : error functionality [ext/session/tests/session_set_save_handler_error3.phpt] We need to make a decision about #45392. 1) Fix it with proposed (or similar) patch 2) Make it bogus because any fix requires output buffering behavior change Sorry for top-posting. Anyway, reading the patch made me think that maybe in the user/recoverable cases the output buffer should not be discarded like this..? And IMO, it's a bug, bugs should be fixed even if it means changing the behaviour in an _edge_ case. I'm not so sure as http://www.php.net/manual/en/function.ob-start.php doesn't make difference between successful and unsuccessful request and assumes output buffer is flushed to the browser at the end of the request. I think that it is critical to output this kind of buffer in case of fatal error, as it may unexpectedly leak data which was not meant to be output. It seems Ok to me to discard this kind of buffers in this case. How do those session tests fail..? As they have ob_start() at top, the output is discarded and only error message is printed. They expect output with fatal errors? (actually those tests failed without your patch too, IIRC :) They works for me without the patch. Thanks. Dmitry. --Jani Regards, Arnaud -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] Constant expr folding (again), and other things
Hi! I forgot to reply to Stas' message yesterday, sorry... But, there is no change in behavior here either as far as I know. For the code Stas quoted, with static vars (if that's what was being referred to), there's definitely not been a change (though its parser code was tweaked a bit), and there has never been a locale issue, and the operand negation happens at compile-time (as always). Yes, it seems like you are right - for such cases it happens in compile time in any case. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] OpenSSL random pseudo bytes
Hi All,
Attached and uploaded [1] is a patch to add the OpenSSL random pseudo
byte function, at the moment it will return FALSE if the bytes aren't
considered cryptographically strong, I am however considering making
this parameter controlled.
Any objections to me applying this to 5.3?
Scott
--
[1] - http://whisky.macvicar.net/patches/openssl_prg.patch.txt
Index: ext/openssl/openssl.c
===
RCS file: /repository/php-src/ext/openssl/openssl.c,v
retrieving revision 1.98.2.5.2.41.2.16
diff -u -r1.98.2.5.2.41.2.16 openssl.c
--- ext/openssl/openssl.c 30 Jul 2008 11:59:05 -
1.98.2.5.2.41.2.16
+++ ext/openssl/openssl.c 3 Sep 2008 01:06:19 -
@@ -94,6 +94,7 @@
PHP_FUNCTION(openssl_decrypt);
PHP_FUNCTION(openssl_dh_compute_key);
+PHP_FUNCTION(openssl_random_pseudo_bytes);
/* {{{ arginfo */
static
@@ -394,6 +395,11 @@
ZEND_ARG_INFO(0, pub_key)
ZEND_ARG_INFO(0, dh_key)
ZEND_END_ARG_INFO()
+
+static
+ZEND_BEGIN_ARG_INFO(arginfo_openssl_random_psuedo_bytes, 0)
+ZEND_ARG_INFO(0, length)
+ZEND_END_ARG_INFO()
/* }}} */
/* {{{ openssl_functions[]
@@ -458,6 +464,7 @@
PHP_FE(openssl_dh_compute_key, arginfo_openssl_dh_compute_key)
+ PHP_FE(openssl_random_pseudo_bytes,
arginfo_openssl_random_psuedo_bytes)
PHP_FE(openssl_error_string, arginfo_openssl_error_string)
{NULL, NULL, NULL}
};
@@ -4742,6 +4749,30 @@
}
/* }}} */
+/* {{{ proto string openssl_random_pseudo_bytes(integer length)
+ Returns a string of the length specified filled with random pseudo bytes */
+PHP_FUNCTION(openssl_random_pseudo_bytes)
+{
+ long buffer_length;
+ unsigned char *buffer = NULL;
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, l,
buffer_length) == FAILURE) {
+ return;
+ }
+
+ if (buffer_length = 0) {
+ RETURN_FALSE;
+ }
+
+ buffer = emalloc(buffer_length);
+ if (RAND_pseudo_bytes(buffer, buffer_length) 0) {
+ RETVAL_FALSE;
+ } else {
+ RETVAL_STRINGL((char *)buffer, buffer_length, 1);
+ }
+ efree(buffer);
+}
+/* }}} */
+
/*
* Local variables:
* tab-width: 8
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OpenSSL random pseudo bytes
2008/9/2 Scott MacVicar [EMAIL PROTECTED]: Hi All, Attached and uploaded [1] is a patch to add the OpenSSL random pseudo byte function, at the moment it will return FALSE if the bytes aren't considered cryptographically strong, I am however considering making this parameter controlled. Any objections to me applying this to 5.3? I'd say that 5.3 should be a rather stable version and that if we add features we should make sure they are rock solid now. Perhaps adding the control (Parameter to control the security/cryptography level) now would save time and would make it a thing less to look back in the future. What do you think? -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OpenSSL random pseudo bytes
On 3 Sep 2008, at 03:33, David Coallier wrote: 2008/9/2 Scott MacVicar [EMAIL PROTECTED]: Hi All, Attached and uploaded [1] is a patch to add the OpenSSL random pseudo byte function, at the moment it will return FALSE if the bytes aren't considered cryptographically strong, I am however considering making this parameter controlled. Any objections to me applying this to 5.3? I'd say that 5.3 should be a rather stable version and that if we add features we should make sure they are rock solid now. This function has been in OpenSSL for 8 years and supported by every version since 0.9.5. It's literally just exposing the API, it's safe for inclusion in 5.3 in my opinion. Perhaps adding the control (Parameter to control the security/cryptography level) now would save time and would make it a thing less to look back in the future. It's not a cryptography level / control. The problem is that the PRNG can run out of data if there isn't enough entropy available, you can still take the result but it's not strong. I should say this function isn't for key generation but for use in places that you need random data. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OpenSSL random pseudo bytes
This function has been in OpenSSL for 8 years and supported by every version since 0.9.5. It's literally just exposing the API, it's safe for inclusion in 5.3 in my opinion. I didn't express myself very clearly. What I meant is that we should probably add that switch for the return right now instead of later (IE: I am however considering making this parameter controlled.) I think it's safe to include it but I'll await on the RMs before saying anything :) Exposing OpenSSL's API is a good idea imo. -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] How to enable debug for my extension?
Hi all, I'm trying to debug my extension.It says that PHP is built with debug flag, but my not my extenison. I used --enable-debug for PHP build. But, in the extension I wrote I can't find any configure option associated with debug in ./configure --help. I tried using the options --enable-debug and --with-debug options, but no result. PHP is giving a startup error while loading my extension. Any suggestions please. -- Mangol Smith
Re: [PHP-DEV] PHP 5.3.0alpha2
Zitat von Lukas Kahwe Smith [EMAIL PROTECTED]: Windows binaries (optimized for various versions of Windows) are available from the new website dedicated to PHP's windows binaries: http://windows.php.net/downloads.php Looks like the file descriptions are wrong. The non-TS PHP 5.3.0alpha2 VC9 x86 is labeled as VC9 build x64. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
