Re: [PHP-DEV] list abuse
- Original Message - From: "Andrey Hristov" <[EMAIL PROTECTED]> To: "Paul G" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, August 02, 2004 4:18 AM Subject: Re: [PHP-DEV] list abuse > Paul G wrote: > > folks, > > > > would someone with ml admin privs take a look and, if present, remove an @tgpwizards.com e-mail address subscription? the user has apparently put a sender confirmation script in place that bombards me (and i'm sure others as well) with confirmation requests. needless to say, it gets very old very fast. > > > > paul > > Last time I looked at the message it does spoof the original address and is being > sent from an unknown server. it is unlikely it does so intentionally. mail coming from the list has internals@ listed as the to: address, which the script obviously doesn't sanity check. regardless of whether this is malicious, the dude needs to go. paul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] list abuse
Paul G wrote: folks, would someone with ml admin privs take a look and, if present, remove an @tgpwizards.com e-mail address subscription? the user has apparently put a sender confirmation script in place that bombards me (and i'm sure others as well) with confirmation requests. needless to say, it gets very old very fast. paul Last time I looked at the message it does spoof the original address and is being sent from an unknown server. Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] list abuse
folks, would someone with ml admin privs take a look and, if present, remove an @tgpwizards.com e-mail address subscription? the user has apparently put a sender confirmation script in place that bombards me (and i'm sure others as well) with confirmation requests. needless to say, it gets very old very fast. paul
RE: [PHP-DEV] PHP 5.0.1
Yep will do. Dmitry should be back tomorrow. At 09:37 PM 8/1/2004 +0200, David Kingma wrote: He's on holiday, so it might take some time. But please wait with the release until the fixes are merged. David -Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED] Sent: Sunday, August 01, 2004 6:41 PM To: Edin Kadribasic; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] PHP 5.0.1 Good call. Will wait for Dmitry to respond. At 12:38 PM 8/1/2004 +0200, Edin Kadribasic wrote: >I saw Dmitry commit several fixes to SOAP extension but I didn't see >them merged. Maybe they should be. > >Edin >- Original Message - >From: "Andi Gutmans" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Sunday, August 01, 2004 2:43 AM >Subject: [PHP-DEV] PHP 5.0.1 > > > > As I mentioned about a week ago, I'd like to roll 5.0.1 (mainly due > > to the auth bug) and some other fixes. > > I was thinking of rolling this minor release tomorrow or Tuesday. If > > you have any bug fixes you'd like to make in, please let me know. > > There's no problem with delaying it somewhat more... > > Andi > > > > -- > > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, > > visit: http://www.php.net/unsub.php > > > > > > > >-- >PHP Internals - PHP Runtime Development Mailing List To unsubscribe, >visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GOTO operator
if you have a look at a parser generated for PHP (eg. this - quite large file) http://cvs.php.net/co.php/pear/HTML_Template_Flexy/Flexy/Tokenizer.php?r=1.51 The original Java/C# stuff does switch/case, In PHP due to the fact you have to evaluate each switch, it used to be quite slow, I ended up replacing it with variable function calls, which even with PHP's penalty on calling functions was faster. I suspect variable goto's would have made this code increadibly fast, in comparison. You can do parsers using switch/case or $function, but unfortunatly they are slow.. Regards Alan David Chen wrote: "Michael Walter" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Another possibility, possibly more concise, would be to introduce a "scoped" keyword (or similar) in the spirit of "global": scoped $foo; might make $foo's destructor be called at the end of the current scope (whether left by a return statement or by an exception). Note that this only solves one part of the problem which could be summarized as "resource management". I'm not sure about generated code - did someone already post an example where goto might be useful in that case or did I miss that one? Considering that some don't accept exceptions to be a valid alternative to gotos, I don't think they'll accept a clearly OOP solution. And yes, I'm also still waiting for a code-generation example, but I guess we'll just assume that gotos are useful there (I use JavaCC, a Java-based top-down generator, so yes there's a lot of recursion but it looks pretty clean to me). David Chen -- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request: Support for a memory_limit exploit paper needed
Hi, The package includes a description how the test works. It basicly consists of compiling PHP on your normal platform: f.e. OpenBSD Apache2 CGI. You should just add --enable-memory-limit to your standard configure line and turn register_globals on. The rest is all explained in the package. Is there any chance enabling mbstring will affect the results of the tests? As far as I experimented in the past, it will unlikely do. Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request: Support for a memory_limit exploit paper needed
Hello Stefan, basically you want to explain everybody how to use those millions of unpatched servers. marcus Sunday, August 1, 2004, 2:33:04 PM, you wrote: > Hi, > I know that this is maybe a little bit off-topic, but I assume that most > people on this list are used to compile PHP just for testing purposes. > I am currently planning to write a paper about the memory_limit security > bug that was announced last month. Actually the paper will explain in > detail what the bug is and how it can be exploited to execute arbitrary > code. > The paper itself will be written because a few people requested it, a > lot of media reported it as a buffer overflow (which is completely > wrong) and just because I need some training in writing papers for > university. > So if anyone here would like to support me writing this paper just grab > a copy of http://security.e-matters.de/mlxdebug.tgz > This package has some special patches in it (for PHP 4.3.2-4.3.7) that > write debug output for every emalloc/efree/erealloc and > php_register_variable_ex call into a file within /tmp. > The package includes a description how the test works. It basicly > consists of compiling PHP on your normal platform: f.e. OpenBSD Apache2 > CGI. You should just add --enable-memory-limit to your standard > configure line and turn register_globals on. The rest is all explained > in the package. > Stefan Esser > PS: those debug files would help me a lot to proof that a few things are > easier than one thinks. -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Lamenting PHP's streaming support...
php-general@ can answer your question... -sterling On Sun, 01 Aug 2004 16:28:18 -0400, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi everyone, > > I'm trying to write some serious parsing applications in PHP. I find myself > frequently lamenting the 4GL-like support for buffered streams. I'd rather a full > fledged streaming API with stream handles (or objects) like you get in mature 3GL > languages like C and Java. > > I'm making do with the single character-stream buffer available to me in the "output > buffer." I wrap this stream in classes that emulate distinct character streams by > saving the current output buffer, clearing the output buffer for the new virtual > stream, and then restoring the original output buffer when the virtual stream is > closed. > > This works, but it costs in overhead and requires repeatedly creating string objects > to store old buffers and then rewriting those objects back to the output buffer. > This is less than ideal from both a performance standpoint and a complexity > standpoint (and an increased potential for wierd errors). > > I'm not too concerned about the performance issues of these virtual buffers because > I can architect the application so that it minimizes these switches. However, I > find myself (so far) unable to architect around another serious performance issue. > > I'm having to create a new string for each character sequence that I write to the > output buffer. I'd rather just copy the substring of the document being parsed > directly to the output buffer. Object creation is an expensive activity when > thousands of objects needed to be created for a single page hit. > > All I need to deal with this problem is a new PHP function: > > ob_write($string, $start, $length) > > This would write the characters in substr($string, $start, $length) to the output > buffer without creating an intermediate string object. > > Is there anything on the horizon that would give me the kind of streaming support > I'm looking for? > > Thanks for your help! > ~joe > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- ..II.. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Lamenting PHP's streaming support...
Hi everyone, I'm trying to write some serious parsing applications in PHP. I find myself frequently lamenting the 4GL-like support for buffered streams. I'd rather a full fledged streaming API with stream handles (or objects) like you get in mature 3GL languages like C and Java. I'm making do with the single character-stream buffer available to me in the "output buffer." I wrap this stream in classes that emulate distinct character streams by saving the current output buffer, clearing the output buffer for the new virtual stream, and then restoring the original output buffer when the virtual stream is closed. This works, but it costs in overhead and requires repeatedly creating string objects to store old buffers and then rewriting those objects back to the output buffer. This is less than ideal from both a performance standpoint and a complexity standpoint (and an increased potential for wierd errors). I'm not too concerned about the performance issues of these virtual buffers because I can architect the application so that it minimizes these switches. However, I find myself (so far) unable to architect around another serious performance issue. I'm having to create a new string for each character sequence that I write to the output buffer. I'd rather just copy the substring of the document being parsed directly to the output buffer. Object creation is an expensive activity when thousands of objects needed to be created for a single page hit. All I need to deal with this problem is a new PHP function: ob_write($string, $start, $length) This would write the characters in substr($string, $start, $length) to the output buffer without creating an intermediate string object. Is there anything on the horizon that would give me the kind of streaming support I'm looking for? Thanks for your help! ~joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GOTO operator
--- Sterling Hughes <[EMAIL PROTECTED]> wrote: > also, when you start quoting djikstra in a php context, you've > lost. > > goto is fine, fight the power! s/quoting djikstra/mentioning state machines/ also s/quoting djikstra/agonising about the algorithmic efficiency of goto versus switch/ Not that I fully believe the above substitutions, but you see the point. Currently -0.25 on goto. regards, Cris ___ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.0.1
At 22:37 01/08/2004, David Kingma wrote: He's on holiday, so it might take some time. He should be back from his vacation tomorrow... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.0.1
He's on holiday, so it might take some time. But please wait with the release until the fixes are merged. David -Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED] Sent: Sunday, August 01, 2004 6:41 PM To: Edin Kadribasic; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] PHP 5.0.1 Good call. Will wait for Dmitry to respond. At 12:38 PM 8/1/2004 +0200, Edin Kadribasic wrote: >I saw Dmitry commit several fixes to SOAP extension but I didn't see >them merged. Maybe they should be. > >Edin >- Original Message - >From: "Andi Gutmans" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Sunday, August 01, 2004 2:43 AM >Subject: [PHP-DEV] PHP 5.0.1 > > > > As I mentioned about a week ago, I'd like to roll 5.0.1 (mainly due > > to the auth bug) and some other fixes. > > I was thinking of rolling this minor release tomorrow or Tuesday. If > > you have any bug fixes you'd like to make in, please let me know. > > There's no problem with delaying it somewhat more... > > Andi > > > > -- > > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, > > visit: http://www.php.net/unsub.php > > > > > > > >-- >PHP Internals - PHP Runtime Development Mailing List To unsubscribe, >visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: implementation of islamic (hijri) calendar for Calendar extension
> 6) How is Hijri pronounced? Is the j hard like english-"Jump", soft like spanish-"Juego", or silent? Just curious on that one... It's like the g in edge. It comes from "El Hijra", the exodus of Muhamed the Islamic prophet :) didou -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] get_defined_constants()
Dear List, i was using the get_defined_constants function the first time today and sadly for me i read in the man-pages that it displays _all_ defined constants. Wouldn't it make sense to implement a function like get_user_defined_constants which would only display those constants define()ed by the user during the development time? If it's not worth a function maybe an parameter would be nice, like // return an array of constants defined by the user using define(); get_defined_constants(C_USER) // return an array with all defined constants get_defined_constants(C_ALL) This would also apply to the functions get_defined_functions and get_defined_vars. Maybe there is already a way to figure such things out, but i haven't found anything in the man-pages. I would be glad to know if something alike exists, or if not, why it wouldn't make sense. Thanks in advance, Nathan PS: Please CC me, as i'm not on the list -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GOTO operator
"Michael Walter" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Another possibility, possibly more concise, would be to introduce a > "scoped" keyword (or similar) in the spirit of "global": > >scoped $foo; > > might make $foo's destructor be called at the end of the current scope > (whether left by a return statement or by an exception). > > Note that this only solves one part of the problem which could be > summarized as "resource management". I'm not sure about generated code - > did someone already post an example where goto might be useful in that > case or did I miss that one? Considering that some don't accept exceptions to be a valid alternative to gotos, I don't think they'll accept a clearly OOP solution. And yes, I'm also still waiting for a code-generation example, but I guess we'll just assume that gotos are useful there (I use JavaCC, a Java-based top-down generator, so yes there's a lot of recursion but it looks pretty clean to me). David Chen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: implementation of islamic (hijri) calendar for Calendar extension
> these is my contribution to implement islamic (hijri) calendar. > > Waiting for your suggestions. > Without knowing the internals of the hijri calender here are a few generic suggestions: 1) Consider using zend_parse_parameters rather than zend_get_parameters, it'll help furture readability. 2) Rather than combining month/day/year into astring for returning from jdtohijri() consider returning them as an array of values, as string-OR-array depending on optional flag parameter, or return the component pieces by-ref. 3) What's the maximum length of a hijri date string? If it's 10 like the gregorian calender MM/DD/, then you need to make your temporary buffer be char[11] to hold the terminating NULL. 3a) When dealing with a short buffer it's a good idea to use snprintf() to be absolutely certain you don't overrun. Since you'll be estrdup()ing this call (in RETURN_STRING()) later on anyway, you could just use spprintf() here and pass the return in with a duplicate parameter of 0, but that's splitting hairs. 3b) It'll also avoid an extra strlen() in RETURN_STRING() if you capture the legnth output of sprintf() and pass it into RETURN_STRINGL(). 4) To avoid potential namespace conflicts, it'd help to prefix the internal methods you define in hijri.c with something uniqing (i.e.: php_cal_hijri_SdnToHijri(), php_cal_hijri_HijriToSdn), or speicfy them as 'static' if they will only be used within their local object file. 5) Internal method names should be all lowercase with underscores used for word boundaries. i.e.: SdnToHijri => std_to_hijri. studlyCaps is meant for object method names exported to userspace. 6) How is Hijri pronounced? Is the j hard like english-"Jump", soft like spanish-"Juego", or silent? Just curious on that one... -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.0.1
Good call. Will wait for Dmitry to respond. At 12:38 PM 8/1/2004 +0200, Edin Kadribasic wrote: I saw Dmitry commit several fixes to SOAP extension but I didn't see them merged. Maybe they should be. Edin - Original Message - From: "Andi Gutmans" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, August 01, 2004 2:43 AM Subject: [PHP-DEV] PHP 5.0.1 > As I mentioned about a week ago, I'd like to roll 5.0.1 (mainly due to the > auth bug) and some other fixes. > I was thinking of rolling this minor release tomorrow or Tuesday. If you > have any bug fixes you'd like to make in, please let me know. There's no > problem with delaying it somewhat more... > Andi > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] implementation of islamic (hijri) calendar for Calendar extension
Hi
these is my contribution to implement islamic (hijri) calendar.
Waiting for your suggestions.
diff -N -u -r source/php-4.3.8/ext/calendar/calendar.c
compiled/php-4.3.8/ext/calendar/calendar.c
--- source/php-4.3.8/ext/calendar/calendar.c2003-08-28 21:01:24.0 +0100
+++ compiled/php-4.3.8/ext/calendar/calendar.c 2004-07-20 15:00:00.0 +0100
@@ -44,6 +44,8 @@
PHP_FE(jewishtojd, NULL)
PHP_FE(jdtofrench, NULL)
PHP_FE(frenchtojd, NULL)
+ PHP_FE(jdtohijri, NULL)
+ PHP_FE(hijritojd, NULL)
PHP_FE(jddayofweek, NULL)
PHP_FE(jdmonthname, NULL)
PHP_FE(easter_date, NULL)
@@ -81,6 +83,7 @@
CAL_JULIAN,
CAL_JEWISH,
CAL_FRENCH,
+ CAL_HIJRI,
CAL_NUM_CALS
};
typedef long int (*cal_to_jd_func_t)(int month, int day, int year);
@@ -101,7 +104,8 @@
{ "Gregorian", "CAL_GREGORIAN", GregorianToSdn, SdnToGregorian, 12, 31,
MonthNameShort, MonthNameLong },
{ "Julian", "CAL_JULIAN", JulianToSdn, SdnToJulian, 12, 31, MonthNameShort,
MonthNameLong },
{ "Jewish", "CAL_JEWISH", JewishToSdn, SdnToJewish, 13, 30, JewishMonthName,
JewishMonthName },
- { "French", "CAL_FRENCH", FrenchToSdn, SdnToFrench, 13, 30, FrenchMonthName,
FrenchMonthName }
+ { "French", "CAL_FRENCH", FrenchToSdn, SdnToFrench, 13, 30, FrenchMonthName,
FrenchMonthName },
+ { "Hijri", "CAL_HIJRI", HijriToSdn, SdnToHijri, 13, 30, HijriMonthName,
HijriMonthName }
};
/* For jddayofweek */
@@ -109,7 +113,7 @@
/* For jdmonthname */
enum { CAL_MONTH_GREGORIAN_SHORT, CAL_MONTH_GREGORIAN_LONG,
CAL_MONTH_JULIAN_SHORT, CAL_MONTH_JULIAN_LONG, CAL_MONTH_JEWISH,
- CAL_MONTH_FRENCH };
+ CAL_MONTH_FRENCH,CAL_MONTH_HIJRI };
/* for heb_number_to_chars */
static char alef_bet[25] = "0àáâãäåæçèéëìîðñòôö÷øùú";
@@ -120,6 +124,7 @@
REGISTER_LONG_CONSTANT("CAL_JULIAN", CAL_JULIAN, CONST_CS|CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("CAL_JEWISH", CAL_JEWISH, CONST_CS|CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("CAL_FRENCH", CAL_FRENCH, CONST_CS|CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT("CAL_HIJRI", CAL_HIJRI, CONST_CS|CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("CAL_NUM_CALS", CAL_NUM_CALS,
CONST_CS|CONST_PERSISTENT);
/* constants for jddayofweek */
REGISTER_LONG_CONSTANT("CAL_DOW_DAYNO", CAL_DOW_DAYNO,
CONST_CS|CONST_PERSISTENT);
@@ -132,6 +137,7 @@
REGISTER_LONG_CONSTANT("CAL_MONTH_JULIAN_LONG", CAL_MONTH_JULIAN_LONG,
CONST_CS|CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("CAL_MONTH_JEWISH",
CAL_MONTH_JEWISH, CONST_CS|CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("CAL_MONTH_FRENCH",
CAL_MONTH_FRENCH, CONST_CS|CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT("CAL_MONTH_HIJRI",
CAL_MONTH_HIJRI, CONST_CS|CONST_PERSISTENT);
/* constants for easter calculation */
REGISTER_LONG_CONSTANT("CAL_EASTER_DEFAULT",
CAL_EASTER_DEFAULT, CONST_CS | CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("CAL_EASTER_ROMAN",
CAL_EASTER_ROMAN, CONST_CS | CONST_PERSISTENT);
@@ -557,6 +563,48 @@
}
/* }}} */
+/* {{{ proto string jdtohijri(int juliandaycount)
+ Converts a julian day count to a islamic(hijri) calendar date */
+PHP_FUNCTION(jdtohijri)
+{
+ pval **julday;
+ int year, month, day;
+ char date[10];
+
+ if (zend_get_parameters_ex(1, &julday) != SUCCESS) {
+ WRONG_PARAM_COUNT;
+ }
+
+ convert_to_long_ex(julday);
+
+ SdnToHijri(Z_LVAL_PP(julday), &year, &month, &day);
+ sprintf(date, "%i/%i/%i", month, day, year);
+
+ RETURN_STRING(date, 1);
+}
+/* }}} */
+
+/* {{{ proto int hijritojd(int month, int day, int year)
+ Converts a islamic(hijri) calendar date to julian day count */
+PHP_FUNCTION(hijritojd)
+{
+ pval **year, **month, **day;
+ int jdate;
+
+ if (zend_get_parameters_ex(3, &month, &day, &year) != SUCCESS) {
+ WRONG_PARAM_COUNT;
+ }
+
+ convert_to_long_ex(month);
+ convert_to_long_ex(day);
+ convert_to_long_ex(year);
+
+ jdate = HijriToSdn(Z_LVAL_PP(year), Z_LVAL_PP(month), Z_LVAL_PP(day));
+
+ RETURN_LONG(jdate);
+}
+/* }}} */
+
/* {{{ proto mixed jddayofweek(int juliandaycount [, int mode])
Returns name or number of day of week from julian day count */
PHP_FUNCTION(jddayofweek)
@@ -631,6 +679,10 @@
SdnToFrench(Z_LVAL_PP(julday), &year, &month, &day);
monthname = FrenchMonthName[month];
break;
+ case CAL_MONTH_HIJRI: /* hijri month */
+ SdnToHijri(Z_LVAL_PP(julday), &year, &month, &day);
+ monthname = HijriMonthName[month];
+ break;
default:
[PHP-DEV] Request: Support for a memory_limit exploit paper needed
Hi, I know that this is maybe a little bit off-topic, but I assume that most people on this list are used to compile PHP just for testing purposes. I am currently planning to write a paper about the memory_limit security bug that was announced last month. Actually the paper will explain in detail what the bug is and how it can be exploited to execute arbitrary code. The paper itself will be written because a few people requested it, a lot of media reported it as a buffer overflow (which is completely wrong) and just because I need some training in writing papers for university. So if anyone here would like to support me writing this paper just grab a copy of http://security.e-matters.de/mlxdebug.tgz This package has some special patches in it (for PHP 4.3.2-4.3.7) that write debug output for every emalloc/efree/erealloc and php_register_variable_ex call into a file within /tmp. The package includes a description how the test works. It basicly consists of compiling PHP on your normal platform: f.e. OpenBSD Apache2 CGI. You should just add --enable-memory-limit to your standard configure line and turn register_globals on. The rest is all explained in the package. Stefan Esser PS: those debug files would help me a lot to proof that a few things are easier than one thinks. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.0.1
I saw Dmitry commit several fixes to SOAP extension but I didn't see them merged. Maybe they should be. Edin - Original Message - From: "Andi Gutmans" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, August 01, 2004 2:43 AM Subject: [PHP-DEV] PHP 5.0.1 > As I mentioned about a week ago, I'd like to roll 5.0.1 (mainly due to the > auth bug) and some other fixes. > I was thinking of rolling this minor release tomorrow or Tuesday. If you > have any bug fixes you'd like to make in, please let me know. There's no > problem with delaying it somewhat more... > Andi > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GOTO operator
At 15:45 31/07/2004, Derick Rethans wrote: Exceptions are an OO thing, and it makes NO sense to use them in procedural code. Goto is a good thing here. Can you explain why it makes no sense to use them in procedural code? It makes perfect sense for me, and they render 100.0% of the examples shown on internals@ redundant... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
