Re: [PHP-DEV] Fix for wordwrap()

On March 6, 2003 06:52 am, Jedi/Sector One wrote: > Hello. > > Maybe this is the intended behavior, but wordwrap()'s behavior is a bit > illogical on PHP 4.3.1, as it does only break after a plain whitespace, not > after punctuation, \n, etc. > > Here's a trivial sample : > > $a = "ww

Re: [PHP-DEV] Apache2 SAPI

On March 6, 2003 11:19 am, Derick Rethans wrote: > Our policy is not to merge new things to stable branches (which is > PHP_4_3 now). True, however the apache2handler works much better then the existing apache2filter and as far as I can tell fixes at least 1 crash bug. There maybe more things it

Re: [PHP-DEV] [PATCH] imagesavealpha()

On March 5, 2003 12:18 am, Steven Brown wrote: > I went to update the official gd library with my bug fixes so I could get > them rolled back into PHP's without requiring PHP's gd diverge more, but it > appears between the time PHP bundled gd and now that the gd people have > fixed the most importa

Re: [PHP-DEV] #php.bugs invite only?

On February 28, 2003 11:50 am, George Schlossnagle wrote: > #php.bugs seems to be invite only now. How do I go about getting > myself invited? It would appear someone had accidentaly set the channel to invite only, it is fixed now. Ilia -- PHP Development Mailing List To

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/tokenizer tokenizer.c

On February 25, 2003 05:05 pm, Magnus M wrote: > On Tue, 25 Feb 2003 14:45:26 -0500 > > J Smith <[EMAIL PROTECTED]> wrote: > > I get missing > > symbols like ZEND_INI_PARSER_POP_ENTRY and such, which should be defined > > in zend_ini.h.) Checking out php5 seemed to correct this. > > That is because

Re: [PHP-DEV] file_put_contents() / file_add_contents() ?

On February 21, 2003 09:38 am, Sascha Schumann wrote: > > implode) and fclose. However, IMO this wrapper is very useful since it > > simplifies commonly used code a great deal and even makes it slightly > > faster since the wrapper is in C rather then in PHP. > > Oh, come on. Put it into a uti

Re: [PHP-DEV] file_put_contents() / file_add_contents() ?

On February 21, 2003 05:00 am, Sascha Schumann wrote: > Alternatively, I would suggest to teach the submitter of that > patch regarding fopen, fwrite, implode. He might have > overlooked those existing functions. That's what I like about PHP, you learn about new functions every single

Re: [PHP-DEV] file_put_contents() / file_add_contents() ?

On February 21, 2003 04:54 am, Wez Furlong wrote: > Look in the archives for that guys original patch; it allowed doing > something like this: > > $foo = array(); > > $foo[] = "some text"; > $foo[] = "more text"; > > file_put_contents("file.txt", $foo); > > and also: > >

Re: [PHP-DEV] file_put_contents() / file_add_contents() ?

On February 20, 2003 02:51 pm, Sara Golemon wrote: > Was it decided not to create these? Yes > Is it simply a matter of noone having gotten around to it? Yes > Am I paying too much attention to the voices in my head? Maybe ;) Joking aside, I do have a patch to implement the mentioned functi

Re: [PHP-DEV] CLI & long options

On February 15, 2003 12:16 pm, Marcus Börger wrote: > the patch below allows long option names such as "--version" and "--help" > what eases the use of php especially when used on the command line. > And it fixes the problem with duplicate error messages if arguments to > command line are erroneous

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard file.c

Here is the final revision of the patch. Ilia Index: ext/standard/file.c === RCS file: /repository/php4/ext/standard/file.c,v retrieving revision 1.300 diff -u -3 -p -r1.300 file.c --- ext/standard/file.c 9 Feb 2003 23:11:23 -

Re: [PHP-DEV] [PATCH] Apache 2.0 Handler module

The patch appears to work correctly with only one 'interesting' bug. When the virtual() function is used to include a php file or php files are included via the use of mod_include, random binary data is dumped on screen. This is particular to PHP files, as virtual() function can successfully inc

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard file.c

Attached is the proposed solution. Ilia Index: ext/standard/file.c === RCS file: /repository/php4/ext/standard/file.c,v retrieving revision 1.299 diff -u -3 -p -r1.299 file.c --- ext/standard/file.c 9 Feb 2003 20:43:05 - 1.2

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard file.c

On February 10, 2003 03:34 am, you wrote: > On Sun, Feb 09, 2003 at 08:05:14PM -, Ilia Alshanetsky wrote : > > iliaa Sun Feb 9 15:05:14 2003 EDT > > > > Modified files: > > /php4/ext/standard file.c > > Log: > > Added feature request #14097 (option allowing file()

Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions

On February 6, 2003 11:17 am, David Gillies wrote: > In a similar itch-scratching moment I whipped up a > trivial PHP module that groks tzfile timezone files to > give you the offset from GMT at any time in the Unix > epoch. I needed this to preflight a bunch of data > which had been gathered with

Re: [PHP-DEV] Re: str_ireplace vs. stri_replace

> 1. Not all users will notice the extra parameter easily. Will take some > time. This modification will not appear until PHP 5 is released, by then this extra parameter (hopefully) will be well documented and people will be aware that it exists. Adding extra code, which virtually does the same

Re: [PHP-DEV] Re: str_ireplace vs. stri_replace

On January 30, 2003 04:55 pm, Jon Parise wrote: > On Thu, Jan 30, 2003 at 01:44:27PM -0800, Sara Golemon wrote: > > You're not the first to voice this opinion. *I* feel str_ireplace is > > better as it follows the naming convention of _. > > Others feel stri_replace is better as that follows ereg

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

> Well, actually, I would prefer to see a proper BNDM > implementation in the tree. > > - character classes are handled for free > (i.e. a case insensitive search does not take longer) > > - combining shift-and and automata is much faster than our > current naive algorit

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

On January 29, 2003 04:35 pm, Shane Caraveo wrote: > What's the benchmark code? How is the benchmark difference on large > text (ie. 100K of text) vs. small text (1K or smaller)? Attached is the benchmark script that I've used. I've intentionally used 'small' strings, since that is what I imagin

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

> I may be wrong since I haven't profiled this, but my understanding is > that str_replace is much faster than doing either of the regex > replacements. For that reason alone, there is a use for it. Normally it would be quite faster, however once case sensitivity is added to the mix I believe th

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / configure.in /main php_ini.c php_scandir.c php_scandir.h /win32 readdir.c readdir.h

On January 27, 2003 04:12 pm, Sebastian Bergmann wrote: > This broke the Win32 build. > > The attached patch works for me, but I'd like it reviewed before I > commit. The header patch looks good, please commit it. Thanks. Ilia -- PHP Development Mailing List To unsu

Re: [PHP-DEV] Error from last cvs (php4)

The error occurs because you are trying to compile HEAD (which is php5, based on ZE2) with ZE1, hence certain defined constants are not avaliable. To checkout head use 'php5' tag, that will get you latest PHP sources + ZE2. Ilia -- PHP Development Mailing List To unsubscr

Re: [PHP-DEV] Adding to the bundled GDlib

On January 25, 2003 01:40 pm, Kasper Skårhøj wrote: > But my actual request is this: > - Who is in charge of the bundled GD? (Who can I discuss it with) There are a number of people who had contributed their wonderful work to PHP's GD extension and the bundled GD library. As far as active maintai

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/gd gd.c /ext/gd/libgd gd.c gd.h gd_gd2.c gd_jpeg.c

On January 17, 2003 03:31 pm, Pierre-Alain Joye wrote: > MFH'ing this commit should be a good thing. > > pierre Indeed, new GD introduces some functionality that is likely to make PHP generate invalid gd2 images, due to format not being specified. If no one has any objections I will MFH this com

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 ma

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 bogu

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

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

I imagine that strings greater then 2 billion characters are fairly rare, so I think it would be a good idea to revert the change as per Sascha's suggestion. This is a fairly old limitation and I think no one will miss this feature. Ilia -- PHP Development Mailing List T

[PHP-DEV] string functions

While converting the functions inside string.c to the new parameter parsing API and doing some general cleanup, I've come across an interesting 'feature'. Three string functions: stristr(), strstr() and strpos() have peculiar way of handling non string values passed as 'needle'. Instead of conv

Re: [PHP-DEV] UNIX file command

On January 3, 2003 12:18 pm, Michael Montero wrote: > Is there a built in function in PHP that mimicks the UNIX file command? > For instance, I run : > > file blah.jpg > > and I get this: > > blah.jpg: JPEG image data, JFIF standard 1.01, resolution (DPI), 72 x 72 For identifying images there is a

Re: [PHP-DEV] Patch for #21309 - memory + php_error_docref.

I've already sent Stefan a patch for this problems as well as other issues in the ftp extension. Ilia On January 2, 2003 08:29 pm, [EMAIL PROTECTED] wrote: > Hello, > >Even if this bug was assigned to sesser, this is a patch that fix > the memory managment and that removes perror and rep

Re: [PHP-DEV] Re: [PHP-CVS] Merging into PHP_4_3

On December 30, 2002 02:17 pm, Edin Kadribasic wrote: > > Could you please add a section for the branch (4.3.1?) in the news file. > > Isn't it already there? There is one for 4.4 (possibly to be renamed 5), but I don't see a 4.3.X section. Ilia -- PHP Development Mailing List

[PHP-DEV] Re: [PHP-CVS] Merging into PHP_4_3

On December 30, 2002 02:04 pm, Andrei Zmievski wrote: > I concur. Please remember to update NEWS on the branch. Could you please add a section for the branch (4.3.1?) in the news file. Ilia -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.ph

[PHP-DEV] Proposed fix for bug #21149

The current implementation of php_register_variable_ex() improperly handles situations when the name of the variable passed via GET/POST/COOKIES contains a '[' or it's urlencoded equivalent. The result is a small memory leak (number of chars between '[' and '=' +1) and invalid data inside the G

Re: [PHP-DEV] Re: #21060 [Opn->Bgs]: range() gives warning and returns false when low == high

lues passed as strings and of course the handling for the high == low condition. Ilia On December 20, 2002 10:49 pm, Chandrashekhar Bhosle wrote: > On Fri, 20 Dec 2002 09:44:49 -0500 > > "Ilia A." <[EMAIL PROTECTED]> wrote: > > > > What would be an output then,

Re: [PHP-DEV] Re: #21060 [Opn->Bgs]: range() gives warning and returns false when low == high

On December 20, 2002 09:37 am, you wrote: > On Fri, 20 Dec 2002, Ilia A. wrote: > > On December 20, 2002 06:35 am, you wrote: > > > > Thank you for taking the time to write to us, but this is not > > > > a bug. Please double-check the documentation available at

[PHP-DEV] Re: #21060 [Opn->Bgs]: range() gives warning and returns false when low == high

On December 20, 2002 06:35 am, you wrote: > On 20 Dec 2002 [EMAIL PROTECTED] wrote: > > ID: 21060 > > Updated by: [EMAIL PROTECTED] > > Reported By: [EMAIL PROTECTED] > > -Status: Open > > +Status: Bogus > > Bug Type: Arrays related > > Oper

Re: [PHP-DEV] Re: #20972 [Opn->Csd]: make fails during gd.c

On December 12, 2002 06:13 pm, Mike Robinson wrote: > Ilia A. wrote: > > This is a different bug (xpm) caused by a bug in the external > > GD library, this > > particular bug has been solved in the CVS. Unless you've > > patched your GD with > > gif write sup

Re: [PHP-DEV] Re: #20972 [Opn->Csd]: make fails during gd.c

after i renamed the functions so its something > else, i'm going to try --with-gd without a prefix and see what happens, are > you talking the latest snapshot when u say cvs, saying cvs is too vague , > as 0RC3 is the latest stable i have also tried the snapshots, but still > sh

Re: [PHP-DEV] Re: #20972 [Opn->Csd]: make fails during gd.c

This is a different bug (xpm) caused by a bug in the external GD library, this particular bug has been solved in the CVS. Unless you've patched your GD with gif write support you have nothing to gain from not using the bundled library, which offers more functionality and is more stable. The prob

Re: [PHP-DEV] register_shutdown_function => register_offline_function

Known issue, the original patch for this problem had to be reveted since it broke the handling of mulit-line CVS fields that are quoted. I am now working on a more permanent fix. Ilia On December 5, 2002 11:39 am, Brian Moon wrote: > Ok, I reopened the bug. It fails with latest CVS. > > [root@

Re: [PHP-DEV] New SNMP function names

Consistency is always good and adding aliases for newly added functions seems like a recipe for bloat & confusion. +1 on the proposed changes. Ilia On December 4, 2002 08:49 am, Derick Rethans wrote: > Hello, > > while browsing the CVS I found that the following functions were added > to the CV

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 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] [PATCH] Redirect on Error

On November 28, 2002 12:56 pm, Maxim Maletsky wrote: > Shall we still consider introducing error codes to PHP? IMO, it does not > represent any enormous maintenance increase while has some positive > points. Do you have an effecient manner in which to implement the introduction of error codes? I

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... > > Is that

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] Redirect on Error (not localisation)

On November 26, 2002 03:09 pm, John Coggeshall wrote: > Unless told otherwise, I'm already planning on making a few changes and > committing. I for one, am -1 on the idea as I am sure some other developers are too. Let's first clearly tally who is for and who is against the idea before adding it

Re: [PHP-DEV] [PATCH] Redirect on Error

On November 25, 2002 10:57 pm, George Schlossnagle wrote: > On Monday, November 25, 2002, at 10:43 PM, Ilia A. wrote: > > On November 25, 2002 10:30 pm, George Schlossnagle wrote: > >> There is no proposed patch to affect all these changes. There are > >> fine >

Re: [PHP-DEV] [PATCH] Redirect on Error

On November 25, 2002 10:59 pm, Sascha Schumann wrote: > On Mon, 25 Nov 2002, Ilia A. wrote: > > On November 25, 2002 08:29 pm, Maxim Maletsky wrote: > > > Who cares? I am an Oracle fun, but this is still not my point. My point > > > is that oracle, as arguable as can be,

Re: [PHP-DEV] [PATCH] Redirect on Error

for example a gettext a commonly used tool for localizations, is not thread safe, so we are looking at having to design a error localization mechanism with a thread safe disk database system. > On Monday, November 25, 2002, at 10:27 PM, Ilia A. wrote: > > On November 25, 2002 09:59 pm, Ge

Re: [PHP-DEV] Error Codes, Langs, etc

On November 25, 2002 09:52 pm, John Coggeshall wrote: > I am completely +1 to the concept of taking error codes out of the PHP > core and replacing them with an XML document, period. I say this > regardless of language considerations -- I just think for everyone > involved having a XML document whi

Re: [PHP-DEV] [PATCH] Redirect on Error

On November 25, 2002 09:59 pm, George Schlossnagle wrote: > > By the way, could you please advise by how much I will need to > > increase the > > power of my server(s) to maintain the same level of performance? > > Why would this need to kill your performance if you're not throwing > errors? Becau

Re: [PHP-DEV] [PATCH] Redirect on Error

On November 25, 2002 09:22 pm, Maxim Maletsky wrote: > On Mon, 25 Nov 2002 21:11:37 -0500 "Ilia A." <[EMAIL PROTECTED]> wrote: > > On November 25, 2002 08:53 pm, Maxim Maletsky wrote: > > > Well, in this case you would just add locales like you do with dates,

Re: [PHP-DEV] [PATCH] Redirect on Error

On November 25, 2002 09:09 pm, Philip Olson wrote: > [snip] > > > Really? Let's see on average each function generates @ least one warning > > message, so we have @least as many warnings as we have functions. Warning > > messages get constantly re-arranged, by having a separate database for > > the

Re: [PHP-DEV] [PATCH] Redirect on Error

On November 25, 2002 08:53 pm, Maxim Maletsky wrote: > Well, in this case you would just add locales like you do with dates, for > example. > Meaning that you will be applying the locale logic in real time? Have you considered what kind of performance degradation this will entail? > > > And you,

Re: [PHP-DEV] [PATCH] Redirect on Error

On November 25, 2002 08:29 pm, Maxim Maletsky wrote: > Who cares? I am an Oracle fun, but this is still not my point. My point > is that oracle, as arguable as can be, thinks about marketing its > product. They biggest sales point, in fact, is not the usability and nor > even the documentation. Tho

Re: [PHP-DEV] [PATCH] Redirect on Error

merely pointed out that Oracle's status as most powerful database is in the eye of the beholder. Ilia > On Monday, November 25, 2002, at 08:24 PM, Ilia A. wrote: > > On November 25, 2002 08:15 pm, Maxim Maletsky wrote: > >> On Tue, 26 Nov 2002 00:30:55 +0200 (EET) Jani Taski

Re: [PHP-DEV] [PATCH] Redirect on Error

On November 25, 2002 08:24 pm, Maxim Maletsky wrote: > On Mon, 25 Nov 2002 20:14:56 -0500 "Ilia A." <[EMAIL PROTECTED]> wrote: > > On November 25, 2002 07:57 pm, Maxim Maletsky wrote: > > > On Mon, 25 Nov 2002 15:21:06 -0500 Sterling Hughes > > > <[EM

Re: [PHP-DEV] [PATCH] Redirect on Error

On November 25, 2002 08:15 pm, Maxim Maletsky wrote: > On Tue, 26 Nov 2002 00:30:55 +0200 (EET) Jani Taskinen <[EMAIL PROTECTED]> wrote: > > Just forget this. I'm not native english speaker, but I REALLY > > don't want to see any errors in any other language but english. > > (does Perl

Re: [PHP-DEV] [PATCH] Redirect on Error

On November 25, 2002 07:57 pm, Maxim Maletsky wrote: > On Mon, 25 Nov 2002 15:21:06 -0500 Sterling Hughes <[EMAIL PROTECTED]> wrote: > > Educate users to speak the base amount of english required, I18N'ing the > > language is just going to lead to headaches from a user perspective > > (incorrect t

Re: [PHP-DEV] [PATCH] Redirect on Error

On November 25, 2002 01:58 pm, John Coggeshall wrote: > >Multi-lingual error codes open's up pandora's box, let's not go > >there. > > I have to disagree with you here Sterling. Worrying about support for > non-english errors in php-general, etc is a bad, bad excuse not to > implement them. The ben

Re: [PHP-DEV] Build of bundled GD broken on Win32

Fixed. On November 25, 2002 06:06 am, Sebastian Bergmann wrote: > gd.obj: error LNK2001: > Unresolved external symbol: _gdImageCreateFromGd2Part > > gd.obj: error LNK2001: > Unresolved external symbol: _gdImageCreateFromGd2PartCtx > > gd.obj: error LNK2001: > Unresolved external symbol

Re: [PHP-DEV] GD segfault in 4.3.0RC1

On November 18, 2002 07:44 am, Derick Rethans wrote: > On Mon, 18 Nov 2002, Marcus Börger wrote: > > Brian could you create a short test for the segfault? It would help us > > finding out the problems. > > For now I think it's very wise to remove all the e*() memory functions > from the branch, it'

Re: [PHP-DEV] mime_magic segfaults

Why was rb changed to rt? Ilia On November 15, 2002 06:58 am, Moriyoshi Koizumi wrote: > Thanks, it works. > Attacthed is a slightly modified version of Ilia's patch in consideration > of win32 build. > If there are no objections, I'll commit it. > > > Moriyoshi

Re: [PHP-DEV] mime_magic segfaults

Could you try the attached patch and see if it fixes the problem. Ilia On November 14, 2002 03:10 pm, Moriyoshi Koizumi wrote: > Hi, > > I found a bug in mime_magic. If the module fails to read the magic file > specified by mime_magic.magicfile during the module initialisation, it > tries to put

Re: [PHP-DEV] mbstring and 4.3.0

On November 13, 2002 07:50 am, Melvyn Sopacua wrote: > FWIW: > * If this is ever going to make core as a part of PHP's i18n efforts, you >are going to have to deal with the 'unseen' at some point. You are not >going to identify them, by testing it within a select group. For this >reason

Re: [PHP-DEV] mbstring and 4.3.0

ly, as it is apparently a double-free bug. I'll look into the problem in more detail tommorow. Ilia > Moriyoshi > > "Ilia A." <[EMAIL PROTECTED]> wrote: > > I've just tried the latest CVS, it still crashes, the backtrace is same > > as before. > >

Re: [PHP-DEV] mbstring and 4.3.0

On November 12, 2002 09:42 pm, Marcus Börger wrote: > At 23:56 12.11.2002, Ilia A. wrote: > >Since I've gotten involved in this conversation would like to add my > > opinion to the tally. I too believe that at least at this point, the > > mbstring extension should

Re: [PHP-DEV] mbstring and 4.3.0

y patch that was > just commited. > > Moriyoshi > > "Ilia A." <[EMAIL PROTECTED]> wrote: > > On November 12, 2002 04:58 pm, Moriyoshi Koizumi wrote: > > > Hi, > > > > > > Thanks for the report. > > > Although I found a bug in

Re: [PHP-DEV] mbstring and 4.3.0

Since I've gotten involved in this conversation would like to add my opinion to the tally. I too believe that at least at this point, the mbstring extension should not be enabled by default. There are two reasons for this decision: 1) Majority of PHP users do not require this functionality. Most

Re: [PHP-DEV] mbstring and 4.3.0

ecause sendmail was not found on the system. The function mail() on unix systems appears to be dependant on sendmail avaliablity or atleast something that would cause the HAVE_SENDMAIL flag to be set. Ilia > Moriyoshi > > "Ilia A." <[EMAIL PROTECTED]> wrote: > >

Re: [PHP-DEV] mbstring and 4.3.0

On November 7, 2002 10:04 am, Andrei Zmievski wrote: > At the PHP Conference in Germany several of us have discussed the > current state of mbstring and there was a proposal to not have it > enabled by default for 4.3.0 release. It seems that the extension > attempts to do "magic" stuff by overload

Re: [PHP-DEV] PHP Snaps

y the files. In this case it would be trivial to make the script sort the files by their creation date. Ilia On November 11, 2002 05:23 pm, Edin Kadribasic wrote: > On Monday 11 November 2002 23:20, Ilia A. wrote: > > > Nice format but it doesn't sort well in directory listings :

Re: [PHP-DEV] PHP Snaps

On November 11, 2002 05:16 pm, Edin Kadribasic wrote: > On Monday 11 November 2002 23:14, Ilia A. wrote: > > On November 11, 2002 05:07 pm, James Cox wrote: > > > I can certainly set this up. > > > > > > any preference for timeformat? (bearing in mind we use un

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] PHP Snaps

On November 11, 2002 05:07 pm, James Cox wrote: > I can certainly set this up. > > any preference for timeformat? (bearing in mind we use unix date) date -R | sed -e 's/ /_/g' Would be the best format IMHO. Ilia > > -- james > > > Is it possible to increase build time from 4 hours to 2 hours >

[PHP-DEV] Configuration Patches

Attached are two patches that I've written to address a number of issues I've come across while testing PHP on Solaris. The first patch (alloca.txt) eliminated a warning message due to the fact that that on Solaris and Tru64 alloca() is defined in a separate header, alloca.h, which is not inclu

Re: [PHP-DEV] Please help document headers_sent()

On November 6, 2002 07:10 pm, Philip Olson wrote: > I get a Segmentation fault with this script using > PHP CLI: > > headers_sent($file, $line); > ?> > philip@rock:~$ php test.php > Segmentation fault > > That's when no headers are sent before the call. But if > headers are sent beforehan

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

review this patch before it goes in. If there won't be any objections to the patch, I will commit it on your behalf. Ilia > Moriyoshi > > "Ilia A." <[EMAIL PROTECTED]> wrote: > > The new appears to work correctly and previously mentioned problem no > > lon

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

--- > > > > > > > > The first script causes no leaks, while the second does: > > > > --- > > > > > > > $ragged = array(); > > > > $ragged[0] = "a"; > > > > $ragged[0][0] =

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

ar_dump($ragged); > > ?> > > --- > > > > The first script causes no leaks, while the second does: > > ------- > > > $ragged = array(); > > $ragged[0] = "a"; > > $ragged[0][0] = (string)array("1&quo

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

Re: [PHP-DEV] Win32 snaps ext/xslt

It appears that the Sablotron needs to be upgraded as well, since xstl cannot be compiled due to 2 missing flags ('SAB_DISABLE_STRIPPING','SAB_IGNORE_DOC_NOT_FOUND'), which I am guessing are only defined in the newer library. Ilia On November 5, 2002 08:01 am, Edin Kadribasic wrote: > > Any ch

Re: [PHP-DEV] Re: [PATCH] run-tests.php

On November 1, 2002 01:08 pm, John Coggeshall wrote: > |What made you decide to go for the OO model of the run-tests > |script, there > |does not seem to be any advantage in adding this overhead (imho)? > > There is most definitely an advantage. Using the OO model, we > essentially created > A "tes

Re: [PHP-DEV] Re: [PATCH] run-tests.php

On November 1, 2002 12:23 pm, John Coggeshall wrote: > Wait wait wait.. > > I think I've been misunderstood... I'm not talking about the version 4.3 > release, and yes we are working on the web edition of the test script.. > However, Shane (rightly so, IMHO) re-wrote run-tests (now run-tests2) > an

[PHP-DEV] Re: [PATCH] run-tests.php

On November 1, 2002 10:05 am, Melvyn Sopacua wrote: > At 15:37 1-11-2002, Derick Rethans wrote: > > > Any objections? > > > >We can't object if there is no attachment :) > > #*!$%', mt_rand(1,6), 1); $i++; } ?> > > > With kind regards, > > Melvyn Sopacua > Looks fine to me, +1. Ilia -- PHP Dev

Re: [PHP-DEV] [PATCH] ereg to pcre conversion

gt; ----- Original Message - > From: "Ilia A." <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, October 31, 2002 12:47 PM > Subject: [PHP-DEV] [PATCH] ereg to pcre conversion > > > Currently PHP ships with two regular expression librari

Re: [PHP-DEV] [PATCH] ereg to pcre conversion

ry changes to the patch, so that the old ereg_* behaviour can be maintained. Ilia > -adam > > On Thu, 31 Oct 2002, Ilia A. wrote: > > Currently PHP ships with two regular expression libraries that are both > > installed by default, PCRE & regex. The regex li

[PHP-DEV] [PATCH] ereg to pcre conversion

Currently PHP ships with two regular expression libraries that are both installed by default, PCRE & regex. The regex library that is responsible for ereg_* functions is fairly old and offers a very limited functionality compared to the PCRE library. In most cases the PCRE functions are also muc

[PHP-DEV] safe_mode_include_dir option

The current implementation of the safe_mode_include_dir only allows bypassing of safe_mode by the include/require functions in the specified directories. No other safe_mode limited file operation can access those files. Since there is no other parameter other then safe_mode_include_dir to 'unloc

Re: [PHP-DEV] RFC: run-tests.php & errors/warnings

On October 29, 2002 09:52 am, Marcus Boerger wrote: > I think we need to discuss the behaviour of run-tests.php > according too error/warning handling a bit. > > First question (let me know if i am wrong): Any error/warning/ > notice in a test result is either expected or a real error. Agreed, how

Re: [PHP-DEV] I hope this is the last email about this :)

+1 to keep PHP-CLI with implicit_flush. Ilia On October 27, 2002 09:05 pm, Zeev Suraski wrote: > Thank you for the detailed explanation, I'm sure everybody understands it > now. > > Let's go for the voting phase. I vote we keep PHP-CLI with implicit_flush > on by default. You vote against. > >

[PHP-DEV] Re: [PHP-CVS] cvs: php4 / run-tests.php

I am curios as to your reasoning behind turning on html_errors by default, why would the tests need HTML data? Logging of errors occurred during the tests seems pointless to me. As I've mentioned before if a test needs to check if a certain type of error is generated the track_errors & $php_erro

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / run-tests.php

On October 25, 2002 04:01 pm, Marcus Börger wrote: > I haven't installed xslt yet so i do not know...but i am testing with 25% > of the modules and get the feeling that we must check for all warnings and > errors. > > A special situation is ext/session/tests/008-php4.2.3.phpt > where a warning mech

[PHP-DEV] Regex Libraries

Currently PHP contains two bundled regular expression libraries, PECL and regex. I am wondering if it would be a good idea to drop the old regex (dates back to 1999) library and use only PECL. The advantage is performance, cleaner code and a more flexible and more recent library. For the people

Re: [PHP-DEV] parse_url still broken!

Also fixed. Ilia On October 18, 2002 06:37 am, Thies C. Arntzen wrote: > url: > file:/bla/test > > 4.2.x output: > array(2) { > ["scheme"]=> > string(4) "file" > ["path"]=> > string(9) "/bla/test" > } > > HEAD: > array(3) { > ["scheme"]=> > string(4) "file" > ["host"]=> >

Re: [PHP-DEV] Re: [4.3] Current critical bugs

On October 17, 2002 07:06 pm, Yasuo Ohgaki wrote: > Andrei Zmievski wrote: > > Hi, > > > > We have 10 critical bugs in the list currently. If you could please see > > about fixing at least one of them, we'd be that much closer to a release > > candidate. > > Summary: Apache2 sending 304 - not modif

Re: [PHP-DEV] short_open_tag

On October 16, 2002 11:46 pm, Yasuo Ohgaki wrote: > We had the same discussion. I brought it up last time. > > There were patch for " > The outcome was modified manual page that discourages > use of short tag for portable script. > > http://www.php.net/manual/en/language.basic-syntax.php Given th

Re: [PHP-DEV] short_open_tag

On October 16, 2002 11:11 pm, Yasuo Ohgaki wrote: > Ilia A. wrote: > >>Isn't BIG caution for short_open_tag=Off while having short_open_tag=On > >>enough for now? Something like; > > > > Nope, please consider a hosting enviroment where an average user does n

  1   2   >