Re: [PHP-DEV] CVS Account Request: jorton
On Thu, 13 Mar 2003, Joe Orton wrote: Commit of autoconf code cleanups to php4 (4_3 branch) needed for systems which have system libraries in /usr/lib64 rather than /usr/lib. Please post patches. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moderate PHP-DEV
On Wed, 12 Mar 2003, Jani Taskinen wrote: Of about 20 emails today, 6 were posted to wrong mailing list. And one of those generated a 5 email thread about not posting to wrong mailing list. (counting this one :) So I suggest we finally make this list MODERATED. -1. The list could be renamed so that it is less confusing for newbie PHP developers. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possible problem in the parser
On Wed, 12 Mar 2003, Andrey Hristov wrote: Few minutes ago I found the following behaviour somehow wierd for me : Known bug, the associativity of the ternary operator has been broken since ages in the engine. It's on the won't be fixed sheet, because of BC concerns. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moderate PHP-DEV
if even that description doesn't work, then nothing would work, not even changing the name. Well, it is obvious that some folks don't read that description and simply move forward, because php-dev sounds about right. They are PHP developers and so a list called php-dev makes absolute sense to them. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moderate PHP-DEV
Let's ask the mysql guys, they did change the name too. (I think that we atleast agree that the noise is annoying, right?) Not really. Maybe I'm more used to skipping noise. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moderate PHP-DEV
Aside from renaming the php-dev list, we should remove the 'PHP and Zend [snip] Sounds good. Then another item that might be considered if it is not already done, allowing posts only from those that have cvs access. A second conditional list of allowed posters can be added that are people who do not have cvs access, but we want to allow to post. Otherwise, the list can be readable by all. A post rejected message could tell them to try a different email list, but if they really feel the email is for the dev list, send it to [EMAIL PROTECTED] and This however sounds too restrictive to me. I'm convinced that the main php development list should stay as open as possible. The issue of a few misdirected emails should not serve as an excuse for closing down the main development list. We should not become an ivory tower. it will be reviewed by someone when they get the time. This manual review effectively implies censorship which is undesirable in an open environment. I doubt it would serve the PHP community in any way. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moderate PHP-DEV
Yes, because getting a cvs account is just *s* hard. The problem is that you easily lose valuable postings when you force people to go through some restrictive system. I'm especially worried about inter-group communication. E.g. where php-dev is involved in a discussion with another group of people. If some developer list tries to protect itself from my input, I usually don't bother to jump through hoops. This happened just recently with group@ and the ASF board where some messages got stuck in a filter. Currently, unless someone points me elsewhere I only read messages from PHP core devs. You must be kidding. There are 20-30 emails on php-dev on normal days. That hardly makes up 10% of my personal email traffic. The volume is quite negligible from my POV. Let's implement the renaming and Shane's two section thing first before we evaluate more draconic measures. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moderate PHP-DEV
You lose: You lose time for implementing and maintaining this system, and you lose time for moderating emails. You also reduce the incentive to contribute. Again, let's take the less intrusive steps first and leave the heavy handed ones as a last resort. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Newbie developer's information
* trying to build php4 head for two days, only to be told that I should be building PHP_4_3 or php5 head. Yes, it should be noted that you can use PHP_4, PHP_4_3 or php5. * forgetting about re2c, which is not mentioned anywhere that I could find, but I found through freshmeat and had a lovely time trying to build :-) Unless you are working on the .re sources, you don't need re2c. I am taking note of the problems I encountered and was planning on updating something (README.CVS-RULES ?) after another week or so. Good idea. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moderate PHP-DEV
Jani, 1. Rename the list to php-group bad name for obvious reasons. Georg's suggestion of internals sounds ok to me. Or hackers from the FreeBSD community. 2. Separate the list entries in mailing-lists.php [DONE!] 3. Apply the same system as is in use for Let's evaluate the results of the first two items before going one step further. There is no need for haste. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moderate PHP-DEV
I wouldn't consider 3rd one that drastic. It has worked very well for me, I haven't got any spam to my php.net addy, but people who really wanted to send me email got through.. Well, maybe I am an exception, but I usually don't bother to register myself anywhere, unless there is a really good reason. Thus, the proposed measure increases the bar for contributions significantly. We don't lose anything by giving the first two items some time to prove their usefullness. On the other hand, it is very likely that we will lose useful input, if we implement the third item prematurely. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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 available at the same URL all the time; however, it is not always the same source. Hmmm.. are they really deleted, or it's just that the snaps.php.net only shows the recent files? Old files are purged regularly. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fun with autoconf on Tru64
# ./flex --version flex 2.5.27 What does this output? flex -V -v --version 2/dev/null - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fun with autoconf on Tru64
On Fri, 7 Mar 2003, David Hill wrote: What does this output? flex -V -v --version 2/dev/null - Sascha # flex-2.5.27/flex -V -v --version 2/dev/null flex 2.5.27 This should be parsed correctly. What kind of OS and /bin/sh do you have? What does ver1=2.5.27 ver2=2 5 27 set $ver2; echo $3 IFS=.; set $ver1; echo $3 output? - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fun with autoconf on Tru64
# cvs co -rPHP_4_3 php4 Or for experimental code which should not go into a release branch like PHP_4_3 $ cvs co -r PHP_4 php4 These are the ONLY useful and up-to-date modules at the moment. I'm planning on syncing those changes which have been forgotten to PHP_4, so please stop the FUD. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache2 SAPI
Can I check this into PHP_4 PHP_4_3 ? Nope :) PHP_4 is ok. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fun with autoconf on Tru64
Thanks ! That does help some. I don't get the buildconf warnings now, but I am still getting shell syntax errors in the resulting configure script. arrrgh :-p Make sure that autoconf-2.13 is completely reinstalled (including rm -rf autoconf-2.13). Otherwise, the frozen files which were generated using m4-1.4o cause problems. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache2 SAPI
Sure, but there is no point in doing that... as there won't be released from that branch anyway. Well, that depends on the needs of our users. Regardless, testing new SAPIs/extensions is quite a burden in the PHP 5 context, because you have two moving targets then -- the engine and your own code. It's often preferrable to have a stable environment for your own testing needs and that is where PHP_4 comes in. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: modules in c++
Please supply 1 as the 6th argument to PHP_NEW_EXTENSION. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #22527 [Opn-Bgs]: Modulus returned negative value
On Tue, 4 Mar 2003, George Schlossnagle wrote: Interesting. I don't know what the ISO standard say, but mathematically a a % b will always return you an integer 0 = a%b b (since there are no negative numbers in canonical representation of Z/bZ). I guess perl/python/tcl ddecided to adhere to the mathematical definition. ISO C truncates towards zero. It specifically says in 6.5.5 Multiplicative Operators: If the quotient a/b is representable, the expression (a/b)*b + a%b shall equal a. So -27 % 7 yields -6. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #22527 [Opn-Bgs]: Modulus returned negative value
Yeah, I read that in the bug report and confirmed that as the intended behavior in C. What I meant was 'regardless of what the ISO standard says, thats not a standard mathematical definition.' Well, the standard mathematical definition r = a mod b = a = floor(a/b) * b + r for 0 = r b applies only, if a, b are members of N (natürliche Zahlen, 0). You cannot simply extend it to Z. As such, it does not apply to the example -27 mod 7, because -27 is evidently not part of N. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt
So for 4.3.2, we add the OnUpdateLong() and replace all the calls to OnUpdateInt() to use that instead and we leave the OnUpdateInt() behaviour same as it was. This shouldn't cause BC problems then..? Yes. And in 5.0.0 we change OnUpdateInt() to use ints. No, unless you are into procuring stealth errors which go undetected for months. It would be better drop that interface completely. Although then extension maintainers whose code needs to work with several PHP releases will have to resort to preprocessor magic once again. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt
Don't they have to do that anyway..? :) No, why? For example, the session extension will be largely unchanged. The same code works in PHP 4 and 5. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #22527 [Opn-Bgs]: Modulus returned negative value
Well, Perl can lean the other way as well actually. Try this: Is there some documentation why the default is as it is? You will see it gives you -6. Like I said, it comes down to which way you truncate. Programmers tend to think that something like (int)(-3.4) should result in -3. If that is what you expect, then I think you also have to expect -27%7 to return -6. Agreed. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt
On Tue, 4 Mar 2003, Jani Taskinen wrote: Yup, that was the idea. I'll first change them all to OnUpdateInteger, and then use your patch to change the ones that need to be long to use OnUpdateLong. Is there any specific reason why a single API (OnUpdateLong) is not sufficient? Is not it a safe assumption that those modules which still use 'int's are simply the result of a mistake on the developer's side? - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.5.x-dev
On Mon, 3 Mar 2003, Harald Radi wrote: sorry for this naive question, i just realized that we have php 4.5.x snapshots on snaps.php.net, i assume this is the PHP_4 branch. does that mean that PHP_4_3 and PHP_4 should kept synchronized ? Yes, general fixes can be committed to the PHP_4 branch. is there also a PHP_4 branch in the Zend module or ist HEAD supposed to be PHP_4 ? There is also a PHP_4 branch in the Zend module, so a regular $ cd php4 $ cvs upd -r PHP_4 works. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.5.x-dev
On Mon, 3 Mar 2003, Sebastian Bergmann wrote: Harald Radi wrote: PHP_4 But why is the version of the PHP_4 branch 4.5, and not 4.4? 4.4 was used already in HEAD for some time. So we skipped it. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP_CHECK_FUNC and shared extension (OCI8)
how do I use PHP_CHECK_FUNC to make it work even when the extension is shared? You can manipulate LDFLAGS directly: php_save=$LDFLAGS LDFLAGS=-L$dir $LDFLAGS .. check .. LDFLAGS=$php_save - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt
So I think the fix of adding OnUpdateLong() is the correct fix. I was under the impression that OnUpdateInt was actually expecting a long. I remember changing some int's to long's to address 64 bit issues. Do I remember this incorrectly? - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt
No, you are correct but misunderstood me. We should introduce OnUpdateLong() for ppl using longs and use OnUpdateInt() for ppl who want to use ints. Well, and how are you planning to mitigate the BC issues? Remember that not all extension code is under our direct control. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt
I think that simply adding OnUpdateLong and deprecating OnUpdateInt is fine while retaining its current semantics. I just don't see any value in changing the meaning of OnUpdateInt; at least that's how I interpreted Andi's message. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt
That's also an option but I think OnUpdateInt() is confusing and how do we stop ppl from using it in new extensions which who's commit messages aren't followed via php-cvs? I volunteer to set up a cron job which greps for OnUpdateInt :-) The problem with _changing_ the existing semantics is that programmers will not notice that they need to adapt types from long to int. That leaves 64 bit platforms with a new set of problems, because the upper half of the long won't be initialized. - Sascha -- 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/tokenizer tokenizer.c
Or more accurately: PHP5 - co php5 PHP4.3 - co -rPHP_4_3 php4 PHP4 - co -rPHP_4 php4 - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC: dba/inifile native interface
I implemented the native interface - inifile_*() functions - in order to be able to work with group and name instead of the single key format that is necessary using the dba interface. Sounds to me like another issue which could have been easily solved by using a thin PHP layer. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC: dba/inifile native interface
On Sun, 23 Feb 2003, Marcus Börger wrote: After fixing hopefully last problems in the inifile handler i made up a patch which introduces a native interface to the inifile handler. I did this because the [group]name key format is not intuitive. Care to explain what it does? Does it feed all entries to the PHP INI system or is this is a custom layer wrapping the DBA API for storage of application settings? - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] file_put_contents() / file_add_contents() ?
On Fri, 21 Feb 2003, Jani Taskinen wrote: I object! :) It should be one function with extra parameter to decide the action.. Please put this code into ext/completely_unneeded. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] file_put_contents() / file_add_contents() ?
I'm not 100% sure if we want this feature, but perhaps it is worth revisiting that patch. Alternatively, I would suggest to teach the submitter of that patch regarding fopen, fwrite, implode. He might have overlooked those existing functions. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] file_put_contents() / file_add_contents() ?
On Fri, 21 Feb 2003, Derick Rethans wrote:
On Fri, 21 Feb 2003, Sascha Schumann wrote:
I'm not 100% sure if we want this feature, but perhaps it is worth
revisiting that patch.
Alternatively, I would suggest to teach the submitter of that
patch regarding fopen, fwrite, implode. He might have
overlooked those existing functions.
I think a counterpart for file_get_contents in the form of a plain
file_put_contents would be welcome.
Don't tell me that
?php file_write_content('foobar.txt', 'foo!', file_exists('foobar.txt'));
is better than
?php
$fp = fopen(foobar.txt, a);
fputs($fp, foo);
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] file_put_contents() / file_add_contents() ?
I meant a *plain* file_put_contents: That must be one of the most useless function proposals I've seen so far. Now, if the function could atomically replace file contents, then it would be something entirely different. But a simple wrapper for a two-line fopen/fputs? Get real. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] file_put_contents() / file_add_contents() ?
n Fri, 21 Feb 2003, Dirkjan Ochtman wrote: That's like one of those functions I've written myself and have to include in about every project I write... I think it's a Good Thing. Well, I fully understand that. I just disagree with the idea that this utility function should become part of the PHP core. It really belongs into some kind of utility collection where it can be implemented in PHP. A PEAR class would be the perfect location for it. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] file_put_contents() / file_add_contents() ?
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 utility library; this does not belong into the core of PHP. Or is your argument we already have so much bloat, a bit more is ok, too? - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Contributing to PHP - how?
On Mon, 17 Feb 2003, David Gillies wrote: OK, I've been using PHP since about six months after Rasmus decided to share his brainchild with us. Can someone PLEASE point me to the appropriate mechanism to contribute my own modules? Apply for a CVS account first, so that you can simply commit/maintain your modules to PECL. http://www.php.net/cvs-php.php Welcome o'board. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] build no longer working
On Thu, 13 Feb 2003, Marcus Börger wrote: I updated all m4,autoconf libtool AND now i can no longer build php Anybody help? Get autoconf-2.13 and m4-1.4 (not 1.4o) from ftp.gnu.org. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] build no longer working
On Fri, 14 Feb 2003, Marcus Börger wrote: At 01:57 14.02.2003, Jani Taskinen wrote: On Fri, 14 Feb 2003, Marcus Börger wrote: AC_PROG_LIBTOOL is defined in libtool.m4, which should come from libtool installation. Most likely you've just got mixed up versions in your system. Easiest way to get it working is to remove _all_ the auto* tools and libtool. And compile all from sources. With same prefix.. --Jani Is it possible that i have a problem due to the order of build and install? Ensure that m4 --version actually outputs 1.4 and not 1.4o. Some rpms are mislabeled in that area. Otherwise, the only problem source comes from having a polluted installation where multiple autoconf/libtool versions are sprinkled through the whole system. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] List of all functions
On Fri, 14 Feb 2003, Rickard Andersson wrote: I would very much like a complete list of all functions in PHP 4.3.0. Is there a way to generate this from the source tree or do I have to go through it all by hand? Try http://www.zugeschaut-und-mitgebaut.de/php/ There are also some awk scripts around which extract that information. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] session security
On Tue, 11 Feb 2003, Hans Prins wrote: Thx guys, I'll play around with it some more and see if I can secure it some more :) Keep in mind that many proxies remove the referrer information. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main spprintf.c
Markus,
here is a patch against the current CVS which
- trims +100 lines of code from spprintf.c
- introduces an overflow detection in STR_TO_DEC
- eliminates dead code (e.g. assert(foo); if (foo) {..})
- removes unused macros from the original code
- simplifies code (e.g. cc was completely dropped)
- improves run-time performance
The max_len feature is never used in our code base.
Nevertheless, cpu cycles were spent on each string
operation to check the current length against max_len which
is quite inefficient. Thus, I've moved the check to
vspprintf where it is applied only once per call.
- Sascha
Index: spprintf.c
===
RCS file: /repository/php4/main/spprintf.c,v
retrieving revision 1.12
diff -u -r1.12 spprintf.c
--- spprintf.c 11 Feb 2003 20:30:37 - 1.12
+++ spprintf.c 11 Feb 2003 22:43:10 -
@@ -89,6 +89,8 @@
#define FLOAT_DIGITS6
#define EXPONENT_LENGTH 10
+#include ext/standard/php_smart_str.h
+
/*
* NUM_BUF_SIZE is the size of the buffer used for arithmetic conversions
*
@@ -96,134 +98,48 @@
*/
#define NUM_BUF_SIZE512
-
-/*
- * Size for realloc operations
- */
-#define SPPRINTF_BLOCK_SIZE 128
-
-/*
- * Descriptor for buffer area
- */
-struct xbuf_area {
- char*buf; /* pointer to buffer */
- size_t size;
- size_t max_len;
- char*buf_end; /* pointer to buffer end or ~0 */
- char*nextb;/* pointer to next byte to read/write */
-};
-
-typedef struct xbuf_area xbuffy;
-
-/* Resize xbuf so that add bytes can be added. Reallocation is done
- * in defined block size to minimize calls to realloc.
- */
-static void xbuf_resize(xbuffy *xbuf, size_t add)
-{
- char *buf;
- size_t size, offset;
-
- if (xbuf-buf) {
- offset = xbuf-nextb - xbuf-buf;
- if (offset+add xbuf-size) {
- return; /* do not change size if not necessary */
- }
- } else {
- offset = 0;
- }
- if (addSPPRINTF_BLOCK_SIZE) {
- size = xbuf-size + SPPRINTF_BLOCK_SIZE;
- } else {
- size = xbuf-size + add;
- }
- if (xbuf-max_len size xbuf-max_len) {
- size = xbuf-max_len;
- }
-
- buf = erealloc(xbuf-buf, size+1); /* alloc space for NUL */
-
- if (buf) {
- xbuf-buf = buf;
- xbuf-buf_end = xbuf-max_len ? buf[size] : (char *) ~0;
- xbuf-nextb = buf+offset;
- xbuf-size = size;
- }
-}
-
-/* Initialise xbuffy with size spprintf_BLOCK_SIZE
- */
-static char * xbuf_init(xbuffy *xbuf, size_t max_len)
-{
- xbuf-buf = NULL;
- xbuf-size = 0;
- xbuf-max_len = max_len;
- xbuf_resize(xbuf, 0); /* NOT max_len */
- return xbuf-buf;
-}
-
/*
- * The INS_CHAR macro inserts a character in the buffer and writes
- * the buffer back to disk if necessary
- * It uses the char pointers sp and bep:
- * sp points to the next available character in the buffer
- * bep points to the end-of-buffer+1
- * While using this macro, note that the nextb pointer is NOT updated.
+ * The INS_CHAR macro inserts a character in the buffer.
*
- * NOTE: Evaluation of the c argument should not have any side-effects
+ * NOTE: Evaluation of the ch argument should not have any side-effects
*/
-#define INS_CHAR_NR(xbuf, ch, cc) \
- if (xbuf-nextb xbuf-buf_end) { \
- *(xbuf-nextb++) = ch; \
- cc++; \
- }
-
-#define INS_STRING(xbuf, s, slen, cc) \
- xbuf_resize(xbuf, s_len); \
- if (xbuf-nextb+slen xbuf-buf_end) { \
- memcpy(xbuf-nextb, s, slen); \
- xbuf-nextb += slen;\
- cc += slen; \
- s += slen; \
- } else {\
- for (i = s_len; i != 0; i--) { \
- INS_CHAR_NR(xbuf, *s, cc); \
- s++;\
- } \
- }
-
-#define INS_CHAR(xbuf, ch, cc) \
- xbuf_resize(xbuf, 1); \
- INS_CHAR_NR(xbuf, ch, cc)
+#define INS_CHAR_NR(xbuf, ch) do { \
+ smart_str_appendc(xbuf, ch);\
+} while (0)
+
+#define INS_STRING(xbuf, s, slen) do { \
+ smart_str_appendl(xbuf, s, slen); \
+} while (0)
+
+#define INS_CHAR(xbuf, ch) \
+ INS_CHAR_NR(xbuf, ch)
/*
* Macro that does padding. The padding is done by printing
* the character ch.
*/
-#define PAD(xbuf, width, len, ch, cc) \
- if (width len) {
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main spprintf.c
Why then this comment? Did you forgot to remove it. Yes. Hey cool i just thought about doing that, too. You're really fast Unfortunatley i haven't yet the time to try it out but it looks good. Does it have any known problems? No, but then there are no real test cases which could be tested against. p.s.: I asked about adding the cli manpage some days ago, can you help? $(mkinstalldirs) $(mandir)/man1 $(INSTALL_DATA) page.1 $(mandir)/man1/page.1 should be sufficient. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Apache 2.0 Handler module
On Mon, 10 Feb 2003, Justin Erenkrantz wrote: In the spirit of code rather than discussions that lead nowhere, here is a contribution that removes the filter code from PHP's sapi layer for Apache httpd-2.0. Until Zend can cleanly support streamy input, PHP should probably just use this method. Of course, this will not solve the threadsafety concerns (nothing really can other than documentation). Yay! This is doubleplusgood. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: uniqid default param
On Mon, 10 Feb 2003, Marcus Börger wrote: Hi, the current implementation of uniqid set the more entropy default true for CYGWIN and false for the rest. CYGWIN must use more entropy because it does not produce new values after usleep(1) necessarily. However usleep(1) should nowadays be very slow compared to whatever php_combined_lcg() needs to do. Shall more entropy be always true? No, some users might depend on the return format (think of database entries). - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Build failure with mod_php4.c (PHP_4_3 branch)..
On Tue, 11 Feb 2003, Jani Taskinen wrote: The old Apache seems to puke on that stuff you added some time ago and now merged to the PHP_4_3 branch. Apache version: IBM HTTP Server 1.3.19.3 (Apache 1.3.20) It propably needs some #ifdefs around it? Thanks for the heads up, I'll look into it. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Build failure with mod_php4.c (PHP_4_3 branch)..
On Tue, 11 Feb 2003, Jani Taskinen wrote: The old Apache seems to puke on that stuff you added some time ago and now merged to the PHP_4_3 branch. Apache version: IBM HTTP Server 1.3.19.3 (Apache 1.3.20) For anyone who cares, these packages can be downloaded for free from http://www-3.ibm.com/software/webservers/httpservers/ - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] session security
Can anyone point me to a possible solution for this? 1. Use SSL. 2. Throw away an existing session id, if a user authenticated successfully (e.g. destroy the old session, and copy the data into a new one). 3. Provide a logout button which destroys the session. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Problems with new CVS account
On Fri, 7 Feb 2003, Uwe Schindler wrote: I got a CVS account for maintenace of the NSAPI SAPI module. If I try to commit a change, I get the following error: CVSROOT=:pserver:[EMAIL PROTECTED]:/repository Access denied: insufficient karma (thetaphi|php4/sapi/nsapi) Contact [EMAIL PROTECTED] for access to php4/sapi/nsapi cvs server: Pre-commit check failed cvs [server aborted]: correct above errors first! I've granted the necessary access. Please try again. Additionally I have a question about the organization of the repository: There are more Modules you can Checkout (PHP4, PHP5, PHP4-only) but it seems that all files are identical and the cvs-program displays always php4/ as root directory. What is the difference of this modules? There are multiple active branches in the php4 module right now. The important ones are: HEAD:Leads to PHP 5 (main development line) $ cvs co php5 PHP_4_3: Maintenance branch (bug fixes only) $ cvs co -r PHP_4_3 php4 PHP_4: Development specific to PHP 4 (anything) $ cvs co -r PHP_4 php4 The module name you pass to cvs checkout gets expanded. It's really just about convenience. This stems from the historical diverse set of modules which are required for building PHP. php4-only will not download the engine/TSRM. You can see the current mappings here: http://cvs.php.net/co.php/CVSROOT/modules?login=2r=1.33 - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: To sed or not to sed (fwd)
FYI - Sascha -- Forwarded message -- Date: Tue, 04 Feb 2003 21:24:36 -0600 From: Robert Boehne [EMAIL PROTECTED] To: Lars Hecking [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: To sed or not to sed Lars, You're in luck! CVS Libtool goes to great pains to ensure that the sed used by it is the best one available. It also has piecewise linking support, most of this added by me for AutoOpenCascade @sourceforge. This doesn't solve the problem completely, it can't work around it if the only sed available truncates to 2401 character lines. It will however pick /usr/ccs/bin/sed over /bin/sed on Solaris for example, because it won't truncate as much. HTH, Robert Lars Hecking wrote: I came across something really annoying recently that I would not consider a libtool bug, but I figured the folks here are most qualified to suggest a solution. The problem is php 4.3.0. They have rearranged their build system for better portability, and stopped using convenience libraries for the various subdirectory builds. The consequence is that all objects are passed to libtool on the command line - which can be a very long list, depending on which features one compiles into php. On Solaris 7/8, this list of objects is too long for the native sed, and linking fails (some error messages about line too long). I reported this as a bug and was told to use GNU sed instead. Am I the only one who things that software should be buildable with native standard tools? The fix for me is to edit the libtool script included with php, and add an explicit PATH which includes GNU tools first (I don't want this change in my build environment, so I change it only where needed). And this needs to be done every time I build php :-/ Generally requiring GNU sed in libtool does not work in the same way as e.g. in autoconf, because the requirement would affect all users of libtool, not only those who build and install it. A possible partial solution could be that libtool has a section near the top where all standard tools it uses are declared, e.g. Sed=/usr/bin/sed which would at least make it easier to identify and change such components. I guess it's probably not possible to get rid of sed completely (other than replacing it with perl, which probably nobody wants). Any other ideas? ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Configure-System on Solaris
There should be another version of 'sed' in Solaris which can handle the long lines though. No idea why they have 2 versions. IIRC that is due to Solaris' BSD heritage. Solaris 1 (SunOS 4) was based on BSD (from the University of California, Berkeley, hence ucb) and they had to keep those utilities for their customers in SysV-based Solaris 2. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Configure-System on Solaris
On Tue, 4 Feb 2003, Melvyn Sopacua wrote: At 17:29 4-2-2003, you wrote: btw. It seems like that test I added for the broken sed is not working on some systems. Any ideas why? That's the grep -E part :) Just use `egrep' unless any1 knows of a system that doesn't carry egrep?. egrep is going to be deprecated by POSIX, but I suppose that switching back to it makes sense for now. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RfC: version names
On Fri, 31 Jan 2003, [ISO-8859-15] Kai Schröder wrote: That can be done, but that means 12 commits a day for a single file. I dont think that's a good idea. That's true. Now we have round about 30 commits each day. 12 more will make less than 5.000 blocks (5MB for 1k-blocks) more disk usage per year. Where do you see the real problem if the commits are not mailed to php-cvs list? Cluttering the history of an important file is an extremely bad idea. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RfC: version names
How is that possible? I don't think it is, because it needs to be done at checkout time, not at build time. What are you smoking? That's a one line addition to the snapshot script. - Sascha, creator, snaps.php.net -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RfC: version names
For manual checkouts that has nothing to do with snapshots, so he isn't smoking anything. echo test -r CHECKOUT_TIME || date CHECKOUT_TIME buildconf would be sufficient for that case. It's not perfect, because it is conceivable that someone does not run buildconf immediately. But that is unlikely from my POV. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RfC: version names
It's not actually, as we were just trying to *solve* this problem and prevent getting test results with the wrong date/time. So what happens if I do this? cd php4 cvs upd and a day later do this? cd php4/ext/standard cvs upd What is the checkout date here? - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RfC: version names
I've no idea, do you? I think we just should not allow submissions with test results if they're not made by a snapshot or our phport.sh thingy for automatic testing. If that phport.sh thingy reliably ensures the integrity of the source files, it could work. Have CVS $Id$'s been discussed yet? This line will give you the timestamp from the latest checked in file: find . -type f|xargs grep '$Id: ' |grep -v Binary |\ sed 's#.*\([12].../../.. ..:..:..\).*#\1#'| sort | tail -1 - Sascha -- 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
On Fri, 31 Jan 2003, Derick Rethans wrote: On Thu, 30 Jan 2003, Sara Golemon wrote: Only one complaint. snip So, we could relegate those VERY few who might've used that fourth parameter already to the read the changelog or suffer bucket, ornot. I think this group of people is very small (less then 10 I assume), so I dont see it as much of a problem to 're'use the 4th parameter. Let me add that even I have never used it. It's save to redeploy. - Sascha -- 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 ofstr_replace()
I suggest to check out http://citeseer.nj.nec.com/navarro01fast.html The presented BNDM algorithm is one of the fastest string searching algorithm while being easy to implement. Its main loop is faster than the naive str_replace implementation(*). Check out a C test implementation: http://www.mail-archive.com/dev@httpd.apache.org/msg00939.html The above paper also discusses extending the algorithm to cover character classes (case insensitivity). (*) I had incorporated it into PHP, if I had found a way to nicely offset the compilation step. This proved to be the major obstacle for small sets. - Sascha -- 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 ofstr_replace()
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 -- 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 ofstr_replace()
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. 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 algorithm (I may say so, I wrote it years ago) - allows us to combine multiple patterns into one search (I have not studied that part of the paper yet). This would enable us to optimize the case where you pass arrays to str_replace. Instead of scanning the haystack one time per replacement text, we would scan it only once. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reducing the number of system calls for includes
files list. It's handy and nice to normalize the path here, but it is really really expensive! ..only on systems with ultra slow syscall setup procedures (e.g. Solaris) or lack of directory cache. Due to our current implementation, if you have a lot of includes, you really should put all your include files in / and you will see some impressive improvements. Can you put some numbers on that? I've done quite a lot of benchmarking and those calls never appeared on the radar. This is annoying, but I am not sure how to fix it. A couple of things crossed my mind: 5. Looking at Linux's syscall implementation and implementing the good ideas in FreeBSD. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reducing the number of system calls for includes
Well, take an app that has 30 includes in a directory 5 levels deep. Just the realpath() call is going to do 180 stats every time that script is hit. Not sure how that wouldn't show up on the radar regardless of the OS. You probably don't have anything that has 30 includes, but people out there write code like that. How about writing a mini preprocessor for such cases which does the interpolation step everytime a programmer updates a source file? That would save way more cycles than killing some fstat calls. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headers required?
What are the headers required out here to compile this code successfully? Libs to link with? There is a SAPI API call for that (in HEAD, but I intend to merge it into the 4.3 branch). SAPI_API int sapi_get_fd(int *fd TSRMLS_DC); - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Headers required?
On Wed, 15 Jan 2003, Vinod Panicker wrote: Thanks for the quick reply... But is there something that I can do right now that will allow this code to work with php 4.2.3? You could add the necessary code from here: http://news.php.net/article.php?group=php.cvsarticle=16651 - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c
On Wed, 15 Jan 2003, Harald Radi wrote: iirc the reason why i changed it to unsigned was that actually the zend engine treated it as unsigned everywhere but in that particular struct. i also remember that i discussed that with andi and that he agreed to change this in the ze2 cvs module and that the extensions should be *fixed*. Well, fixing the engine is a small, finite task whereas auditing all existing extension on this planet is an open-ended one. I think it is easy to see that. You need to realize that once a certain API has been established, you cannot go around and change it at will. Especially if the breakage is as subtle as in this case. If the compiler dies, because a function takes a new number of arguments, it is something which becomes visible immediately. Signedness issues are usually hidden until someone exploits them. i agree that it doesn't make any sense to mix types. changing it to uint means to fix all the extensions, changing it to int means to fix the engine (and not just to revert my patch). In which areas of the engine did you notice defects? If we had a list, we could start from there. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)
On Wed, 15 Jan 2003, Derick Rethans wrote: On Wed, 15 Jan 2003, Christoph Grottolo wrote: So why not release a bugfix 4.3.1 not because of a security hole but just to complete the great work already done on PHP 4.3 - before definitely jumping to PHP 5? Who said that we're not going to release a 4.3.1 or 4.3.n? I'm just not favoring new code going into the PHP_4_3 branch, but only bugfixes. I'd like to see new functionality going into HEAD, for PHP 5. You might favor that, but I don't pretend that PHP 5.x will become useful immediately for my purposes. I need something to rely on and that is PHP 4 at this time. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c
you're propably a bit too optimistic, i can hardly imagine that all existing extensions all over the world compile out of the box against ZE2. i guess only a handful do this. Apparently, most of the extensions PHP ships with seem to work out of the box. I'm under the impression that almost no changes are required, unless you directly manipulate objects. That brings up the question -- do we have some documentation for extension authors which covers necessary changes. the only thing that should be realized is that compiler warnings are still a bad thing(tm). i don't see any difference in this compared to changing the number of arguments of a function. There is an important difference regarding developer awareness: No. of args change: The compiler will always bail out. Developer knows: Aha, I need to fix something. Signedness change: The compiler might issue a warning or not. Developer knows: Usually nothing. There are so many signedness issues in ext/standard alone, that I would not want to run with such warnings enabled. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache2Filter SAPI segfaults
On Mon, 13 Jan 2003, Derick Rethans wrote: So, save versions are 1.28, 1.30 and 1.75 for now? Perhaps restrict buildconf to check for this? It's a configure/genfiles-time check as hashed out in an older thread. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patches for buildconf and build/buildcheck.sh
On Mon, 13 Jan 2003, Magnus Määttä wrote: Hi! I made these two patches so the buildconf script works on Tru64. You can simply add MAKE=gmake export MAKE to your .profile (or how it's called on your system). buildconf will then use GNU make. Although I do wonder why you would need that -- the makefiles are supposed to work even with Tru64's native make. I've committed a portability fix for the use of the which command. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c
I might be misunderstanding the problem and I didn't have time to read the phrack article, but doesn't this mean that leaving it unsigned is better? It wouldn't pass the length check and thus, memcpy() wouldn't convert a negative number to something huge. The problem is that every single line of existing PHP extensions, both public and non-public, would need to be audited, if we were to switch the type, because 100% of the current code misinterpretes data from the ZE2 API right now. Changing the API does not solve the existing problem, it merely adds to it. For example, you can add a single central check to the engine today which checks string lengths to be at least 0. If the length field was changed to an unsigned type permanently, such a check would be impossible to implement in a portable way, because C does not define how a negative number will appear when cast to an unsigned type. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/com .cvsignore COM.cCREDITS TODO VARIANT.c com.h conversion.c conversion.h dispatch.c php_COM.h php_VARIANT.h variant.h
On Sat, 11 Jan 2003, Sebastian Bergmann wrote: Sascha Schumann wrote: You removed those files from the PHP 5 branch which you claimed were supposed to be used in the PHP 5 branch. ext/com/ are the old files, ext/rpc/com are the new files Yeah, somehow my brain told me those strings were the same. Weird. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] when PHP code causes crash due to bad input, is it abug?
Greg, don't make that big fuss about it. I fixed the code 15 minutes after bogusfying your report, so it throws an error, if the input is bad. Maybe setting it to bogus was a little bit too unfair, but my additional comments should have clarified it... Looks to me like it should have been set to 'closed' after fixing the crash bug. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c
On Sat, 11 Jan 2003, Ilia A. wrote:
On January 11, 2003 06:03 pm, Moriyoshi Koizumi wrote:
On Sat, Jan 11, 2003 at 11:38:20PM +0100, [EMAIL PROTECTED] wrote:
Sorry but just a thought, in that line:
if (argc 1 (int)Z_STRLEN_P(return_value) len / 2) {
Does this mean we now always need to cast the result of the
Z_STRLEN_P/Z_STRLEN_PP macros to int? That seems pretty annoying and not to
producing ugly code.
Certainly not.
What kind of warnings was the compiler (which one?) issuing?
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c
The cause for this is that phanto changed the type of the string length from a signed type to zend_uint without providing any kind of justification (zvalue_value). As many past security advisories have shown, signedness issues are the frequent cause for severe vulnerabilities in software (recent examples include MySQL, OpenBSD kernel). As all existing PHP extensions and other relevant code assumes that the length of strings is denotated by a signed integer type, I hereby propose to revert that commit and to reinstate the old type. Any objections? - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c
On Sun, 12 Jan 2003, Moriyoshi Koizumi wrote: On Sun, Jan 12, 2003 at 12:12:39AM +0100, Sascha Schumann wrote: As many past security advisories have shown, signedness issues are the frequent cause for severe vulnerabilities in software (recent examples include MySQL, OpenBSD kernel). Actually codes like below produce vulnerble runtimes because the length of string is expected to be a positive integer value... Yes, unfortunately. Basically the same problem as in the OpenBSD kernel and its select syscall: http://www.phrack.org/phrack/60/p60-0x06.txt Quote: Whilst there is a check [1] on the 'nd' argument (nd represents the highest numbered descriptor plus one, in any of the fd_sets), which is checked against the p-p_fd-fd_nfiles (the number of open descriptors that the process is holding), this check is inadequate -- 'nd' is declared as signed [6], so it can be negative, and therefore will pass the greater-than check [1]. Then 'nd' is put through a macro [2], in order to calculate an unsigned integer, 'ni', which will eventually be used as the the length argument for the copyin operation. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] string functions
On Sun, 5 Jan 2003, Ilia A. wrote: 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'. Ilia, there is a consensus that the new (slower) parameter parsing is only supposed to be used for new functions. It makes little sense to replace faster, correct, working code with its worse counterpart. Three string functions: stristr(), strstr() and strpos() have peculiar way of handling non string values passed as 'needle'. Instead of converting the needle to a string they instead convert it to an integer and search for a character equivalent to that integer. This behavior causes a problem such as strstr(abc123, 1) returning false rather then returning 123 as one may expect. Because this behavior is not documented, I believe we could safely change it back to the behavior listed This should be documented then. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /sapi/apache2filter php_apache.h sapi_apache2.c
On Fri, 3 Jan 2003, Anantha Kesari H Y wrote: hyanantha Fri Jan 3 10:59:02 2003 EDT Modified files: /php4/sapi/apache2filter php_apache.h sapi_apache2.c Log: Modifications for NetWare. I need to say it again. These modifications are *extremely* ugly. It's like spilling a glass of wine over important documents. You won't be able to remove the spilled substance without expensive labor. These modifications lack proper factoring. They repeat the same kind of change all over our code base. Instead of hiding some of netware's properties behind appropiate macros and typedefs, you duplicate existing code in a slightly changed manner all over the place. What do you guys think about this? - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update: Quoting behaviour exposed
Zeev, you start to bore me. If you didn't notice it yet, yesterday's email already constituted my EOT contribution. So, now, explicitly for you, EOT. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update: Quoting behaviour exposed
On Sun, 29 Dec 2002, Zeev Suraski wrote: At 11:46 29/12/2002, Sebastian Bergmann wrote: Rasmus Lerdorf wrote: Sascha, we need to give you something constructive to work on... -Rasmus (top-posted with lots of quoted text just for you) If it brings Bad E-Mail Practices to the attention of the perps, I would consider it constructive. Sascha is not the only one annoyed by issues like bad quoting behaviour. As with PHP's featureset, php-dev is not a purists' place. To each his own, we're not going to start applying quoting etiquette or calculate percentages. Zeev, get off the high horse. Jesus, a majestatis pluralis! Or do you still think you can make decisions for everyone? - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update: Quoting behaviour exposed
As much as it is amusing, tihiye besheket vetafsik lehishtamesh beLatinit. If that language had interested me, I would have made my Hebraicum in addition to the Latinum. [snip off-topic] If it has not been clear to you or anyone else -- this has all been about drawing attention to the issues of proper quoting. If only one person starts to embrace some of the available guidelines, it has been well worth it. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] autoconf troubles with 4.3.0
***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH ***BUG in Autoconf--please report*** AC_ADD_INCLUDE Install m4 1.4 rather than 1.4o. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] META: Proper quoting
I've noticed a trend to extreme over-quoting on the php developer mailing lists. (Not to mention top-posting, but that's another topic.) In the latest example, Derick' email could have been 88% shorter, if he had just cut down the contents to the essential pieces. While it takes the writer like 5 seconds to remove such parts, each reader will have to scan the non-essential parts and thereby spend a lot more time on it (e.g. 5s compared to n*3 seconds). Helpful links: URL:http://www.math.fu-berlin.de/user/guckes/mail/edit.html#over_quoting URL:http://www.math.fu-berlin.de/user/guckes/mail/edit.html#full_quote Good Example: URL:http://news.php.net/article.php?group=php.devarticle=92888 Bad Examples: URL:http://news.php.net/article.php?group=php.devarticle=92886 URL:http://news.php.net/article.php?group=php.devarticle=92903 URL:http://news.php.net/article.php?group=php.devarticle=92906 - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Quoting behaviour exposed
So, I had a look at whether pure numbers would support the suggestion that quoting behaviour was not up to speed on this list. Considering the last 888 emails to php-dev, the script found the following quoted/original ratio: 1%: = 17.25 5%: = 6.25 10%: = 3.50 15%: = 2.75 I.e. 5% of the emails contain at least 6.25 quoted lines per single original line. (Empty original/quoted lines are dropped.) The script also looked at 10% of the messages with the highest ratio. It computed the average ratio for these messages per sender. The top 10 follows :-) Marcus Börger avg of 13.02 in 11 postings Markus Fischer avg of 11.05 in 2 postings Ilia A.avg of 10.85 in 4 postings Andrei Zmievskiavg of 10.16 in 3 postings Andi Gutmans avg of 8.97 in 14 postings John Coggeshallavg of 8.43 in 6 postings Moriyoshi Koizumi avg of 8.27 in 10 postings George Schlossnagleavg of 7.69 in 3 postings Jani Taskinen avg of 7.31 in 3 postings Xavier Spriet avg of 7.27 in 2 postings (For a realistic picture, I dropped records with a single posting, because those are true accidents. Otherwise, Thies would have won with a ratio of 60.08 in one posting.) - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Update: Quoting behaviour exposed
After looking at a few messages again, I noticed that my script also considered signatures (personal and the mailing list's) as original lines. Once these are kicked out, we see a far worse picture (the ratios almost double): 1%: = 34.60 5%: = 12.50 10%: = 6.75 15%: = 4.50 And the top 10 again (messages with a ratio = 3): Jani Taskinen avg of 18.86 in 3 postings John Coggeshallavg of 14.12 in 10 postings Xavier Spriet avg of 12.71 in 8 postings Ilia A.avg of 12.22 in 7 postings Marcus Börger avg of 12.03 in 22 postings George Schlossnagleavg of 11.78 in 4 postings Moriyoshi Koizumi avg of 10.44 in 14 postings Andi Gutmans avg of 10.22 in 22 postings Markus Fischer avg of 9.42 in 5 postings Wez Furlongavg of 8.97 in 4 postings - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update: Quoting behaviour exposed
Only a fool would decry the importance of effective communication. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] autoconf troubles with 4.3.0
p15104972:/usr/src/packages/SPECS # rpm -qi m4 Try m4 --version. The package version is likely to be wrong. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] autoconf troubles with 4.3.0
***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH ***BUG in Autoconf--please report*** AC_ADD_INCLUDE Ah, sorry, I did not really look at the output. The undefined macros should not be referenced by any of PHP's config.m4 scripts anymore. If you e.g. copied an old external extension into the PHP source tree, you are likely to see these messages. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update: Quoting behaviour exposed
On Sun, 29 Dec 2002, Zeev Suraski wrote: Give us a break. And spare me an intelligent explanation about why we're fools and you roolz, and why we don't deserve a break. Only a fool would blow such an idiotic thing out of proportion. I ran a script and posted the results -- why is that out of proportion? - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update: Quoting behaviour exposed
Read back your (as usual) condescending remarks, and the entire thread. You're a smart guy, figure it out! Well, I would appreciate an answer on why this thing is 'idiotic' and 'out of proportion'. Please enlighten my poor soul, dear Zeev! - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update: Quoting behaviour exposed
I did my best to enlighten your poor soul in the past, numerous times, but I at some point I realized it's beyond my reach. Knowing one's limits is a virtue, and I know mine, so you're on your own! As enjoyable as always, - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update: Quoting behaviour exposed
On Sat, 28 Dec 2002, George Schlossnagle wrote: Wow... top 10. And to think my guidance counselor said I would never amount to anything And if it has not been obvious, the top 10 should be taken with a grain of salt. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update: Quoting behaviour exposed
On Sat, 28 Dec 2002, George Schlossnagle wrote: Guess I should add visible sarcasm/sarcasm tokens in the future, eh? Not really, I just wanted to point that out explicitly for the benefit of the rest. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] -+ [01]
On Thu, 19 Dec 2002, Zeev Suraski wrote: Just to somewhat limit my agreement with that statement, I'd rephrase it so that it's clear that people's opinion does matter. Something along the lines of 'Too many people think that they're in a position to decide about PHP'. There is nothing funny about that statement. For example, if you are not going to do the work on merging the CLI/CGI code, just saying that you would like to see that happening has little to no effect. Conclusively, there is simply too much noise on the php-dev list by people who are not going to do any work, but somehow think they are entitled to actually waste other people's time with their opinions. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] -+ [01]
I disagree. For instance, if I helped writing the combined module, and someone separated it without thoroughly making sure that everyone is ok with this separation, I believe it's upto him to be responsible to merge it back in. That surely happens in 0.01% of the cases. My example referred to the fact that decisions by anyone on this list are completely meaningless, unless the person can convert that decision into actual code. What you suggest is that PHP will really be f(t), as people's resources change with time. I do not agree. PHP has hardly evolved over the last six months. php-dev has become another dragging, slow committee where no actual evolution can happen. The sorry state of PHP development stems from that. Sometimes I envy the Linux kernel model where a dictator can actually move the development process forward and does not need to seek consensus with those individuals who managed to subscribe to some mailing list. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
