Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions
I haven't been following this whole discussion.
However, the function names should follow the coding standards and be named
something like date_sunrise(), date_sunset() (or whatever other prefix
makes sense).
Andi
At 05:02 PM 2/6/2003 +0200, Moshe Doron wrote:
Zeev Suraski [EMAIL PROTECTED] wrote in message
5.1.0.14.2.20030206161428.050f11c0@localhost">news:5.1.0.14.2.20030206161428.050f11c0@localhost...
At 13:36 06/02/2003, moshe doron wrote:
b. sunrise()
c. sunset()
Hrm, what are these functions?
* {{{ proto mixed sunrise(mixed time[, double latitude][, double
longitude][, double zenith,][ double gtm_offset][, int format])
Returns time of sunrise for a given day location */
/* {{{ proto mixed sunset(mixed time[, double latitude][, double
longitude][, double zenith,][ double gtm_offset][, int format])
Returns time of sunset for a given day location */
i wrote those functions as infrastructures for the calendar extension for
returning optionaly the 'real' date depending on the calendar native e.g,
the jewish dayes are come by the night mean the day is changed on sunset.
the information is is also used for other religion tasks (e.g, jewish and
arabic prayer times), for astronomy studies and for travelers design.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions
Andi Gutmans [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I haven't been following this whole discussion. However, the function names should follow the coding standards and be named something like date_sunrise(), date_sunset() (or whatever other prefix makes sense). here is part of my replay to Leon Atkinson: Also, shouldn't sunrise() and sunset() be cal_sunrise() and cal_sunset()? well, since sunset() sunrise() have aspects more then cal_* related, i thought the right place is standard. new astronomy extension, or linking against exisint lib, 'll be overhead since i want use it on the calendar extension, that is build by default on VC. moshe --
Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions
At 12:47 PM 2/7/2003 +0200, moshe doron wrote: Andi Gutmans [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I haven't been following this whole discussion. However, the function names should follow the coding standards and be named something like date_sunrise(), date_sunset() (or whatever other prefix makes sense). here is part of my replay to Leon Atkinson: Also, shouldn't sunrise() and sunset() be cal_sunrise() and cal_sunset()? well, since sunset() sunrise() have aspects more then cal_* related, i thought the right place is standard. new astronomy extension, or linking against exisint lib, 'll be overhead since i want use it on the calendar extension, that is build by default on VC. Even functions in standard have a prefix. Only ancient ones don't and we didn't fix them for BC reasons. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions
well, what about sun_set(), sun_rise()? moshe -- Andi Gutmans [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 12:47 PM 2/7/2003 +0200, moshe doron wrote: Andi Gutmans [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I haven't been following this whole discussion. However, the function names should follow the coding standards and be named something like date_sunrise(), date_sunset() (or whatever other prefix makes sense). here is part of my replay to Leon Atkinson: Also, shouldn't sunrise() and sunset() be cal_sunrise() and cal_sunset()? well, since sunset() sunrise() have aspects more then cal_* related, i thought the right place is standard. new astronomy extension, or linking against exisint lib, 'll be overhead since i want use it on the calendar extension, that is build by default on VC. Even functions in standard have a prefix. Only ancient ones don't and we didn't fix them for BC reasons. Andi
Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions
On Fri, 7 Feb 2003 14:37:32 +0200 moshe doron [EMAIL PROTECTED] wrote: well, what about sun_set(), sun_rise()? date_sunset() (or date_sun_set ;) ) if it is defined in the date/time section or cal_sunset() if it is defined within the calendar extension. my 2cts, hth pierre -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions
I don't think this is good idea. date_sunset(), date_sunrise() are better. Andrey - Original Message - From: moshe doron [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 07, 2003 2:37 PM Subject: Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions well, what about sun_set(), sun_rise()? moshe -- Andi Gutmans [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 12:47 PM 2/7/2003 +0200, moshe doron wrote: Andi Gutmans [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I haven't been following this whole discussion. However, the function names should follow the coding standards and be named something like date_sunrise(), date_sunset() (or whatever other prefix makes sense). here is part of my replay to Leon Atkinson: Also, shouldn't sunrise() and sunset() be cal_sunrise() and cal_sunset()? well, since sunset() sunrise() have aspects more then cal_* related, i thought the right place is standard. new astronomy extension, or linking against exisint lib, 'll be overhead since i want use it on the calendar extension, that is build by default on VC. Even functions in standard have a prefix. Only ancient ones don't and we didn't fix them for BC reasons. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions
+1 for date_sunset and date_sunrise. -- Regards. M.CHAILLAN Nicolas [EMAIL PROTECTED] www.WorldAKT.com Hébergement de sites internets. Andrey Hristov [EMAIL PROTECTED] a écrit dans le message de news: 016f01c2cea6$ccc6f880$[EMAIL PROTECTED] I don't think this is good idea. date_sunset(), date_sunrise() are better. Andrey - Original Message - From: moshe doron [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 07, 2003 2:37 PM Subject: Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions well, what about sun_set(), sun_rise()? moshe -- Andi Gutmans [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 12:47 PM 2/7/2003 +0200, moshe doron wrote: Andi Gutmans [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I haven't been following this whole discussion. However, the function names should follow the coding standards and be named something like date_sunrise(), date_sunset() (or whatever other prefix makes sense). here is part of my replay to Leon Atkinson: Also, shouldn't sunrise() and sunset() be cal_sunrise() and cal_sunset()? well, since sunset() sunrise() have aspects more then cal_* related, i thought the right place is standard. new astronomy extension, or linking against exisint lib, 'll be overhead since i want use it on the calendar extension, that is build by default on VC. Even functions in standard have a prefix. Only ancient ones don't and we didn't fix them for BC reasons. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions
At 02:37 PM 2/7/2003 +0200, moshe doron wrote: well, what about sun_set(), sun_rise()? I hope you're kidding. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re[2]: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions
Hi, Friday, February 7, 2003, 10:45:31 PM, you wrote: AH I don't think this is good idea. AH date_sunset(), date_sunrise() are better. AH Andrey AH - Original Message - AH From: moshe doron [EMAIL PROTECTED] AH To: [EMAIL PROTECTED] AH Sent: Friday, February 07, 2003 2:37 PM AH Subject: Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions well, what about sun_set(), sun_rise()? moshe -- Andi Gutmans [EMAIL PROTECTED] wrote in message AH [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 12:47 PM 2/7/2003 +0200, moshe doron wrote: Andi Gutmans [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I haven't been following this whole discussion. However, the function names should follow the coding standards and AH be named something like date_sunrise(), date_sunset() (or whatever other AH prefix makes sense). here is part of my replay to Leon Atkinson: Also, shouldn't sunrise() and sunset() be cal_sunrise() and AH cal_sunset()? well, since sunset() sunrise() have aspects more then cal_* related, AH i thought the right place is standard. new astronomy extension, or linking against exisint lib, 'll be AH overhead since i want use it on the calendar extension, that is build by default AH on VC. Even functions in standard have a prefix. Only ancient ones don't and we didn't fix them for BC reasons. Andi time_sunset time_sunrise would make more sense :) -- regards, Tom -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] patch for pear/PECL/fribidi
I've fixed compilation errors for the fribidi extension (see attached
patch). It's tested on Linux and Windows with fribidi 0.10.4 and 0.11.-0
(current dev). Please commit.
To solve compilation problems on Windows you need a fribidi.lib _with_ char
sets.
Regards, Kai
Index: fribidi.c
===
RCS file: /repository/pear/PECL/fribidi/fribidi.c,v
retrieving revision 1.33
diff -u -r1.33 fribidi.c
--- fribidi.c 31 Dec 2002 16:06:37 - 1.33
+++ fribidi.c 7 Feb 2003 14:45:38 -
@@ -32,7 +32,7 @@
#include fribidi/fribidi.h
/* The fribidi guys dont believe in BC */
-#ifdef FRIBIDI_CHAR_SET_UTF8
+#ifndef FRIBIDI_CHARSET_UTF8
#define FRIBIDI_CHARSET_UTF8FRIBIDI_CHAR_SET_UTF8
#define FRIBIDI_CHARSET_ISO8859_6 FRIBIDI_CHAR_SET_ISO8859_6
#define FRIBIDI_CHARSET_ISO8859_8 FRIBIDI_CHAR_SET_ISO8859_8
@@ -212,7 +212,11 @@
out_string = (char *) emalloc(sizeof(char)*alloc_len);
+#if FRIBIDI_MAJOR_VERSION == 0 FRIBIDI_MINOR_VERSION = 10
fribidi_log2vis(u_logical_str, len, base_dir, u_visual_str,
position_L_to_V_list, position_V_to_L_list, embedding_level_list);
+#else
+ fribidi_log2vis(NULL, u_logical_str, len, base_dir, u_visual_str,
+position_L_to_V_list, position_V_to_L_list, embedding_level_list);
+#endif
/* convert back to original char set */
switch(Z_LVAL_PP(charset)) {
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Timezone functions
OK, so I've had a couple of replies stating interest in this. How do I go about contributing my code? Best Wishes David Gillies San Jose Costa Rica --- David Gillies [EMAIL PROTECTED] wrote: My module exposes a single function, timezone_offset(). From the module code: proto int timezone_offset(string zfVal,int timeVal) __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Problems with new CVS account
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! Error, CVS operation failed (used program TortoiseCVS) 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? Uwe -- 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: php4 . cant compile . ext/standard/var.c
Make sure you have the correct set of working files: For PHP 5: cvs co php5 For PHP 4.3-dev cvs co -r PHP_4_3 php4 Checking out php4 HEAD is not supported. --Wez. On Sat, 8 Feb 2003, Lukas Schroeder wrote: hi wez, i'm currently trying to compile cvs head. there are quite a lot of missing definitions in there. one of them is Z_OBJ_HANDLER + get_class_name in /ext/standard/var.c the failing code has been committed by you on 2003-02-01 (http://marc.theaimsgroup.com/?l=php-cvsm=104407155303062w=2) could you please check whether you have forgotten to commit these definitions? (i already tried a clean checkout; to no avail. regards, -lukas -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Files Headers
From our files haeders: | available at through the world-wide-web at | Shouldn't the first 'at' be dropped? marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] e-commerse recommendations engine, beta testers.
If I am misusing this list incorrectly, I apologize. I am the author of MSession and the PHP msession extension. I just finished up productizing a recommendations engine for e-commerce sites. I need a few sites with a good customer history willing to be my testers and example sites. I'll help you set it up (it should be really easy) and help you tune it. A preliminary user guide can be found at http://www.mohawksoft.com/cgr.pdf Please do not respond on this list as I doubt people would appreciate the extra traffic. Thanks for your time. Mark. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] bug #22103
Hello, About this bug, I can backport the new functions wroten for the new gd. But I do not know if it is allowed to add new functions to the current HEAD or 4_3_0. The new functions fix only the filled ellipse/circle problem, the new filled_arc cannot be fixed without adding a lot of things to the libgd. Should I go ahead for both 4.3 and head ? pierre -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions
On Fri, 07 Feb 2003 14:48:50 +0200 Andi Gutmans [EMAIL PROTECTED] wrote: At 02:37 PM 2/7/2003 +0200, moshe doron wrote: well, what about sun_set(), sun_rise()? me too :) We are not going to have the whole sun extension (which is what this naming convention suggests) :) If ever these two functions would get implemented (which I think is a good idea to have such algorithm) then they would be something like date_sunrise() and date_sunset(). Much more logic, no? +1 for date_sunrise() and date_sunset() -- Maxim Maletsky [EMAIL PROTECTED] I hope you're kidding. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug #22103
On Sat, 8 Feb 2003, Pierre-Alain Joye wrote: Hello, About this bug, I can backport the new functions wroten for the new gd. But I do not know if it is allowed to add new functions to the current HEAD or 4_3_0. The new functions fix only the filled ellipse/circle problem, the new filled_arc cannot be fixed without adding a lot of things to the libgd. Should I go ahead for both 4.3 and head ? Feel free.. --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: preg_replace() docs need expliot warning
While I'm..*grossly* against the /e switch (or eval()s in general) at
all (and its use with tainted sources even moreso), I realize my whinning
and moaning isn't going to change the fact /e and eval() exist and are used.
But here's a thought...
How about a /E switch to preg_replace which would function like /e except
that it temporarily enables safe_mode. Similarly eval() could be extended
with a second parameter that does the same. I realize safe_mode is
generally intended for sysadmins to protect themselves from malicious
content authors, but why not use this functionality at the content level to
protect from malicious clients?
There *might* be a need to have an eval.* version of the safe_mode ini
options to specify how much is (dis)allowed when in eval-safe_mode. I
havn't thought through the implications of doing this, but it seems worth
exploring.
-Pollita
Cross-Posting to php-dev
James E. Flemer [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Just one more example. Even when using double quotes, it
is possible to execute code:
?php
$a = '___! ${`rm -rf /tmp/sess_*`} !___';
$b = preg_replace(/!(.*)!/e, print(\\\1\);, $a);
?
Again, assume $a comes from a tainted source.
-James
On Mon, 3 Feb 2003, James E. Flemer wrote:
A warning about preg_replace() command needs to be added to
the docs page for this command. The preg_replace() command
can use the /e modifier to have the replacement be
eval()d by PHP, just like perl.
There is a high potential for exploitable PHP code if a
programmer uses the /e modifier and does not use quotes
around the back references (backrefs). Without quotes,
arbitrary commands may be executed by using the backtick
operator. Other commands may be executed as well, but are
more difficult, since addslashes() prevents the characters
['\\\0] from being used.
An clear and explicit warning should be added to the doc
page for preg_replace, indicating the backrefs must always
be quoted. Single quotes are preferable, since double
quotes allow variable expansion.
See the messages below for examples of how this may be
exploited. (Assume that $a comes from an untrusted source,
i.e. a get/post/cookie/header variable.)
-James
-- Forwarded message --
Date: Mon, 3 Feb 2003 01:04:23 -0500 (EST)
From: James E. Flemer [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] preg_replace oddity [exploitable]
I found a more evil example:
?php
$a = ___! `rm -rf /tmp/sess_*` !___;
$b = preg_replace(/!(.*)!/e, print(\\1);, $a);
?
This happily executes rm -rf /tmp/sess_*. I will not
give out more examples, but if one examines the code for
addslashes() it is quite obvious what you can an cannot do
here. Thus it is clearly a Bad Thing for someone to use
preg_replace with the /e modifier and not use quotes around
the \\n or $n backrefs.
The docs should be updated to include a very noticeable
warning about this hole. I am contemplating possible
solutions for this problem...
Also as a side note, it does not seem to be possible to use
'echo' as part of the expression, print must be used. (Yes
I know why, just pointing it out.)
-James
On Thu, 30 Jan 2003, James E. Flemer wrote:
Can someone explain what is going on here:
--- foo.php ---
?php
$a = ___! 52); echo(42 !___;
$b = preg_replace(/!(.*)!/e, print(\\1);, $a);
print(\n---\na: $a\nb: $b\n);
?
--- end ---
--- output ---
52
---
a: ___! 52); echo(42 !___
b: ___1___
--- end ---
I understand that one is supposed to use single quotes
around the \\1 in the above preg_replace. But what happens
when they do not? Clearly the echo(42); is not executed,
and it is not printed by print(). Even more interesting is
if you put something like echo(\42 in $a, then you get a
bunch of errors including:
Fatal error - Failed evaluating code:
print( 52); echo(\42 );
It seems like preg_replace() is doing some strange things,
and might be something that could be exploitable if a
remote user can supply the first argument, and the second
argument does not enclose \\n options.
-James
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP4 vs. PECL
Hi all, some extensions included in the PHP_4_3 branch was moved to PECL (fribidi for instance). If I understand right, all commits to the PHP_4_3 branch are for bug fixing for the next 4.* releases. How to handle fixes for moved extensions? Commit twice (PHP_4_3 and pear/PECL) or commit only to pear/PECL? What is with the test cases? For fribidi we have the test cases in HEAD but the extension itselves in PECL. In my opinion both should be in PECL and the ext/whatever dir complete removed in HEAD. Make it sense to move all Windows only extensions (for instance w32api) already to PECL? I think, that someone who is able to build PHP for Windows from sources also can checkout pear/PECL. For future win32 binary releases we can add this extensions from PECL again. Regards, Kai -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
