Re: [PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / avail loginfo
On 28.11.2007, at 00:28, Pierre wrote: One word: transparency. It is amazing how it helps to discuss things instead of acting like that. I find it amazing how oblivious to community concerns this all is. Anyways, from some other discussions I gathered that the main thing that is currently being talked about is CLA's. Once they have a CLA in place they will open the discussions. From what I hear at least part of the previous secret discussions will then be opened as well via some kind of archive. To me the key piece that would kill the idea of a CLA is if it required me to be able to grant all patents that may be covering any of the code I contribute. So far all the CLA's I have read seemed to imply this. And from my understanding this is what makes the CLA work for companies. The alternate interpretation [1], that the Apache CLA and its many derived CLAs, only requires that you grant all patents that knowingly cover the given code, seems bogus to me, since that would defeat the purpose of the CLA to begin with. And that is to be able to deflect all law suits aimed at the project and its users, by pointing the finger at a single developer. The idea being that single developers are no interesting targets for patent trolls. I find this claim, that most OSS projects keep repeating, so hideously evil. If all you need is to ensure that only single developers are to blame for patent violations, than the patent system would probably quickly get an update (because then even our friends at IBM, SUN etc would start to care - they do like software patents, do not let yourself get confused by their patent pool schemes). The point is, there is no guarantee that a patent holder will not still proceed to sue developer Joe Schmo. Number one, not all of us stay poor, but more importantly it will just take a few law suits to teach all the developers in the world that all the guys that gave you friendly advice on CLA's were either lying or uninformed (or lying about being informed). However all the Joe Schmo developers that were taught this lesson can kiss happy life good bye. Now without CLA's, there would be more incentive for companies like IBM and SUN to actually take a different approach to software patents, like using their happy lobby money to actually put an end to them. Or invalidate the patent claim in question, because otherwise they can be sued as well for using the given code, since they do not have a patent grant from Joe Schmo. I have asked IBM to validate the legal situation with a proper legal analysis (which I might still get cross checked by a lawyer of my choice), but I do not know if my contact at IBM was too lazy to actually ask, or if IBM just chose to not answer because they know full well that CLAs is essentially using developers as bumpers. And when the big guys slam into each other .. there is not much left of the bumpers in between. regards, Lukas [1] http://osdir.com/ml/java.harmony.devel/2006-02/msg00344.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] question regarding type hinting parameters of php functions (array_slice)
Hi, i have tried a current snapshot of PHP 5.3 and have a question regarding type hinting. For example when using the function array_slice(array $array, int $offset, int $length) with a non-integer length parameter, what is the desired behavior? When calling array_slice($array, 0, (float)2); the resulting array is EMPTY. When using the right type array_slice($array, 0, (int)2); it works as expected. Shouldn't there be a notice/warning than just a wrong return value? In my case there is neither a warning nor does it work as expected. (perhaps i do something wrong?) Of course i can use int's, but in my opinion either a warning should be given or the function should gracefully handle the wrong typed parameter. Is this problem specific to array_splice or the same with other functions? It works with 5.2.x without a problem. Thank you for any feedback, Dirk PS: i posted this to php-general before and someone supposed to better post it to the iternals list -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] question regarding type hinting parameters of php functions (array_slice)
Hi Dirk,
When calling
array_slice($array, 0, (float)2);
the resulting array is EMPTY.
When using the right type
array_slice($array, 0, (int)2);
it works as expected.
i think this should print a warning like other array functions.
But i looked into the src and this looks more like a casting bug inside this
function.
$input = array('a', 'b', 'c', 'd', 'e');
var_dump(array_slice($input, 1, 1));
var_dump(array_slice($input, 1, 1));
var_dump(array_slice($input, 1, (FLOAT)1));
var_dump(array_slice($input, 1, 1.0));
output:
array(1) {
[0]=
string(1) b
}
array(1) {
[0]=
string(1) b
}
array(0) {
}
array(0) {
}
So i think the float value isnt correct casted as int value here. Maybe
someone else
can proof this.
-- Marco
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] question regarding type hinting parameters of php functions (array_slice)
Hi,
When calling
array_slice($array, 0, (float)2);
the resulting array is EMPTY.
When using the right type
array_slice($array, 0, (int)2);
it works as expected.
i think this should print a warning like other array functions.
But i looked into the src and this looks more like a casting bug inside this
function.
Actually most functions use implicit type conversions for this. So I
wouldn't say this should cause a warning.
So i think the float value isnt correct casted as int value here. Maybe
someone else
can proof this.
Yes, you are right here I think
the code is
if (ZEND_NUM_ARGS() = 3 Z_TYPE_P(length_param) != IS_NULL) {
length = Z_LVAL_P(length_param);
} else {
length = num_in;
}
and afaik should be
if (ZEND_NUM_ARGS() = 3 Z_TYPE_P(length_param) != IS_NULL) {
convert_to_long(length_param);
length = Z_LVAL_P(length_param);
} else {
length = num_in;
}
best regards
Moritz Bechler
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] question regarding type hinting parameters of php functions (array_slice)
the code is
if (ZEND_NUM_ARGS() = 3 Z_TYPE_P(length_param) != IS_NULL) {
length = Z_LVAL_P(length_param);
} else {
length = num_in;
}
and afaik should be
I think in fact it should just parse it as long and not as zval - what
would be any reason to parse it as zval and then convert to long anyway?
--
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] Reliable header sending mechanism in php 6
Alexey Zakhlestin wrote: Enforcing people to use some specific way of coding to use library is incorrect, anyway. But, you can correctly handle the situation (i.e. provide a meaningful error to the user) by making a simple check: http://docs.php.net/headers-sent With a little bit of magic (get_included_files) you can even tell the user where the leading/trailing whitespace is! -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PATCH: zend_alloc.c x86_64 optimization
I noticed that there where some x86_64 assembly optimizations missing
from Zend/zend_alloc.c, it only accounts for i386. The following
patch should add x86_64 support (I don't have karma for Zend of
course, patch is against 5.2.5), I've included a bench mark with a
simple test script to test out memory allocation. I'd be interested
in getting feedback on this and knowing what other's results are.
Sorry for the custom micro-bench but zend_bench.php did show small
gains, but they where extremely small to really show anything.
A note on the i386 assembly, I had to add the following '' char to
make sure the input/outputs are using different registers. Lack of
this had caused some serious memory corruption on my system with -O2
so I'm guessing it might be appropriate to do the same on the i386
code as well, but I've left that out of this patch, perhaps someone
with some assembler experience can verify this is correct?
- : =a(res), =d (overflow)
+ : =a(res), =d (overflow)
Thanks,
-shire
?php
$start = microtime(true);
for($i=0; $i 100; $i++) {
$x[$i] = 'x';
}
$stop = microtime(true);
print ($stop-$start).\n;
?
php-5.2.5
---
no-asm asm delta
-
Run10.926729918 0.767436981 -0.159292936
Run20.920269966 0.768045902 -0.152224064
Run30.918609858 0.758006096 -0.160603762
Total 2.765609741 2.293488979 -0.472120762
Percentage: -17.07%
Index: Zend/zend_alloc.c
===
--- Zend/zend_alloc.c (revision 69567)
+++ Zend/zend_alloc.c (working copy)
@@ -656,6 +656,11 @@
__asm__(bsrl %1,%0\n\t : =r (n) : rm (_size));
return n;
+#elif defined(__GNUC__) defined(__x86_64__)
+ unsigned long n;
+
+ __asm__(bsrq %1,%0\n\t : =r (n) : rm (_size));
+ return (unsigned int)n;
#elif defined(_MSC_VER) defined(_M_IX86)
__asm {
bsr eax, _size
@@ -677,6 +682,11 @@
__asm__(bsfl %1,%0\n\t : =r (n) : rm (_size));
return n;
+#elif defined(__GNUC__) defined(__x86_64__)
+ unsigned long n;
+
+ __asm__(bsfq %1,%0\n\t : =r (n) : rm (_size));
+ return (unsigned int)n;
#elif defined(_MSC_VER) defined(_M_IX86)
__asm {
bsf eax, _size
@@ -2309,18 +2319,30 @@
return _zend_mm_block_size(AG(mm_heap), ptr
ZEND_FILE_LINE_RELAY_CC ZEND_FILE_LINE_ORIG_RELAY_CC);
}
-#if defined(__GNUC__) defined(i386)
+#if defined(__GNUC__) (defined(i386) || defined(__x86_64__))
static inline size_t safe_address(size_t nmemb, size_t size, size_t
offset)
{
size_t res = nmemb;
- unsigned long overflow ;
+ unsigned long overflow = 0;
- __asm__ (mull %3\n\taddl %4,%0\n\tadcl $0,%1
+#if defined(i386)
+ __asm__ ( mull %3\n\t
+ addl %4,%0 \n\t
+ adcl $0,%1 \n\t
: =a(res), =d (overflow)
: %0(res),
rm(size),
rm(offset));
+#else /* __x86_64__ */
+ __asm__ ( mulq %3 \n\t
+ addq %4,%0 \n\t
+ adcq $0,%1 \n\t
+ : =a(res), =d (overflow)
+ : %0(res),
+ rm(size),
+ rm(offset) );
+#endif
if (UNEXPECTED(overflow)) {
zend_error_noreturn(E_ERROR, Possible integer overflow in memory
allocation (%zu * %zu + %zu), nmemb, size, offset);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / avail loginfo
Lukas Kahwe Smith wrote: On 28.11.2007, at 00:28, Pierre wrote: One word: transparency. It is amazing how it helps to discuss things instead of acting like that. I find it amazing how oblivious to community concerns this all is. Anyways, from some other discussions I gathered that the main thing that is currently being talked about is CLA's. Once they have a CLA in place they will open the discussions. From what I hear at least part of the previous secret discussions will then be opened as well via some kind of archive. I agree. As most of you know, I met with IBM a couple of years ago the last time they were keen on getting a CLA in place so they could contribute more. I voiced my skepticism, but kept an open mind and put the ball in their court asking them to write up a detailed explanation of how a CLA will help the average PHP contributor. They said they would do that and disappeared never to be heard from again. My stance on this hasn't changed. I don't care the slightest how a CLA helps them, I want to hear what it does for us. The obvious benefit for the project is to get more contributions, but the cost of those contributions in terms of a CLA burden has to be weighed. And so far nobody has adequately justified why the average PHP contributor should sign a CLA. The existing CLA stuff on IBM-specific stuff like DB2, SDO and IDS was something I didn't care much about since it was pretty much entirely an IBM effort and I doubted there would be a general interest in those things, which has pretty much turned out to be the case. But I am very much against expanding this to cover more of PHP and encroaching on general-purpose things that a large number of non-patent encumbered PHP contributors would have an interest in. So yes, before this goes any further, we need full disclosure here and a really well thought out explanation by someone convincing us of the benefits of signing a CLA. Barring that, I am with Marcus and Lukas on this. Keep it out of PHP CVS and host it somewhere else. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / avail loginfo
On Nov 28, 2007 5:49 PM, Rasmus Lerdorf [EMAIL PROTECTED] wrote: Lukas Kahwe Smith wrote: On 28.11.2007, at 00:28, Pierre wrote: One word: transparency. It is amazing how it helps to discuss things instead of acting like that. I find it amazing how oblivious to community concerns this all is. Anyways, from some other discussions I gathered that the main thing that is currently being talked about is CLA's. Once they have a CLA in place they will open the discussions. From what I hear at least part of the previous secret discussions will then be opened as well via some kind of archive. I agree. As most of you know, I met with IBM a couple of years ago the last time they were keen on getting a CLA in place so they could contribute more. I voiced my skepticism, but kept an open mind and put the ball in their court asking them to write up a detailed explanation of how a CLA will help the average PHP contributor. They said they would do that and disappeared never to be heard from again. My stance on this hasn't changed. I don't care the slightest how a CLA helps them, I want to hear what it does for us. The obvious benefit for the project is to get more contributions, but the cost of those contributions in terms of a CLA burden has to be weighed. And so far nobody has adequately justified why the average PHP contributor should sign a CLA. The existing CLA stuff on IBM-specific stuff like DB2, SDO and IDS was something I didn't care much about since it was pretty much entirely an IBM effort and I doubted there would be a general interest in those things, which has pretty much turned out to be the case. But I am very much against expanding this to cover more of PHP and encroaching on general-purpose things that a large number of non-patent encumbered PHP contributors would have an interest in. So yes, before this goes any further, we need full disclosure here and a really well thought out explanation by someone convincing us of the benefits of signing a CLA. Barring that, I am with Marcus and Lukas on this. Keep it out of PHP CVS and host it somewhere else. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Without sounding too naive on this, I hope, isn't it also possible that IBM's internal policies require them to have CLAs in place for tax and documentation purposes? Or perhaps to cover their own engineers from liability by claiming them as open source developers, protected under the agreement accepted, ultimately, by the end user. I'd concur that it doesn't belong in the PHP CVS because it's out of the scope and spirit of the initial project, but is it really such a Big Brother issue? It states that all developers are completely free to use and redistribute any code they commit to the repository and the project as a whole, and further, that any user can then use it freely to create derivative works from said code, et cetera. Of course, it does lay the groundwork for new licensing in the future, whereby this project could eventually take on more and more of PHP, until a project that began as open source joins the ranks as a commercial competitor to ASP and Java. Then again, maybe I'm missing something or just blowing smoke out of my ass. I'm exhausted, but I'm trying to understand a bit more about the hot-button parts of the issue. -- Daniel P. Brown [office] (570-) 587-7080 Ext. 272 [mobile] (570-) 766-8107 If at first you don't succeed, stick to what you know best so that you can make enough money to pay someone else to do it for you. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / avail loginfo
Daniel Brown wrote: Without sounding too naive on this, I hope, isn't it also possible that IBM's internal policies require them to have CLAs in place for tax and documentation purposes? Or perhaps to cover their own engineers from liability by claiming them as open source developers, protected under the agreement accepted, ultimately, by the end user. Like I said, I understand why they need a CLA, and they can develop stuff under whatever terms they want. It is only the final license of what they produce that should matter to most people. The sticky point is if this CLA requirement starts bleeding out of fringe things very specific to a certain product and starts infecting general PHP components like all of PDO instead of just a specific PDO driver. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: krid_
Please send me a new CVS password as I forgot mine for the account krid ([EMAIL PROTECTED]) (Don't create a new account!) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: krid_
On Nov 28, 2007, at 10:49 PM, Dirk Randhahn wrote: Please send me a new CVS password as I forgot mine for the account krid ([EMAIL PROTECTED]) Hello Dirk, http://master.php.net/forgot.php Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
