Re: [PHP-DEV] bcpowmod() and bigIntegers

> is there a possibility to implement bcpowmod() in a > version prior than PHP5? > The following patch can be applied to PHP 4.3.0 or PHP 4.3.1. It adds bcpowmod() which isn't scheduled for inclusion until PHP5 and also includes bugfixes and other modifications slated for the PHP4.3.2 release. Us

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

I recall a discussion sometime back about making file_put_contents() (create a file and write the provided contents to it in one command) and file_add_contents() (like put but append rather than overwrite) to complement file_get_contents() but looking in HEAD I don't see either put or add. Was it

Re: [PHP-DEV] http streams can't be filtered?

Actually, I was a little bit wrong... It's not that it's buffering the entire request... only the first 1180 or so bytes The first php_stream_gets() call in http_fopen_wrapper.c requests a line of data, php_stream_gets reads in a chunk (1448 bytes?) via php_stream_fill_read_buffer(). The data

[PHP-DEV] http streams can't be filtered?

Wez, After our short discussion in IRC today I decided to try and put together a simple implementation of that filter wrapper. What I came up with can be seen here: http://frankenbox.alphaweb.net/test/php.filter.diff.txt but it's not something I'm suggesting be commited, just a quick exercise t

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

> Indeed I wasn't aware of this bug report. It seems as if your patch is fine > although I could only look at it briefly. > It does look strange that you need to initialize the resulting scale > manually. I thought the BC functions are supposed to take care of returning > the results as the right s

[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] Question on bug list

> > Wouldn't it be nice/more useful to generate RDF/RSS on a per-bug basis? > > Then you could just add the feed url to your favourite RSS client. > > > > If you make it do that, then I will take a look and commit, provided > > that there are no objections to this. > > > Jesus suggested the same th

Re: [PHP-DEV] Question on bug list

> Wouldn't it be nice/more useful to generate RDF/RSS on a per-bug basis? > Then you could just add the feed url to your favourite RSS client. > > If you make it do that, then I will take a look and commit, provided > that there are no objections to this. > Jesus suggested the same thing, I'm tryin

Re: [PHP-DEV] Question on bug list

> > >I had two questions: One to assign to all NEW messages and one > > >feature request to assign to selective bugs...I wanted to avoid reading > > >all messages on any bug. Thats overkill... > > > > Get a mail client that can handle threading.. > > PHP-Bugs doesn't have "In-Reply-To" and "Ref

Re: [PHP-DEV] Question on bug list

> I have a "daily page" I go to every morning which contains all my news > feeds, some comic strips, movie listings, etc If there were a > programmatic query interface to bugs.php.net I could select bug #s to track, > and be able to bring up histories of them from my daily page. > To that end..

Re: [PHP-DEV] Question on bug list

> > Wouldn't it be nice if one could attach himself to a bug and receive an email > > on every new message to that bug? > > I have a "daily page" I go to every morning which contains all my news feeds, some comic strips, movie listings, etc If there were a programmatic query interface to bugs.p

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

> > +1 from me too, stri_replace sound like a function some users may have > > > > implemented them selves and we could end up breaking their code by > > introducing it. > > exactly :). > Only one complaint. Previously (including in 4.3.0) there already WAS a fourth (undocumented) parameter to str

[PHP-DEV] Re: str_ireplace vs. stri_replace

> One little thingie: shouldn't it be called stri_replace() rather than > str_ireplace() ? > 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 eregi_replace's style. I have no t

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

> better and better... > One last optimization to save memcpys when needle_len == str_len (thanks again ilia): Actual Patch: http://169.229.139.97/test/str_ireplace.diff-5.txt Resultant string.c for easy reading: http://169.229.139.97/test/string-5.c I've heard enough Ayes over Nays (here, in bu

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

better and better... Ilia offered up an optimized version of php_str_to_str which skips string resizing and handles do-no-work scenarios up front. I've made necessary changes to make this case_optional and made a new patch: http://169.229.139.97/test/str_ireplace.diff-4.txt as well as posting w

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

whoops, missent just to sascha instead of list... >> On a related topic, the 'boyer' option of str_replace isn't even >> documented. That alternate method of performing str_replaces look >> like it's a bit more efficient (no benchmarkes atm) but I'm wondering >> if there's a specific reasons why

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 be

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

> I've got an implementation put together, the patch for which can be > viewed at: > > http://169.229.139.97/test/str_ireplace.diff.txt > After some comments on IRC, here's an alternate version to the above patch. This second approach avoids creating php_memnstri by simply searching through a copy

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

This feature request (which seems worth doing) has sat on the back burner awhile. Probably because, in the words of one commenter, those who can produce the patch are just using regex instead. I've got an implementation put together, the patch for which can be viewed at: http://169.229.139.97/te

Re: [PHP-DEV] PROPOSAL: 'unless' control structure

> My apologies if this has been brought up before, but I searched the > archives and couldn't find a reference to it. > > I'm sure this is the sort of thing that would have already been > implemented if there was any desire for it among the developers, but I > was wondering if anyone had considered

[PHP-DEV] Fix for Bug#21531 -- 2nd set of eyes?

I believe the patch below will fix bug#21531 but my blood sugar is high and my head feels like a brick. Could someone else take a look and see if it's at least nearly sane? The problem seems to be that when php_stat tries to check for the existence of a file (called as file_exists() ) on a server

Re: [PHP-DEV] CVS Account Request: angela

> phpdoc-es > > Spanish language translation of PHP documentation > ^^^ My better half :) +1 (Unless it counts as nepotism) And I should also mention that she was born and raised in Colombia and is a fluent speaker of both english and spanish. -Pollita -- PHP Development Mailing List

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

oooh yes, good point: stream_filter_append($fp, "string.base64", "encode"); and stream_filter_append($fp, "string.base64", "decode"); probably with "encode" being the default behavior. That make implementation very simple and in fact the toupper/tolower calls should be similarly combined into a

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

>> Couldn't you have used parts of ext/standard/base64.c here instead of >> duplicating code? > > At first I thought of using php_base64_encode() and php_base64_decode() > rather than reimplementing them. But because those functions are > designed to be used in string semantics while streams requir

[PHP-DEV] Re: [PHP-DOC] streams reference

>--Cross-Post from php-doc discussion thread-- > > You may want to mention what the following means, this is > from a phpinfo() on www.php.net: > > Registered PHP Streams: http > php > ftp > https > comp

[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

Re: [PHP-DEV] T_PAAMAYIM_NEKUDOTAYIM

>>> I guess I am going to have to write stupid code such as: >>> >>> switch ($param1) { >>> case 'parser1': >>> return parser1::method(); >>> case 'parser2': >>> return parser2::method(); >>> } >> >> call_user_func(array($param1, 'method')); > > No. Undefined variable this i

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

[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] Critical Bug #20887

I THINK the patch below will fix critical bug #20887, but it's late and I've had a long day so I havn't begun to make sure it'll work properly in any circumstance, could anyone else have a look and try it out? See my note in Bug #20887 for an explanation of what my theory about the problem is. -P

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/bcmath bcmath.c php_bcmath.h

I'm hearing two options here: 1) Name the new function bcpowmod() to keep it similiar to existing functions, we'll worry about renaming the functions in this module later... 2) Name the new function bc_powmod(), rename the existing functions now, and create aliases. Possibly introduce an ini opt

[PHP-DEV] New function: bcpowmod()

I'd like to add a new function to the bcmath module. It's very similar to the bcpow() function except that it takes advantage of a fast exponentiation method when used with a modulous. Based on the function call into libbcmath to bc_raisemod() {bcpow() uses bc_raise()}, it would seem to make the

Re: [PHP-DEV] Re: Default Return-Path with mail() and qmail

>> Are you sure you should be using malloc()/free() and not >> emalloc()/efree()? Also please use strlcpy() instead of strncpy(). >> (Weird I mentioned it twice in one day :) >> http://www.courtesan.com/todd/papers/strlcpy.html > > Probably there are even more things broken in my patch :) I'm quit

Re: [PHP-DEV] Problem with commit

And it's not just Marcus, I got the same error commiting to phpdoc five minutes ago... The commit DID go through, just not the notification. -Pollita > There seems to be a problem with CVS server: > > cvs -z3 -q commit -m "php_error -> php_error_docref" xml.c > Checking in xml.c; > /repository/ph

[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

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)

>> 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)

>> 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] CVS Account Request: pollita

Address open items on bugs.php.net, developing patches where appropriate. Also propose extensions such as my recent contributions to log() and the pending function getanyrr(). -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php