[PHP-DEV] Bug #22651 [Bgs]: mysql_errno/error failing to return a expected error after a failed connect

Hi all. This bug was marked as Bogus, but is a real concern for us at ABR, as we may use many different databases on different servers in the course of generating a page using php. The long and the short of it is, we can't get an error message if connecting to a database fails, after we have a

Re: [PHP-DEV] Bug fixing and CVS

Le sam 08/03/2003 à 12:59, Derick Rethans a écrit : > > Also, right now Mandrake is in deep freeze, so I can only add new > > patches if they are fully documented and tested. I just can't diff the > > cvs with the standard version and apply the changes, otherwise the > > package won't be accepted.

Re: [PHP-DEV] Bug fixing and CVS

On Sat, 8 Mar 2003, Jean-Michel Dault wrote: > Also, right now Mandrake is in deep freeze, so I can only add new > patches if they are fully documented and tested. I just can't diff the > cvs with the standard version and apply the changes, otherwise the > package won't be accepted. That's not re

Re: [PHP-DEV] Bug fixing and CVS

> I would, but the problem is that the snaps are always updated, and the The constant names are php4-latest.tar.bz2 php4-STABLE-latest.tar.bz2 php5-latest.tar.bz2 > old files deleted, and my QA requires that the sources be always > available at the same URL. The sources are

Re: [PHP-DEV] Bug fixing and CVS

Le sam 08/03/2003 à 10:31, Derick Rethans a écrit : > > I maintain PHP for Mandrake Linux, and I try to ship a bug-free PHP. > bug-free doesn't exist :) I said "I try" ;-) I always try the impossible ;-) > > That is, if there were some showstopper bugs that were not corrected in > > 4.3.1, I take

Re: [PHP-DEV] Bug fixing and CVS

On Fri, 7 Mar 2003, Jean-Michel Dault wrote: > > I maintain PHP for Mandrake Linux, and I try to ship a bug-free PHP. bug-free doesn't exist :) > That is, if there were some showstopper bugs that were not corrected in > 4.3.1, I take the bugfixes from CVS and apply them. If you want to do that,

Re: [PHP-DEV] bug in zend_API.c (with patch)

On Sat, 7 Mar 2003, Eric Lambart wrote: > > Adding strtolower calls will only slow down the whole language. > but my > point is the overhead involved cannot possibly rival the amount already > created by the zend_str_tolower() calls within zend_execute.c, which is > surely encountered far more o

Re: [PHP-DEV] bug in zend_API.c (with patch)

On Fri, 2003-03-07 at 15:30, Wez Furlong wrote: > It's not a bug; PHP is a case-IN-sensitive language when it comes to > function and class names. I understand that, and if my message implied anything differently, I apologize. That is precisely the problem I am addressing; when storing the functi

Re: [PHP-DEV] bug in zend_API.c (with patch)

It's not a bug; PHP is a case-IN-sensitive language when it comes to function and class names. Adding strtolower calls will only slow down the whole language. Using lowercase function and class names is the best solution. --Wez. On Fri, 7 Mar 2003, Eric Lambart wrote: > On Fri, 2003-03-07 at 1

Re: [PHP-DEV] bug in zend_API.c (with patch)

On Fri, 2003-03-07 at 14:24, Brad LaFountain wrote: > Why can't you just simply name your classes all lowercase. Because then I wouldn't have discovered the bug! =) > All of the extensions currently do this and it works fine. Apparently that is the case--that's probably why I had the pleasure of

Re: [PHP-DEV] bug in zend_API.c (with patch)

Why can't you just simply name your classes all lowercase. All of the extensions currently do this and it works fine. - Brad --- Eric Lambart <[EMAIL PROTECTED]> wrote: > Hello. > > After a short bout of hair-pulling, I have discovered the source (in the > Zend engine) of a recent problem, and h

[PHP-DEV] bug in zend_API.c (with patch)

Hello. After a short bout of hair-pulling, I have discovered the source (in the Zend engine) of a recent problem, and have fixed it. BACKGROUND: As I have mentioned previously on this list, I am developing a complex PHP extension, which among many other things creates its own PHP classes, and whe

[PHP-DEV] Bug fixing and CVS

Hello, I'm not sure this is the right mailing list, but at least it's not about development _with_ php, it's about development _of_ php ;-) I maintain PHP for Mandrake Linux, and I try to ship a bug-free PHP. That is, if there were some showstopper bugs that were not corrected in 4.3.1, I take th

[PHP-DEV] Bug or not?

Hi, I just tried to compile PHP 4.3.1 in AIX 4.3.3. Compile crashed because in ext/socket/socket.c there is #define _XOPEN_SOURCE_EXTENDED and it's already defined in /usr/include/standard.h in AIX... -Juha- ### This message has been scanned by

Re: [PHP-DEV] bug notification ?

No. --Jani On Wed, 26 Feb 2003, Corne' Cornelius wrote: >Are maintainers of extensions automagically notified of bugs submitted >regarding the ext's they maintain ? > >Corne' > >!Exclude Disclaimer! > > > -- <- For Sale! -> -- PHP Development Mailing List

[PHP-DEV] bug notification ?

Are maintainers of extensions automagically notified of bugs submitted regarding the ext's they maintain ? Corne' !Exclude Disclaimer! -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bug #22103

On Sat, 8 Feb 2003, Pierre-Alain Joye wrote: >Hello, > >About this bug, I can backport the new functions wroten for the new gd. >But I do not know if it is allowed to add new functions to the current >HEAD or 4_3_0. The new functions fix only the filled ellipse/circle >problem, the new filled_arc

[PHP-DEV] bug #22103

Hello, About this bug, I can backport the new functions wroten for the new gd. But I do not know if it is allowed to add new functions to the current HEAD or 4_3_0. The new functions fix only the filled ellipse/circle problem, the new filled_arc cannot be fixed without adding a lot of things to th

Re: [PHP-DEV] Bug #21279 Karma request (Windows Bug)

tyle /*comments*/. > > > > Also, send a unified diff. Do this by running cvs diff -u > modified>. > > > > Joseph > > > > > -----Original Message- > > > From: Ernani Joppert Pontes Martins [mailto:[EMAIL PROTECTED]] > > > Sent: Wed

Re: [PHP-DEV] Bug #21279 Karma request (Windows Bug)

On Wed, 5 Feb 2003, Ernani Joppert Pontes Martins wrote: > > OK, I will change the Style of the comments > > But that's not the point. > > The point is that I need CVS Karma to commit it and I don't have. If you only have such a small fix you generally don't need karma, as other people can co

[PHP-DEV] Bug #5975 request

The last patch was core dumping, now it's fixed. It runs fine here in my system, last php 5 CVS. The patch is in: http://www.ricesu.com.br/php_dev/patch_new.diff Please, take a look and apply it if it's ok. Regards, Fabricio Olivetti -- PHP Development Mailing List To un

Re: [PHP-DEV] Bug #21279 Karma request (Windows Bug)

fied diff. Do this by running cvs diff -u > modified>. > > > > Joseph > > > > > -Original Message- > > > From: Ernani Joppert Pontes Martins [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, February 05, 2003 10:05 AM > > >

Re: [PHP-DEV] Bug #21279 Karma request (Windows Bug)

. Also, send a unified diff. Do this by running cvs diff -u . Joseph -Original Message- From: Ernani Joppert Pontes Martins [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 10:05 AM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Bug #21279 Karma request (Windows Bug) Hi Rasmu

Re: [PHP-DEV] Bug #21279 Karma request (Windows Bug)

tes Martins [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, February 05, 2003 10:05 AM > > To: [EMAIL PROTECTED] > > Subject: [PHP-DEV] Bug #21279 Karma request (Windows Bug) > > > > > > Hi Rasmus, > > > > A Few months ago I was willing to help in bug

RE: [PHP-DEV] Bug #21279 Karma request (Windows Bug)

You need to use "C" style /*comments*/. Also, send a unified diff. Do this by running cvs diff -u . Joseph > -Original Message- > From: Ernani Joppert Pontes Martins [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 05, 2003 10:05 AM > To: [EMAIL PROTECTE

[PHP-DEV] Bug #21279 Karma request (Windows Bug)

Hi Rasmus, A Few months ago I was willing to help in bug fixes and bcompiler development I solved the bug #21279 and now I need karma to commit my changes there I debbuged the file with the help of Manuel Lemos and I found the bug. Here is the diff: 1615: // Z_STRVAL_P(tmp) = empty_string

Re: [PHP-DEV] Bug #5975 request

r" <[EMAIL PROTECTED]> To: "Keyser Soze" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, February 04, 2003 5:57 PM Subject: Re: [PHP-DEV] Bug #5975 request Patch looks ok. Just be sure to use zend_parse_parameters instead of zend_get_parameters and zend_bool in

Re: [PHP-DEV] Bug #5975 request

Patch looks ok. Just be sure to use zend_parse_parameters instead of zend_get_parameters and zend_bool instead of an integer (just grep ext/standard/* for zend_parse_parameters for examples). Tal Keyser Soze wrote: Sending in plain text: - cut here

Re: [PHP-DEV] Bug #5975 request

t; Sent: Tuesday, February 04, 2003 5:44 PM Subject: Re: [PHP-DEV] Bug #5975 request On Tue, 4 Feb 2003, Keyser Soze wrote: > Sending in plain text: Got mangled :I Can you put it on the web? Derick -- - Deric

Re: [PHP-DEV] Bug #5975 request

On Tue, 4 Feb 2003, Keyser Soze wrote: > Sending in plain text: Got mangled :I Can you put it on the web? Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine

[PHP-DEV] Bug #5975 request

Sending in plain text: - cut here ? patch.diff ? ext/standard/file_new.c ? ext/standard/string_new.c Index: ext/standard/file.c === RCS file: /repository/php4

Re: [PHP-DEV] Bug #5975 request

ck Rethans" <[EMAIL PROTECTED]> To: "Keyser Soze" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, February 04, 2003 4:52 PM Subject: Re: [PHP-DEV] Bug #5975 request On Tue, 4 Feb 2003, Keyser Soze wrote: > > Hi all, > > I implemented the B

Re: [PHP-DEV] Bug #5975 request

On Tue, 4 Feb 2003, Keyser Soze wrote: > > Hi all, > > I implemented the BUG #5975 requesting a third parameter in strip_tags, to > disallow the tags in the second parameter instead of allowing then. But > since I don't have CVS account, I would like that someone send me the files > ext/standard

[PHP-DEV] Bug #5975 request

Hi all, I implemented the BUG #5975 requesting a third parameter in strip_tags, to disallow the tags in the second parameter instead of allowing then. But since I don't have CVS account, I would like that someone send me the files ext/standard/string.c ext/standard/php_string.h ext/standard/file.

[PHP-DEV] Bug # 13551, bcmath scale:: when to apply

Andi, Nicos assigned this bug to you a month ago, but since I've seen no activity (and it's entirely possible you didn't know he'd assigned it) I went ahead and took a crack at it. Would you care to give me the go ahead to commit/close for you? ...or tell me to mind my own bugs? :) Patches ag

Re: [PHP-DEV] Bug # 21261 -- PHP_SELF not set correctly with sapi/CGI

Sara Golemon wrote: It looks like the correct behavior was broken with patch 1.199 to php/sapi/cgi/cgi_main.c Because there are a number of modifications in this patch and I don't want to go messing it up any further I'll ask the original patch submitter (shane) to take a look and reconsider the

[PHP-DEV] Bug # 21261 -- PHP_SELF not set correctly with sapi/CGI

It looks like the correct behavior was broken with patch 1.199 to php/sapi/cgi/cgi_main.c Because there are a number of modifications in this patch and I don't want to go messing it up any further I'll ask the original patch submitter (shane) to take a look and reconsider the argv0 hack that was r

[PHP-DEV] Bug # 21177 - main/main.c_r1.515 - Second call to sapi_activate?

Ref: http://bugs.php.net/21177 r1.515 seems to have added a second call to sapi_activate. In the case of this particular bug this is causing the following behavior: 1) Call sapi_active: initialize sapi globals 2) sapi/cgi sets SG(headers_sent) = 1 for options like -q & -f 3) New Code in patch

[PHP-DEV] bug #16820

Hi! some time ago (half year or so) I submited this bug ... I cleaned the patch (at last ;)) - it is in attached file. It applies to php-4.2.3 and also to php-4.3.0RC3 (with offset warnings but works ok). Please someone add it to main version or give me CVS account so I could do it by myself. Re

Re: [PHP-DEV] Bug #20887 (Two separate issues)

Note that the patche is still incomplete because it dismisses many *nix OS out there other than SunOS, Linux, FreeBSD, OpenBSD and NetBSD. Moriyoshi "Sara Golemon" <[EMAIL PROTECTED]> wrote: > > ??? The original report goes: > > > > If /php.ini exists, that one is used no matter what PHPRC en

Re: [PHP-DEV] Bug #20887 (Two separate issues)

> ??? The original report goes: > > If /php.ini exists, that one is used no matter what PHPRC env is set > or compiled in when starting up apache from a SysV script. Is it a bug > in php, or could it be the Mandrake Linux 9.0 system? > My bad, the fact does remain however, that there is a command

Re: [PHP-DEV] Bug #20887 (Two separate issues)

Hi, > The original complaint in bug 20887 was that the CLI version was picking > up ini files in the wrong places. The patch I suggested last night does > address that problem (albiet not correctly, see below). ??? The original report goes: If /php.ini exists, that one is used no matter what

[PHP-DEV] Bug #20887 (Two separate issues)

The original complaint in bug 20887 was that the CLI version was picking up ini files in the wrong places. The patch I suggested last night does address that problem (albiet not correctly, see below). The secondary "bug" which isn't really a bug is the complaint that CWD is included in the ini se

[PHP-DEV] bug #15209 register_shutdown_function - please discuss

Hi, I know there was some hot discussion about this topic but I really need to get this bug fixed. Even I'll make a patch with my zero knowledge of c if no one would like to make it, but please try to find a reasonable sollution that fits (almost) everyone's need. I thought of one. I think a ne

[PHP-DEV] Bug #20807

Hi, the attached patch fixes bug #20807. It's against current HEAD. Verified to install 'php' and 'php-cli' (without the exe extension). -- With kind regards, Melvyn Sopacua Index: sapi/cli/config.m4 === RCS file: /repository/p

[PHP-DEV] Bug # 20746

User requets that aggregation_info() be renamed to aggregate_info() to bring it inline with other functions in that module: (e.g.: aggregate(), aggregate_methods(), aggregate_properties(), etc...) It doesn't seem unreasonable to do the rename and include an alias for backward compatability. Objec

[PHP-DEV] Bug #20449

Just wondering if anyone has a 'heads-up' on this issue or and insight into a fix. http://bugs.php.net/bug.php?id=20449 -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] bug of the day: $this

Hi, $this stays defined when an instantatiated member function calls a non-instantiated member function. Here's the tester: test(); } function btest() { b::test(); } } class b { function test() { var_dump($this); } function objtest($obj) { $obj->test(); } functio

Re: [PHP-DEV] Bug or Not?

At 16:34 03.12.2002, Adam Voigt wrote: I have some data that can't contain certain character's, so I have something akin to the following: function getProper($string) { $string = strip_tags($string); $string = str_replace("][","][",$string); $string = str_replace("'","'",$string); $string = str_r

[PHP-DEV] Bug or Not?

I have some data that can't contain certain character's, so I have something akin to the following: function getProper($string) { $string = strip_tags($string); $string = str_replace("][","][",$string); $string = str_replace("'","'",$string); $string = str_replace("\"",""",$string)

Re: [PHP-DEV] Bug #20460 (Feature Request)

On Sat, 30 Nov 2002, Stig S. Bakken wrote: > > 4) Make sure we can use fscanf on a dynamically sized buffer. This will > > definitely the hardest solution, but also the most beautiful one. > > [4] is definitely the best option. formatted_print.c already does > something similar. Stig, it's al

Re: [PHP-DEV] Bug #20460 (Feature Request)

On Wed, 27 Nov 2002, Derick Rethans wrote: > On Wed, 27 Nov 2002, Sara Pollita Golemon wrote: > > > User complains that maximum length of a line used by fscanf is too short > > (he has lines > 1600 chars). Looking at file.h I agree (it's only 512). > > > > The user requested two options: > > >

Re: [PHP-DEV] Bug #20308 (Feature Request)

>> I'm not so much worried about the user in this case, a few explodes >> will keep them happy. I'm more worried about the behavior of >> parse_url being just plain lacking. >> mailto:[EMAIL PROTECTED]?subject=Bug+20308 should be entitled to >> everybit as much parsing as >> http://joe:[EMAIL PROT

Re: [PHP-DEV] Bug #20308 (Feature Request)

On November 29, 2002 12:41 pm, Sara Golemon wrote: > >> It looks like php_url_parse can be modified to return user and host > >> for mailto schemes without making it a 'special case', but that would > >> also remove the current 'path' index which would break existing PHP > >> code ((bad)). > >> > >

Re: [PHP-DEV] Bug #20308 (Feature Request)

On Fri, 29 Nov 2002, Sara Golemon wrote: > I'm not so much worried about the user in this case, a few explodes will > keep them happy. I'm more worried about the behavior of parse_url being > just plain lacking. mailto:[EMAIL PROTECTED]?subject=Bug+20308 should be > entitled to everybit as much

Re: [PHP-DEV] Bug #20308 (Feature Request)

>> It looks like php_url_parse can be modified to return user and host >> for mailto schemes without making it a 'special case', but that would >> also remove the current 'path' index which would break existing PHP >> code ((bad)). >> >> So we can (A) put in a special case, or (B) not modify the fu

Re: [PHP-DEV] Bug #20308 (Feature Request)

On November 29, 2002 01:05 am, Sara Golemon wrote: > >> I disagree with this, the current behaviour is imho wrong. > >> > >> mailto: is a url, rejecting the patch because it introduces a special > >> case, is not a good thing. parse_url() is for _all_ url's, not just > >> http:// url's, and beside

Re: [PHP-DEV] Bug #2965

On Thu, 28 Nov 2002, John Coggeshall wrote: > > This bug was changed to a documentation problem, and I'm a bit confused > as to what exactly the issue is > > For($i = 'A'; $i <= 'Z' $i++) echo $i; > > I'm assuming this *should* echo the A-Z alphabet (which it doesn't).. > But, since it was

Re: [PHP-DEV] Bug #20308 (Feature Request)

>> I disagree with this, the current behaviour is imho wrong. >> >> mailto: is a url, rejecting the patch because it introduces a special >> case, is not a good thing. parse_url() is for _all_ url's, not just >> http:// url's, and besides, the current syntax for mailto is >> completely valid, and

[PHP-DEV] Bug #2965

This bug was changed to a documentation problem, and I'm a bit confused as to what exactly the issue is For($i = 'A'; $i <= 'Z' $i++) echo $i; I'm assuming this *should* echo the A-Z alphabet (which it doesn't).. But, since it was changed to a documentation problem -- is the current form in

[PHP-DEV] Bug #2965

This bug was changed to a documentation problem, and I'm a bit confused as to what exactly the issue is For($i = 'A'; $i <= 'Z' $i++) echo $i; I'm assuming this *should* echo the A-Z alphabet (which it doesn't).. But, since it was changed to a documentation problem -- is the current form in

Re: [PHP-DEV] Bug #20308 (Feature Request)

On November 27, 2002 04:32 pm, Sterling Hughes wrote: > > On November 27, 2002 04:45 pm, Sara "Pollita" Golemon wrote: > > > That was one of the comments I was looking for "Is this really > > > necessary?" After all the user can certainly use explode() to take it > > > apart. I'm not against givin

Re: [PHP-DEV] Bug #20308 (Feature Request)

> On November 27, 2002 04:45 pm, Sara "Pollita" Golemon wrote: > > That was one of the comments I was looking for "Is this really necessary?" > > After all the user can certainly use explode() to take it apart. I'm not > > against giving him that answer, it was just a quick patch to write... > >

Re: [PHP-DEV] Bug #20308 (Feature Request)

On November 27, 2002 04:45 pm, Sara "Pollita" Golemon wrote: > That was one of the comments I was looking for "Is this really necessary?" > After all the user can certainly use explode() to take it apart. I'm not > against giving him that answer, it was just a quick patch to write... > > Is that

Re: [PHP-DEV] Bug #20308 (Feature Request)

That was one of the comments I was looking for "Is this really necessary?" After all the user can certainly use explode() to take it apart. I'm not against giving him that answer, it was just a quick patch to write... Is that a -1 then? > I am not so sure that adding special cases for things li

Re: [PHP-DEV] Bug #20308 (Feature Request)

I am not so sure that adding special cases for things like mailto: and so on is a good idea. The code works identically to how it worked in 4.2.3 and prior. Ilia On November 27, 2002 04:19 pm, Sara "Pollita" Golemon wrote: > While waiting for opinions on Bug#20460 I went ahead and addressed #20

Re: [PHP-DEV] Bug #20308 (Feature Request)

> While waiting for opinions on Bug#20460 I went ahead and addressed #20308. > > User complains that parse_url returns the full email address in 'path' > element. Makes reference to documents which claim it should return 'user' > and 'host' element. > > To address this request and maintain backw

[PHP-DEV] Bug #20308 (Feature Request)

While waiting for opinions on Bug#20460 I went ahead and addressed #20308. User complains that parse_url returns the full email address in 'path' element. Makes reference to documents which claim it should return 'user' and 'host' element. To address this request and maintain backward compatabil

Re: [PHP-DEV] Bug #20460 (Feature Request)

On Wed, 27 Nov 2002, Sara Pollita Golemon wrote: > >> Derick Rethans <[EMAIL PROTECTED]> wrote: > >> > >> > I don't like us adding a new ini entry for this, I think we should > >> try another option: > >> > > >> > 4) Make sure we can use fscanf on a dynamically sized buffer. This > >> will defin

Re: [PHP-DEV] Bug #20460 (Feature Request)

> >> Derick Rethans <[EMAIL PROTECTED]> wrote: > >> > >> > I don't like us adding a new ini entry for this, I think we should > >> try another option: > >> > > >> > 4) Make sure we can use fscanf on a dynamically sized buffer. This > >> will definitely the hardest solution, but also the most beau

Re: [PHP-DEV] Bug #20460 (Feature Request)

>> Derick Rethans <[EMAIL PROTECTED]> wrote: >> >> > I don't like us adding a new ini entry for this, I think we should >> try another option: >> > >> > 4) Make sure we can use fscanf on a dynamically sized buffer. This >> will definitely the hardest solution, but also the most beautiful >> one.

Re: [PHP-DEV] Bug #20460 (Feature Request)

Sterling Hughes <[EMAIL PROTECTED]> wrote: > > > err. it didn't need a reimplementation, i fixed it, it works fine in cvs. > > > > Then, > > > > > $buf = "123 456 \0 567" > > sscanf($buf, "%d%d%s%d", $a, $b, $c, $d); > > var_dump($a, $b, $c, $d); > > ?> > > > > How about this? > > > > T

Re: [PHP-DEV] Bug #20460 (Feature Request)

> > err. it didn't need a reimplementation, i fixed it, it works fine in cvs. > > Then, > >$buf = "123 456 \0 567" > sscanf($buf, "%d%d%s%d", $a, $b, $c, $d); > var_dump($a, $b, $c, $d); > ?> > > How about this? > > The result was the same as for fscanf. > Yes, but it didn't need a rei

Re: [PHP-DEV] Bug #20460 (Feature Request)

> err. it didn't need a reimplementation, i fixed it, it works fine in cvs. Then, How about this? The result was the same as for fscanf. Moriyoshi > > -Sterling > > > > Moriyoshi > > > > > Derick > > > > > > -- > > > > > > --

Re: [PHP-DEV] Bug #20460 (Feature Request)

On Thu, 28 Nov 2002, Moriyoshi Koizumi wrote: > Derick Rethans <[EMAIL PROTECTED]> wrote: > > > I don't like us adding a new ini entry for this, I think we should try > > another option: > > > > 4) Make sure we can use fscanf on a dynamically sized buffer. This will > > definitely the hardest

Re: [PHP-DEV] Bug #20460 (Feature Request)

> > > > I don't like us adding a new ini entry for this, I think we should try > > another option: > > > > 4) Make sure we can use fscanf on a dynamically sized buffer. This will > > definitely the hardest solution, but also the most beautiful one. > > I like this fourth option, because the in

Re: [PHP-DEV] Bug #20460 (Feature Request)

Derick Rethans <[EMAIL PROTECTED]> wrote: > On Wed, 27 Nov 2002, Sara Pollita Golemon wrote: > > > User complains that maximum length of a line used by fscanf is too short > > (he has lines > 1600 chars). Looking at file.h I agree (it's only 512). > > > > The user requested two options: > > >

Re: [PHP-DEV] Bug #20460 (Feature Request)

> User complains that maximum length of a line used by fscanf is too short > (he has lines > 1600 chars). Looking at file.h I agree (it's only 512). > > The user requested two options: > > 1) Add an optional length field. > No way to do that without breaking parameter list. :( > > 2) Increase

Re: [PHP-DEV] Bug #20460 (Feature Request)

On Wed, 27 Nov 2002, Sara Pollita Golemon wrote: > User complains that maximum length of a line used by fscanf is too short > (he has lines > 1600 chars). Looking at file.h I agree (it's only 512). > > The user requested two options: > > 1) Add an optional length field. > No way to do that wi

[PHP-DEV] Bug #20460 (Feature Request)

User complains that maximum length of a line used by fscanf is too short (he has lines > 1600 chars). Looking at file.h I agree (it's only 512). The user requested two options: 1) Add an optional length field. No way to do that without breaking parameter list. :( 2) Increase to a larger arbit

Re: [PHP-DEV] Bug #20377

t: Saturday, November 16, 2002 12:47 AM Subject: Re: [PHP-DEV] Bug #20377 > On Fri, 15 Nov 2002 [EMAIL PROTECTED] wrote: > > > Hello, > > > > What do you think of that? > > Davey propose to have : > > open_basedir > > session.save_path > > upl

Re: [PHP-DEV] Bug #20377

On Fri, 15 Nov 2002 [EMAIL PROTECTED] wrote: > Hello, > > What do you think of that? > Davey propose to have : > open_basedir > session.save_path > upload_tmp_dir > > PHP_INI_SYSTEM|PHP_INI_PERDIR. -1 on that. .htaccess also falls in the PERDIR class, and it's not a good idea to allow

[PHP-DEV] Bug #20377

Hello, What do you think of that? Davey propose to have : open_basedir session.save_path upload_tmp_dir PHP_INI_SYSTEM|PHP_INI_PERDIR. Regards. M.CHAILLAN [EMAIL PROTECTED] Hébergement de sites internets. -- PHP Development Mailing List To unsubscribe, visit: h

Re: [PHP-DEV] Bug #20175 (Static vars can't store ref to new instance)

This should be solved in ZE2. We now treat static variables like special variables such as $GLOBALS, $this and so on where they are treated at compile-time. This means that they are faster now but they can't be referenced indirectly similar to the above mentioned. I don't think this is a problem

[PHP-DEV] Bug 20147

Bug #20147 has been reported as a PEAR bug, but IMO this sounds more like a PHP problem. The user reports that he gets the error message /usr/src/ServerSoftware/PHP/php-4.3.0pre2/sapi/cli/php: relocation error: /usr/local/php/lib/php/extensions/no-debug-non-zts-20020429/xml.so: undefined symbol: X

Re: [PHP-DEV] Bug in PHP

Mike Robinson wrote: > > You can use PHP as CGI on Win32/IIS platform which proves to > > be far more stable or use Apache instead of IIS. > > Is this documented anywhere? I recall it was fairly well known but it wasn't explicitly mentioned in the install notes. I don't have my bookmarks

RE: [PHP-DEV] Bug in PHP

Markus Fischer writes: > > You can use PHP as CGI on Win32/IIS platform which proves to > be far more stable or use Apache instead of IIS. > > The combination you're using is known to have serious > problems and is not recommended. > Is this documented anywhere? Regards Mike R

Re: [PHP-DEV] Bug in PHP

You can use PHP as CGI on Win32/IIS platform which proves to be far more stable or use Apache instead of IIS. The combination you're using is known to have serious problems and is not recommended. On Mon, Nov 04, 2002 at 05:36:53PM -0200, Domingos Teruel wrote : > Dear Sir, > >

[PHP-DEV] Bug in PHP

Dear Sir, I am PhP programmer and have encountered the following error quite often: PHP has encountered an Access Violation at 77FCBAAC What could be causimg this errors? I have just installed the version 4.3 pre 1 after encountering the samen problems with the version 4.2.3. I have already

Re: [PHP-DEV] [PATCH] A suggested fix for bug #19943 (Re: [PHP-DEV] bug #19943)

I *very slightly* tested it and it worked for me. Not sure of the old code though. -- Maxim Maletsky [EMAIL PROTECTED] "Ilia A." <[EMAIL PROTECTED]> wrote... : > On November 5, 2002 09:44 pm, Moriyoshi Koizumi wrote: > > Ilia, thank you for double-checking. > > > > Since I have no access to Z

Re: [PHP-DEV] [PATCH] A suggested fix for bug #19943 (Re: [PHP-DEV]bug #19943)

We'll take a look at this. Thanks, Andi At 07:48 AM 11/6/2002 +0900, Moriyoshi Koizumi wrote: The attached patch may be a fix for that bug. Hope it works. Moriyoshi Moriyoshi Koizumi <[EMAIL PROTECTED]> wrote: > I looked into it, and I've found you really got a point. > >

Re: [PHP-DEV] [PATCH] A suggested fix for bug #19943 (Re: [PHP-DEV] bug #19943)

On November 5, 2002 09:44 pm, Moriyoshi Koizumi wrote: > Ilia, thank you for double-checking. > > Since I have no access to Zend module, I'm waiting for that to be > committed by someone for now... Does it need more review? It would probably be a good idea if more developers review this patch befo

Re: [PHP-DEV] [PATCH] A suggested fix for bug #19943 (Re: [PHP-DEV] bug #19943)

Ilia, thank you for double-checking. Since I have no access to Zend module, I'm waiting for that to be committed by someone for now... Does it need more review? Moriyoshi "Ilia A." <[EMAIL PROTECTED]> wrote: > The new appears to work correctly and previously mentioned problem no longer > occ

Re: [PHP-DEV] [PATCH] A suggested fix for bug #19943 (Re: [PHP-DEV] bug #19943)

The new appears to work correctly and previously mentioned problem no longer occures. I've also ran the test suit after applying the patch and none of the tests have been adversly affected, so it does not appear to break any old functionality. Ilia On November 5, 2002 09:17 pm, Moriyoshi Koizu

Re: [PHP-DEV] [PATCH] A suggested fix for bug #19943 (Re: [PHP-DEV] bug #19943)

> The patch does work and memory leak goes away after it is applied. There is > another problem that I've just noticed. If you increase the loop from 10 to > 100 then you'll see that the $ragged[$count]['idx'] value is always the 1st > character of the $ragged[$count] value. > If a var_dump of

Re: [PHP-DEV] [PATCH] A suggested fix for bug #19943 (Re: [PHP-DEV] bug #19943)

The patch does work and memory leak goes away after it is applied. There is another problem that I've just noticed. If you increase the loop from 10 to 100 then you'll see that the $ragged[$count]['idx'] value is always the 1st character of the $ragged[$count] value. If a var_dump of an array i

[PHP-DEV] [PATCH] A suggested fix for bug #19943 (Re: [PHP-DEV] bug #19943)

The attached patch may be a fix for that bug. Hope it works. Moriyoshi Moriyoshi Koizumi <[EMAIL PROTECTED]> wrote: > I looked into it, and I've found you really got a point. > > --- > $ragged = array(); > $ragged[0] = "a"; > $ragged[0][0] = array("1"); > var_dump($rag

Re: [PHP-DEV] bug #19943

I looked into it, and I've found you really got a point. --- --- The first script causes no leaks, while the second does: --- --- Thanks for your insight. Moriyoshi "Ilia A." <[EMAIL PROTECTED]>

Re: [PHP-DEV] bug #19943

I agree with you that this bug may not be critical, I am not certain why it was marked as such, however I do believe this is a bug that should be fixed. If my understand of the situation is correct, the memory leak is the result of original $ragged[$count] = "$count"; expression. At this point ZE

[PHP-DEV] bug #19943

This appears not a bug, but an expected behaviour for me. Let's change it from "Critial" to "Won't Fix" or so on. --- --- The above snippet is actually a variant of the followi

  1   2   3   4   5   6   7   8   9   10   >