Re: [PHP-DEV] segfault with ze2/php5-cvs
Very nice.
What about:
?php
class person {
var $name;
}
$start = new person;
$start-name = 'Eve';
$new = $start-__clone();
?
Does it come back with 'Call to a member function on a non-object'?
On Fri, Mar 21, 2003 at 02:47:06PM -0500, Sterling Hughes wrote:
?php
class sheep {
var $name;
}
$start = new sheep;
$start-name = Dolly;
$new = $start-__clone();
$new-name = Molly;
var_dump($start);
?
BOOM!
-Sterling
--
Good judgement comes from experience, and experience comes from
bad judgement.
- Fred Brooks
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] TML++
On Saturday, Jan. 26th, at 11:36am MST my son, Joseph Clark Smith, Jr. was born. He is 19.5 in length and 7 lbs. 5 oz. More pictures later, but here's on to start with: http://www.joeysmith.com/~joey/jj.jpg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug N°13763 Update with example
This bug is completely unrelated to your COMPUTE statement, it's because
you are returning more than 1 result set from your stored procedure.
There is a known weakness in the PHP sybase_ct implementation right now,
in that you can only get at the first result set that any query
returns. Nick Marden (IIRC) has a proposed patch for this...as soon as I
get some time, I will look over it and commit it...unless someone else
beats me to it.
To see this in action outside of the COMPUTE statement, just run
sp_help from PHP, and see what happens...
The bug has already been bogusified.
On Thu, 25 Oct 2001, Arnaud L wrote the following to [EMAIL PROTECTED] :
Here a complete example (php and sybase) with the problem of compute sql statement.
PHP stop when he encountred the compute.
PHP :
sybase_query=(EXEC MYPROC);
$result = sybase_query($query);
while ($row = sybase_fetch_array($result))
{
print $row[COLUMN1];
print $row[COLUMN3];
print $row[COLUMN3];
}
SYBASE PROC :
SELECT DISTINCT doc1,;, conste+concen
+conqtm+conord+coni1+coni2,;, numchg,;
, rais1d,;, cpd,;, intcomd,;,
dpliv,;, tcaht, ;, qtet,;, crgro, ;
FROM fantasio..f_mtf
WHERE datchg=@debut
AND datchg=@fin
AND unit='6'
ORDER BY dpliv, rais1d, intcomd, cpd
COMPUTE SUM(tcaht), SUM(qtet)
BY dpliv, rais1d, intcomd, cpd
PHP stop on COMPUTE... Then it's a bug of PHP
This error is encountred when i try to return two select.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Rand...
Jeroen: It would probably help the discussion a lot if you would sort through all of the comments on your page, decide which are valid and which are not, and then rewrite the proposal. I can't seem to follow which comments are being accepted and which are being discarded. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Bug #13322 Updated: Still SIGSEGV with DOMXML /double free()
On Sat, 15 Sep 2001, Ivo Hulinsky wrote the following to Bug Database and...: Why now I cannot update this bug? I've got error: The username or password you supplied was incorrect. Something went wrong updating the database. Is this problem that I have not CVS username? Most likely you forgot to set a password when you created the bug. We really should fix this one of these days. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP and CSS
Are you sure that PHP is doing it? In what way does it mangle the text? And why on earth is your server set to have PHP parse CSS files? :) On Fri, 14 Sep 2001, Lindsey Simon wrote the following to [EMAIL PROTECTED]: The last two projects I've worked on I've noticed that PHP somehow mangles my Cascading Styles, rendering the text almost unreadable. If I paste the same stlyes into an .html document the text looks beautiful. Any one experienced this before / know a solution? -lindsey -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] imap support
Please send support questions to [EMAIL PROTECTED] On Wed, 12 Sep 2001, Carry Ian wrote the following to [EMAIL PROTECTED] : Hello, Our ISP does not support IMAP with PHP. We requested them to enable IMAP support but they refused. Is there any other way we can use the IMAP functions ? Can we take the functions from the PHP Source and include it in our PHP files ? Pl. help . Regards Carry Carry Ian e-mail: [EMAIL PROTECTED] -- Get real solutions to all your problems. http://www.salahkarindia.com - India's first advisory Portal Your friend, advisor, healer,companion!!! Register now to get free advice on all your problems. -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Woah
It is no more obscure than a #define in a C file, which is the way this construct is most commonly implemented...but, as I said, I would rather see [this]...than to see _() stay. I don't like it. But it is less offensive to me than _() is... On Tue, 11 Sep 2001, Hartmut Holzgraefe wrote the following to Joey Smith : Joey Smith wrote: I would rather see something to the effect of use strict; (as in perl) that can be defined (per site/directory/namespace/SOMETHING...) to mean use gettext on all calls to print than to see _() stay. now tell me how *that* isn't obscure if you happen to be looking at some piece of code (maybe due to an error message with line number) without recognising this statement at the top ... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Woah
No, actually. I find syntax highlighting both annoying and distracting. I hope you're not terribly surprised by my answer. :) I would rather see something to the effect of use strict; (as in perl) that can be defined (per site/directory/namespace/SOMETHING...) to mean use gettext on all calls to print than to see _() stay. On Mon, 10 Sep 2001, Wez Furlong wrote the following to Joey Smith : On 10/09/01, Joey Smith [EMAIL PROTECTED] wrote: I would love if every C developer in the world would stop using this. I doubt that's going to happen anytime soon...but at least I can voice my opinion here, what people at least hear me out, if they don't exactly *hear* me. :) I hear you, but sadly I don't think this will ever be changed :-( It's a bad idea. Always. No matter what language you are using. No matter what kind of library you are talking about. Making things this complex into such an easy thing to overlook is a good way to hurt and frustrate your users, and your fellow coders. Is gettext() *REALLY* that hard to type? I find that really, really hard to believe. It's not just the typing factor, it's the readability factor. Yes, gettext tells you what it does but it gets in the way. Do you use syntax highlighting in your code editor of choice? I do, and I find that I take in a lot of the syntactic information almost on a sublimininal level; my brain doesn't have to work as hard to understand the grammar so I can spend more time understanding what the code does. If I turn off the highlighting, or if it is not available (like running vi over telnet) it is that much harder to work with the code. To a certain extent shortening gettext() to _() is the same; think about it for a moment (you don't have to like it! ;-) If I gave you a piece of paper that had the word gettext tiled in the background with the code printed over the top you'd find it hard work to read the code. I know it's not exactly the same thing, but I'm just highlighting why I prefer _() in this case. The sheer quantity of gettext calls does make it unwieldy to use the full function name. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Regarding the code audit
There are quite a few warnings generated which are semi-bogus, because the tool being used is picking up PHP function names like chmod() and chown()while there *are* potential problems here (see TSRM/tsrm_virtual_cwd.h), the situation is not as bad as it appears... On the other hand, the suggested fixes (ie, using fchown()) require a file descriptor being passed in, which will require quite a bit of changes to the underlying API (IIUC), so things may just be worse than they appear! :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Woah
These are two of the most ridiculous statements I have *EVER* heard anyone make. Cleaning up a language is a benefit worth paying in price for. How many millions of lines of C code had to be re-written when the ANSI standard was published? And I'm not personally sure, but I'd be willing to bet that the same thing happened once C++ was standardized. There's 2 *VERY* big examples. But even if these examples *WEREN'T* there, it makes me question your intelligence to read this email. Let me try and rephrase, so you can see how this sounds: Look, if no one else out there has had the balls or the brains to forbid this kind of behavior, it doesn't matter whether it's wrong or not, we should be good little sheep and follow along. This is either the stupidest, or the most cowardly email I have read on php-dev to dateI just can't decide which. Inconveniencing your long-time users in the name of language purity is, IMHO, just plain stupid. SNIP And I personally am not sure why the 'get rid of _' faction is failing to see that doing so would be a language REGRESSION, not a step forward. Please tell me of some examples in other languages in which long-time warts with thousands of users have been removed in later versions in the name of 'language purity.' If you can name some, cool; I will be less ignorant, and might reconsider my position. Otherwise, d'you think PHP should be *that* kind of groundbreaker? :-) Look, I think there is no question that removing '_()' is going to BREAK some users. I do not see how anyone can consider that a Good Thing. I suggest that it be left in, and documented more clearly, and the documentation updated to say 'the use of gettext() is highly recommended and preferred over that of _()'. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Woah
Yes, it bothers me. If it stays, I suppose I'll accept it, but it is such a horrendously bad idea that could easily be done in user-space insteadthis is *NOT* the kind of thing that should be encouraged on a language level. On Fri, 7 Sep 2001, Rodent of Unusual Size wrote the following to PHP...: * On 2001-09-07 at 23:06, Joey Smith [EMAIL PROTECTED] excited the electrons to say: So let's be the first ones to get our heads on straight and get rid of this ridiculous concept. It is, IMHO, one of the worst ideas in the history of the world...I'd really rather be reading perl regular expressions than this. Um, it has been around since sometime in version 3. Have you noticed it before? Has it bothered you? I think at this point it should be considered a legacy exception. Getting rid of it is going to break a lot of existing *user* scripts. Doing that to them for the sake of language elegance hardly sounds like a good idea to me.. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Woah
No, I haven't, but let me get this straight: You're saying that if something is a bad idea, that the more often it is used, the less bad [1] it becomes? [1] Yes, I know this is improper...but think about it in context. I'm trying to illustrate the point. On Fri, 7 Sep 2001, Chuck Hagenbuch wrote the following to Joey Smith : Quoting Joey Smith [EMAIL PROTECTED]: So let's be the first ones to get our heads on straight and get rid of this ridiculous concept. It is, IMHO, one of the worst ideas in the history of the world...I'd really rather be reading perl regular expressions than this. I know that backwards compatibility is a pain in the ass, but you might want to consider that this has been around ever since the gettext extension was introduced, before launching the next crusade. Just out of the curiosity, have any of the people jumping on the bandwagon to bash this ever actually _used_ gettext at any kind of scale? -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] The rand() can of worms
Replied to Sterling off-list. I really just want to get all of this resolved so those of us who are on the sidelines on this one can get back to work. :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #13137 Updated: CVS incompatible with autoconf2.13 (AC_LANG_POP)
Wow, everyone touched that one! :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] The rand() can of worms
I realize I'm (as one person put it) [stepping] right into the line of fire on this, but I want to resolve the issues with Jeroen's big rand() patch. From what I can tell, there are 3 camps: 1) Leave it, let Jeroen fix it. We know it is broken, but we're willing to wait for Jeroen to get through school orientation so that he has time to fix it. 2) Revert the whole big mess. This camp seems to have an internal split. Some of them hate the idea of the patch entirely for things like BC, while others just seem upset with the way the patch was merged with (what appears to be) very little peer review (no matter who is at fault...I don't really care. :) We'll call these 2A and 2B respectively. 3) Just like any other bug: Those who are bothered by it, fix it The reason I'm writing this is because I'm in the third camp. I could care less if it gets reverted or fixed, really...I just want PHP to *work*. If it's going to stay, we should *all* be able to pitch in and fix it...I really don't want to wait around. I wouldn't wait around when Sybase-CT was broken even *much* smaller ways...even when I had to teach myself C in my spare time! This is Open Source...if it's broken, I get to fix it! That's the whole *point*, isn't it? Personally, I'm not bothered by the way in which backwards compatibility is destroyed by this patch, because I think it actually behaves more like most people expect rand() to now... Good points: 1) no need to seed the generator 2) use mt_rand by default Bad points: 1) Leaks 2) Inconsistent style 3) Really bizzare macros, etc. So, just to make my compile here happier (bcz I don't want to check out older CVS just to continue working), I have tried to fix some of the bad points. Since it is not clear to me yet which of the above camps is going to hold sway on this issue, I'm not going to commit them to CVS...but I *will* provides diffs for anyone who asks. After having thrown myself into the middle of a heated debate, I think I'm going to ignore php-dev for a few days until I'm ready to face the firestorm I know I'm stirring up. When the smoke clears, somebody please let me know. :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Rand
Ditto. I have no conceptual issues with Jeroen's patch, but I would have preferred a please review on the branch before comitting to HEAD. I like Zeev's suggestions. Is someone already on it, or should I get started? ;) Jeroen, I was waiting for you tell us the branch was stable before I began even LOOKING at it. Sorry about the confusion. On Mon, 3 Sep 2001, Sebastian Bergmann wrote the following to...: Rasmus Lerdorf wrote: When he merged his branch into the HEAD branch everyone suddenly noticed because everyone keeps track of the HEAD branch. That's the point, I think. I for one expected Jeroen to post a message like I'm done with my rewrite, have a look at the branch, or something like that. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Where is the bug in #13067?
As I commented in bug #13067, it's not clear whether the manual or the
source is correct...Whichever it is, I think this patch may be the right
way to move from returning an int to returning a bool...
Index: db.c
===
RCS file: /repository/php4/ext/db/db.c,v
retrieving revision 1.64
diff -u -r1.64 db.c
--- db.c14 Aug 2001 17:46:17 - 1.64
+++ db.c31 Aug 2001 00:09:27 -
@@ -549,7 +549,6 @@
{
pval *id, *key, *value;
dbm_info *info;
- int ret;
if (ZEND_NUM_ARGS()!=3||zend_get_parameters(ht, 3, id, key, value) ==
FAILURE) {
WRONG_PARAM_COUNT;
@@ -563,8 +562,11 @@
RETURN_FALSE;
}
- ret = php_dbm_replace(info, Z_STRVAL_P(key), Z_STRVAL_P(value) TSRMLS_CC);
- RETURN_LONG(ret);
+ if (php_dbm_replace(info, Z_STRVAL_P(key), Z_STRVAL_P(value) TSRMLS_CC) == 0)
+{
+ RETURN_TRUE;
+ } else {
+ RETURN_FALSE;
+ }
}
/* }}} */
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Crash in var_dump and print_r
This may be due to the way domxml is doing things, but the test script in bug #10936 still creates a crash, and the backtrace points to zend_print_zval_r_ex...see attachment 1. Attachment 2 show that var_dump() gives more or less the same result. #0 0x81bf5d6 in zend_print_zval_r_ex (write_func=0x808d098 php_body_write_wrapper, expr=0x0, indent=8) at zend.c:203 #1 0x81bf5c4 in zend_print_zval_r (expr=0x0, indent=8) at zend.c:197 #2 0x81bf22b in print_hash (ht=0x86f5824, indent=4) at zend.c:111 #3 0x81bf66a in zend_print_zval_r_ex (write_func=0x808d098 php_body_write_wrapper, expr=0x86e71a4, indent=0) at zend.c:211 #4 0x81bf5c4 in zend_print_zval_r (expr=0x86e71a4, indent=0) at zend.c:197 #5 0x8133c00 in zif_print_r (ht=1, return_value=0x86f4c24, this_ptr=0x0, return_value_used=0) at basic_functions.c:2176 #6 0x81eb8aa in execute (op_array=0x86cb5a4) at ./zend_execute.c:1590 #7 0x81c05f4 in zend_execute_scripts (type=8, file_count=3) at zend.c:807 #8 0x808df0f in php_execute_script (primary_file=0xbbac) at main.c:1310 #9 0x808b79c in main (argc=3, argv=0xbc3c) at cgi_main.c:737 #0 0x8172a40 in php_var_dump (struc=0x8700a30, level=3) at var.c:67 #1 0x8172a0d in php_array_element_dump (zv=0x8700a30, num_args=1, args=0xbfffe56c, hash_key=0xbfffe540) at var.c:55 #2 0x81c5cd2 in zend_hash_apply_with_arguments (ht=0x86f5824, destruct=0x81729a0 php_array_element_dump, num_args=1) at zend_hash.c:714 #3 0x8172c67 in php_var_dump (struc=0x86c3024, level=1) at var.c:93 #4 0x8172ddd in zif_var_dump (ht=1, return_value=0x86f4c24, this_ptr=0x0, return_value_used=0) at var.c:132 #5 0x81eb8aa in execute (op_array=0x86cb5a4) at ./zend_execute.c:1590 #6 0x81c05f4 in zend_execute_scripts (type=8, file_count=3) at zend.c:807 #7 0x808df0f in php_execute_script (primary_file=0xbbac) at main.c:1310 #8 0x808b79c in main (argc=3, argv=0xbc3c) at cgi_main.c:737 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Crash in var_dump and print_r
OK, I'll track it down. Thanks. On Sun, 26 Aug 2001, Zeev Suraski wrote the following to Joey Smith : It looks like domxml is responsible here. The hash table that's sent to it contains a NULL value, which should be a valid zval *... Zeev At 13:04 26-08-01, Joey Smith wrote: This may be due to the way domxml is doing things, but the test script in bug #10936 still creates a crash, and the backtrace points to zend_print_zval_r_ex...see attachment 1. Attachment 2 show that var_dump() gives more or less the same result. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] about domxml api-change in 4.0.7
I've since looked at it, and I fixed #1 and #3. The other two issues are not going away any time soon... (that is, 2 and the issue Christian raised). On Mon, 20 Aug 2001, Christian Stocker wrote the following to...: On Mon, 20 Aug 2001, Colin Viebrock wrote: FWIW, I've needed to hack my code to handle three differences between the 2 different API versions. To be honest, I can't keep track of which API was in which release of PHP, so I'll just call them API A) and API B). 1) Names of tags: API A) $node-name API B) $node-tagname 2) Tag attribute value: API A) $node-children[0]-content API B) $node-value 3) Is a node a text node: API A) $node-type == XML_TEXT_NODE API B) strtolower(get_class($node)) == 'domtext' i have one more :) content of a node API A) $node-content API B) $node-children()-content (that does not work this way, but you get the idea...) I haven't installed libxml 2.4.2 and PHP 4.0.7rc1 yet, but I'm wondering if someone can tell me which API version is in use? This script should tell you: it's API B) as far as i know chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] mysql_fetch_xml
I agree with Brian on this. The only way I can see it being a good idea to have this in a module is if it were made part of the dbx extension, or maybe a PEAR C module... On Thu, 23 Aug 2001, Brian Moon wrote the following to Eliot Shepard : This is a very neat function. I may be able to use it. Having said that I think it is best left as a userland function. Brian Moon -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] pif
I considered exactly this, before coming to the same conclusion as Andrei. :) +1 On Wed, 22 Aug 2001, Zeev Suraski wrote the following to Jeroen van Wolffelaar : How about phf_, for PHP Helper Function? I see a point in differentiating language level API functions (e.g. like output buffering) and module-specific helper functions (e.g., like php_mysql_do_connect()). Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] about domxml api-change in 4.0.7
On Mon, 20 Aug 2001, Colin Viebrock wrote the following to [EMAIL PROTECTED]: I haven't installed libxml 2.4.2 and PHP 4.0.7rc1 yet, but I'm wondering if someone can tell me which API version is in use? This script should tell you: By your script, B is in use for 4.0.7. I'm going to look at this tonight, perhaps we can merge the 2 somehow before .7 goes final... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] about domxml api-change in 4.0.7
Christian: The only change that I am aware of is the removal of half of the aliases that domxml used to use. For example, previous versions had both $node-tagname and $node-tag_name, which both returned the same structure. I have removed all of the former in favor of the latter, to hold to PHP conventions. Given the chance to think about it, you're right, there should have been some mention in NEWS about the work going on in domxml, but as it has been more or less completely broken for 2 point releases, I wasn't concerned at the time. What is the old API that you are referring to (ie, what PHP version)? On Sat, 18 Aug 2001, Christian Stocker wrote the following to...: Hello it looks like the new domxml-extension (and therefore a api-change) got into 4.0.7RC1. I still find it quite unfortunate to have this api-change in a minor release, but first the manual says, it's experimental and second i found a way, to write my code to work with the new and the old extension (bloats the code a little bit, but it works...) But could someone please at least make a note about that in the NEWS file. I think, a lot of people are using the domxml-extension and if it's not in the NEWS-file, they won't notice it and are surprised, that their scripts do not work anymore... BTW, i'm not sure if one can call it an api-change, since the functions did not change, but the structure of the returned values ... ($node-tagname instead of $node-name for example) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #12795 Updated: php-4.0.7RC1: make error
Bump it. 2.4.0 looks solid. On 18 Aug 2001, [EMAIL PROTECTED] wrote the following to [EMAIL PROTECTED] : ID: 12795 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Assigned Old Bug Type: Compile Failure Bug Type: DOM XML related Operating System: rh 7.2 PHP Version: 4.0.6 Old Assigned To: Assigned To: sniper New Comment: This is cause by too old libxml version. Now waiting for replies what whether we require newer version or not. --Jani Previous Comments: [2001-08-16 11:27:12] [EMAIL PROTECTED] ./configure \ --with-mysql=/usr/local \ --disable-pear \ --enable-track-vars \ --enable-debug \ --disable-magic-quotes \ --enable-ftp \ --with-gettext \ --with-xml \ --with-dom \ --enable-wddx \ --with-curl \ --with-pgsql \ --with-zlib \ --enable-versioning \ --enable-sockets \ --with-openssl \ --with-snmp \ --with-readline \ --with-mcrypt ... php_domxml.c: In function `php_xpathptr_eval': php_domxml.c:2719: `XPATH_XSLT_TREE' undeclared (first use in this function) php_domxml.c:2719: (Each undeclared identifier is reported only once php_domxml.c:2719: for each function it appears in.) make[3]: *** [php_domxml.lo] Error 1 make[3]: Leaving directory `/usr/local/sources/php-4.0.7RC1/ext/domxml' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/sources/php-4.0.7RC1/ext/domxml' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/sources/php-4.0.7RC1/ext' make: *** [all-recursive] Error 1 Edit this bug report at http://bugs.php.net/?id=12795edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: cvs: php4 / NEWS
I thought Jani already did?? On 18 Aug 2001, [EMAIL PROTECTED] wrote the following to [EMAIL PROTECTED] : Zeev Suraski [EMAIL PROTECTED] wrote: +?? ??? 200?, Version 4.0.8-dev +- Fixed a crash in dbase_replace_record (Patch by [EMAIL PROTECTED]). is there a reason not to merge this into the 4.0.7 branch? jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: cvs: php4 / NEWS
Yup... sniper Thu Aug 16 20:48:34 2001 EDT Modified files: (Branch: PHP_4_0_7) /php4/ext/dbase dbase.c Log: MFH He just didn't MFH the NEWS entry... On Sat, 18 Aug 2001, Joey Smith wrote the following to [EMAIL PROTECTED] : I thought Jani already did?? On 18 Aug 2001, [EMAIL PROTECTED] wrote the following to [EMAIL PROTECTED] : Zeev Suraski [EMAIL PROTECTED] wrote: +?? ??? 200?, Version 4.0.8-dev +- Fixed a crash in dbase_replace_record (Patch by [EMAIL PROTECTED]). is there a reason not to merge this into the 4.0.7 branch? jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] about domxml api-change in 4.0.7
That will change shortly. On Sat, 18 Aug 2001, Christian Stocker wrote the following to...: On Sat, 18 Aug 2001, Jani Taskinen wrote: DOMXML is an experimental extension. So you can expect it to change still..Your mileage may vary :) e.g. In 4.0.7 the required libxml version will be 2.4.2. mmmh, JFYI, i have here only 2.4.1, but it seems to work with no problems. chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Linux Today Article
(And other .NET is the death knell for Open Source articles...) I guess I am just missing something, but how can ANYTHING kill Open Source in general, or PHP in specific? There is no way that .NET is going to be a silver bullet solution that solves every possible problem in the most efficent, intelligent, reusable, buzzword buzzword buzzword. Even if it were, SO WHAT? Linux more or less popularized the Open Source movement, but the movement itself is OLD. It's an idea, not a list of products or companies. If RedHat, Zend, VA, Andover, and all the others were to disappear tomorrow, who here would toss their hands up in the air, and roll over whimpering? Not I. And I doubt any of you would, either. Otherwise, you wouldn't be here to begin with...you'd be off writing VB Applications, selling your soul to corporate America. Open Source isn't going anywhere. I don't care if it ever takes over the world, becuase I know that, in the WORST CASE, I will be the LAST Open Source developer in the face of the whole earth. In such a case, I *STILL* have the source code to ALL of my tools (via Debian Source CD's, etc.) All of you could disappear forever tomorrow, and it might slow things down quite a bit, but it's NOT GOING TO DIE. The cat is already out of the bag. People already see that in some cases, opening the code *IS* the right thing to do. Personally, I would argue that it is the right thing in *ALL* cases, but that's an issue for another time...like the Founding Fathers of the United States, I don't agree with the concept of Intellectual Property, and that's all I will say on it for now. :) Am I missing something? Why should we care what .NET can do, other than to use it the way ALL other languages should be used: learn from their mistakes, steal all their really useful ideas, and always always always try to do it better than the other guy? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Output Compression Issues
On Thu, 16 Aug 2001, Troels Arvin wrote the following to [EMAIL PROTECTED] :
#if 0
} else {
char lenbuf[64];
sprintf(lenbuf,Content-Length: %d,Z_STRLEN_P(return_value));
sapi_add_header(lenbuf,strlen(lenbuf), 1);
#endif
What does #if 0 actually mean?
#if 0
means the compiler will NEVER reach this code. Usually signifies
something that the developer knows is only half implemented, or
something.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Memory leaks in CGI (latest CVS)
When you call the CGI against a script that does not exist, it seems to bail out too soon, or something, becuase an awful lot of stuff never gets cleaned up... I snipped the references to script=non-existant script... mbstring.c(457) : Freeing 0x086D0E24 (20 bytes), zend_hash.c(176) : Freeing 0x086D35A4 (32 bytes), Last leak repeated 10 times php_sybase_ct.c(347) : Freeing 0x086D0DE4 (8 bytes), zend_hash.c(260) : Freeing 0x086D34A4 (44 bytes), Last leak repeated 117 times main.c(1157) : Freeing 0x086D33A4 (44 bytes), zend_API.c(561) : Actual location (location was relayed) main.c(1156) : Freeing 0x086D0DA4 (12 bytes), main.c(1139) : Freeing 0x086D1D24 (44 bytes), zend_API.c(561) : Actual location (location was relayed) main.c(1138) : Freeing 0x086D0D64 (12 bytes), main.c(1227) : Freeing 0x086D0D24 (12 bytes), zend_hash.c(404) : Freeing 0x086D1AA4 (35 bytes), main.c(1209) : Freeing 0x086D1A24 (29 bytes), main.c(1206) : Freeing 0x086D0CE4 (12 bytes), main.c(1194) : Freeing 0x086D1924 (44 bytes), zend_API.c(561) : Actual location (location was relayed) main.c(1193) : Freeing 0x086D0CA4 (12 bytes), php_variables.c(170) : Freeing 0x086D0C64 (12 bytes), Last leak repeated 66 times zend_hash.c(438) : Freeing 0x086CBC24 (256 bytes), Last leak repeated 1 time string.c(2415) : Freeing 0x086D0BE4 (11 bytes), Last leak repeated 66 times main.c(1020) : Freeing 0x086CF124 (44 bytes), zend_API.c(561) : Actual location (location was relayed) main.c(1019) : Freeing 0x086CAEA4 (12 bytes), php_variables.c(230) : Freeing 0x086CF0A4 (44 bytes), zend_API.c(561) : Actual location (location was relayed) Last leak repeated 1 time php_variables.c(229) : Freeing 0x086CAE64 (12 bytes), Last leak repeated 1 time main.c(1117) : Freeing 0x086C8824 (44 bytes), zend_API.c(561) : Actual location (location was relayed) main.c(1116) : Freeing 0x086CA064 (12 bytes), SAPI.c(392) : Freeing 0x086C87A4 (28 bytes), zend_ptr_stack.c(29) : Freeing 0x086CB424 (256 bytes), Last leak repeated 2 times zend_stack.c(27) : Freeing 0x083CFC24 (256 bytes), Last leak repeated 6 times zend_llist.c(36) : Freeing 0x0839F024 (23 bytes), Configure line: ./configure \ --with-sybase-ct=/usr/local/sybase \ --enable-dmalloc \ --enable-dbase \ --enable-bcmath \ --enable-calendar \ --with-db3=/usr/local/BerkeleyDB.3.0 \ --enable-ftp \ --with-imap=/usr \ --with-mhash \ --with-mysql \ --with-pdflib \ --enable-shmop \ --with-mm \ --enable-sockets \ --enable-sysvsem \ --enable-sysvshm \ --enable-inline-optimization \ --enable-debug \ --with-zlib-dir=/usr \ --with-zlib \ --enable-ctype \ --with-pgsql \ --with-readline \ --enable-xslt --with-xslt-sablot \ --with-mm \ --enable-shmop \ --enable-sysvsem \ --enable-sysvshm \ --enable-wddx \ --enable-inline-optimization \ --with-dom \ --with-mod_charset \ --with-openssl=/usr/local/openssl \ --disable-short-tags \ --with-bz2 \ --enable-exif \ --with-ldap \ --enable-mailparse \ --enable-yp -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Setting up RFC
This is why I sort of dropped the subject. I've been waiting until I have time to look into Python's PEP system in depth, and see what it requires. Thanks to Jon for pointing it out. :) - Original Message - From: Jon Parise [EMAIL PROTECTED] To: Jeroen van Wolffelaar [EMAIL PROTECTED] Cc: PHP Developers Mailing List [EMAIL PROTECTED]; Joey Smith [EMAIL PROTECTED]; Zak Greant [EMAIL PROTECTED] Sent: Tuesday, August 14, 2001 4:58 PM Subject: Re: [PHP-DEV] Setting up RFC On Wed, Aug 15, 2001 at 12:18:06AM +0200, Jeroen van Wolffelaar wrote: About a month ago there was a discussion on the Engine 2 mailing list, about a possible RFC-proces for the more imporant PHP-issues. In the end, there was some consensus that it would be good if such a system exists. I thought the idea was sound, too, and suggested we mimic Python's PEP (Python Enhancement Proposal) system: http://python.sourceforge.net/peps/ -- Jon Parise ([EMAIL PROTECTED]) . Rochester Inst. of Technology http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Setting up RFC
On Tue, 14 Aug 2001, John Donagher wrote the following to [EMAIL PROTECTED]: With what end in mind is an RFC to be created for? In the IETF, RFC's are typically long, complex, and authoritative. They are often referenced for years after their inception. Do you honestly think we could (or want to) achieve this with PHP feature RFC's? Or will they be used only before initial feature implementation, then quickly outdated and discarded? That is my biggest problem with documents: they take a lot of effort to create, are often difficult to grok, and _almost always_ have a very short lifecycle. PHP feature RFC != IETF RFC's. Go back and read my original proposal on the issue. What I had in mind was something more like what Perl has done with the Perl 6 RFC's, or (perhaps) the PEP's of Python... The point being that there is a LOT of discussion on certain topics, and people often change sides on an issue over the life of the discussion. I was simply trying to say Let's make this a *bit* more orderly., mainly becuase I had already lost track of several of the then-current threads on the zend-engine list. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Setting up RFC
+1: Strongly Support +0: Support 0: Neutral -0: Oppose -1: Strongly Oppose Are you doing a new O'Reilly book, PHP-DEV in a nutshell? -Sterling I especially enjoy the idea of positive zero and negative zero. :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #12505: array_sum function total calculate error
Confirmed with CVS a/o July 20th. On Wed, 1 Aug 2001, Heikki Korpela wrote the following to [EMAIL PROTECTED]: On 1 Aug 2001 [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Operating system: Red Hat Linux 7.1 PHP version: 4.0.4pl1 PHP Bug Type: Arrays related Bug description: array_sum function total calculate error $tt=array(382478633,367687181,452504275,471367521,848270658,1181944543); $total_tt=array_sum($tt); echo Total_tt=.$total_tt; // Prints Total_tt=-590714485 Must be 3704252811. Confirmed on: i386 / OpenBSD-current / PHP 4.0.6 (from OpenBSD ports tree) i386 / RH 7.1 / PHP 4.0.5 (from RH Rawhide) i386 / RH 7.0 / PHP 4.0.5 (from Arvin's 4.0.5 RPMS) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #11489 Updated: Sybase query result is gettingdestructed
Paul: Right. It seems the other situations that caused the bug to appear have closed, but I still intend to apply your patch as soon as I have a spare moment. Thanks. :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Reworking DOMXML
OK, for those who actually commented, there seems to be a consensus. Glad I asked. :) On Thu, 19 Jul 2001, Colin Viebrock wrote the following to Paul Marquis,...: I prefer style #1 as well -- it preserves backward compatability and is consistent with the libxml2 docs. Plus, it is then similar to other PHP functions that use an object or handle as the first argument (e.g. mysql_, fopen, fwrite, curl, etc.). - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] ext_skel and php_extname.c vs. extname.c
I had thought the decision was that php_extname.c was the correct way to name the .c file for an extension, so that we are less likely to conflict with any files from the package itself? ext_skel creates a .c file using the bare extname. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Reworking DOMXML
There needs to be a decision made in order to complete the work on domxml, as it currently stands. I think it is a good idea to keep both the procedural and object oriented interfaces in the code. The way the module is currently written, it will take the least amount of work to just require the user to pass a valid XML object to the procedural calls. I would like to be consistent across the board on where we expect this object to be passed, and I see to ways to do it, each with their pro's and con's, so I thought I would ask for input before I went too much farther down the road I'm currently following. Style #1: The dom_document object is always the FIRST parameter to the function, if called as a procedure and NOT as a method on a dom_document object. Pro: This seems cleaner, as the user will ALWAYS know where the object belongs. Con: This might confuse the oop users, as the documentation does not currently clearly distinguish the two interfaces. Style #2: The dom_document object is always LAST. Pros: Simplest to implement with code as it currently stands. Seems to be the way many other functions have been written. Cons: User will have to remember all arguments of all functions and pass SOMEthing, even if that means passing NULLs or something. Position of dom_document becomes a moving target. Does anyone have any input? I'm currently leaning towards the 2nd style... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] CVS is broken??
I'm getting the following error trying to compile latest CVS: undefined reference to `_zval_ptr_dtor_wrapper' This appears a number of times. I am about to go searching in the Zend CVS to see if I can find what broke it, but thought maybe someone out there might already know... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Restructuring the PHP Group
Is this a dead issue, or were we ever going to finish this? Is James still gone on vacation? On Tue, 10 Jul 2001, Zeev Suraski wrote the following to Joey Smith : At 03:22 10/7/2001, Joey Smith wrote: Has it ever been considered that it may be time to restructure the PHP Group, if nothing else than bringing in some new blood? I think bringing in new blood is not enough. It should be restructured. James had a pretty clear view of how it should look (as a basis for discussion) - but he's on vacation right now. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Crash in php_fopen_with_path
I'm not sure what I've done to cause this...I ran ../php -f Config.php
from srcdir/pear. I have an old PEAR install under
/usr/local/lib/php, and my include path is .:/usr/local/lib/php.
Here's the back trace.
#0 0x40369567 in memcpy (dstpp=0x8505bb9, srcpp=0x8505a64,
len=4294967295) at ../sysdeps/generic/memcpy.c:55
#1 0x80998e0 in php_fopen_with_path (filename=0x8505ae4 PEAR.php,
mode=0x8336563 rb, path=0x8335f95 .:/usr/local/lib/php,
opened_path=0xbfffea0c) at fopen_wrappers.c:486
#2 0x8099ca8 in php_fopen_url_wrapper (path=0x8505ae4 PEAR.php,
mode=0x8336563 rb, options=1, issock=0xbfffe940,
socketd=0xbfffe93c, opened_path=0xbfffea0c) at fopen_wrappers.c:585
#3 0x80990e2 in php_fopen_wrapper (path=0x8505ae4 PEAR.php,
mode=0x8336563 rb, options=1, issock=0xbfffe940,
socketd=0xbfffe93c, opened_path=0xbfffea0c) at fopen_wrappers.c:278
#4 0x809762f in php_fopen_wrapper_for_zend (filename=0x8505ae4
PEAR.php, opened_path=0xbfffea0c) at main.c:508
#5 0x81c7016 in execute (op_array=0x8507424) at ./zend_execute.c:2062
#6 0x8198074 in zend_execute_scripts (type=8, file_count=3) at
zend.c:752
#7 0x809893f in php_execute_script (primary_file=0xbb7c) at
main.c:1282
#8 0x80966bc in main (argc=3, argv=0xbc0c) at cgi_main.c:741
The attached patch turns it from a crash to a leak, as below:
[Mon Jul 16 06:06:48 2001] Script: 'Config.php'
---
fopen_wrappers.c(530) : Block 0x08505B00 status:
Beginning: OK (allocated on fopen_wrappers.c:479, 21 bytes)
End: Overflown (magic=0x666E6F43 instead of 0x2A8FCC84)
At least 4 bytes overflown
---
fopen_wrappers.c(479) : Freeing 0x08505B24 (21 bytes),
script=Config.php
Perhaps someone who better understands the fopen magic could take a look
at this one?
Index: fopen_wrappers.c
===
RCS file: /repository/php4/main/fopen_wrappers.c,v
retrieving revision 1.123
diff -u -r1.123 fopen_wrappers.c
--- fopen_wrappers.c15 Jul 2001 12:24:06 - 1.123
+++ fopen_wrappers.c16 Jul 2001 12:08:54 -
@@ -483,6 +483,7 @@
#else
pathbuf[path_length] = ':';
#endif
+ if (exec_fname_length 0) { exec_fname_length = strlen(exec_fname); }
memcpy(pathbuf+path_length+1, exec_fname, exec_fname_length);
pathbuf[path_length + exec_fname_length +1] = '\0';
} else {
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] ext/dom/php_domxml.c patch
Well, xmldocfile() is fixed in HEAD, and I'm closing in on some memory leaks...Paul, if possible, I may want to collaborate with you some, because we seem to be working in the same areas of the code, and I could use the help. On Wed, 11 Jul 2001, Andi Gutmans wrote the following to Paul Marquis and...: At 07:00 PM 7/10/2001 -0400, Paul Marquis wrote: Attached is a patch to ext/dom/php_domxml.c that adds the ability to set the context node when running xpath_eval(). xpath_eval() (and xpath_eval_expression()) can now accept and optional second parameter that is the context node. If no argument is specified, it works as before. This patch is against the head of the CVS tree. I also have a patch for the 4.0.6 version of this file for those who need/want it. BTW, has a decision been made about what interface to domxml will be in the next release of PHP? This is a good question. For 4.0.6 we rolled back DOM/XML. What do you think should be done for 4.0.7? Will 4.0.6 users be able to upgrade? What is the status of the module today vs. before? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #11997: PHP Won't work on XP 2
Thanks, Phil! I apologize...I have been unable to duplicate the error, myself, so I've never seen the error...:) On Tue, 10 Jul 2001, Phil Driscoll wrote the following to Joey Smith and...: On Tuesday 10 July 2001 04:24, Joey Smith wrote: Geez...is this not in the FAQ? It really should be... Perhaps, for the next installer, this msg could be modified to: Unable to configure webserver, due to a missing OCX control on your system, the install Wizard is unable to configure your web server. However, PHP has been sucessfully installed. For more information, please see insert FAQ URL. PLEASE DO NOT POST THIS TO THE BUG DATABASE! Well - as it happens, the error message in full actually reads Due to a missing OCX control on your system, the installation Wizard is unable to configure your web server. However, PHP has been successfully installed, and all you need to do now is manually configure the web server as described in the install.txt file which can be found in your php installation directory. Which, surprisingly, is exactly what the user needs to do! -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] zend_hash patch
Andi: I really want to give it a shot, but my compile box is isolated from the rest of the world until my ISP gets their heads back on straight. On Tue, 10 Jul 2001, Andi Gutmans wrote the following to [EMAIL PROTECTED] : Hey, Has anyone had a chance to check the zend_hash patch I wrote about yesterday? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] tsrm patch
Shane: I just want to say it's good to hear from you again! :) On Sun, 8 Jul 2001, Shane Caraveo wrote the following to Andi Gutmans : Hi Andi, Here is yet another patch to tsrm. The popen implementation was broken. You could not write to a process because pclose did not wait for a process to end, and the executed process could hang, because both sides of the pipe were inheritable. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [UPDATE] NGScan
Zak: Thank you for expressing my thoughts exactly. We all get pissy once in a while, and there seems, for the most part, to be a inverse relation between intelligence and patience. Zeev: I understand your frustration. I really do. There have been times when just about EVERYONE in the PHP Group has shocked me, or made me, to be honest, wonder if I even belong here. I'm often afraid to ask question, simply because I'm a self-taught coder...I didn't even graduate from High School! Because of that, I hestiate to address certain things with you, or Andi, or Sascha, because you can all tend to be a bit abrasive. Yes, you seem to have improved, for the most part. Sascha hasn't. So what, really, should be done about it? The only resolution, IMHO, is the one all of us have to take when addressing any of the PHP Group...be patient, and realize that there are going to be clashes. Sascha: You can be a bit abrasive. I'd be terribly surprised if others had not mention this to you. Perhaps it would not be quiet so bad to rethink sometimes, before you push that Send button (or keystroke, or whatever?) If not for yourself, think about the good of the projectthings like this take everyone's time away from what we REALLY love... On Mon, 9 Jul 2001, Zak Greant wrote the following to Rasmus Lerdorf, Zeev...: Everyone knows this issue - it gets dragged onto the list every couple of months or so... What result do you want out of this argument? Sascha's exile from the project? The other developers to rise up with torches and pitchforks, lynch Sascha and burn his lab... ;) Sascha, what do you think? A lot of people believe that you are a pain in the ass - do you like this? Do you think that it is un- justified? I think that the majority of developer don't want to lose either Zeev or Sascha and wish that these vicious fights did not happen so consistently. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [UPDATE] NGScan
Has it ever been considered that it may be time to restructure the PHP Group, if nothing else than bringing in some new blood? On Mon, 9 Jul 2001, Andi Gutmans wrote the following to Sascha Schumann : At 10:30 PM 7/9/2001 +0200, Sascha Schumann wrote: Sascha, don't come to conclusions too quickly if you do want to improve your weak spots. Andi, have you ever considered that your approach of guiding other people is not appreciated? Yes. That is what a guide is. He can try and guide you but it doesn't mean you have to appreciate the guidance nor take the advice. You are free to ignore whatever I write. Anyway, I think right now the easiest thing for us to do is to move to re2c without your sources (it should be relatively trivial as it's just a scanner and we wrote the original regex's) and allow for better communication to address the issues that were raised (both the team issues and the license issues) when things cool down a bit. I don't particularly like Andre's suggestion of keeping everything on group@ because I find that as time has gone by there are many active contributors on php-dev@ who have a right to be more involved in PHP. Actually I often find people in the community who are more involved in PHP than some on the PHP Group. So as I mentioned, it should be in a more diplomatic and constructive manner but I definitely think that the whole PHP Group is sacred way is not the right way. I think the PHP developers community have a lot of great ideas and great inputs (even if some of these are not things I necessarily agree with) and we should probably adjust our whole working mechanism. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #11997: PHP Won't work on XP 2
Geez...is this not in the FAQ? It really should be... Perhaps, for the next installer, this msg could be modified to: Unable to configure webserver, due to a missing OCX control on your system, the install Wizard is unable to configure your web server. However, PHP has been sucessfully installed. For more information, please see insert FAQ URL. PLEASE DO NOT POST THIS TO THE BUG DATABASE! :) On 10 Jul 2001, [EMAIL PROTECTED] wrote the following to...: From: [EMAIL PROTECTED] Operating system: Microsoft Windows XP Professiona PHP version: 4.0.6 PHP Bug Type: Unknown/Other Function Bug description: PHP Won't work on XP 2 Unable to configure webserver, due to a missing OCX control on your system, the install Wizard is unable to configure your web server. However, PHP has been sucessfully installed. I am running IIS 5.1. please help. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] What happened to cvs-daily?
Is it gone, or did I just get removed from the list somehow? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #11818 Updated: Using the PDF functions after July1st triggers an internal PDFlib error
That's the whole point. The code that generates the watermarks, or times out, or whatever, is based in pdflib's code (IE, pdflib.dll). It has nothing to do with our code. There is the question of whether or not we can ship pdflib.dll with PHP at all. I've asked the members of the PHP Group for input on this, as they are (hopefully) more qualified than I to decide, but in the interim, it remains a pdflib.dll issue, completely seperate from PHP. Assuming that we CAN ship pdflib.dll, the timeout issue will go away, but you will still (IIUC) have the watermarking issue... On Sat, 7 Jul 2001, Joao Prado Maia wrote the following to Joey Smith : On Fri, 6 Jul 2001, Joey Smith wrote: There are 2 parts that are required to make PDF's using pdflib. There is the pdflib code, and the PHP code that makes calls to the pdflib code. We can ship our own code, but not pdflib's. And that is what I'm talking about here. Changing only the PHP extension so this silly watermark string is not seen on the PDF's generated by PHP scripts. Am I correct that this is only a matter of compiling the PHP extension from source and creating a php_pdf.dll ? Of course, I'm supposing in all this that the code to generate the watermark is inside the PHP extension. Anyway, can this be done for future releases ? Joao -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #11818 Updated: Using the PDF functions after July1st triggers an internal PDFlib error
There are 2 parts that are required to make PDF's using pdflib. There is the pdflib code, and the PHP code that makes calls to the pdflib code. We can ship our own code, but not pdflib's. On Fri, 6 Jul 2001, Joao Prado Maia wrote the following to Joey Smith : Ok, I must be missing something really bad here then. What is this php_pdf.dll doing on my /extensions/ sub-directory ? Someone must have compiled that, huh. I downloaded the latest version of the pre-compiled PDFlib which comes with the compiled php_pdf.dll file, so it was just a matter of dropping the file on the /extensions sub-directory, but now I get a huge water mark with the 'www.pdflib.com' string in it. Am I still missing something here that you guys could compile the PDF extension from the Windows source code of PDFlib when making the Windows binary release of PHP ? Why is this illegal anyway ? I even took my time to open the license file of PDFlib source and it clearly stated on the Alladin Free Public License that you can re-distribute PDFlib non-commercially, which is what PHP is doing here. Why would compiling from source and distributing a version of PDFlib without that ridiculous water mark be such an issue ? I might be missing something really bad here, so I apologize if there is something really obvious that I'm overlooking. Joao -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #11818 Updated: Using the PDF functions after July1st triggers an internal PDFlib error
Surely you are kidding. I cannot see in any of our packages where we bundle the PDF library with our release. If we are, we should probably remove it. In either case, there is no way we can compile an unencumbered version of PDFLib. That would be illegal. PDFLib is not free, in the gratis sense. This is like making the fact that Win32 does not come with a free C compiler PHP's problem, based on the fact that you need one to compile your own binary. It's absolutely ridiculous. On Sun, 1 Jul 2001, Joao Prado Maia wrote the following to [EMAIL PROTECTED] : That is not true at all, if you bundle the PDF library with PHP releases on the Windows binary it starts being your problem too. I just went to pdflib.com and it seems to me that binary packages of pdflib for Windows have a demo / time limit. May I suggest to whoever packaged the Windows binary version of PHP to compile the source code of pdflib on Windows, so to create a limit free version of PDFlib ? Joao -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] switch, equality and preg_match
I can answer #2 for you... http://php.net/manual/en/language.types.type-juggling.php http://php.net/manual/en/language.types.string.php#language.types.string.conversion An excerpt from String Conversion: The value is given by the initial portion of the string. If the string starts with valid numeric data, this will be the value used. Otherwise, the value will be 0 (zero). It might be a good idea if switch didn't convert its types, but then that would be inconsistent with the rest of the language, so maybe not. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Karma request
*sg* Yes, I was in my anonymous tree. Sorry for the noise. On Fri, 29 Jun 2001, Rasmus Lerdorf wrote the following to Joey Smith : Can I get karma in ext/sybase and ext/sybase_ct again? You do -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] sybase-ct extension hangs when querying mssql
I have been unable to duplicate this when querying a sybase server. If someone could provide a MSSQL server that I can run some queries against in order to track down this bug, I will see what I can do to locate it. In the meantime, I don't think that it's wise to point people to FreeTDS as we know that there are compile problems with FreeTDS that are not going to be fixed before 4.0.7. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Réf. : [PHP-DEV] Possible bug in sybase-db?
Actually, I was recently in contact with Tom, it seems he no longer really is involved in PHP. I have been quietly working on quite a few things, but I don't really have a whole lot of time. On Tue, 26 Jun 2001, Jean-Claude Schopfer wrote the following to...: Joey Smith wrote : I just finished coding up a patch to sybase-ct to add charset support. I want to put it through a little more testing before I apply it.. Ah :))) but there's already a patch for this, see bug #11559 or #11320 Zeev / Tom: what is the TODO plan for sybase_ct ? which functions can be develloped ? (sybase_unbuffered_query is possible ?) @++ JC -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Totally Blue Sky
This is not what the GPL is for at all. The GPL only protects PHP itself, and even that does not preclude you from charging for PHP...it simply requires that you make the source available at no additional cost. On Mon, 25 Jun 2001, Brian Tanner wrote the following to Marc Boeren : I'm not sure you would be able to distribute a commercial application that is built around PHP commercially, could you? Isn't that what the GPL protects against? -Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] About ext/sockets/
Not to beat a dead horse, but I'm glad someone else noticed this. I almost went back to bed, thinking the whole world had gone mad. :) On Mon, 25 Jun 2001, Jani Taskinen wrote the following to Zeev Suraski : tagged as experimental makes it easier for us to change the API to a PHP-like API, even though it would have probably been the right thing to do even if it didn't have the experimental tag. BTW. Have you noticed that I am now the one against breaking BC and YOU want to do it? Did someone switch our brains or what? :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Possible bug in sybase-db?
Zeev:
I just finished coding up a patch to sybase-ct to add charset
support. I want to put it through a little more testing before I apply
it, but in the process, I found what appears to be a bug in the db
extension, and you seemed like the right person to talk to.
It all comes from hashed_details_length. If they specify a charset,
then hashed_details_length will be one byte too short...there is no
space allocated for the _ seperator in the hashed_details.
So I followed what seemed to be the conventional wisdom, and added one
byte to all cases, and added an extra _ at the end of cases 1-3.
Is this the correct way to do this? Was this even a bug, or are we
safe anyways?
I attached the patch so you could take a look at it.
Index: ext/sybase/php_sybase_db.c
===
RCS file: /repository/php4/ext/sybase/php_sybase_db.c,v
retrieving revision 1.16
diff -u -r1.16 php_sybase_db.c
--- ext/sybase/php_sybase_db.c 12 Jun 2001 05:28:40 - 1.16
+++ ext/sybase/php_sybase_db.c 26 Jun 2001 12:39:08 -
@@ -282,9 +282,9 @@
}
convert_to_string(yyhost);
host = yyhost-value.str.val;
- hashed_details_length = yyhost-value.str.len+6+3;
+ hashed_details_length = yyhost-value.str.len+6+4;
hashed_details = (char *)
emalloc(hashed_details_length+1);
-
sprintf(hashed_details,sybase_%s__,yyhost-value.str.val);
+
+sprintf(hashed_details,sybase_%s___,yyhost-value.str.val);
}
break;
case 2: {
@@ -297,9 +297,9 @@
convert_to_string(yyuser);
host = yyhost-value.str.val;
user = yyuser-value.str.val;
- hashed_details_length =
yyhost-value.str.len+yyuser-value.str.len+6+3;
+ hashed_details_length =
+yyhost-value.str.len+yyuser-value.str.len+6+4;
hashed_details = (char *)
emalloc(hashed_details_length+1);
-
sprintf(hashed_details,sybase_%s_%s_,yyhost-value.str.val,yyuser-value.str.val);
+
+sprintf(hashed_details,sybase_%s_%s__,yyhost-value.str.val,yyuser-value.str.val);
}
break;
case 3: {
@@ -314,9 +314,9 @@
host = yyhost-value.str.val;
user = yyuser-value.str.val;
passwd = yypasswd-value.str.val;
- hashed_details_length =
yyhost-value.str.len+yyuser-value.str.len+yypasswd-value.str.len+6+3;
+ hashed_details_length =
+yyhost-value.str.len+yyuser-value.str.len+yypasswd-value.str.len+6+4;
hashed_details = (char *)
emalloc(hashed_details_length+1);
-
sprintf(hashed_details,sybase_%s_%s_%s,yyhost-value.str.val,yyuser-value.str.val,yypasswd-value.str.val);
/* SAFE */
+
+sprintf(hashed_details,sybase_%s_%s_%s_,yyhost-value.str.val,yyuser-value.str.val,yypasswd-value.str.val);
+ /* SAFE */
}
break;
case 4: {
@@ -333,7 +333,7 @@
user = yyuser-value.str.val;
passwd = yypasswd-value.str.val;
charset = yycharset-value.str.val;
- hashed_details_length =
yyhost-value.str.len+yyuser-value.str.len+yypasswd-value.str.len+yycharset-value.str.len+6+3;
+ hashed_details_length =
+yyhost-value.str.len+yyuser-value.str.len+yypasswd-value.str.len+yycharset-value.str.len+6+4;
+
hashed_details = (char *)
emalloc(hashed_details_length+1);
sprintf(hashed_details,sybase_%s_%s_%s_%s,yyhost-value.str.val,yyuser-value.str.val,yypasswd-value.str.val,yycharset-value.str.val);
/* SAFE */
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Karma request
Can I get karma in ext/sybase and ext/sybase_ct again? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] List messages are being delayed?
Ooh. Hrm...that's a bit heavier than the hardware I have available. Best I can do is PIII 400, .5 GB RAM...but the initial responsed from the ISP looks pretty positive. Do you want me to persue this further, or just let it go? On Wed, 20 Jun 2001, Rasmus Lerdorf wrote the following to Brian Moon : The hard part is finding someone who is willing to do it and does not want a lot of advertising in return. Good Luck. BTW, what kind of machine does it take to turn the list out? I know you were on a dual CPU box with Gig of ram at VA. That's about what it needs. Not for the mailing lists, but for some of the other things that runs on it. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #11558 Updated: Sybase-CT functions not found.
On Thu, 21 Jun 2001, Daniel Beulshausen wrote the following to [EMAIL PROTECTED]: Maybe not, but there's no reason they can't exist. :) can you please explain what you meant by that? sybase_min_error_severity() sybase_min_message_severity() are part of the sybase extension but not of the sybase_ct extension. the sybase_ct extension is the only one available under win32 so far, thus those functions can't exist. i guess there are other functions for this behaviour, or if there aren't make this a feature request but it's definetly not a (valid) bug report. daniel [2001-06-20 05:48:45] [EMAIL PROTECTED] such functions don't exist in the sybase_ct extension (only one available under win32) They are not in there right now, you're correct...so I filed this as a Feature Request, bcz there's no reason we can't add these functions for a future release. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] List messages are being delayed?
Rasmus (or anyone): Can you quantify what lists.php.net consumes for bandwidth on average? As long as it's not some completely outrageous figure, I can meet all of these criteria... On Wed, 20 Jun 2001, Rasmus Lerdorf wrote the following to Daniel Beckham : From what I can tell, you are hosting this on your own connection at home/work? Is there no one in the community that is willing to host the server for you guys? It is on my home DSL connection. And yes, there are people willing, but we are somewhat picky about the terms of such hosting. We basically want a server to ourselves with full root access, but we also want someone we can call who will get the server back up and running quickly if something happens. And we want to host it somewhere that will still be around in 6 months. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] List messages are being delayed?
OK, I will run these numbers and see what I can do. I get all of my hosting as a quid pro quo from a local ISP, in return for occasional contracting jobs. On Wed, 20 Jun 2001, Rasmus Lerdorf wrote the following to Joey Smith : Rasmus (or anyone): Can you quantify what lists.php.net consumes for bandwidth on average? As long as it's not some completely outrageous figure, I can meet all of these criteria... Once you add the cvs server and the snapshots it would eat up the better part of a T1 consistently. Perhaps not quite 1.5M, but probably in the 1M range. 384K is definitely not enough just for the lists. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Fix for bug 10252
Bug report:
http://bugs.php.net/?id=10252edit=1
Could someone look over this patch and tell me whether it is safe? Both
attached and inline here.
--- php_odbc.c.orig Wed Apr 11 12:23:56 2001
+++ php_odbc.c Wed Apr 11 12:27:23 2001
@@ -1928,6 +1928,8 @@
chardsnbuf[300];
short dsnbuflen;
char*ldb = 0;
+ int ldb_len = 0;
+
if (strstr((char*)db, ";")) {
direct = 1;
@@ -1936,8 +1938,9 @@
ldb = (char*)emalloc(strlen(db) +
strlen(uid) + strlen(pwd) + 12);
sprintf(ldb, "%s;UID=%s;PWD=%s", db,
uid, pwd);
} else {
- ldb = (char*)emalloc(strlen(db) + 1);
- strcat(ldb, db);
+ ldb_len = (strlen(db)+1);
+ ldb = (char*)emalloc(ldb_len);
+ strlcpy(ldb, db, ldb_len);
}
}
--- php_odbc.c.orig Wed Apr 11 12:23:56 2001
+++ php_odbc.c Wed Apr 11 12:27:23 2001
@@ -1928,6 +1928,8 @@
chardsnbuf[300];
short dsnbuflen;
char*ldb = 0;
+ int ldb_len = 0;
+
if (strstr((char*)db, ";")) {
direct = 1;
@@ -1936,8 +1938,9 @@
ldb = (char*)emalloc(strlen(db) + strlen(uid) +
strlen(pwd) + 12);
sprintf(ldb, "%s;UID=%s;PWD=%s", db, uid, pwd);
} else {
- ldb = (char*)emalloc(strlen(db) + 1);
- strcat(ldb, db);
+ ldb_len = (strlen(db)+1);
+ ldb = (char*)emalloc(ldb_len);
+ strlcpy(ldb, db, ldb_len);
}
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Date/timestamp on CVS versions..
I think the timestamp idea is the better of the two, myself. :) On Tue, 10 Apr 2001, Jani Taskinen wrote the following to [EMAIL PROTECTED]: X-Powered-By: PHP/4.0.6-dev Just an idea..would it be stupid to have the date of last CVS update included in the version string? Like this: 4.0.6-dev-20011004 Or maybe the timestamp would be better? That way we could ask for it to be included in the bug report if the bug submitter uses CVS. And could tell for sure if a fix was in that version or not? --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: ; arg seperator
Just wanted to toss in my .02 here... Anyone who wrote scripts in the past expecting: foo.php?a=1;2;3 to get "$a=1;2;3" was relying on a bug, or at the very LEAST an undocumented feature. So if it goes away, it goes away. It should never have worked to begin with, IMHO... This doesn't mean it won't bite some people, but that's never been a problem before in cases of undocumented features. On Tue, 3 Apr 2001, Andi Gutmans wrote the following to James Moore, Sascha...: James, You have to be aware that now PHP has such a big user base we need to be very careful in the changes we make especially when we can be pretty certain that it might burn quite a lot of people. We can break compatibility more easily when we have a major release (as from PHP 3 to PHP 4) but these kind of patches need to also be sensitive to the existing users. I personally don't know this issue very well and it is hard for me to guess how many people will be effected. Probably some of you who know this better can get an idea. Also I missed if this is the same directive as in php.ini. Anyway, I'm just saying don't take the user base too lightly because most of them aren't php-dev@ hackers who want the standards but they want their web sites to continue working. Anyway, this doesn't mean I am necessarily against including the patch but we need to make sure we're all OK with it and make a decision not only based on the standard but also on how much damage this might make. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: ; arg seperator
On Tue, 3 Apr 2001, James Moore wrote the following: I would question about it being optional in the long term though. If we begin to make everything optional then we get to a point where PHP is so configurable with enabling this bug here or there it becomes impossible to create distribuable scipts that are easy to install and make work (making it difficult for commercial companies to create PHP Scripts to sell which is a bad thing IMHO). I've never bought into this argument, because these companies can include a "config.php", or something like that, which uses ini_set() to set up the INI file however they need it... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] Re: ; arg seperator
Just thinking out loud here before I go to bed...how about: arg_sep.read = "" | ";" arg_sep.write = ";" Or something like this. It'd be nice to be able to do the |. On Tue, 3 Apr 2001, James Moore wrote the following to Rasmus Lerdorf and...: I disagree, we explicitly document that the arg_separator defaults to and that this is the character that separates url arguments. This follows the original CGI specification. The fact that this is no longer the accepted standard for this doesn't mean we can just up and change it in a minor PHP version. Well how about a comprimise then. We keep the broken behavior configurable in the php.ini for now. If needed we default it to off. At 4.1 Which perhaps should not be too far away due to the amount of things like this we default it to on. Then at 4.2 we remove the option? James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: ; arg seperator
Same here. I know there's a few things like this out there...I am going to bed now. If no one else has done it before I wake, I'll start doing some digging. On Tue, 3 Apr 2001, Andi Gutmans wrote the following to Joey Smith, PHP...: At 03:18 PM 4/3/2001 -0600, Joey Smith wrote: Speaking of this, I think we need to collect all of these types of issues that are waiting for a "4.1" release somewhere, so we can get a clear idea of when 4.1 is appropriate. Anyone know of any off-hand? If not, I can go search the archives... In any case it is a good idea to make a list of these issues. I can't remember off hand what issues we had so I hope people have a better memory than me :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Proper version of PostgreSQL?
For those of you building --with-pgsql, what version of PostgreSQL are you able to build against? I cannot get PHP to build against 6.5.3... Make fails with: pgsql.c: In function `_rollback_transactions': pgsql.c:165: void value not ignored as it ought to be Line 165 of ext/pgsql/pgsql.c: old_notice_hook = PQsetNoticeProcessor(link, _be_quiet, NULL); In /usr/include/postgresql/libpq-fe.h, I have: extern void PQsetNoticeProcessor (PGconn *conn, PQnoticeProcessor proc,void *arg) I looked in the 7.0.3 source, and found that this function now returns a "PQnoticeProcessor". Perhaps once 4.0.5 is out, someone would like to patch pgsql's config.m4 so that it checks version? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9858 Updated: mail() still doesn't sendcc
I did find some oddities under win32 with the mail() function in
general. I spent much time just trying to get the build working again on
my win32 box. I will look into it later today, I hope.
On Thu, 22 Mar 2001, [EMAIL PROTECTED] wrote the following to Joey Smith :
Hello,
Did your Win32 test agree with my bug report?
Joel
At 05:52 AM 3/20/01 -0700, you wrote:
I will test on win32 in a bit, but for now, let me say that this works
just fine on linux:
mail("[EMAIL PROTECTED]", "Test cc", "Testing CC",
"cc:[EMAIL PROTECTED]\r\nCc:[EMAIL PROTECTED]\r\nCC:joey@communityacti
on.net");
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9911: Segmentation fault of httpd(w/mod_php4)
Can you possibly try it with the real Sybase CT Library, rather than FreeTDS? Also, if you built --enable-debug, send me the backtrace ([EMAIL PROTECTED]), let me tak a look at it. On 22 Mar 2001, [EMAIL PROTECTED] wrote the following to...: From: [EMAIL PROTECTED] Operating system: Linux Redhat 6.2/Freebsd 4.2 PHP version: 4.0.4pl1 PHP Bug Type: Reproduceable crash Bug description: Segmentation fault of httpd (w/mod_php4) The bug occurs when using the sybase-ct libraries. I'm using freetds 5.0 as the sybase-ct lib Connecting to MSSQL 6.5 Db This occured on 3 different machines w/ 2 different OS's so I'm not sure if you want a gdb backtrace..? Apache child segmentation faults when I try to write to the database. Select queries work fine. Update and Insert queries will cause the crash. Insert will actually insert the data into the db before it crashes. Downgrade to php4.03 solved this problem and the insert's and updates work fine. If I can be of any more help please let me know.. Regards Chris -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] [IANAL] Re: [PHP-DEV] Debugger protocol
According to the DMCA [ 1201(f) ], legal precedent [ see http://home.joeysmith.com/~joey/sony-v-connectix.html ], and common practice, there is nothing that prohibts a "clean room implementation". (http://www.boreworms.com/karellen/rev-eng.html). That said: PHP *is* open. The Zend debugger is not. It is a commercial product, developed by people who know the internals of PHP/Zend *very* well. There is nothing that precludes you from dropping the same time investment into the PHP code as the Zend folks have. If you do invest this amount of time, I feel pretty sure that you could see how to develop a debugger, but this is just a guess. I have been told that the Zend Debugger license explicitly prohibits such activity. I, for one, do not begrudge Zend trying to make a little money. Just because some of us manage to live an idealistic world does not mean that everyone can afford to do so. Anyone can take the PHP code and do the same. Not everyone will have the same degree of credibility, though. BTW, the PHP3 debugger was NOT really a debugger, IMNSHO. Not having used the Zend debugger, I cannot make any claims. I do not recommend trying to do this. IANAL. I would like to see people's hard work rewarded. When one of my companies makes me rich and famous, one of my first actions will be to turn around to those people OUTSIDE of Zend that also deserve a reward for hard work that has kept me employed for 3 years or more. =) On Tue, 20 Mar 2001, Varun Shoor wrote the following to [EMAIL PROTECTED] : Hi there, I have been working on an Open Source IDE for PHP but from what i heard in the #php the debugger protocol is no more open in PHP4? And only binaries are distributed and above all it is illegal to reverse engineer the protocol. Why in the world is this done?... I mean PHP is supposed to be open, right?.. The protocol was open in PHP3 but now i hear that it is closed.. isnt this a perfect monoply?.. Everyone knows an IDE is nothing without a good debugger and if i cant add it then all of my time devoted to this thing will go waste.. Someone care to tell me a way out? Regards, Varun Shoor --- www.DeskCode.com (Programmers Resource) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5)/sapi/fastcgi
Well, IIUC, this is really all Jani is trying to say...RC2 is could be considered invalid now... On Tue, 20 Mar 2001, Zeev Suraski wrote the following to Sascha Schumann : In my humble opinion (humility is a virtue), new modules are fine to add while in the release process, as long as there's at least one RC after them -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Independent comments on a bug.
Only if you are a developer. You may want to try requesting a developer account. I know the QA/QC team can always use more helping closing reports and fixing bugs... http://www.php.net/cvs-php.php On Sat, 17 Mar 2001, Fredrik Ohrn wrote the following to [EMAIL PROTECTED] : In the bug tracker, is it possible to add a comment to a bug already filed by someone else? If it is, please explain coz I'm to dumb to figure it out. Regards, Fredrik -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] QA: chunked output buffering does notwork on win32 + internal function output callbacks
Which means there'll need to be another RC. So we'll also be able to test the IMAP-2000 stuff someone was asking about... On Fri, 16 Mar 2001, Andi Gutmans wrote the following to Andr Langhorst,...: This is extremely reproducible. Definitely a show stopper until Zeev fixes this one. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9716: internal_functions.c:32: `#include'expects FILENAME or FILENAME
I bet this is related to getting those line endings correct...ie, it's "\n" on Unix, "\r\n" on Win32...and so on. Most likely not a PHP bug. On 13 Mar 2001, [EMAIL PROTECTED] wrote the following to [EMAIL PROTECTED]: From: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Operating system: Mac OS X RC1 PHP version: 4.0 Latest CVS (12/03/2001) PHP Bug Type: *Install and Config Bug description: internal_functions.c:32: `#include' expects "FILENAME" or lt;FILENAMEgt; After configuration the this error occurs" Making all in main /bin/sh /Users/Shared/php4-200103121645/libtool --silent --mode=compile cc -I. -I/Users/Shared/php4-200103121645/main -I/Users/Shared/php4-200103121645/main -I/Users/Shared/php4-200103121645 -I/usr/include/httpd -I/Users/Shared/php4-200103121645/Zend -I/usr/local/mysql/include/mysql -I/Users/Shared/php4-200103121645/ext/xml/expat/xmltok -I/Users/Shared/php4-200103121645/ext/xml/expat/xmlparse -I/Users/Shared/php4-200103121645/TSRM -traditional-cpp -DDARWIN -DUSE_HSREGEX -DUSE_EXPAT -DSUPPORT_UTF8 -DXML_BYTE_ORDER=21 -g -O2 -c internal_functions.c internal_functions.c:32: `#include' expects "FILENAME" or FILENAME make[2]: *** [internal_functions.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 This error is caused by the following line: #include "ext/mysql/php_mysql.h"n#include "ext/pcre/php_pcre.h"n#include "ext/posix/php_posix.h"n#include "ext/session/mod_mm.h"n#include "ext/session/php_session.h"n#$ p_zlib.h"n This line should be broken into multiple lines: #include "ext/mysql/php_mysql.h" #include "ext/pcre/php_pcre.h" #include "ext/posix/php_posix.h" #include "ext/session/mod_mm.h" #include "ext/session/php_session.h" #include "ext/standard/php_standard.h" #include "ext/xml/php_xml.h" #include "ext/zlib/php_zlib.h" The file can be manually edited after configuration and the build will proceed normally with success. However running configuration again will revert this file to the broken state again. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: PHP 4.0 Bug #9745 Updated: PHP Warning: Unable toload dynamic library './msql.dll'
Open a new bug. You reported two bugs in the same place. You had the msql.dll bug, and: Parse error: parse error, expecting `','' or `';'' On Wed, 14 Mar 2001, John Stoops wrote the following to Bug Database : Lets start again. My php page: !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" html head titleUntitled/title /head body ?php echo "Hello world"; ? /body /html My error message: PHP Warning: Unable to load dynamic library './msql.dll' - One of the library files needed to run this application cannot be found. in Unknown on line 0 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.0.5RC1 packaged
Everything looks clean on Debian Potato and Debian Woody as a CGI. I'll run the Apache through some testing tonight. (I think everyone knows by now that I need sleep. :) On Tue, 13 Mar 2001, Zeev Suraski wrote the following to [EMAIL PROTECTED] : http://www.php.net/distributions/RCs/php-4.0.5RC1.tar.gz Do your thing :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: PHP 4.0 Bug #9745 Updated: PHP Warning: Unable toload dynamic library './msql.dll'
Actually, he doesn't need either. Just put a semi-colon in front of the line starting: extension=msql.dll Note the section a few lines down: ;Note that MySQL and ODBC support is now built in, so no dll is needed for it. On Wed, 14 Mar 2001, Jani Taskinen wrote the following to John Stoops : On Wed, 14 Mar 2001, John Stoops wrote: Lets start again. My php page: !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" html head titleUntitled/title /head body ?php echo "Hello world"; ? /body /html My error message: PHP Warning: Unable to load dynamic library './msql.dll' - One of the library files needed to run this application cannot be found. in Unknown on line 0 msql.dll ?? Weren't you using mysql? It's mysql.dll then. --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Karma request
Can I get karma back in php3 and php4? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PHP 4.0 Bug #8954 Updated: compiling with sybase-ctfails
It can be. Just no one (AFAIK) has gotten around to it yet. Simply using the patch specified in 7792 would make FreeTDS work, but break people using the realy Sybase CT libs. On Wed, 31 Jan 2001, J.R. Lillard wrote the following to Bug Database : the patch provided for php 4.0.3pl1 in bug 7792 can be easily adapted for 4.0.4pl1. i don't see why it couldn't be a simple configure option to automate it. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] NEWBIE QUESTION
1. Take off caps lock. This is bad manners.
2. This mailing list is for people interested in the development of the
PHP language. Please use [EMAIL PROTECTED] That's the mailing
list for PHP users.
On Thu, 1 Feb 2001, Stinie Steinbach wrote the following to [EMAIL PROTECTED]:
DOES ANYONE KNOW WHAT'S WRONG WITH THIS CODE
IK WANT TO GENERATE A CODE THAT SELECTS A COUPELE OF PARAMETERS FROM TWO
TABLES IN A MYSQL DATABASE...
THE QUERY THAT I USE WORKS CORRECTLY BUT I HAVE A PROBLEM WITH THE LINKS
I WANT TO GENERATE WITH PHP...
I NEED TO CREATE AN ARRAY OF LINKS THAT LOOK LIKE THIS...
BLOK 0 | BLOK 1 | BLOK 2 | BLOK 3 | BLOK 4 | BLOK 5 | BLOK 6 | BLOK 7 |
BLOK 8 | BLOK 9
PLEASE HELP!!!
? include("connect.php3") ?
?
$result = mysql_query ("select m.module_id, m.leergang_afkorting,
m.module_nummer, l.opleiding_afkorting
from module m, leergang l where m.leergang_afkorting =
l.leergang_afkorting
and m.leergang_afkorting = 'EDP16' order by m.module_nummer");
while (list
($module_id,$leergang_afkorting,$module_nummer,$opleiding_afkorting) =
mysql_fetch_row ($result)) {
echo "a
href=\"http://tias.kub.nl/programs/\"opleiding_afkorting=$opleiding_afkorting\"/
\"leergang_afkorting=$leergang_afkorting\"/
\"virtuele.klas/programma/blok\"module_nummer=$module_nummer\"/\"leergang_afkorting=$leergang_afkorting\"_blok0\"
module_nummer=$module_nummer.html\"$module_nummer/a
}
?
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
