[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 decided not to create these? Is it simply a matter of noone having gotten around to it? Am I paying too much attention to the voices in my head? -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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 read into buffer here includes the headers PLUS (in the case of www.php.net the first 1180 or so bytes of content) This seems like it could produce unexpected results in other cases as well. Take the following example: ?php /* Open this script as our text file */ $fp = fopen(test.php,r); /* Display the first line unfiltered */ echo fgets($fp); /* rot13 the rest */ stream_filter_append($fp, string.rot13); while ($str = fgets($fp)) print $str; fclose($fp); ? We might expect to get ?php output normally and all other lines ROT13ed... The reality is that the entire file is output normally because the initial echo fgets($fp); reads the entire file (because its so small) into its buffer. In the case of a large file there would be a cutoff seemingly random cutoff point where the unfiltered section ends and the filtered one begins. It seems to me that the data should be read into buffer unfiltered at ALL times whether or not filters exist, only when the data is actually used (whether it's taken from the buffer or directly from the stream) should the filters be applied. -Pollita It should not happen, and there is code in the http opener that *should* avoid this, because it has negative implications for including files via http. I will take a look when I have more time... Now, the point I've managed to completely skirt around I discovered something a little disturbing about the http wrapper (and presumably other network wrappers as well). The following script (with or without the above patch applied) will *NOT* uppercase the content retrieved from the url because the content is read into buffer immediately (on the fopen call) and the filter isn't applied until the next line. ?php $fp = fopen(http://www.php.net/;, r); /* the data is already sitting in buffer */ stream_filter_append($fp, string.toupper); while ($str = fgets($fp)) print $str; fclose($fp); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[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 to open my brain to thinking about implications... There's also the fact it's working on the current single filter chain model rather than the asymetric filter chains you've got planned. Now, the point I've managed to completely skirt around I discovered something a little disturbing about the http wrapper (and presumably other network wrappers as well). The following script (with or without the above patch applied) will *NOT* uppercase the content retrieved from the url because the content is read into buffer immediately (on the fopen call) and the filter isn't applied until the next line. ?php $fp = fopen(http://www.php.net/;, r); /* the data is already sitting in buffer */ stream_filter_append($fp, string.toupper); while ($str = fgets($fp)) print $str; fclose($fp); ? Presumably you're aware of this? -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[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 scale. The BC functions will predeict the required scale of the output, but the numbers have to be in bc_num format going in and str2num requires that you specify a scale. In any case, it probably makes sense for you to go ahead and commit it. Will do. BTW, is php_str2num() only supposed to work on whole or decimal values? What about exponents? bc_str2num() only allows whole or decimal values so that's all I wrote php_str2num to allow for. By 'exponents' do you mean scientific notation? I don't see any support for that in the bc conversion functions. I don't suppose it would take much to add that capability, but that'd be a feature change and should probably be done separately (and only in HEAD). -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[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 against PHP_4_3 and HEAD can be found at: http://frankenbox.alphaweb.net/test/php_4_3.bcmath.diff.txt and http://frankenbox.alphaweb.net/test/HEAD.bcmath.diff.txt The idea being to automagically determine the scale of the input numbers so that they are not truncated prior to the op. Then, once the op has been performed, reduce the scale to whatever was requested. The result-n_scale = scale; line might look a little dangerous, but since it only comes after lines which create 'result' with a scale of *at minimum* 'scale' it means that 'result-n_scale' will always be = 'scale' and hence assigning it to 'scale' will always result in a reduction (or no change at all) and bc_num2str won't go looking in undefined sections of the bc_num val. -Pollita P.S. - This one's for you sniper ;) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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 trying out a few different approaches to see what looks best, I'll post again when I have something usable. http://frankenbox.alphaweb.net/test/export.phps In normal mode (called as http://bugs.php.net/export.php?id=12345 ) it would output an RSS 1.0 valid bug listing similar to the following output: http://frankenbox.alphaweb.net/test/export.rss It also allows for a more detailed extract (called as http://bugs.php.net/export.php?id=12345format=xml ) which includes all the information related to the bug (except password, I accidently included that field in my first sample) Output sample: http://frankenbox.alphaweb.net/test/export.xml -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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.php.net I could select bug #s to track, and be able to bring up histories of them from my daily page. Something along the lines of: http://bugs.php.net/export.php?bugid=12345 which would output: phpbug bugid12345/bugid submitter[EMAIL PROTECTED]/submitter submitdateJan 30, 2003 12:45 pm PST -0800/submitdate statusBogus/status update updater[EMAIL PROTECTED]/updater updatedJan 31, 2003 8:13 am PST -0800/updated statusbogus/status commentYour comment does not imply a bug in PHP itselfblah blah blah.../comment /update update updater[EMAIL PROTECTED]/updater updatedJan 30, 2003 12:45 pm PST -0800/updated statusNEW/status commentI havnapos;t read the manual/comment /update /phpbug Obviously not all the information one would look for, basicly the output of 'bug.php' but in XML format for easy parsing. Anyway, if I went to the trouble of writting this page, would it be accepted? Or at least entertained? Does such an animal already exist? -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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... here's a simple script (based heavily on php-bugs-web/bug.php) to do just that: http://frankenbox.alphaweb.net/test/export.phps Meant to be called as: http://bugs.php.net/export.php?id=1234 If it's deemed worthy could someone add it to php-bugs-web? I don't have the karma. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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 trying out a few different approaches to see what looks best, I'll post again when I have something usable. -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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_replace. A boolean value which would allow the user to use an alternate search and replace method. True, this was undocumented, and was probably only included for developer debugging (Sascha? Can you enlighten us?). This alternate method has been removed (by virtue of being deprecated) and should produce wrong param count errors for users who include that fourth parameter currently (how many would even know of this?) so that they can fix their code. If we introduce a *new* fourth parametere (also boolean) which checks for case_sensitivity, this could potentially cause problems for users who were using this undocumented parameter. Leaving the fourth and adding a fifth would get even more confusing if the appearance is that the fourth parameter was just added *and* served no purpose. So, we could relegate those VERY few who might've used that fourth parameter already to the read the changelog or suffer bucket, ornot. -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[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/test/str_ireplace.diff.txt Ilia has already voiced a -1 on IRC, but since many php-dev folks have voiced +1s in the bug comment I'd like to open a dialog. Comments? -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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 of haystack which is strtolowered against a strtolowered version of needle (no need to copy that part). http://169.229.139.97/test/str_ireplace.diff-2.txt Should be quicker and cleaner at the cost of a small malloc in the estrndup call. -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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 the speed difference would be minimal. I don't even see the speed difference as an issue as much as (A) simplicity for the user who hasn't figured out regex yet, (B) consistency (we have 'i' versions of most other string functions, why not this one?) The parameter accepting still needs to be fixed though, I copied most of the str_ireplace code from str_replace and forgot to clean that section up and make it nicer. I'll save that for *if* a quorum can be reached to include it at all. 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 it wasn't documented yet. -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[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 it wasn't documented yet. The BM algorithm is outdated and can savely be dropped. - Sascha That simplifies implementation then :) Here's a patch that takes out the boyer implementation and cleans up the parameter accepting in both str_replace and str_ireplace. It also avoids the _ex business since replace_in_subject is a static method which is only called by str_replace str_ireplace anyway. I also reduced php_str_to_str back to a single implementation by passing the case_sensitivity parameter to it, but since it's a PHPAPI function I also renamed it *_ex and created a passthrough for BC. http://169.229.139.97/test/str_ireplace.diff-3.txt The large chunk of added code is getting diminishingly smaller... though I suppose str_replace and str_ireplace could be turned into passthrough wrappers for a unified version, but that's probably going further than necessary. -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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 what the resulting string.c looks like: http://169.229.139.97/test/string-4.c Yes the patch is getting larger, but the resulting codebase is shrinking... -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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 bugs.php.net, and in IRC) to say this should go in. I'm on my way home now, If I havn't heard a showstopper in the next 4-5 hours, I'll go ahead and apply it. -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[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 running safe
mode and the file doesn't exist, the php_checkuid function winds up
throwing an error before php_stat gets a change to say Hey, I don't care
if it's not there.
The solution being to only check the UID match on the directory and not
care if the script owner is also the owner of the file being checked.
After all we're only looking to see if the file is there, we're not
looking at/altering its contents.
-Pollita
Index: filestat.c
===
RCS file: /repository/php4/ext/standard/filestat.c,v
retrieving revision 1.117
diff -u -r1.117 filestat.c
--- filestat.c 5 Jan 2003 00:56:17 - 1.117
+++ filestat.c 9 Jan 2003 01:47:25 -
@@ -564,7 +564,7 @@
char *stat_sb_names[13]={dev, ino, mode, nlink, uid,
gid, rdev,
size, atime, mtime, ctime,
blksize, blocks};
- if (PG(safe_mode) (!php_checkuid(filename, NULL,
CHECKUID_CHECK_FILE_AND_DIR))) {
+ if (PG(safe_mode) (!php_checkuid(filename, NULL,
(IS_EXISTS_CHECK(type) ? CHECKUID_ALLOW_ONLY_DIR :
CHECKUID_CHECK_FILE_AND_DIR {
RETURN_FALSE;
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
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 single filter class (string.case ?). What is the preferred way of passing multiple parameters? I know each filter could handle it differently, but consistency is also a very nice thing. Coma separated perhaps? Changing the behavior of stream_append to use an array instead of a string? (might be going a bit far, but would give maximum flexibility) With the current model, the concept is that you can use either the filter name or filter parameters to distinguish the ultimate behaviour. Yes this is a possible headache. I am thinking that two separate chains of filters (one for reading and one for writing) might make this situation a little easier; this way you could have a filtered read stream but leave writing unfiltered etc. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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 require a different facility due to its statefulness, I couldn't use the existing implementation. Speaking of filter string.base64 I have an issue with its parity. string.base64 will encode on write and decode on read... What if the user wants the other way round? Is the expected behavior even obvious from the name alone? Should there be two separate filters? string.base64-encode string.base64-decode with each doing the same opperation on either read or write? I'm personally conflicted on which way it should be, but I wanted to raise the questions so that we could dialouge. The questions apply to string.quoted-printable for that matter. (( string.rot13 is fully symmetric so its the same no matter how you slice it, and string.to(upp|low)er are both fully asymmetric so only one implementation makes any sense. )) -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[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 removed with this patch. ((Assuming that is indeed the source of the problem)) -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[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 r1.515 calls sapi_active again, reinitializing the sapi globals ( in this case SG(headers_sent) = 0 ) Can someone explain this second call to sapi_active? gschlossnagle perhaps? -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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 in $param1. Get it ?
No. The code you displayed (in the switch block) is 100% identical to the
code Derick offered (except for the fact that Derick's example will handle
any class name while yours is limited).
$classname::method() === call_user_func(array($classname,'method'));
Get it?
-Pollita
P.S. - This thread has gone on long enough, either TRY IT, or take it to
[EMAIL PROTECTED] where it belongs so that they can tell you the
same thing.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[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 search path. While that *should* be suspended as the arguments for keeping . in the search path for non-CLI sapis is valid. It really has nothing to do with the issues in bug 20887. The problem with the double forward slash is trivial and doesn't cause a real issue, the problem I mentioned above is with php being launched without a path (without even ./) If PHP is launched directly from the command line a la: mybox:~$ php -f myscript.php the system checks the PATH variable to find an executable and run PHP. When php_ini.c runs, it finds a 'binary_location' of php (inaccurate! Our CWD is ~ and ~/php does not exist) Neither my patch nor Moriyoshi's fixes this. If PHP is launched via a script's pound-bang declaration a la: mybox:/usr/local/bin$ ./myscript.php --- /usr/local/bin/myscript.php (filemode 755) #!php ?php echo 'foo'; ? The shell (bash in the case of my tests) only looks for php in the CWD, If it finds one then it'll run and php_ini.c will show a binary_location of 'php' (correct in this instance, since /usr/local/bin/php does exist and is our executable). The current code in php_ini.c however, will try to look for the php.ini in 'php/php.ini' Ooops! (Both my patch and Moriyoshi's approach solves this one) In the former instance, ./php.ini shold not be scanned for CLI sapi, /usr/local/bin/php should be scanned instead except that we can't find it. (that's the whole discussion about not icluding '.' in the search path for CLI) In the latter instance, ./php.ini SHOULD be scanned for the CLI sapi as that is indeed where the binary is located. -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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 line issue. the system checks the PATH variable to find an executable and run PHP. When php_ini.c runs, it finds a 'binary_location' of php (inaccurate! Our CWD is ~ and ~/php does not exist) Neither my patch nor Moriyoshi's fixes this. My patch would give the accurate location of the binary being executed since it doesn't rely on argv[0]. Once again, my bad... When I tested your patch on my system I forgot about the fact that the php found in the path would be my copy of 4.2.3 and would therefore not have your patch! Whoops... :) I retested with sapi/cli/php put into the path and lo-and-behold: open(/usr/local/bin//php-cli.ini, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/local/lib/php-cli.ini, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/local/bin//php.ini, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/local/lib/php.ini, O_RDONLY) = 3 Exactly the right behavior! +1 your patch. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[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.
-Pollita
Index: main/php_ini.c
===
RCS file: /repository/php4/main/php_ini.c,v
retrieving revision 1.106
diff -u -r1.106 php_ini.c
--- main/php_ini.c 12 Nov 2002 20:56:47 - 1.106
+++ main/php_ini.c 12 Dec 2002 06:49:50 -
@@ -298,7 +298,9 @@
char *separator_location =
strrchr(binary_location, DEFAULT_SLASH);
if (separator_location) {
- *(separator_location+1) = 0;
+ separator_location[0] = '\0';
+ } else {
+ binary_location[0] = '\0';
}
if (*php_ini_search_path) {
strcat(php_ini_search_path, paths_separator);
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
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 option to control whether or not deprecated functions are enabled or not. #2 Sounds like The Right Way to do it, but also sounds like something which needs a strong consensus before implementing and should perhaps be put off till the next revision (4.4 or 5.0 -- whichever it winds up being) -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[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 most sense to call the php version
of the function bcpowmod(), but with the change in naming conventions
I'm more inclined to call it something closer to bcmath_raisemod() or
bcmath_powmod().
Am I overcomplicating things by agonizing over the name?
I'd love to hear your thoughts
-Pollita
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
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 quite new to C and I'm happy it works without segfaulting. strlcpy looks interesting and I'll read through the link as soon as I find some free time. Oh, this patch is explicitly *NOT* meant to go into the main branch. It's just an additional patch for whoever needs it, sorry for not pointing this out more explicitly. Good because I havn't seen any positive responses to this and I'm still negative on it. Apart from disagreement with the prinicipal here I'd also ask: Where is the portion of the patch to support Win32 SMTP via the MAPI interface? ((as opposed to sendmail_path interface which you've covered on all platforms)) A more generalized fix would be to append the Return-Path to the headers string at the top of the php_mail function so that it's caught by both the sendmail block and by the TSendMail call (MAPI). Any modification to behavior which effects one platform should affect all platforms equally. While Win32/sendmail is kept equal, Win32/MAPI (used by the majority of Win32 users) is not. -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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/php4/ext/xml/xml.c,v -- xml.c new revision: 1.112; previous revision: 1.111 done Bad response from SMTP -- 553 (2002/12/04) Open Proxy: http(3128) Mailing the commit email to [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[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. Objections? If none I'll do this, otherwise (if there's a reason not to) I'll just fix the documentation which actually refers to it as aggregate_info(). -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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 function at all. Either way leaves someone unhappy so in the absence of a majority I can't help but do nothing. This request will have to remain open, at least for now. Users requests all kinds of features all the time, just because someone will be unhappy because their request is not implemented is hardly a reason to implement it. As a rule, special cases are bad, if you REALLY think this is useful functionality we are better off adding a parse_email() function, who's job would be to break email addresses into parts. 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 PROTECTED]/pathto/somepage?var=value The ONLY real concern here, and reason for not fixing php_url_parse, comes in the fact that 'path' would no longer contain '[EMAIL PROTECTED]?subject=Bug+20308' (per the example above) which would likely break existing scripts. Perhaps the compromise is to create a new function 'parse_url_rfc' (name could be better) which behaves correctly (without having special cases). Then add a note to the manpage for parse_url saying to use parse_url_rfc instead, and eventually depricate parse_url (perhaps with PHP 5.0). -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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 PROTECTED]/pathto/somepage?var=value The ONLY real concern here, and reason for not fixing php_url_parse, comes in the fact that 'path' would no longer contain '[EMAIL PROTECTED]?subject=Bug+20308' (per the example above) which would likely break existing scripts. Perhaps the compromise is to create a new function 'parse_url_rfc' (name could be better) which behaves correctly (without having special cases). Then add a note to the manpage for parse_url saying to use parse_url_rfc instead, and eventually deprecate parse_url (perhaps with PHP 5.0). No. parse_url_rfc would be misleading because it would not follow RFC. There are special rules for scheme:, scheme:/ and scheme://, your suggested patch would actually break RFC, since mailto: is already parsed properly according to RFC. E-mail addresses are not urls, if we want to offer an email parser it should be separate function parse_email or something similar, there is no need to pollute php_parse_url() with hacks for non-intended functionality. Okay, okay... I throw my hands up... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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 should be parsed anyway. (ie, a special case shouldn't be required if the url parser was rfc compliant). PHP's php_url_parse() function is not in any way limited to http:// as you claim, it support a large variety of valid URLs, take a look at the very extensive test for parse_url() function located here: ext/standard/tests/strings/url_t.phpt. Even the regular expression described in RFC 2396 does not recognize mailto: any differently the our very own parse_url(). 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 function at all. Either way leaves someone unhappy so in the absence of a majority I can't help but do nothing. This request will have to remain open, at least for now. -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
