Re: [PHP-DEV] Bug #6248 Updated: parent:: is undocumented

2001-05-19 Thread Jeroen van Wolffelaar
On Sat, 19 May 2001, Hartmut Holzgraefe wrote: Jani Taskinen wrote: Do not close any bug reports before the possible bug is REALLY fixed. so you claim it has *not* been fixed by the latest updates that kk made to phpdoc/en/language/oop.xml ??? ;) I'd almost say: RTFM :-D Jeroen van

Re: [PHP-DEV] Bug #11685 Updated: Bad Auto-Cast

2001-06-26 Thread Jeroen van Wolffelaar
Old-Status: Open Status: Bogus ?php $var=-1073741824; #^ Here! $var*=2;$var*=2; var_dump($var); ? It will print out int(0). but I believe it should print outint(-2147483648) or float(-2147483648) like this program: IMO the output is wrong indeed. On integer overflow, it should be

[PHP-DEV] [PATCH] for bug#11685 'bad auto-cast'

2001-06-26 Thread Jeroen van Wolffelaar
The patch is attached, for line-breaking reasons. I also noted a probably-wrong if-statement, added a comment about that, but didn't fix it. Would someone have a look at it. IMPORTANT: did *not* test the patch, as I doen't have the equip here to compile. Greetz, Jeroen Jeroen van Wolffelaar

[PHP-DEV] New pow-function

2001-07-03 Thread Jeroen van Wolffelaar
Hi, I've rewritten the pow(base,exp) function. It is attached. In stead of a mere call to the c-lib function pow, this one actually does something more smart. This is to protect those people not knowing that there is huge difference between raising to an integer power and raising to a

Re: [PHP-DEV] New pow-function

2001-07-03 Thread Jeroen van Wolffelaar
IMPORTANT: I didn't test it yet, I'm not even sure there are no compile errors. (My linux machine doesn't have libtool 1.4 :-(( ) Hey, I can now compile :) And there is an error, so ignore this for now :( Please use proper Z_* macros, that is Z_LVAL_PP(exp) instead of Z_LVAL(*exp).

Re: [PHP-DEV] New pow-function

2001-07-03 Thread Jeroen van Wolffelaar
You use *_PP variants for ** pointers, and _P for * pointers. k. I've now fixed the compile problems, it will compile now. Even better: it works :-) See attachment. Greetz, Jeroen new_pow_func.c -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] New pow-function

2001-07-03 Thread Jeroen van Wolffelaar
And try to use ZEND_NUM_ARGS() wherever possible. Like here: zend_get_parameters_ex(ZEND_NUM_ARGS(),zbase,zexp); I'm fairly new to C, and surely new to the php-implementation, so I took this from many, many other functions, where it was done that way... I haven't noticed any function

[PHP-DEV] [patch] New pow function

2001-07-03 Thread Jeroen van Wolffelaar
Hi, I've fixed some bugs in the function, and believe it is now correct. It's best to come up with a whole bunch of tests, since there are 25 conditional expressions in it, for 25 different cases... This is due to the nature of pow(), and the fact it is now overloaded. pow(0,0) is now fixed to

[PHP-DEV] Re: [PHP-DOC] Re: [PHP-NOTES] note 13852 added to function.mail.php

2001-07-07 Thread Jeroen van Wolffelaar
Has anyone idea's for a good syntax? I think there are enough classes for mime-mail handling, maybe someone could get one into PEAR... Hm, so you don't think it'd be a good think to get in PHP itself? There are numerous functions that are less common-used, and can be written very well in

[PHP-DEV] pow()

2001-07-08 Thread Jeroen van Wolffelaar
, please drop me a line (and of course also when they don't) Greetz, Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen Index: math.c === RCS file: /repository/php4/ext/standard/math.c,v retrieving

[PHP-DEV] RE: Bug #11962 Updated: eval() doesn't handle multi-dimentionalarrays.

2001-07-09 Thread Jeroen van Wolffelaar
! To reply, use the web interface found at http://bugs.php.net/?id=11962edit=1 Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL

[PHP-DEV] [PATCH] for bug#10721

2001-07-09 Thread Jeroen van Wolffelaar
Hi, I've made a patch for 10721, based on justin's, and it now works correctly. Andi/Zeev, would you please commit this? Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen Index: zend_builtin_functions.c

[PHP-DEV] Re: Bug #11988 Updated: irc_function

2001-07-09 Thread Jeroen van Wolffelaar
How about having some 'reject' button/link on the bug pages? Just like with the notes: The sender gets a default mail with: read bugs do and don't, include sample, ask php-general first, etc. And the bug gets bogusfied automatically with a default comment if none is supplied. I think it'd be

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: Str enhancement, final run

2001-07-10 Thread Jeroen van Wolffelaar
I've said it before, but I *really* am convinced now, that we should: - At least allow $str{index} (while _deprecating_ the array $str[ ] indices) - _possibly_ also allowing $str{start..end} - and if the above is allowed, then I think you should also allow $str{..end} and $str{start..} But

[PHP-DEV] Re: php4 /main fopen_wrappers.c

2001-07-10 Thread Jeroen van Wolffelaar
- Right now this also effects things like opening php.ini. It'll now always check in the current working directory for php.ini. I think this doesn't screw up todays behavior. Isn't this a huge security risk? When there is something wrong so that php.ini can't get read where it

Re: [PHP-DEV] Preliminary patch for allowing relative includes

2001-07-11 Thread Jeroen van Wolffelaar
I don't have access to the PHP CVS at the moment (note to self: get a C compiler)... but I wanted to ask how this will affect (or will it?) HTML generated from within included PHP files. Eg. A is at web root and includes B in a subdirectory X. B generates HTML that calls for image C.gif in

[PHP-DEV] Re: [PHP-DOC] Re: [PHP-NOTES] note 13852 added to function.mail.php

2001-07-07 Thread Jeroen van Wolffelaar
The mail() function can be used to send email with attachments and special types of content. This is accomplished via MIME-encoding - for more information, see http://www.zend.com/zend/spotlight/sendmimeemailpart1.php; Just a wild idea, but maybe we should add a real

[PHP-DEV] Re: Patch for ext/standard/[basic_functions.c|php_math.h|math.c]

2001-08-01 Thread Jeroen van Wolffelaar
I am sending this patch to the php-dev list for your consideration. Attached are the listing produced with cvs diff -u, and listed below is a test file to check the changes. Basically I just added some more math funcs from the C library (hyperbolics and exponentials). Hyporbolic

[PHP-DEV] Re: Patch for ext/standard/[basic_functions.c|php_math.h|math.c]

2001-08-01 Thread Jeroen van Wolffelaar
It might be that. Just implemented the functions taking advantage of their presence in the standard set of math functions of the C library, so the C people might be more familiar that the rest I guess. Agreed, but I'm not certain this is worth the extra bloath of relatively unneeded

Re: [PHP-DEV] RFC: New math functions: log2, etc

2001-08-03 Thread Jeroen van Wolffelaar
log(a) / log(n) is not that much harder, and its the right way, imho. Yes, you're right that it is the right way. But for example, for tan(x), the right way is sin(x)/cos(x). (Not such a good example, but anyway) log($bla,2) is cleaner, IMO, than log($bla)/log(2), not mentioning the possible

Re: [PHP-DEV] RFC: New math functions: log2, etc

2001-08-03 Thread Jeroen van Wolffelaar
There is a possibility that GSL will be implemented in PHP, but that's in GSL: GNU Scientific Library, http://sources.redhat.com/gsl/ Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To

Re: [PHP-DEV] Tests: naming

2001-08-04 Thread Jeroen van Wolffelaar
You can call them whatever.phpt, the reason they're numbered is to define the order they are checked in. Maybe naming them 03trim.phpt would be a good compromise? Why do you want to know the order they're checked in? Jeroen -- PHP Development Mailing List http://www.php.net/ To

Re: [PHP-DEV] RFC: New math functions: log2, etc

2001-08-04 Thread Jeroen van Wolffelaar
At 01:53 AM 8/4/2001 +0200, Jeroen van Wolffelaar wrote: log(a) / log(n) is not that much harder, and its the right way, imho. Yes, you're right that it is the right way. But for example, for tan(x), the right way is sin(x)/cos(x). (Not such a good example, but anyway) As you said

Re: [PHP-DEV] Bug #12566 Updated: Cascaded ternaries evaluate incorrectly

2001-08-04 Thread Jeroen van Wolffelaar
See some messages I had on php-dev back around the first week of January, 2001 on this topic. FWIW, I would like to change it. On http://marc.theaimsgroup.com/?w=4r=1s=trachtenbergq=a , I could only find messages about break/continue in switch statements... Am I overlooking something? Of did

Re: [PHP-DEV] RFC: mt_* functions

2001-08-04 Thread Jeroen van Wolffelaar
Please don't. Ini settings that change semantics are a bother, and people should be able to choose their random function. Both function families are the same in syntax returning, only the algorithm is different. I.e.: the semantics is the same. The algorithm - if correct - shouldn't bother,

Re: [PHP-DEV] Re: rand_str

2001-08-05 Thread Jeroen van Wolffelaar
but why not put it into PEAR? PEAR can be useful, but the power of PHP is, that is has so many helpful build-in functions. And with pear, it will always be longer. I think that new functions should be added on basis of usefulness, not the coolness factor. IMNSHO this function isn't very

Re: [PHP-DEV] RFC: mt_* functions

2001-08-05 Thread Jeroen van Wolffelaar
Both function families are the same in syntax returning, only the algorithm is different. I.e.: the semantics is the same. The algorithm - if correct - shouldn't bother, and shouldn't be the concern of the programmer, but rather the system maintainer (specific cases excluded, but than

Re: [PHP-DEV] Re: rand_str

2001-08-05 Thread Jeroen van Wolffelaar
and it is extremely easy to implement in userland: That is not true, So how about this? function str_rand($len=8) { $retval = strtr(md5(microtime()), chr(0x30), chr(0x4F)); return substr($retval,0,$len); } for($i=0; $i10; $i++){ echo str_rand(), \n; } I find

Re: [PHP-DEV] Re: rand_str

2001-08-05 Thread Jeroen van Wolffelaar
Hi Jeroen, I think we're not on the same page. :) I consider both versions of str_rand() I posted trivial... Agree. But they are not what rand_str could do. The result has 16 different chars, just because md5 happens to have that much. Implementing something that has NOT that limitation, is

[PHP-DEV] Re: PHP Notes

2001-08-05 Thread Jeroen van Wolffelaar
- Original Message - From: Andy [EMAIL PROTECTED] To: Jeroen van Wolffelaar [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, August 05, 2001 9:47 PM Subject: Re: PHP Notes confirmation would be even worse, then I'd (we'd) STILL have to go through all of the notes (and this time

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

2001-08-05 Thread Jeroen van Wolffelaar
Can't post to php-cvs :-( jeroen Sun Aug 5 16:27:04 2001 EDT Modified files: /php4/ext/standard math.c Log: Bugfix in abs(), abs(LONG_MIN) was bogus ---AND--- - Replaced the pow(LONG_MIN,1) fix for a better one - Removed bogus left-over comment in pow() --

Re: [PHP-DEV] Re: rand_str

2001-08-05 Thread Jeroen van Wolffelaar
Implementing something that has NOT that limitation, is far less trivial. function str_rand($len = 8, $class = 'a-zA-Z1-9') { static $init = 1; if(1 == $init){ mt_srand((double) microtime() * 100); $init = 0; } $chars = array(); for($i = 0; $i

[PHP-DEV] Re: Bug #12245 Updated: gettype(true true) returns integer!

2001-08-08 Thread Jeroen van Wolffelaar
Patch attached - Original Message - From: [EMAIL PROTECTED] Newsgroups: php.dev To: [EMAIL PROTECTED] Sent: Thursday, August 09, 2001 1:12 AM Subject: Bug #12245 Updated: gettype(true true) returns integer! ID: 12245 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Status:

Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)

2001-08-09 Thread Jeroen van Wolffelaar
What about $_TAINTED ? for non-english ppl REQUEST is a more familiar word that TAINTED. I only encountered it when studying JS security. +1, tainted? I needed a dictionary for that... -- teodor -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL

[PHP-DEV] Re: [PHP-DOC] Bug #12550 Updated: rand() and mt_rand() don't behave as documented

2001-08-13 Thread Jeroen van Wolffelaar
Now you assume that you need to pass arguments to these functions. Which is not the case. Here's the proto: /* {{{ proto int rand([int min, int max]) Returns a random number */ So revert that patch. mt_rand() / rand() accecpt either 2 parameters or none at all. It was at least LESS

[PHP-DEV] Setting up RFC

2001-08-14 Thread Jeroen van Wolffelaar
Hi, About a month ago there was a discussion on the Engine 2 mailing list, about a possible RFC-proces for the more imporant PHP-issues. In the end, there was some consensus that it would be good if such a system exists. I'm simply writing to get some comments, to hear what the general opinion

Re: [PHP-DEV] Setting up RFC

2001-08-14 Thread Jeroen van Wolffelaar
Just poit them to php-dev and keep bringing it up until there is some decent comment on it, at the moment there is no democratic process in PHP, people just do what they want and someone normally knows some part of PHP better than anyother, IE if you have a sessions thing speak to sascha (via

Re: [PHP-DEV] Setting up RFC

2001-08-14 Thread Jeroen van Wolffelaar
On the other hand, the latter one could be named 'RFC process', since it hasn't yet been defined what the heck it is precisely... RFC.. Request For Comments, its as simple as that someone posts a document outlining what they want changed/want to do, calls it an RFC and is litterally

Re: [PHP-DEV] Setting up RFC

2001-08-14 Thread Jeroen van Wolffelaar
The work on Zend Engine 2 has now started, _without_ a proper definition of it. IMHO, that's not the ideal situation, since this could lead to strange inconsequences, because the precise behaviour is decided during implementation. Umm what about the white paper that was prepaired

Re: [PHP-DEV] Setting up RFC

2001-08-14 Thread Jeroen van Wolffelaar
With what end in mind is an RFC to be created for? In the IETF, RFC's are typically long, complex, and authoritative. They are often referenced for years after their inception. Do you honestly think we could (or want to) achieve this with PHP feature RFC's? Or will they be used only before

[PHP-DEV] RFC: rand() change, second try

2001-08-16 Thread Jeroen van Wolffelaar
Hi, [Impact and relevance: all functions that use randomness (including array_shuffleco)] After the previous discussion, I've been thinking, and I think I've got a way which has only a neglectible BC problem (unlike my first proposal), while still keeping the following in mind: Probably 99% or

Re: [PHP-DEV] chroot(): _not_ safe-mode restricted?

2001-08-20 Thread Jeroen van Wolffelaar
As I read it in CVS, chroot() will work even in safe-mode. Isn't this a bad idea(tm), or am I wrong? If users can chroot in safe-mode, Apache won't serve any more pages after all children have been chrooted to an empty dir? uhm, where have you read that? [ curious ] I just reasoned

Re: [PHP-DEV] pif

2001-08-21 Thread Jeroen van Wolffelaar
Zeev Suraski [EMAIL PROTECTED] wrote in message 5.1.0.14.2.20010822013439.02e0c498@localhost">news:5.1.0.14.2.20010822013439.02e0c498@localhost... At 23:14 21-08-01, [EMAIL PROTECTED] wrote: What about using the pif_ prefix for php's internal functions, analogously to zif? This makes them more

Re: [PHP-DEV] pif

2001-08-22 Thread Jeroen van Wolffelaar
What's wrong with php_ prefix? Nothing. It is just the same prefix as for PHPAPI functions, and the purpose was to diffentiate in the name between helper functions and API-functions. But starting it with an underscore is also a good way of achieving that, on second thought. -Andrei Jeroen

Re: [PHP-DEV] pif

2001-08-22 Thread Jeroen van Wolffelaar
I'm against that. Usually underscore-prefixed symbols are used by system libraries and OS and we don't need to go in that direction. I'm also against using pif_, because it's not an internal function that you are naming, but rather, a helper one. I don't really have an opinion on this

Re: [PHP-DEV] pif

2001-08-22 Thread Jeroen van Wolffelaar
At 23:09 22-08-01, Andrei Zmievski wrote: On Wed, 22 Aug 2001, Zeev Suraski wrote: How about phf_, for PHP Helper Function? I see a point in differentiating language level API functions (e.g. like output buffering) and module-specific helper functions (e.g., like

Re: [PHP-DEV] Branching ext/standard?

2001-08-22 Thread Jeroen van Wolffelaar
At 23:37 22-08-01, [EMAIL PROTECTED] wrote: Hi, I've got an experimental beginning of the new rand functions ready. I think it's good if others can comment on it before it is finished, because the course can be changed now quite easily, but when it's all done, I don't feel much about

Re: [PHP-DEV] Branching ext/standard?

2001-08-22 Thread Jeroen van Wolffelaar
If it's such a far reaching change, I suggest you simply send the diff the php-dev. It should be enough to be a basis for a discussion on the proposed changes. If we decide to go through with it, it should be At this time, it's merely a big move-around with code, no single thing of

Re: [PHP-DEV] Branching ext/standard?

2001-08-22 Thread Jeroen van Wolffelaar
What I would do in your case is: (a) Tag the relevant files as they are today (i.e., PRE_RAND_REDESIGN or whatever) (b) Commit your move-around changes (c) Commit the real changes (can be done immediately after (b), as long as it's separate) The real changes are not ready... and I didn't

Re: [PHP-DEV] Branching ext/standard?

2001-08-22 Thread Jeroen van Wolffelaar
(a) Tag the relevant files as they are today (i.e., PRE_RAND_REDESIGN or whatever) (b) Commit your move-around changes I really think a lot of people will set ext/standard to PRE_RAND_REDESIGN then, because they want to work on other parts, and don't want a broken build. That's the other

[PHP-DEV] RAND_REDESIGN branched

2001-08-22 Thread Jeroen van Wolffelaar
Execute - in ext/standard: cvs update -rRAND_REDESIGN Makefile.in php_rand.h php_math.h rand.c rand_mt.c crypt.c And check it out... (I didn't branch whole ext/standard, so it's needed to name the necessary files... sorry) Jeroen -- PHP Development Mailing List http://www.php.net/ To

[PHP-DEV] Re: RAND_REDESIGN branched

2001-08-22 Thread Jeroen van Wolffelaar
Execute - in ext/standard: cvs update -rRAND_REDESIGN Makefile.in php_rand.h php_math.h rand.c rand_mt.c crypt.c Update: changed my mind, and branched whole ext/standard. It seems that it doesn't cause any overhead or whatever. So % cvs update -rRAND_REDESIGN ext/standard will do.

[PHP-DEV] Re: [PHP-CVS] cvs: php4 / php.ini-dist php.ini-recommended

2001-08-25 Thread Jeroen van Wolffelaar
Better question is, do we really want to do this? This doesn't fix anything. It only breaks things. Second, this will make writing portable scripts harder. Yet another ini setting to be checked for.. No! PLEASE read my propasal, this is a WRONG assumption. Even better: IF wou want a portable

[PHP-DEV] Re: [PHP-CVS] cvs: php4 / php.ini-dist php.ini-recommended

2001-08-25 Thread Jeroen van Wolffelaar
+; Default random number generator. Specify here which random number generator +; you want to use for the PHP-rand() function. Usually MT (Mersenne Twister, +; see http://www.php.net/manual/en/function.mt-rand.php) is the best choice. +; It is thread-safe, fast, and, quite important, mod

[PHP-DEV] How to make Thread Safety work (ZTS,TSRMLS) (was: Re: [PHP-CVS] cvs: php4 /main streams.c )

2001-08-26 Thread Jeroen van Wolffelaar
[Changed subject, I missed this thread until now because of it...] I assume this difference between 12 and 3 is _strictly_ performance, and _nothing_ else? And a note for others: You don't need TSRML* in every function, but you do need it if you use: - Global variables, like BG(...) co. - Use

[PHP-DEV] [PATCH] Fix for 12245

2001-08-29 Thread Jeroen van Wolffelaar
See attachment. I tested it, and I'm sure it works. --jeroen fix_for_12245.diff -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #13094 Updated: Upload very slow

2001-09-02 Thread Jeroen van Wolffelaar
I think the problem is the fact that we read all of the file into Memory That seems like a bad idea to me... it doesn't get in PHP directly, only after specific request. So you mean that PHP read's the whole file, than writes it to /tmp (or c:\temp), and then clears the memory again? If that's

Re: [PHP-DEV] [C] struct, function pointers question

2001-09-02 Thread Jeroen van Wolffelaar
Hi, I'm sure there's some simple (stupid?) error, which an experienced C-programmer can see immediately... But I don't. You're missing a variable name (you only put a type), and the line is not in the beginning of a code block (there's a statement before it). php_randgen_entry is (supposed

Re: [PHP-DEV] RAND_REDIGN

2001-09-02 Thread Jeroen van Wolffelaar
Also, I ask again: Why didn't you just add new function random() instead of changing all this and breaking BC. I DID NOT BREAK BC. Sorry, but this has been discussed dozens of times... --jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-CVS] cvs: php4 / NEWS

2001-09-02 Thread Jeroen van Wolffelaar
I was waiting for you to tell that now the branch works and I could test it and say 'good, this works you can merge'. I'm sure everybody else waited for same. You do NOT need the implementation to know how it is going to be. I explained that multiple times, and everybody (though silently)

[PHP-DEV] Re: [PHP-CVS] cvs: php4 / NEWS

2001-09-02 Thread Jeroen van Wolffelaar
(and *yes* I'm angry, and *yes* I'm talking to someone in particular). And I'm now going to sleep before it gets worse. Good night, Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To

Re: [PHP-DEV] Rand

2001-09-04 Thread Jeroen van Wolffelaar
PS: Egon, go read my reply when you asked that the first time. Wasn't I clear? It was in plain English though... I have only asked you, why have you deleted the comments. It was in my mail: - I DID NOT REMOVE THEM Ich habe den nicht weggeholt!!! I just MOVED them. That was

Re: [PHP-DEV] Bug #12841: ++, -- operators does not conert the typeof variable.

2001-09-04 Thread Jeroen van Wolffelaar
description: ++, -- operators does not conert the type of variable. The attached patch should cure it. jeroen, are you on it or should I commit this patch? Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net

[PHP-DEV] Re: The rand() can of worms

2001-09-05 Thread Jeroen van Wolffelaar
I *NEVER* have anything to say until I have seen the code. Otherwise, it's just a bunch of castles in the air. Okay, that's a point. That is not the custom where I learnwork, actually, there is a saying that design planning is 67% of the job, implementing just 33%. That is if you want a good

[PHP-DEV] Fw: [PHP-CVS] cvs: php4 /ext/standard rand_mt.c rand_sys.c

2001-09-05 Thread Jeroen van Wolffelaar
:[EMAIL PROTECTED]... On Wed, 05 Sep 2001, Jeroen van Wolffelaar wrote: Just look at the algorithm and you'll see at once it is bogus. Only in the special case that one single key is requested it is correct. Proving it's bogus is trivial, so I'll leave that as an exercise to the reader

[PHP-DEV] Fw: Rand again

2001-09-05 Thread Jeroen van Wolffelaar
News re-sent - Original Message - From: [EMAIL PROTECTED] Newsgroups: php.dev Sent: Wednesday, September 05, 2001 11:27 PM Subject: Rand again Hm, I notice there has been a huge discussion on php-dev, I think I'm going to read it first... My two previous mails were sent without having

[PHP-DEV] Fw: The rand() can of worms

2001-09-05 Thread Jeroen van Wolffelaar
Resent - Original Message - From: [EMAIL PROTECTED] Newsgroups: php.dev Sent: Wednesday, September 05, 2001 11:21 PM Subject: Re: The rand() can of worms Bad points: 1) Leaks 2) Inconsistent style 3) Really bizzare macros, etc. Let's put one thing straigt: I merged it

[PHP-DEV] Apology

2001-09-06 Thread Jeroen van Wolffelaar
I'm very sorry for whatever I wrote yesterday, I happend to got a quite drunk because of the closing of the introduction. I shouldn't have gone online in that state. I now redraw whatever I said, because I'm afraid it wasn't all that neat. For today I'm not going to write anything either, since

Re: [PHP-DEV] About the Rand Merge: apologoy how further?

2001-09-08 Thread Jeroen van Wolffelaar
Stig wrote: Wow. :) [[EMAIL PROTECTED]] (...) I'll keep it short. You were referring to this? Yes, I realized it after I sended it... I (obviously) wrote that before I finished the mail... Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL

Re: [PHP-DEV] Woah

2001-09-08 Thread Jeroen van Wolffelaar
At 01:24 09-09-01, Jeroen van Wolffelaar wrote: Exactly the same goes for ?= unless you happen to stumble across the one-line footnote on the php.net/echo page. So that's a documentation bug. It clearly belongs in the documentation about PHP's various special tags, just next

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

2001-09-08 Thread Jeroen van Wolffelaar
sterling Wed Sep 5 16:52:45 2001 EDT Modified files: /php4/ext/standard rand.c Log: a bit of api cleanup... move range stuff into a macro (properly :) Yeah yeah... I know by now... +#define RAND_RANGE(__n, __min, __max) \ + (__min) + (int)((double)(__max) - (__min) + 1.0) *

[PHP-DEV] Re: Note added to rand

2001-09-09 Thread Jeroen van Wolffelaar
People interested in rand can still visit http://www.A-Eskwadraat.nl/~jeroen/rand , but if you have something interesting to say you can of course also mail to php-dev! World Wide Web Cie [EMAIL PROTECTED] wrote: Note added by jmoore: My vote: ±1 :) Suggestions/remarks: I think that PHP

[PHP-DEV] Re: Note added to rand

2001-09-10 Thread Jeroen van Wolffelaar
Note added by joey, text: My vote: +0 Suggestions/remarks: I'll take the proposal one piece at a time: Good idea :-) float random() / int random(min, max): If I understand correctly, the only way you'll know what kind of return the user is expecting is by counting args. That means if

[PHP-DEV] Re: Note added to rand

2001-09-10 Thread Jeroen van Wolffelaar
No number is truly random. That is the nature of computers. You can only generate a sequence of numbers, based on a seed. True (of course, I knew that already long ago...), but 1) You can obscure that by using time-varying seeds in order to get seemingly random numbers 2) You can

[PHP-DEV] Re: [Zend Engine 2] Right/Left Shift Zero Fill operator

2001-09-10 Thread Jeroen van Wolffelaar
Is there anyone out there who uses on negative numbers? There is the discussion on the engine2 list about whether to make an unsigned right shift, or to introduce a new operator . In my opinion, and should consider integers as a row of bits, thus do not treat the msb differently... I

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Right/Left Shift Zero Fill operator

2001-09-10 Thread Jeroen van Wolffelaar
FWIW: Signed shift seems to make little sense to me personally, since we are just dealing with a row of bits, and if you really want to do a quick multiplication/division, you might just as well use a * or / operator - it is not going to hurt that much:). I completely agree *However*,

[PHP-DEV] Re: Bug #12690 Updated: array_unique under windows does not work as it does under linux

2001-09-15 Thread Jeroen van Wolffelaar
then why does this work in version 4.0.4 ? It was an implementation side-effect. It was not intentionally. The same issue as that, for example, you can specify a variable violating the naming rules by using: $GLOBALS[0a\n] = Some value; because it would be bad for performance to check for

[PHP-DEV] Re: array_sum() needed but not available in 4.0.4 versions..

2001-09-16 Thread Jeroen van Wolffelaar
How can I add the function array_sum() to older php core installations? Grep though the current source with 'array_sum', and add the three things that come up to your 4.0.3-source: a proto in a .h-file, a PHP_FE entry, and the PHP_FUNCTION itself. It should work... but why not simply upgrade?

[PHP-DEV] Rand...

2001-09-16 Thread Jeroen van Wolffelaar
Hi all, There has been a bit of discussion about rand(). I really appreciate that, though I would have preferred if it was held BEFORE the changes I (tried to) make. Okay, back to business. By special request, as short as possible: (I assume you've read the latest proposal, if not, go to

Re: [PHP-DEV] TSRM coverage question

2001-09-19 Thread Jeroen van Wolffelaar
On Tue, 18 Sep 2001, lo-tek @pb1.pair.com cshmoove wrote: suppose i have a function which returns a pointer to a variable in thread local storage foo_t *get_global_foo() { TSRMLS_FETCH(); return (foo_t *)BAR_G(foo); } void fubar() { foo_t *foo =

[PHP-DEV] Re: TSRM again

2001-09-20 Thread Jeroen van Wolffelaar
Jeroen, then i have one more question. The real problem im trying to solve is Would some one please answer this question, because this is getting somewhere (mutexs) I don't know much of. And not much is nearly nothing in this case ;-) --Jeroen -- PHP Development Mailing List

Re: [PHP-DEV] RE: Bug #13388 Updated: Could not connect to server

2001-09-21 Thread Jeroen van Wolffelaar
How can you determine it is bogus within 2 minutes, please provide your rational. (...) This is probably not a bug ? Are you kidding me ? I hope you are not closing any real nasty bugs because of this reasoning :) From http://www.chiark.greenend.org.uk/~sgtatham/bugs.html Give the

[PHP-DEV] Time of www.php.net incorrect

2001-09-21 Thread Jeroen van Wolffelaar
I posted a bug-update 5 minutes ago, and from the mail headers: Date: 22 Sep 2001 10:34:57 - It is now GMT/UTC 21 sep 2001 22:30 or something. That means that bugs.php.net is off-time by 12 hours, which is very annoying. (chronology of posts is completely wrong). Can someone please fix

[PHP-DEV] Confirmed: False positive in php_ mhash.dll with AntiVir software

2001-09-22 Thread Jeroen van Wolffelaar
FYI, I mailed the authors of that virus program, and they replied the following: - Original Message - From: H+BEDV Datentechnik GmbH [EMAIL PROTECTED] To: Jeroen van Wolffelaar [EMAIL PROTECTED] Sent: Friday, September 21, 2001 11:42 AM Subject: Re: False positive in PHP-distribution

[PHP-DEV] Re: Undefining user functions/classes at runtime?

2001-09-23 Thread Jeroen van Wolffelaar
Is it currently possible to undefine user functions or classes at runtime? Although not a newbie ;) I'm unsure if its possible right now. No, you can't do that in PHP-userland (in the C code it can be done, see implementation of create_function). And IMHO that should remain so. If not,

[PHP-DEV] Fw: Bumping PHP to support 8byte integers

2001-09-23 Thread Jeroen van Wolffelaar
Hi, For a scripting language, integers should IMHO be bounded by a number that will reasonally not be bound by numbers that will be used in normal scripts. That is currently not the case, 4 bytes are insufficient IMHO. Why not make sure PHP uses 8 bytes at least? Or are there platforms not

[PHP-DEV] Re: [Zend Engine 2] Bumping PHP to support 8byte integers

2001-09-23 Thread Jeroen van Wolffelaar
Hi, For a scripting language, integers should IMHO be bounded by a number that will reasonally not be bound by numbers that will be used in normal scripts. That is currently not the case, 4 bytes are insufficient IMHO. Why not make sure PHP uses 8 bytes at least? Or are there platforms not

[PHP-DEV] Re: [Zend Engine 2] Bumping PHP to support 8byte integers

2001-09-23 Thread Jeroen van Wolffelaar
how much slower it is. Anyway, it would be nice if someone with expericence with changing to 8 byte integers could share his experiences... --Jeroen Andi At 09:13 PM 9/23/2001 +0200, Jeroen van Wolffelaar wrote: Hi, For a scripting language, integers should IMHO be bounded by a number

Re: [PHP-DEV] Fw: Bumping PHP to support 8byte integers

2001-09-23 Thread Jeroen van Wolffelaar
I would be very worried about making numbers 8 bytes by default, unless the CPU supports them natively. There are a lot of consequenses involved with something like that. Assuming a 32 bit register system (x86) integers will no longer fit in registers. This changes EVERYTHING, from passing

[PHP-DEV] Re: [Zend Engine 2] Bumping PHP to support 8byte integers (fwd)

2001-09-23 Thread Jeroen van Wolffelaar
This subject is being crossposted to [EMAIL PROTECTED] and [EMAIL PROTECTED] This mail was only on engine2 (let's keep everyting at least on phpdev): -- Forwarded message -- Date: Sun, 23 Sep 2001 22:41:45 +0200 (CEST) From: Jeroen van Wolffelaar [EMAIL PROTECTED] To: Stig

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Fw: Bumping PHP to support 8byteintegers

2001-09-24 Thread Jeroen van Wolffelaar
indeed. The question was wether all compilers on 32bit platforms DO have long long support at all, in other words: is it true that all compilers for which PHP needs to compile have a C-type which is 64bit (native or not)? --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV]Fw: Bumping PHP to support 8byte integers

2001-09-24 Thread Jeroen van Wolffelaar
for the macro's... Unsubscribe from php-cvs while you still can ;-) (just kidding... I hope) Jeroen - Markus On Mon, Sep 24, 2001 at 09:13:35AM +0200, Jeroen van Wolffelaar wrote : On Sun, 23 Sep 2001 [EMAIL PROTECTED] wrote: Hey, it's open source, go for it dude. Let us know. :-) I

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Fw: Bumping PHP to support 8byteintegers

2001-09-24 Thread Jeroen van Wolffelaar
that IF it is going to be implemented, it should be a compiler option to choose what the type of integer needs to be: long, long long, or something else... With proper use of macro's that would mean 1 single #define. --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP

[PHP-DEV] Bug in autoconf report

2001-09-25 Thread Jeroen van Wolffelaar
./ltconfig: ./ltconfig: No such file or directory configure: error: libtool configure failed (indeed, 'ltconfig' doesn't exist) Also note that I didn't ever succesfully build PHP directly from CVS - I didn't have libtool 1.4 till yesterday --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A

Re: [PHP-DEV] Bug in autoconf report

2001-09-25 Thread Jeroen van Wolffelaar
- Original Message - From: [EMAIL PROTECTED] To: Jeroen van Wolffelaar [EMAIL PROTECTED] Cc: PHP Development List [EMAIL PROTECTED] Sent: Tuesday, September 25, 2001 7:46 PM Subject: Re: [PHP-DEV] Bug in autoconf report On Tue, 25 Sep 2001, Jeroen van Wolffelaar wrote: [jeroen

Re: [PHP-DEV] Bug in autoconf report

2001-09-25 Thread Jeroen van Wolffelaar
On Tue, 25 Sep 2001, Jeroen van Wolffelaar wrote: snip Note: after I solved that warning about automake libtool not being in the same dir, the error remainded the same. (I copied the automake executable to the same dir as the libtool executable) Ok, but it's still a problem

[PHP-DEV] Re: zip ext compile problem

2001-09-26 Thread Jeroen van Wolffelaar
Fixed - Original Message - From: Holger Schopohl [EMAIL PROTECTED] Newsgroups: php.dev To: [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 10:51 AM Subject: zip ext compile problem Hi, in the current cvs tree the zip extension have problems to compile with zziplib 0.10.27

Re: [PHP-DEV] Bug in autoconf report

2001-09-30 Thread Jeroen van Wolffelaar
of my Autotools - will try again when that is done. --zak On September 25, 2001 11:53 am, Jeroen van Wolffelaar wrote: On Tue, 25 Sep 2001, Jeroen van Wolffelaar wrote: snip Note: after I solved that warning about automake libtool not being in the same dir, the error remainded

[PHP-DEV] Re: Minor addition to http://php.net/anoncvs.php?

2001-10-01 Thread Jeroen van Wolffelaar
Does anyone object to me modifying the anoncvs.php webpage to include the following note? Does anyone have anything to add - Jeroen? :) There's a typo in it, but that's not what you meant :-) I wouldn't name that SuSE thing, it's way to specific for indicating that something DOESN'T work. I'd

[PHP-DEV] Fw: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c

2001-10-18 Thread Jeroen van Wolffelaar
Resent. The discussion isn't closed yet, and this is important, since it will be already in 4.1.0 --Jeroen - Original Message - From: Jeroen van Wolffelaar [EMAIL PROTECTED] To: Andi Gutmans [EMAIL PROTECTED] Cc: PHP cvs [EMAIL PROTECTED] Sent: Wednesday, October 10, 2001 8:46 PM Subject

  1   2   >