Re: [PHP-DEV] variables_order annoyance
On Tue, 14 Jan 2003, Rasmus Lerdorf wrote: Check out this bug report: http://bugs.php.net/16155 Ah thanks, that's where I remember the discussion from. I do disagree with one part: (c) It shouldn't be possible to prevent $_GET, $_POST, $_COOKIE, and $_FILES from being populated. Why in the world not? I explicitly need to be able to prevent $_COOKIE from being populated and showing up in $_REQUEST here at Yahoo because we have access functions that we want to force people to go through to fetch cookie data. I think we should just have a completely clean separation of variable ordering priority and superglobal array population. Before register_globals it made sense to just have one setting for this as you couldn't have one without the other, but today it doesn't make sense anymore. How about an ini setting for all autoglobals with all being boolean except request_autoglobal which takes on 'gpc'. This will solve your problem but will introduce one possible problem (aside from even more directives to keep track of). It's nice to document: $_REQUEST will always contain a mix of... Instead of: $_REQUEST may contain a mix of ... depending on your request_autoglobal directive. Sure currently it depends on variables_order but few know the true power of this directive and even fewer are tempted to mess with it. Having the contents being consistent is nice but is it required? One last thing. Some people ask for the ability to hide certain ENV and SERVER variables. This is a related topic that might want to be addressed at this time. One thought for env: 0 = Variable won't exist. 1 = Entire variable will exist. RUNLEVEL,PATH = Partial variable exists except these. BUT, this would mean getenv() would need to be brought into the picture too so this topic will need a new related idea and may want to be ignored for now :) It would sorta be like disable_variables vs disable_functions. Regards, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Headers required?
Hi,
I have a custom extension in which I want to write this piece of code -
/* {{{ proto int apache_client_socket()
Get the client socket */
PHP_FUNCTION(apache_client_socket)
{
RETURN_LONG(((request_rec
*)SG(server_context))-connection-client-fd);
}
/* }}} */
This code is something that I've put in sapi/apache/php_apache.c and I
want to move it to my custom extension. When I try to compile the
extension, I get a lot of errors regarding undefined yada yada
What are the headers required out here to compile this code
successfully? Libs to link with?
Tx,
Vinod.
---
Vinod Panicker [EMAIL PROTECTED]
Sr. Software Designer
Geodesic Information Systems Ltd.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headers required?
What are the headers required out here to compile this code successfully? Libs to link with? There is a SAPI API call for that (in HEAD, but I intend to merge it into the 4.3 branch). SAPI_API int sapi_get_fd(int *fd TSRMLS_DC); - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Headers required?
Thanks for the quick reply... But is there something that I can do right now that will allow this code to work with php 4.2.3? Tx, Vinod. --- Vinod Panicker [EMAIL PROTECTED] Sr. Software Designer Geodesic Information Systems Ltd. -Original Message- From: Sascha Schumann [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 4:28 PM To: Vinod Panicker Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Headers required? What are the headers required out here to compile this code successfully? Libs to link with? There is a SAPI API call for that (in HEAD, but I intend to merge it into the 4.3 branch). SAPI_API int sapi_get_fd(int *fd TSRMLS_DC); - Sascha -- 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
RE: [PHP-DEV] Headers required?
On Wed, 15 Jan 2003, Vinod Panicker wrote: Thanks for the quick reply... But is there something that I can do right now that will allow this code to work with php 4.2.3? You could add the necessary code from here: http://news.php.net/article.php?group=php.cvsarticle=16651 - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: #21659 [Com]: sprintf
Agreed in general. And whilst I'm here can I throw in my 2c about Bogus? Although an accurate description, it's hardly likely to be perceived as friendly. If you've taken the time to report a bug, even if you are in error, having it thrown back as Bogus seems pretty mean. How about a less antagonistic wording? I'd put forward something like NotaBug, which gives the same information without putting people's backs up. adamw - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 3:01 PM Subject: #21659 [Com]: sprintf ID: 21659 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *General Issues Operating System: linux PHP Version: 4.3.0 New Comment: Why has this bug been marked as Bogus when it's a Duplicate? It seems to be increasingly common for this to happen -- when did it become standard policy to set duplicate report to Bogus? This is very confusing, when there is still a Duplicate status in the system. Surely, if a bug is a duplicate of another, it's far better to set its status to Duplicate, so that it's obvious from a brief look that it *is* a duplicate (and it shows up in search results as such). Setting it to Bogus is bogus, because it's patently not Bogus if it's the same issue as an Open bug. And even if it is policy to set duplicate report to Bogus, that policy should be prominently documented, so that people don't get in a huff about bugs being dismissed as not a bug when their duplicate report is set to Bogus (which has happened more than once already!). Cheers! Mike Previous Comments: [2003-01-15 08:13:43] [EMAIL PROTECTED] See bug #21658, it's the same so this one is not needed - bogus. [2003-01-15 08:10:55] [EMAIL PROTECTED] Error with sprintf i obtain conversion from numbner in not printable caracter. various numebr of my application don't work now see above [2003-01-15 08:09:57] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. [2003-01-15 08:08:41] [EMAIL PROTECTED] I obtain from php 4.30 and error using sprintf My php code generate a result file in which is it possible to see the bug: example: sprintf(%.3f,2.04204204204) = 0.0#65533;0 sprintf(%.3f,2.1981981982) = 000.000 sprintf(%.3f,1.07507507508) = 1.000 sprintf(%.3f,1.98498498498) = 0.000 sprintf(%.3f,0.318318318318) = 0.000 sprintf(%.3f,0.90990990991) = 1.000 sprintf(%.3f,0.660660660661) = 0.000 sprintf(%.3f,2.27327327327) = 00.000 sprintf generate strange non visible alfanumeric caracter -- Edit this bug report at http://bugs.php.net/?id=21659edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bugsystem status codes (Was: Re: #21659 [Com]: sprintf)
On 15 Jan 2003 [EMAIL PROTECTED] wrote: Why has this bug been marked as Bogus when it's a Duplicate? It seems to be increasingly common for this to happen -- when did it become standard policy to set duplicate report to Bogus? Two exactly the same bugs were posted one minute after eachother from persons on the same domain. This is very confusing, when there is still a Duplicate status in the system. Surely, if a bug is a duplicate of another, it's far better to set its status to Duplicate, so that it's obvious from a brief look that it *is* a duplicate (and it shows up in search results as such). Setting it to Bogus is bogus, because it's patently not Bogus if it's the same issue as an Open bug. It was in this case. And even if it is policy to set duplicate report to Bogus, that policy should be prominently documented, so that people don't get in a huff about bugs being dismissed as not a bug when their duplicate report is set to Bogus (which has happened more than once already!). People who dont understand the implicit meaning of the statii shouldn't touch the reports in the bug system. I'll write them down again: bogus: submitted twice after each other, or by the same person on the same topic; it's not a bug, but a support question. The reason should always be noted in the comments dupli: almost the same bug, both bugs are found 'duplicate' later on and have both useful information verif: a member of the QA has verified the bug to be a real one analy: the cause of the bug is known, or a solution is known for it but not yet implemented assig: don't touch this one, somebody is working on this. open: just submitted, or nobody knows what to do with it (after feedback) feedb: Waiting for more feedback from the user suspe: at some point in the future we'll look at it again, currently we are waiting on an external thing to be fixed first close: the bug has been solved (fixed in cvs) wontf: we are not going to fix this issue because criti: critical bug, should be fixed ASAP no fe: No feedback from the user was added since we asked it two weeks ago if you;re not sure what status to set a report to, ask on the php-qa@ list! regards, Derick -- - Derick Rethans http://derickrethans.nl/ JDI Media Solutions http://www.jdimedia.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #21659 [Com]: sprintf
On January 15, 2003 10:14 am, Adam Wright wrote: Agreed in general. And whilst I'm here can I throw in my 2c about Bogus? Although an accurate description, it's hardly likely to be perceived as friendly. If you've taken the time to report a bug, even if you are in error, having it thrown back as Bogus seems pretty mean. How about a less antagonistic wording? I'd put forward something like NotaBug, which gives the same information without putting people's backs up. NotaBug or similar may lead to confusion. Quite often the issue may indeed be a bug, however it is not a bug in PHP and is therefor bogus. By marking such a bug report NotaBug may lead to confusion. IMO bogus is a fairly accurate representation of what the 'bogus' bug reports are, it is no more or less friendly then other bug status and is only a problem (less 'friendly') if you choose to make it such. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #21659 [Com]: sprintf
On Wed, 15 Jan 2003, Ilia A. wrote: On January 15, 2003 10:14 am, Adam Wright wrote: Agreed in general. And whilst I'm here can I throw in my 2c about Bogus? Although an accurate description, it's hardly likely to be perceived as friendly. If you've taken the time to report a bug, even if you are in error, having it thrown back as Bogus seems pretty mean. How about a less antagonistic wording? I'd put forward something like NotaBug, which gives the same information without putting people's backs up. NotaBug or similar may lead to confusion. Quite often the issue may indeed be a bug, however it is not a bug in PHP and is therefor bogus. By marking such a bug report NotaBug may lead to confusion. IMO bogus is a fairly accurate representation of what the 'bogus' bug reports are, it is no more or less friendly then other bug status and is only a problem (less 'friendly') if you choose to make it such. +1 on on that, but I do think that when a bug is set to bogus the reason why it is bogus should always be noted. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #21659 [Com]: sprintf
Last ditch effort of NotAPHPBug? ;) adamw - Original Message - From: Derick Rethans [EMAIL PROTECTED] To: Ilia A. [EMAIL PROTECTED] Cc: Adam Wright [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 3:21 PM Subject: Re: [PHP-DEV] Re: #21659 [Com]: sprintf On Wed, 15 Jan 2003, Ilia A. wrote: On January 15, 2003 10:14 am, Adam Wright wrote: Agreed in general. And whilst I'm here can I throw in my 2c about Bogus? Although an accurate description, it's hardly likely to be perceived as friendly. If you've taken the time to report a bug, even if you are in error, having it thrown back as Bogus seems pretty mean. How about a less antagonistic wording? I'd put forward something like NotaBug, which gives the same information without putting people's backs up. NotaBug or similar may lead to confusion. Quite often the issue may indeed be a bug, however it is not a bug in PHP and is therefor bogus. By marking such a bug report NotaBug may lead to confusion. IMO bogus is a fairly accurate representation of what the 'bogus' bug reports are, it is no more or less friendly then other bug status and is only a problem (less 'friendly') if you choose to make it such. +1 on on that, but I do think that when a bug is set to bogus the reason why it is bogus should always be noted. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- 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
Re: [PHP-DEV] Re: #21659 [Com]: sprintf
On January 15, 2003 10:27 am, Adam Wright wrote: Last ditch effort of NotAPHPBug? ;) This too may not be a correct solution all the time. Consider 75th duplicate report of an invalid or even a resolved bug report. It may have been a bug at some point, but certainly is not anymore. It is bogus, because the user chose not to search in the bug database for similar reports before posting their report. Surely you can agree that such a report is bogus. I suppose we could introduce a dozen different more 'friendly' statuses to replace the existing bogus status, but why? Surely not for the purpose of making users who don't do the necessary research before posting their bug reports feel better about themselves. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #21659 [Com]: sprintf
Agreed, on second thoughts those weren't terribly great example choices. I'm just coming from the point of view that you're generally better off not alienating someone for posting a bug before they've had their caffeine injection as they may in the future discover a legitimate bug which would be usefully reported. I certainly agree that the report is Bogus, it's just the terminology I was questioning. I suppose it's a culture thing, but the bogus status sounds rather harsh/rude to me (from the UK) even though I know its never (generally ;) intended to be. Even something like Invalid sounds better. Guess it's just a personal preference. I'll go back to my lurking now :) adamw - Original Message - From: Ilia A. [EMAIL PROTECTED] To: Adam Wright [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 3:39 PM Subject: Re: [PHP-DEV] Re: #21659 [Com]: sprintf On January 15, 2003 10:27 am, Adam Wright wrote: Last ditch effort of NotAPHPBug? ;) This too may not be a correct solution all the time. Consider 75th duplicate report of an invalid or even a resolved bug report. It may have been a bug at some point, but certainly is not anymore. It is bogus, because the user chose not to search in the bug database for similar reports before posting their report. Surely you can agree that such a report is bogus. I suppose we could introduce a dozen different more 'friendly' statuses to replace the existing bogus status, but why? Surely not for the purpose of making users who don't do the necessary research before posting their bug reports feel better about themselves. Ilia -- 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
RE: [PHP-DEV] Re: #21659 [Com]: sprintf
+1 on on that, but I do think that when a bug is set to bogus the reason why it is bogus should always be noted. While on that topic, I had a bug recently set to bogus because it was reported against 4.2.3 while 4.3.0 was out. More than once in the bug reporting info there is a comment something like: Every time a new version of PHP is released, hundreds of bugs are fixed. If you're using a version of PHP that is more than two revisions older than the latest version, you should upgrade to the latest version to make sure the bug you are experiencing still exists. If people are going to set to bogus reports against the previous stable release, then this should really be noted somewhere. Especially since the new version is less than a month old, and had quite a few changes in, I was slightly ruffled at the somewhat dismissive resolution. (As it happens, this particular problem is still present in 4.3.0, but it took us a while to free up a machine to build and test this on.) Don't take this the wrong way - in general I'd support rejecting bugs against older versions, but the documentation should be clear about it if that is the case, and the status change email probably shouldn't appear so terse. The somewhat lengthy form response: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. Again, thank you for your continued support of PHP. was not the best mood enhancer when I came in the following morning :-) Cheers, James -- James Aylett Chief Technical Architect, Tangozebra t 020 7535 9850 f 020 7535 9900 w http://tangozebra.com/ This e-mail message, including any attachments, is intended only for the person or entity to which it is addressed, and may contain confidential information. If you are not the intended recipient, any review, retransmission, disclosure, copying, modification or other use of this e-mail message or attachments is strictly forbidden. Copyright Tangozebra 2003. All Rights Reserved. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.370 / Virus Database: 205 - Release Date: 05/06/2002 This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: #21659 [Com]: sprintf
On January 15, 2003 10:27 am, Adam Wright wrote: Last ditch effort of NotAPHPBug? ;) This too may not be a correct solution all the time. Consider 75th duplicate report of an invalid or even a resolved bug report. It may have been a bug at some point, but certainly is not anymore. It is bogus, because the user chose not to search in the bug database for similar reports before posting their report. Surely you can agree that such a report is bogus. I suppose we could introduce a dozen different more 'friendly' statuses to replace the existing bogus status, but why? Surely not for the purpose of making users who don't do the necessary research before posting their bug reports feel better about themselves. The wording could be something like NotValidBug or something like that. I think the issue that Adam is bringing up is that Bogus has a derogatory connotation. Changing it doesn't necessarily make users who don't do necessary research before posing feel better about themselves, but it may make people more willing to report actual bugs in the future. Look, I'm not on the QA team and ultimately, what makes it easiest and most worthwhile for you guys to find and fix bugs is the best thing to do. But I can easily see how a well-meaning person who might be new to PHP might report what they think is a bug, have their bug report closed with This isn't a bug. with the status changed to Bogus, and take that as a big fat Go away. PHP doesn't welcome you. Maybe their report was a bug in something else (like that XML bug that was discussed recently) or maybe they didn't make themselves clear enough in their report. Derick's suggestion of making sure that the reason why the bug is Bogus is included in the discussion help with this. But it's pretty easy for someone to get discouraged by a curt dismissal and then not offer help in the future. If you guys are inundated with bogus bugs, then perhaps this is all moot. I can just see how easy it might be for someone who isn't an initiate to get a bad taste in their mouth for PHP by an unfortunate interaction with the bug system. -dave -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #21659 [Com]: sprintf
On Wednesday, January 15, 2003, at 08:48 AM, David Sklar wrote: The wording could be something like NotValidBug or something like that. I think the issue that Adam is bringing up is that Bogus has a derogatory connotation. Changing it doesn't necessarily make users who don't do necessary research before posing feel better about themselves, but it may make people more willing to report actual bugs in the future. Look, I'm not on the QA team and ultimately, what makes it easiest and most worthwhile for you guys to find and fix bugs is the best thing to do. But I can easily see how a well-meaning person who might be new to PHP might report what they think is a bug, have their bug report closed with This isn't a bug. with the status changed to Bogus, and take that as a big fat Go away. PHP doesn't welcome you. It occurs to me that it would be relatively easy for someone with direct access to the bug database to determine whether this is a real problem - just see what percentage of people whose bugs get marked Bogus never post another bug (vs. people whose bugs get assigned other status codes). I would do it, except the web interface doesn't seem to allow searching by submitter name. -Alex -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #21659 [Com]: sprintf
Consider the following, there are a lot more PHP users then PHP developers and considering that not all PHP developers are actively involved in the bug solving process (many are involved with PEAR/PECL/Documentation and so on) there are very few people actively working on resolving bugs. This makes the time of these people very valuable, people who post invalid bug reports eat up that valuable time and by doing so not only cause a loss of bug fixing time but also disillusion developers and often make them move on to more exciting things like writing new code. Perhaps a slightly less then an absolutely polite approach, will make those people reconsider their bug posting technique and do a little research before deciding that their non-working script constitutes a valid bug report and start wasting everyone's time. Most of the time when a bug is marked bogus the developer will indicate why the bug is bogus, so that the user is not left in the dark. All that said, I see nothing especially inflammatory about 'bogus' and I do not believe it is the intent of the developers to insult or degrade the user who had posted a bogus report. The 'invalid' status that was proposed, in my opinion, just as 'unfriendly' as bogus. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Bugsystem status codes (Was: Re: #21659 [Com]: sprintf)
-Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED]] Sent: 15 January 2003 15:17 To: [EMAIL PROTECTED] Cc: PHP Quality Assurance Team Mailing List; PHP Developers Mailing List Subject: [PHP-DEV] Bugsystem status codes (Was: Re: #21659 [Com]: sprintf) On 15 Jan 2003 [EMAIL PROTECTED] wrote: Why has this bug been marked as Bogus when it's a Duplicate? It seems to be increasingly common for this to happen -- when did it become standard policy to set duplicate report to Bogus? Two exactly the same bugs were posted one minute after eachother from persons on the same domain. (Grits teeth) But it's still a duplicate report! It was in this case. And even if it is policy to set duplicate report to Bogus, that policy should be prominently documented, so that people don't get in a huff about bugs being dismissed as not a bug when their duplicate report is set to Bogus (which has happened more than once already!). People who dont understand the implicit meaning of the statii shouldn't touch the reports in the bug system. I'll write them down again: I'm not talking about touching them in the bug system, I'm talking about understanding them as a bog standard user. bogus: submitted twice after each other, or by the same person on the same topic; it's not a bug, but a support question. The reason should always be noted in the comments That's very confusing - there's really two different stauses in that definition, which I think is the crux of the problem. The first definition really needs a new status such as Repeat, which is otherwise treated like Bogus. But this definition is interesting, because I think some responders are not respecting the by the same person part. dupli: almost the same bug, both bugs are found 'duplicate' later on and have both useful information Yes, fair enough. I just get the feeling that, lately, the balance has tipped too far towards labelling repeat reports Bogus -- personally, I think responders should be a little less Bogus-happy, and err on the side of Duplicatifying if there's any doubt in the matter. Also, when marking a repeat as Bogus, not calling it a duplicate in the explanation would be useful -- saying something more like repeat of #xxx or Identical to #xxx would be better. verif: a member of the QA has verified the bug to be a real one analy: the cause of the bug is known, or a solution is known for it but not yet implemented assig: don't touch this one, somebody is working on this. open: just submitted, or nobody knows what to do with it (after feedback) feedb: Waiting for more feedback from the user suspe: at some point in the future we'll look at it again, currently we are waiting on an external thing to be fixed first close: the bug has been solved (fixed in cvs) wontf: we are not going to fix this issue because criti: critical bug, should be fixed ASAP no fe: No feedback from the user was added since we asked it two weeks ago H'mmm, interesting -- I don't think I've ever seen that list before -- certainly not linked from anywhere obvious such as http://bugs.php.net/, or http://bugs.php.net/search.php. Perhaps a what happens to bug reports sort of link would be useful on the bugs front page, to complement How to report a bug? Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: #21659 [Com]: sprintf
From: Ilia A. [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 11:19 AM Consider the following, there are a lot more PHP users then PHP developers and considering that not all PHP developers are actively involved in the bug solving process (many are involved with PEAR/PECL/Documentation and so on) there are very few people actively working on resolving bugs. This makes the time of these people very valuable, people who post invalid bug reports eat up that valuable time and by doing so not only cause a loss of bug fixing time but also disillusion developers and often make them move on to more exciting things like writing new code. Perhaps a slightly less then an absolutely polite approach, will make those people reconsider their bug posting technique and do a little research before deciding that their non-working script constitutes a valid bug report and start wasting everyone's time. Most of the time when a bug is marked bogus the developer will indicate why the bug is bogus, so that the user is not left in the dark. Like I said, ultimately, whatever works best for the folks actively resolving the best approach. My only point was that the people posting the bugs often aren't aware of these dynamics beforehand, so the less then an absolutely polite approach, which makes sense when you explain it here, can be discouraging. All that said, I see nothing especially inflammatory about 'bogus' and I do not believe it is the intent of the developers to insult or degrade the user who had posted a bogus report. The 'invalid' status that was proposed, in my opinion, just as 'unfriendly' as bogus. I don't think that anyone thinks it's the intent of developers to insult or degrade users. -dave -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Bugsystem status codes (Was: Re: #21659 [Com]: sprintf)
On Wed, 15 Jan 2003, Ford, Mike [LSS] wrote: Two exactly the same bugs were posted one minute after eachother from persons on the same domain. (Grits teeth) But it's still a duplicate report! No, it was merely a co-worker which wanted to focus more attention on the bug of his friend. bogus: submitted twice after each other, or by the same person on the same topic; it's not a bug, but a support question. The reason should always be noted in the comments That's very confusing - there's really two different stauses in that definition, which I think is the crux of the problem. The first definition really needs a new status such as Repeat, which is otherwise treated like Bogus. But this definition is interesting, because I think some responders are not respecting the by the same person part. dupli: almost the same bug, both bugs are found 'duplicate' later on and have both useful information Yes, fair enough. I just get the feeling that, lately, the balance has tipped too far towards labelling repeat reports Bogus -- personally, I think That's only because we get more and more stupid bogus bug reports. H'mmm, interesting -- I don't think I've ever seen that list before -- certainly not linked from anywhere obvious such as http://bugs.php.net/, or http://bugs.php.net/search.php. Perhaps a what happens to bug reports sort of link would be useful on the bugs front page, to complement How to report a bug? Feel free to make a patch to php-bugs-web. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #21659 [Com]: sprintf
Ilia A. wrote: On January 15, 2003 10:27 am, Adam Wright wrote: Last ditch effort of NotAPHPBug? ;) This too may not be a correct solution all the time. Consider 75th duplicate report of an invalid or even a resolved bug report. It may have been a bug at some point, but certainly is not anymore. It is bogus, because the user chose not to search in the bug database for similar reports before posting their report. Surely you can agree that such a report is bogus. Your definition of bogus is very broad. Personally I think bogus was a bad idea in the first place. Anyway, in the situation above, it's a duplicate, not a bogus. Marking it a duplicate informes the user (for the 75th time) that the bug was already reported, and even if that bug is fixed, it then points the user to the fix as well. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c
iirc the reason why i changed it to unsigned was that actually the zend engine treated it as unsigned everywhere but in that particular struct. i also remember that i discussed that with andi and that he agreed to change this in the ze2 cvs module and that the extensions should be *fixed*. i agree that it doesn't make any sense to mix types. changing it to uint means to fix all the extensions, changing it to int means to fix the engine (and not just to revert my patch). harald. I might be misunderstanding the problem and I didn't have time to read the phrack article, but doesn't this mean that leaving it unsigned is better? It wouldn't pass the length check and thus, memcpy() wouldn't convert a negative number to something huge. The problem is that every single line of existing PHP extensions, both public and non-public, would need to be audited, if we were to switch the type, because 100% of the current code misinterpretes data from the ZE2 API right now. Changing the API does not solve the existing problem, it merely adds to it. For example, you can add a single central check to the engine today which checks string lengths to be at least 0. If the length field was changed to an unsigned type permanently, such a check would be impossible to implement in a portable way, because C does not define how a negative number will appear when cast to an unsigned type. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c
On Wed, Jan 15, 2003 at 06:36:20PM +0100, Harald Radi wrote: iirc the reason why i changed it to unsigned was that actually the zend engine treated it as unsigned everywhere but in that particular struct. i also remember that i discussed that with andi and that he agreed to change this in the ze2 cvs module and that the extensions should be *fixed*. i agree that it doesn't make any sense to mix types. changing it to uint means to fix all the extensions, changing it to int means to fix the engine (and not just to revert my patch). While I think changing the len field to unsigned or size_t itself is a good idea, it is also the case that there're certain security risks that should have been considered. IMHO as long as no one is likely to agree the idea to either modify Z_STRLEN macro or make a new macro Z_SAFE_STRLEN so that it would force the engine to bail out when the length exceeds the maximam value of signed integer (or possibly signed short) like Sascha said, more priority has to be taken on fixing the engine over the former because it hardly seems the change has been known by the numerous extension developers. Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: sil
Translating the documentation (English to Italian) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [Win32] Install Problems....
I ran in serious troubles trying to install a recent version of PHP compiled with the Zend Engine 2. I have the latest release of Apache2 installed and running a PHP Snapshot as CGI always ends in a crash (PHP not Windows) I was able to install a recent CVS version of 4.3.0 with the Zend Engine 2 to keep my work on a script which requires the new object model. Problems came up with ZE2 from the php-4-3-0dev-ze2-alpha2 giving me some serious errors while working with parent:: (just in some cases though). Now i want to install a more recent version but don't know where i can get a stable version. Enviroment: Win2000 SP3 with Apache 2.0.43 --- Red Wingate p.s: plz dont flame about my english :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c
On Wed, 15 Jan 2003, Harald Radi wrote: iirc the reason why i changed it to unsigned was that actually the zend engine treated it as unsigned everywhere but in that particular struct. i also remember that i discussed that with andi and that he agreed to change this in the ze2 cvs module and that the extensions should be *fixed*. Well, fixing the engine is a small, finite task whereas auditing all existing extension on this planet is an open-ended one. I think it is easy to see that. You need to realize that once a certain API has been established, you cannot go around and change it at will. Especially if the breakage is as subtle as in this case. If the compiler dies, because a function takes a new number of arguments, it is something which becomes visible immediately. Signedness issues are usually hidden until someone exploits them. i agree that it doesn't make any sense to mix types. changing it to uint means to fix all the extensions, changing it to int means to fix the engine (and not just to revert my patch). In which areas of the engine did you notice defects? If we had a list, we could start from there. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c
From: Sascha Schumann [mailto:[EMAIL PROTECTED]] iirc the reason why i changed it to unsigned was that actually the zend engine treated it as unsigned everywhere but in that particular struct. i also remember that i discussed that with andi and that he agreed to change this in the ze2 cvs module and that the extensions should be *fixed*. Well, fixing the engine is a small, finite task whereas auditing all existing extension on this planet is an open-ended one. I think it is easy to see that. you're propably a bit too optimistic, i can hardly imagine that all existing extensions all over the world compile out of the box against ZE2. i guess only a handful do this. You need to realize that once a certain API has been established, you cannot go around and change it at will. Especially if the breakage is as subtle as in this case. If the compiler dies, because a function takes a new number of arguments, it is something which becomes visible immediately. Signedness issues are usually hidden until someone exploits them. the only thing that should be realized is that compiler warnings are still a bad thing(tm). i don't see any difference in this compared to changing the number of arguments of a function. i agree that it doesn't make any sense to mix types. changing it to uint means to fix all the extensions, changing it to int means to fix the engine (and not just to revert my patch). In which areas of the engine did you notice defects? If we had a list, we could start from there. hmm, that patch is quite old, i can't remember very well. iirc almost everywhere, but i have to look at my commit again. harald. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Win32] Install Problems....
You'll find the latest development snapshot on http://snaps.php.net On Wed, 2003-01-15 at 14:24, Red Wingate wrote: don't know where i can get a stable version. Enviroment: Win2000 SP3 with Apache 2.0.43 --- Red Wingate p.s: plz dont flame about my english :) -- Xavier Spriet [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)
[EMAIL PROTECTED] (Sascha Schumann) wrote: And we should not close our eyes from the possibility of a 4.3.1 release (e.g. due to a security issue). In that not-so-remote event, having a 4.3 branch with minimal changes is a simple requirement. With 4.3.0 you introduced lots of useful new features and new code (streams, bundled gd, PEAR release) and is - in my eyes - one of the biggest steps since 4.0.0. However - there have also been some new and annoying bugs. So why not release a bugfix 4.3.1 not because of a security hole but just to complete the great work already done on PHP 4.3 - before definitely jumping to PHP 5? Maybe I'm too swissy, but it makes me sad when I see PHP 4 beeing thrown away so fast... and PHP 5 will not be mature with the 5.0.0 release, there will be bugs, missing extensions and so on. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Fwd: 4.3.0 w/ Sablotron version check problem]
That's because -lpng was compiled with gcc2, because the config.log showed an error in -lpng and barfed on the first C++ extension. See his config.log at: http://www.theapotek.com/teknotes/config.log.txt At 22:07 1/15/2003, J Smith wrote: And here's my error output during config: checking for XSLT Sablotron backend... yes checking for libexpat dir for Sablotron XSL support... yes checking for iconv dir for Sablotron XSL support... yes checking for JavaScript for Sablotron XSL support... yes checking for Sablotron libraries in the default path... found in /usr/local checking for sablot-config... found checking for Sablotron version... configure: error: Sablotron version 0.96 or greater required. The Machine is Red Hat Linux v 2.4.7-10 Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua @Logan I spent a minute looking at my own code by accident. @Logan I was thinking What the hell is this guy doing? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)
On Wed, 15 Jan 2003, Christoph Grottolo wrote: So why not release a bugfix 4.3.1 not because of a security hole but just to complete the great work already done on PHP 4.3 - before definitely jumping to PHP 5? Who said that we're not going to release a 4.3.1 or 4.3.n? I'm just not favoring new code going into the PHP_4_3 branch, but only bugfixes. I'd like to see new functionality going into HEAD, for PHP 5. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)
[EMAIL PROTECTED] (Derick Rethans) wrote: So why not release a bugfix 4.3.1 not because of a security hole but just to complete the great work already done on PHP 4.3 - before definitely jumping to PHP 5? Who said that we're not going to release a 4.3.1 or 4.3.n? I'm just not favoring new code going into the PHP_4_3 branch, but only bugfixes. I'd like to see new functionality going into HEAD, for PHP 5. Maybe I misunderstood when Edin said that there will be no new release for some time due to the move on PHP 5. I completely agree with you, then. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)
Maybe I misunderstood when Edin said that there will be no new release for some time due to the move on PHP 5. Yes, you misunderstood what I said which was that there is not going to be a release from the HEAD branch for some time to come -- until PHP 5 is released. As a matter of fact I think it would be good idea to go for 4.3.1 in February because number of bugfixes in PHP_4_3 branch is already significant and since no major new features have been added there the QA process shouldn't take that long either. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] request data filter
In trying to implement a security policy I need to pass all user-supplied data (GET/POST/Cookie) through a filter function which implements this security. This isn't all that hard to implement as an extension through new 4.3 treat_data and post_handler hooks, however it gets messy when you throw mbstring into the mix as that extension also uses those hooks. The cleanest way I can think of doing this is to add a function pointer to SAPI for the filtering function that will be run right before the php_register_variable_safe() call. Currently we are always calling php_url_decode() on the data before registering the variable, so I propose that we make php_url_decode() the default that an extension can then override. Anybody see any reason not to make this simple change? Without that I will need to somehow detect whether mbstring is present and then filter the data after it has already been registered by mbstring's treat_data/post_handler hooks. That's a big mess! -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] request data filter
You consider running the apache_hooks code? This should be simple there. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] request data filter
On Wed, 15 Jan 2003, George Schlossnagle wrote: You consider running the apache_hooks code? This should be simple there. You mean do the filtering straight from a PHP script that gets called from a hook? That's a lot of looping through a bunch of arrays. This has to happen on every request on the busiest site in the world; it needs to be written in C. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] request data filter
You could have your custom C extension be called as one of the hooks. On Wednesday, January 15, 2003, at 09:42 PM, Rasmus Lerdorf wrote: On Wed, 15 Jan 2003, George Schlossnagle wrote: You consider running the apache_hooks code? This should be simple there. You mean do the filtering straight from a PHP script that gets called from a hook? That's a lot of looping through a bunch of arrays. This has to happen on every request on the busiest site in the world; it needs to be written in C. You could have your custom C extension be called as one of the hooks. Shouldn't be any slower than what you proposed. -Rasmus -- 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
Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)
On Wed, 15 Jan 2003, Derick Rethans wrote: On Wed, 15 Jan 2003, Christoph Grottolo wrote: So why not release a bugfix 4.3.1 not because of a security hole but just to complete the great work already done on PHP 4.3 - before definitely jumping to PHP 5? Who said that we're not going to release a 4.3.1 or 4.3.n? I'm just not favoring new code going into the PHP_4_3 branch, but only bugfixes. I'd like to see new functionality going into HEAD, for PHP 5. You might favor that, but I don't pretend that PHP 5.x will become useful immediately for my purposes. I need something to rely on and that is PHP 4 at this time. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)
Who said that we're not going to release a 4.3.1 or 4.3.n? I'm just not favoring new code going into the PHP_4_3 branch, but only bugfixes. I'd like to see new functionality going into HEAD, for PHP 5. You might favor that, but I don't pretend that PHP 5.x will become useful immediately for my purposes. I need something to rely on and that is PHP 4 at this time. I completely agree. We can't stall all new development waiting for PHP 5. For example, my little user data filter hook thing would be considered a new feature that I really can't wait for PHP 5 for. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c
you're propably a bit too optimistic, i can hardly imagine that all existing extensions all over the world compile out of the box against ZE2. i guess only a handful do this. Apparently, most of the extensions PHP ships with seem to work out of the box. I'm under the impression that almost no changes are required, unless you directly manipulate objects. That brings up the question -- do we have some documentation for extension authors which covers necessary changes. the only thing that should be realized is that compiler warnings are still a bad thing(tm). i don't see any difference in this compared to changing the number of arguments of a function. There is an important difference regarding developer awareness: No. of args change: The compiler will always bail out. Developer knows: Aha, I need to fix something. Signedness change: The compiler might issue a warning or not. Developer knows: Usually nothing. There are so many signedness issues in ext/standard alone, that I would not want to run with such warnings enabled. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)
On Wed, 15 Jan 2003, Edin Kadribasic wrote: Maybe I misunderstood when Edin said that there will be no new release for some time due to the move on PHP 5. Yes, you misunderstood what I said which was that there is not going to be a release from the HEAD branch for some time to come -- until PHP 5 is released. As a matter of fact I think it would be good idea to go for 4.3.1 in February because number of bugfixes in PHP_4_3 branch is already significant and since no major new features have been added there the QA process shouldn't take that long either. There were some, for example Sascha's addition. This alone would qualify a full QA, and not a short and fast one. Our general idea was to NOT add new code to release branches, but at the moment developers are still doing this because *they* need a new function and dont want to wait for 5.0.0. I can understand that they dont want to wait for PHP 5, but what I dont understand is that they think less about the general stability and QA processes for the PHP 4.3.x series. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re[2]: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)
DR There were some, for example Sascha's addition. This alone would qualify DR a full QA, and not a short and fast one. Our general idea was to NOT add DR new code to release branches, but at the moment developers are still DR doing this because *they* need a new function and dont want to wait for DR 5.0.0. I can understand that they dont want to wait for PHP 5, but what DR I dont understand is that they think less about the general stability DR and QA processes for the PHP 4.3.x series. As a PHP developper and Hostmaster I really agree with you and I am looking foward a real stable PHP4.3.x with current functionnality and no more ;-) -- Cordialement, Laurentmailto:[EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
