Re: [PHP-DEV] ?= and %= both work, why not ?php=
On Thu, 2002-04-25 at 15:27, Brinkman, Theodore wrote:
Ok. I have the feeling that I'm going to be making myself a bit unpopular
here with my first post, but I mean no offense or disrespect. I'm just
trying to understand something.
PHP allows ?= if short tags are enabled, or %= if asp-style tags are
enabled, but doesn't allow ?php=. Why? I went so far as to look into the
source and as near as I can tell without getting my hands on a C compiler,
changing it so that the '{opentag}=' format was equivalent to '{opentag}
echo' would take a 2 line patch to one file. I submitted this change as a
feature request in the bug system (#16763), and got the incredibly
informative and helpful response of this was discussed to death on php-dev.
it's not going to happen. 17 minutes later.
I've spent the next 2 days trying to hunt down any mention of it, and having
no luck because searching for ?php=, or ?php= turns up no results. So in
an effort to understand why and how the decision was made to leave a feature
partially implemented, I'm left with no resort except to post here and
probably bring down a can of whoop-ass on myself. My appologies to anyone
who is sick of this being discussed.
That said. Why?
- Theo
One long discussion starts here:
http://marc.theaimsgroup.com/?l=php-devm=100405792100833w=2
It looks like consistency was voted down because someone might
misread ?php=$var to mean ?$php=$var. Which doesn't seem much
worse than the age-old '=' vs. '==' screwup. Anyway, there's the
thread and you should read it and decide whether this needs to
get going again. :)
--
Torben Wilson [EMAIL PROTECTED]
http://www.thebuttlesschaps.com
http://www.hybrid17.com
http://www.inflatableeye.com
+1.604.709.0506
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] exec + safemode
On Wed, 2002-03-13 at 00:13, Stefan Esser wrote: Hi, It is not off topic. Its an annoying bug and I asked around if I oversee something if i change php_escape_shell_cmd to ignore stuff between quotes. (off course checking for escaped quotes within the quotes) Stefan Sorry, I didn't see that question. -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] exec + safemode
On Tue, 2002-03-12 at 07:30, Stefan Esser wrote: Morning, (maybe i am just blind...) I doubt this can be counted as support question *grin* Has anyone of you ever tried to exec a command while in safe_mode? exec (blub); works fine, but it seems impossible to give a param to blub that has spaces in it. Stefan Well, it is sorta off-topic for this list, but hey. :) It's in the bug database: http://bugs.php.net/bug.php?id=15157 Essentially: we know about it, but haven't gotten around to documenting it. If someone would like to fix it, that would probably be the best solution. -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Adding the cpdf textBox function to php
This is what I already submitted as a comment to the cpdf_text function. Maybe you can
include this
simple patch in one of the following releases... it would be great. Here's the text I
submitted as
comment:
Unfortunately there hasn't been anyone else adding the textBox feature to the php CPDF
functions, so
I had to it. ;)
Do the following, in order to get a cpdf_textbox function, so that you don't have to
call the
cpdf_text function for every single line of text you want to print.
Add the following line to php-source-dir/ext/cpdf/php_cpdf.h line 58:
PHP_FUNCTION(cpdf_textbox);
Add the following line to php-source-dir/ext/cpdf/cpdf.c line 96:
PHP_FE(cpdf_textbox, NULL)
Add the code block below to php-source-dir/ext/cpdf/cpdf.c somewhere after the
cpdf_text function
(i.e. line 847)
snip---
/* {{{ proto void cpdf_textbox(int pdfdoc, double x-koor, double y-koor, double
width, double
height, double angle, double linespace, string text [, int alignmode [, float
paragraphspacing [,
int newlinemode]]]);
Output a textbox */
PHP_FUNCTION(cpdf_textbox)
{
pval *argv[11];
int id, type, argc, mode=0;
CPDFdoc *pdf;
CPDFtboxAttr tbattr;
argc = ZEND_NUM_ARGS();
if((argc 8) || (argc 11))
WRONG_PARAM_COUNT;
if (getParametersArray(ht, argc, argv) == FAILURE)
WRONG_PARAM_COUNT;
convert_to_long(argv[0]);
convert_to_double(argv[1]);
convert_to_double(argv[2]);
convert_to_double(argv[3]);
convert_to_double(argv[4]);
convert_to_double(argv[5]);
convert_to_double(argv[6]);
convert_to_string(argv[7]);
id=argv[0]-value.lval;
pdf = zend_list_find(id, type);
if(!pdf || type!=CPDF_GLOBAL(le_cpdf)) {
php_error(E_WARNING, Unable to find identifier %d, id);
RETURN_FALSE;
}
tbattr.alignmode = TBOX_LEFT;
tbattr.NLmode = 0;
tbattr.paragraphSpacing = 0.0;
tbattr.noMark = 0;
switch(argc) {
case 9:
convert_to_long(argv[8]);
tbattr.alignmode = argv[8]-value.lval;
break;
case 10:
convert_to_long(argv[8]);
convert_to_double(argv[9]);
tbattr.alignmode = argv[8]-value.lval;
tbattr.paragraphSpacing = (float) argv[9]-value.dval;
break;
case 11:
convert_to_long(argv[8]);
convert_to_double(argv[9]);
convert_to_long(argv[10]);
tbattr.alignmode = argv[8]-value.lval;
tbattr.paragraphSpacing = (float) argv[9]-value.dval;
tbattr.NLmode = argv[10]-value.lval;
break;
}
cpdf_textBox(pdf,
(float) argv[1]-value.dval,// x
(float) argv[2]-value.dval,// y
(float) argv[3]-value.dval,// width
(float) argv[4]-value.dval,// height
(float) argv[5]-value.dval,// angle
(float) argv[6]-value.dval,// linespace
tbattr,// Attributes prespecified
argv[7]-value.str.val);// Text string
RETURN_TRUE;
}
/* }}} */
snap---
Then recompile php with cpdf support and use the new function.
It has to be called in between the cpdf_begin_text and cpdf_end_text tags
cpdf_textbox(int pdfdoc, double x-koor, double y-koor, double width, double height,
double angle,
double linespace, string text [, int alignmode [, float paragraphspacing [, int
newlinemode]]]);
Notes:
Alignmode aligns the text within the box:
0 -- left (default)
1 -- center
2 -- right
3 -- justify
Newline mode:
if non-zero, NL (\n) is is a line break, if 0 reformatted (default 0)
Have fun with it. It works great for me.
regards,
lars
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug #15937: Call-time pass-by-reference has beendeprecated
On Thu, 2002-03-07 at 11:23, Markus Fischer wrote:
On Thu, Mar 07, 2002 at 08:02:17PM +0100, [EMAIL PROTECTED] wrote :
On Thu, 7 Mar 2002, Andrey Hristov wrote:
You probably do:
$some_len = strlen($some_str);
right.
you do not need to use . Probably $some_str is passed by reference
without .
What do you mean by probably? I mean, the reason for me to use the
call-by-reference is the performance...
I'm not on php-dev, so please reply to my personal adress ;)
The not obvious thing is that references _are not_ faster. It
is was Andi always has told us and it is what people said who
did testing. Testings were posted to this list a while ago
and performance of references was also discussed in the
german php newsgroup. PHP is not C; references are
not like C pointers; they are not faster.
This was my understanding too, until I tested it a few seconds ago. But
when I created a large string and did the following:
?php
error_reporting(E_ALL);
$bigstring = implode(\n,
file('/home/torben/work/phpdoc/en/appendices/reserved.xml'));
function with_ref() {
global $bigstring, $with_ref_len;
$with_ref_len = strlen($bigstring);
}
function without_ref() {
global $bigstring, $without_ref_len;
$without_ref_len = strlen($bigstring);
}
speedtest(array('with_ref', 'without_ref'), 1000);
echo With Ref len: $with_ref_len; Without ref len: $without_ref_len\n;
?
I got:
Warning: Call-time pass-by-reference has been deprecated - argument
passed by value; If you would like to pass it by reference, modify the
declaration of strlen(). If you would like to enable call-time
pass-by-reference, you can set allow_call_time_pass_reference to true in
your INI file. However, future versions may not support this any longer.
in /home/torben/public_html/phptest/__phplist.html on line 22
Running with_ref() 1000 times...
0.064337968826294 seconds
Running without_ref() 1000 times...
18.39444899559 seconds
Results:
with_ref_1: 0.064337968826294
without_ref_2: 18.39444899559
With Ref len: 448490; Without ref len: 448490
...which seems to indicate that under some circumstances passing by
ref is indeed much faster. I could be missing something though--I
haven't had breakfast yet and I'm not too smart in the morning. :)
Cheers,
Torben
--
Torben Wilson [EMAIL PROTECTED]
http://www.thebuttlesschaps.com
http://www.hybrid17.com
http://www.inflatableeye.com
+1.604.709.0506
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP module creation
On Sun, 2002-03-03 at 17:30, topside wrote: Where can I get information/documentation on creating my own PHP modules in C? I basicly just want to use some C functions within PHP - so I figure I can write a PHP module with functions which use the C functions I need. thanks --topside The manual is a good place to start: http://www.php.net/manual/en/zend.php Cheers and happy hacking! Torben -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-QA] Re: 4.2.0 CLI
On Wed, 2002-02-27 at 19:27, Zak Greant wrote: On Wed, 2002-02-27 at 20:23, Yasuo Ohgaki wrote: Jim Winstead wrote: In php.dev Edin Kadribasic [EMAIL PROTECTED] wrote: 1. If you compile CGI binary and then issue 'make install' it will be installed in $PREFIX/bin, then CLI will be put in the same place overwriting it. Any suggestions on what to do in this situation? imho, the cgi binary should get called php.cgi. jim Sound nice to me. +1 Good idea! How about php-cgi instead so that some wacky sysadmin does not think that it is a cgi script and drop it into a cgi-bin directory? :) +1 Also, is using the cli build of PHP going to break any old scripts? --zak -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Help on PHP vs JAVA
On Thu, 2002-02-21 at 01:07, Berlina wrote: Hello to everybody, I need some help for writting a comparison of PHP vs JAVA, and of course, I need that PHP wins ;-D Wins what? For what task? This is quite a nebulous question. And if you've decided which will win before you've done the research, that research won't be worth much, will it? However, here's one place to start: try typing words like 'comparison', 'php', and 'java' together into Google. I just found a pile of articles on the topic in under 3 seconds of looking. Any ideas? Any comparison wrote? Advanced Thanks, F.P. P.S. Please, pick *one* mailing list. This question has nothing to do with either php-dev or php-db. -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable magic quote by default.
On Sat, 2002-02-16 at 18:01, Yasuo Ohgaki wrote: Yasuo Ohgaki wrote: Stefan Esser wrote: magic_quotes_by_default is a nice way to make scripts (written by novices) safer. Unfourtunately mqbd forces you to write unsecure scripts. If you put such scripts onto a server that doesnt have mqbd they are insecure. This is true. I bet many novice writes insecure scripts. It may not be good idea for PHP 4.2 :( I'll add more description to http://www.php.net/manual/en/security.variables.php and try again for PHP5. Hmmm btw... This idea just came to my mind and i don't know if it would be too much overhead, but what about keeping track of what variables got already magically quoted and do not quote them again if the script wants it. This idea sounds nice to me :) The WTF factor for that would be off the scale. Think about how many bug reports about addslashes() not working we'd have to bogusify. -1 Forgot to ask if anyone objects to make magic qoutes off by default for PHP5. Anyone? +1 -- Yasuo Ohgaki -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patches for odbc_execute()
Could someone check these out and commit them (or similar)? At
the moment, odbc_execute() allows any script to view any file
without regard to safe_mode or open_basedir, and also under
certain circumstances can corrupt its parameters. See Bug #15516
for more info. It may be desirable to change this mechanism
entirely, since presently you can't use odbc replaceable params
to enter strings which start and end with quotes.
If these changes are not suitable, could someone email me a
comment explaining why? Thanks...
Index: php_odbc.c
===
RCS file: /repository/php4/ext/odbc/php_odbc.c,v
retrieving revision 1.115
diff -u -r1.115 php_odbc.c
--- php_odbc.c 30 Jan 2002 21:54:54 - 1.115
+++ php_odbc.c 13 Feb 2002 08:52:27 -
@@ -943,12 +943,23 @@
else
ctype = SQL_C_CHAR;
- if (Z_STRVAL_PP(tmp)[0] == '\''
+ if (Z_STRLEN_PP(tmp) 2
+ Z_STRVAL_PP(tmp)[0] == '\''
Z_STRVAL_PP(tmp)[Z_STRLEN_PP(tmp) - 1] == '\'') {
- filename = Z_STRVAL_PP(tmp)[1];
- filename[Z_STRLEN_PP(tmp) - 2] = '\0';
+ filename = estrndup(Z_STRVAL_PP(tmp)[1],
+Z_STRLEN_PP(tmp) - 2);
+ filename[strlen(filename)] = '\0';
-if ((params[i-1].fp = open(filename,O_RDONLY)) == -1) {
+ /* Check for safe mode. */
+ if (PG(safe_mode) (!php_checkuid(filename, NULL,
CHECKUID_CHECK_FILE_AND_DIR))) {
+ RETURN_FALSE;
+ }
+
+ /* Check the basedir */
+ if (php_check_open_basedir(filename TSRMLS_CC)) {
+ RETURN_FALSE;
+ }
+
+ if ((params[i-1].fp = open(filename,O_RDONLY)) == -1) {
php_error(E_WARNING,Can't open file %s,
filename);
SQLFreeStmt(result-stmt, SQL_RESET_PARAMS);
for(i = 0; i result-numparams; i++) {
@@ -957,8 +968,11 @@
}
}
efree(params);
+ efree(filename);
RETURN_FALSE;
}
+
+ efree(filename);
params[i-1].vallen = SQL_LEN_DATA_AT_EXEC(0);
--
Torben Wilson [EMAIL PROTECTED]
http://www.thebuttlesschaps.com
http://www.hybrid17.com
http://www.inflatableeye.com
+1.604.709.0506
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Constants
On Wed, 2002-02-13 at 17:22, Evan Nemerson wrote: I was thinking about putting together a list of constants, their purpose, what version of PHP they initially appeared in, etc. So far, I have figured out a function called REGISTER_LONG_CONSTANT is used, or a constant is defined in the source with a name that has a preceeding PHP_ (eg PHP_RAND_MAX- which is 2^31??? why not 2^32? sorry off the point.) Are there any other ways? Are these ways inaccurate? Please reply to my e-mail address ([EMAIL PROTECTED]). I don't subscribe to this list. Evan Nemerson I've committed a list of (almost) all predefined constants and classes to the phpdoc cvs. There is a bit more work to be done before the list makes it into the online manual, but you can either check out phpdoc from cvs, or view it online here: http://cvs.php.net/co.php/phpdoc/en/appendices/predefined.xml?r=1.3 Warning: it's a long list. There are over a thousand predefined constants, all told. :) Comments welcome (from Evan and from anybody else reading this...) -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #15415: [VOTE] case sensitive function/classnames for PHP5
On Wed, 2002-02-06 at 17:34, Chris Shiflett wrote: NO I think he meant to vote using the voting form in the bug database. ;) Torben On 7 Feb 2002 [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Operating system: ANY PHP version: 4.1.1 PHP Bug Type: Feature/Change Request Bug description: [VOTE] case sensitive function/class names for PHP5 Please vote YES if you *LIKE* case sensitive function/class/constant names under PHP5. Please vote NO if you *DO NOT LIKE* case sensitive function/class/constant names under PHP5. Thank you. PS: I'm creating this report(vote) as a result of Zend Engine 2 and php-dev list discussion. Don't cheat, please :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Lists
On Tue, 2002-02-05 at 15:34, John Donagher wrote: This has probably been mentioned before, but I think the naming of php-dev is way misleading. It's funny that people get so ripped when someone sends an off-topic question to this list. Someone who doesn't read the descriptions may very well take php-dev to mean PHP development. This is ambiguous; it doesn't make any distinction between developing with php and developing the language itself. Whining about people not reading the descriptions won't change it; get over it. Before taking a huge step like making the list moderated or (gasp!) We don't (typically) whine about them not reading the descriptions--but if they don't, they should be prepared to be told to go elsewhere. As you say, however, the poster often does not have English as a first language and so may not have understood the instructions, which needs to be taken into account when replying to the OT posts. We do have some people who display abrasive and arrogant ways of dealing with people they perceive to be below their own ability level, but that's life. -1 to moderate/close the list, and -1 to change the name. Torben -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #15370: Class Visibility methods
From: [EMAIL PROTECTED]
Operating system: All
PHP version: 4.1.1
PHP Bug Type: Feature/Change Request
Bug description: Class Visibility methods
Would it be much work, to implement a class visibility
architecture, like in c++/java etc., like
class Foo
{
private var $bar;
protected var $boo;
public function SetBar($newBar) { $this-bar = $newBar; }
}
?
Regards,
Lars Wilhelmsen
--
Edit bug report at http://bugs.php.net/?id=15370edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15370r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15370r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15370r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15370r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15370r=support
Expected behavior: http://bugs.php.net/fix.php?id=15370r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15370r=notenoughinfo
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #15370 Updated: Class Visibility methods
ID: 15370
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Duplicate
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 4.1.1
New Comment:
Couldn't find any. Could you please give me a url, or two?
--larsw
Previous Comments:
[2002-02-04 14:33:14] [EMAIL PROTECTED]
PLEASE, search the bug-db. There is already a bugreport for this.
[2002-02-04 14:28:40] [EMAIL PROTECTED]
Would it be much work, to implement a class visibility
architecture, like in c++/java etc., like
class Foo
{
private var $bar;
protected var $boo;
public function SetBar($newBar) { $this-bar = $newBar; }
}
?
Regards,
Lars Wilhelmsen
--
Edit this bug report at http://bugs.php.net/?id=15370edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strange behaviour in arrays
On Mon, 2002-02-04 at 03:41, Martin Jansen wrote: Taking the following script: ?php $array = array(foo = true, bar = false ); print_r($array); ? The result of print_r is: Array ( [foo] = 1 [bar] = ) Shouldn't false in the array definition result to 0 instead of nothing? - Martin No--the string representation of boolean false is ''. You could, I suppose, force the conversion to int in the assignment: ?php $array = array(foo = true, bar = (int)false); print_r($array); ? Torben -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Developer Seeking To Help
On Sun, 2002-02-03 at 16:29, Chris Shiflett wrote: On Sun, 3 Feb 2002, Manuel Lemos wrote: Manuel, Thank you for the suggestion. If you would be so kind, I have a few questions. 1) How can I change the status of a bug? For example, I was looking through session bugs (since that's most likely where I could contribute the easiest) and read a bug #14227. This bug is bogus and is the result of the submitter not understanding HTTP and the Set-Cookie header enough. I would love to be able to act as a mediater of sorts, so that the bogus bugs can be filtered to save developers some time. I can even give elaborate explanations in the beginning to make sure people know why it's bogus. :) You need to either be a developer (i.e. have a cvs account) or be the original bug poster to modify a bug's status. As a developer, this is done from the 'Developer' tab in the bug db interface. 2) If a bug is legitimate, and I know how to fix it, how do I go about doing this? Must I receive permission for a CVS account? How does one gain the trust to be able to commit changes? One common way is to create your patches and post them either to the php-dev list or as a comment (prefered) in the bug db, and if they are useful, the dev team will have a good reason to give you cvs access. (Use unified diff format for patches.) Alternatively, you could just ask for a cvs account and hope you get one--if your patches suck, it will eventually be revoked, I guess. :) 3) How do I know if someone is working on a bug? If it is open status, can I safely assume it's not been investigated by a member of the PHP development team? If someone is *really* into working on a bug themselves, it will be 'Assigned' in the bug db to that person's account id. If the bug's status is not 'Assigned' (sometimes 'Analyzed' is used here too) then you should be able to safely engage the bug in combat. Thanks for the information. Chris Hope it helps, Torben -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] XOR or bit manupulation
On Sat, 2002-02-02 at 18:25, Mika Toewe wrote: Hi Is there anything that can manipulate a variable bit by bit? If have a variable $x that has to switch between two values. It doesn't matter if it is true or false, 0 and 255 or whatever. Normally the easiest way would be to use xor to have the variable switch between both states but I couldn't find anything like that in the reference. Does PHP support such kind of bit manipulation? Or does anybody know another way to have the variable switch on an easy way? I know that it is possible with several if...thens but I'm looking for an easier and faster way. Thanks for your answers and help. Mika First off, please don't crosspost to all these lists. The list for general questions in PHP is [EMAIL PROTECTED]; the lists this question was posted to are for the PHP quality assurance team, the documentation team, and the development team, respectively. You can find a list of the available mailing lists, their purposes, and an easy-to-use subscription form at: http://www.php.net/mailing-lists.php Second, the knowledge you seek is in the manual, under 'Language Reference|Operators|Bitwise operators': http://www.php.net/manual/en/language.operators.bitwise.php Hope this helps, Torben -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for sapi/roxen/roxen.c
A fix for the bug number 13231 11699.
makes the roxen support compile.
(replaces the error() calls with php_error() );
Regards,
--
Lars Wilhelmsen,
Software Engineer
[EMAIL PROTECTED]
begin 666 roxen.c.diff
M*BHJ('!HTT+C$N,2]S87!I+W)O5N+W)O5N+F,)1G)I($]C= Q,B Q
M,SHU-CHS-R R,# QBTM+2!P:' M-XQ+C$M;F5W+W-ADOF]X96XOF]X
M96XN8PE4:'4@2F%N(#,Q(# P.C$U.C0W(#(P,#(**BHJ*BHJ*BHJ*BHJ*BHJ
MBHJ*B V,3@L-C(Y(HJ*BH*( @(%134DU,4U]151#2@I.PH@( H@( @
M:68H8W5RF5N=%]T:')E860@/3T@=A?V5L9B@I*0HA( @(!EG)OB@B
M4$A0-Y);G1EG!R971EBT^G5N.B!4FEE9!T;R!R=6X@82!02% MV-R
M:7!T(9R;VT@82!02% @(@H@( D@()C86QL8F%C:R$B*3L*( @(=E=%]A
M;Q?87)GR@B4$A0-Y);G1EG!R971EBT^G5N(BP@87)GRP@(B53)6TE
M3R4J(BP@)G-CFEP=P*( )( @( @(9R97%U97-T7V1A=$L(9M5]F
M9%]O8FHL(9D;VYE7V-A;QB86-K*3L*( @(EF*1O;F5?8V%L;)A8VLM
M/G1Y4@(3T@4$E+15]47T953D-424].*2 *(2 @( @97)R;W(H(E!(4#0N
M26YT97)PF5T97(M/G)U;CH@0F%D(%R9W5M96YT(#0L(5X5C=5D(9U
M;F-T:6]N+EQN(BD[B @(!02%!?3$]#2RA42$E3*3L@+RH@3F5E9!T;R!L
M;V-K(AEF4@;W(@F5UVEN9R!T:4@V%M92!O8FIE8W0@;6EG:'0@8V%U
MV4*( )2 @( @( J('!R;V)L96US(EN(-H86YG:6YG('-T=69F(EN
M('1H870@;V)J96-T(HOB @(VEF;F1E9B!23UA%3E]54T5?6E13BTM+2 V
M,3@L-C(Y(TM+2T*( @(%134DU,4U]151#2@I.PH@( H@( @:68H8W5R
MF5N=%]T:')E860@/3T@=A?V5L9B@I*0HA( @(!P:'!?97)R;W(H15]7
M05).24Y'+ B4$A0-Y);G1EG!R971EBT^G5N.B!4FEE9!T;R!R=6X@
M82!02% MV-R:7!T(9R;VT@82!02% @(@H@( D@()C86QL8F%C:R$B*3L*
M( @(=E=%]A;Q?87)GR@B4$A0-Y);G1EG!R971EBT^G5N(BP@87)G
MRP@(B53)6TE3R4J(BP@)G-CFEP=P*( )( @( @(9R97%U97-T7V1A
M=$L(9M5]F9%]O8FHL(9D;VYE7V-A;QB86-K*3L*( @(EF*1O;F5?
M8V%L;)A8VLM/G1Y4@(3T@4$E+15]47T953D-424].*2 *(2 @( @AP
M7V5RF]R*$5?5T%23DE.1RP@(E!(4#0N26YT97)PF5T97(M/G)U;CH@0F%D
M(%R9W5M96YT(#0L(5X5C=5D(9U;F-T:6]N+EQN(BD[B @(!02%!?
M3$]#2RA42$E3*3L@+RH@3F5E9!T;R!L;V-K(AEF4@;W(@F5UVEN9R!T
M:4@V%M92!O8FIE8W0@;6EG:'0@8V%UV4*( )2 @( @( J('!R;V)L
M96US(EN(-H86YG:6YG('-T=69F(EN('1H870@;V)J96-T(HOB @(VEF
M;F1E9B!23UA%3E]54T5?6E13BHJ*BHJ*BHJ*BHJ*BHJ*@HJ*BH@-C4Y+#8V
M-2 J*BHJB @(J96-T*')A
M=U]F9T^=2YO8FIE8W0I.PH@( @(!I9BAF9 ]/2 M,2D*(2 @( @(!E
MG)OB@B4$A0-Y);G1EG!R971EBT^G5N.B!M5]F9!O8FIE8W0@;F]T
M(]P96X@;W(@;F]T(%N($9$+EQN(BD[B @( @(%1(25,M/FUY7V9D(#T@
M9F0[B @(!](5LV4*( @( @5$A)4RT^;7E?9F0@/2 P.PHM+2T@-C4Y
M+#8V-2 M+2TMB @(J96-T
M*')A=U]F9T^=2YO8FIE8W0I.PH@( @(!I9BAF9 ]/2 M,2D*(2 @( @
M(!P:'!?97)R;W(H15]705).24Y'+ B4$A0-Y);G1EG!R971EBT^G5N
M.B!M5]F9!O8FIE8W0@;F]T(]P96X@;W(@;F]T(%N($9$+EQN(BD[B @
M( @(%1(25,M/FUY7V9D(#T@9F0[B @(!](5LV4*( @( @5$A)4RT^
+;7E?9F0@/2 P.PH`
`
end
--
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]
[PHP-DEV] Re: Content Management
[EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Does anyone know of any group who has put together a web content management architecture for a large site? Hi. But an answer to your question is: eZ Publish (GPL Licensed). http://developer.ez.no/ regards, Lars Wilhelmsen -- 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] Content Management
On Tue, 2002-01-29 at 22:35, [EMAIL PROTECTED] wrote: Does anyone know of any group who has put together a web content management architecture for a large site? Two things: first, this list is for development of PHP, not in PHP (you want php-general for that), and second, HTML emails will get you spanked on these lists. :) Now that the net cop thing is done, I would suggest checking out phpnuke and postnuke (search on google or something). I've not used either, but you can find a comparison review at http://www.phpauthority.com/article.php?sid=9 ...if the colour scheme doesn't give you a seizure. :) Good luck, Torben -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- 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]
[PHP-DEV] EXTENSIONS file XSLT
The EXTENSIONS file doesn't appear to have been updated to mention the new xslt extension which replaced Sablotron. Could someone with sufficient karma commit this? Thanks. Index: EXTENSIONS === RCS file: /repository/php4/EXTENSIONS,v retrieving revision 1.29 diff -u -r1.29 EXTENSIONS --- EXTENSIONS 10 Jan 2002 00:38:05 - 1.29 +++ EXTENSIONS 28 Jan 2002 21:41:00 - @@ -370,7 +370,7 @@ --- EXTENSION: sablot PRIMARY MAINTAINER: Sterling Hughes [EMAIL PROTECTED] -MAINTENANCE: Maintained +MAINTENANCE: Obsolete STATUS: Experimental SINCE: 4.0.3 --- @@ -430,6 +430,12 @@ PRIMARY MAINTAINER: Thies C. Arntzen [EMAIL PROTECTED] MAINTENANCE: Maintained STATUS: Working +--- +EXTENSION: xslt +PRIMARY MAINTAINER: Sterling Hughes [EMAIL PROTECTED] +MAINTENANCE: Maintained +STATUS: Experimental +SINCE: 4.1.0 --- EXTENSION: yaz PRIMARY MAINTAINER: Adam Dickmeiss [EMAIL PROTECTED] -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- 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] Re: Bug #3830 Updated: Function to timeout/break offa function
On Mon, 2002-01-28 at 15:08, Wico de Leeuw wrote:
Hiya,
thats not true... register_tcik_function is for between 2 instructions
(lines?) and will not break into a long takeing mysql_select
(correct me if i'm wrong)
But i still think that such a function will improve php
Greetz,
Wico
I believe you are correct--I reopened this in the Bug Database
a little while ago.
Cheers,
Torben
At 21:54 28-1-2002 +, Bug Database wrote:
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at
http://bugs.php.net/?id=3830edit=2
ID: 3830
Updated by: yohgaki
Reported By: [EMAIL PROTECTED]
Old Status: Analyzed
Status: Closed
Bug Type: Feature/Change Request
Operating System: linux
PHP Version: 4.0 Beta 4 Patch Level 1
New Comment:
register_tick_function() can be used.
Previous Comments:
[2000-07-31 22:49:52] [EMAIL PROTECTED]
well, could be quite nice
[2000-03-14 11:27:16] [EMAIL PROTECTED]
Hiya,
i did like to see a function wich breaks into another when it take to
long:
?
funtion Hour () {
sleep 3600;
}
// break after say 2 secs
$timeout = Timeout_function(hour(), 2);
if ($timeout) {
// function took to long
} else {
// function compledet normal
}
?
--
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]
--
Torben Wilson [EMAIL PROTECTED]
http://www.thebuttlesschaps.com
http://www.hybrid17.com
http://www.inflatableeye.com
+1.604.709.0506
--
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] Question: Should exit() print out the integer exit-status?
Zeev Suraski writes:
At 15:18 20/12/2001, Yasuo Ohgaki wrote:
Nobody should complain about BC changes if changes are notified
early enough and there is alternative way to do the same thing.
IMHO. (This has been done for some features such as track vars ;)
That's a very impractical statement in my opinion... Breaking
compatibility hurts (almost) regardless of when you announce you're going
to break it. Users would still have to go over their code and fix it.
What I *really* fail to understand is the gain we get by modifying exit()'s
behavior, as opposed to adding a new function or adding a new $silent
argument. Giving a WFF to several people? Consistency with other
languages that have nothing to do with the Web environment (which is why we
got so little complaints about this over *5* years)?
What would the problem be with the attached patch (against PHP
4.1.0rc3)? This patch meets the following criteria:
o Backward compatibility is maintained, since strings passed to
exit() will still be output. BC will only break in those instances
where something depends on the fact that PHP will not set the exit
code when exiting with a string--very unlikely. This should keep
the BC people happy and not introduce any new surprises.
o No new functions need to be created, and no new arguments need to
be added to exit(). This should keep the No New Functions or
Arguments For Small Functionalities people happy.
o exit() will now behave like other PHP functions wrt its argument
type. Whereas a PHP programmer expects the calls
somefunc('2') and somefunc(2) to behave identically, exit() breaks
this mould. This patch rectifies that, so that exit('2') and
exit(2) will now behave the same. Again, the only time BC is broken
is in cases where something depends on i.e. exit('2') outputting
'0'--which is likely to be *very* rare since it doesn't make any
sense.
Of course, the criterium which this patch does not fulfil is that of
killing the output from exit(), which would break BC. However, it
would still be possible to add an option second argument to exit()
which would suppress this output, but be off by default.
I see this as very similar to the case sensitivity issue, even though this
is obviously on a much smaller scale. It's possibly a bad decision that
was made 5 years ago, but it was made all the same. Since it does *not*
have far-reaching negative implications, it shouldn't be changed.
Zeev
The current behaviour may not be earthshatteringly bad, but it does
break language consistency and so introduces a higher memory load on
the user (gotta remember that everything works the same 'cept
exit()). It also tends to keep some people (OK, at least me) from
doing much non-web scripting in PHP since it's a fairly fundamental
bit of functionality which is something of a bother to work
around. Not a major bother, but enough.
My point is this: we don't break, lose, or complicate anything with
this patch, and it makes the language more consistent and generally
usable.
Just my $0.02 for the night.
Torben
--- zend_execute.bakWed Dec 19 16:19:44 2001
+++ zend_execute.c Wed Dec 19 16:37:29 2001
@@ -2379,11 +2379,16 @@
case ZEND_EXIT:
if (opline-op1.op_type != IS_UNUSED) {
zval *ptr;
+ zval exit_code;
ptr = get_zval_ptr(opline-op1, Ts,
EG(free_op1), BP_VAR_R);
- if (Z_TYPE_P(ptr) == IS_LONG) {
- EG(exit_status) = Z_LVAL_P(ptr);
- }
+
+ exit_code = *ptr;
+ zval_copy_ctor(exit_code);
+ convert_to_long(exit_code);
+
+ EG(exit_status) = Z_LVAL_P(exit_code);
+
zend_print_variable(ptr);
FREE_OP(opline-op1, EG(free_op1));
}
--
Torben Wilson [EMAIL PROTECTED]
http://www.thebuttlesschaps.com
http://www.hybrid17.com
http://www.inflatableeye.com
+1.604.709.0506
--
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]
[PHP-DEV] Bug #14619: Number doesn't fit the data type
From: [EMAIL PROTECTED] Operating system: AIX (probably not OS specific) PHP version: 4.1.0 PHP Bug Type: Compile Warning Bug description: Number doesn't fit the data type zend_alloc.c, line 635.22: 1506-419 (E) Converting 2576696087 to type long int does not preserve its value. zend_alloc.c, line 643.22: 1506-419 (E) Converting 4219631580 to type long int does not preserve its value. Using 32 bit long these values won't fit. Changing the declaration on line 36 of Zend/zend_alloc.h from 'long magic' to 'unsigned long magic,' or lowering the constant codes might be worth considering. Yours, lars-owe -- Edit bug report at: http://bugs.php.net/?id=14619edit=1 -- 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] Question: Should exit() print out the integer exit-status?
[EMAIL PROTECTED] writes:
On Thu, 20 Dec 2001, Zeev Suraski wrote:
This patch is fine with me, but as it would still print out the error
message, I think it's not fine with some other people...
This solves nothing IMO. The problem is that exit (5) displays '5', and
that must be fixed.
Derick
This does solve a problem, just not that one. :) I did actually
address that one as well in my message, with the suggestion of an
optional second parameter to suppress the output. Something like:
void exit($status[, $suppress_output = false])
Existing scripts would behave as they always have but coders would
have the option to not have any output generated. My personal
suggestion would be to do this, actually:
void exit($status[, $suppress_output = true])
void die($status[, $suppress_output = false])
...but that first one would reintroduce the BC problem. :)
Anyway, the whole output/not output thing isn't that important to me
personally; I was more concerned about the inconsistency in the
argument usage. At least with that patch it would be
language-consistent, even if one doesn't like the output.
At 16:29 20/12/2001, Lars Torben Wilson wrote:
Zeev Suraski writes:
At 15:18 20/12/2001, Yasuo Ohgaki wrote:
Nobody should complain about BC changes if changes are notified
early enough and there is alternative way to do the same thing.
IMHO. (This has been done for some features such as track vars ;)
That's a very impractical statement in my opinion... Breaking
compatibility hurts (almost) regardless of when you announce you're going
to break it. Users would still have to go over their code and fix it.
What I *really* fail to understand is the gain we get by modifying
exit()'s
behavior, as opposed to adding a new function or adding a new $silent
argument. Giving a WFF to several people? Consistency with other
languages that have nothing to do with the Web environment (which is
why we
got so little complaints about this over *5* years)?
What would the problem be with the attached patch (against PHP
4.1.0rc3)? This patch meets the following criteria:
o Backward compatibility is maintained, since strings passed to
exit() will still be output. BC will only break in those instances
where something depends on the fact that PHP will not set the exit
code when exiting with a string--very unlikely. This should keep
the BC people happy and not introduce any new surprises.
o No new functions need to be created, and no new arguments need to
be added to exit(). This should keep the No New Functions or
Arguments For Small Functionalities people happy.
o exit() will now behave like other PHP functions wrt its argument
type. Whereas a PHP programmer expects the calls
somefunc('2') and somefunc(2) to behave identically, exit() breaks
this mould. This patch rectifies that, so that exit('2') and
exit(2) will now behave the same. Again, the only time BC is broken
is in cases where something depends on i.e. exit('2') outputting
'0'--which is likely to be *very* rare since it doesn't make any
sense.
Of course, the criterium which this patch does not fulfil is that of
killing the output from exit(), which would break BC. However, it
would still be possible to add an option second argument to exit()
which would suppress this output, but be off by default.
I see this as very similar to the case sensitivity issue, even though this
is obviously on a much smaller scale. It's possibly a bad decision that
was made 5 years ago, but it was made all the same. Since it does *not*
have far-reaching negative implications, it shouldn't be changed.
Zeev
The current behaviour may not be earthshatteringly bad, but it does
break language consistency and so introduces a higher memory load on
the user (gotta remember that everything works the same 'cept
exit()). It also tends to keep some people (OK, at least me) from
doing much non-web scripting in PHP since it's a fairly fundamental
bit of functionality which is something of a bother to work
around. Not a major bother, but enough.
My point is this: we don't break, lose, or complicate anything with
this patch, and it makes the language more consistent and generally
usable.
Just my $0.02 for the night.
Torben
--- zend_execute.bakWed Dec 19 16:19:44 2001
+++ zend_execute.c Wed Dec 19 16:37:29 2001
@@ -2379,11 +2379,16 @@
case ZEND_EXIT:
if (opline-op1.op_type != IS_UNUSED) {
zval *ptr;
+ zval exit_code;
ptr = get_zval_ptr(opline-op1,
Ts, EG(free_op1), BP_VAR_R);
- if (Z_TYPE_P(ptr) == IS_LONG
Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?
Vlad Krupin writes: Uh? You probably do not want to see the returned code printed anyway (unless you are debugging and are lazy to get it in any other way). Chances are that the codes returned by exit() won't make much sense to anyone but the one who develops the code, and it's not too difficult to do: echo 1; exit(1); There are ways to print out a message right before we exit. There aren't too many ways to return an error code. I can think of a very good reason why we might want the error code returned, but not prnted (in fact, a lot of reasons), and we don't have this functionality. Hence, at least if parameter to exit() is an int, we should just return the error code, *not* print it. I know, nobody has called a vote, but I thought I'd express my opinion in the form of a vote anyway, since somebody asked:) Vlad +1 Jani Taskinen wrote: background information: http://bugs.php.net/bug.php?edit=1id=11008 http://bugs.php.net/bug.php?edit=1id=14574 exit() function is broken. Fixing the broken behaviour is the only real solution, IMO. One solution: - When passed argument is string: print out this string - When passed argument is integer: Don't print it, use it as exit-status This is what is the expected behaviour is and I really can't think of any good examples where this would fail. Nobody ever gave any. And to get the REAL users (not only Zeev's opinion) I'm sending this also to php-general. From manual: The exit() function terminates execution of the script. It prints status just before exiting. If status is an integer, that value will be used as exit-status. This can be understood in many ways. If the status is integer, it is used as exit-status..but it's not clear that it's ALSO printed out which is simply buggy behaviour. Now, if general concencus amongs the users of PHP is that it should also print out the exit-status when it's an integer then 'shell_exit()' function should be added. --Jani -- 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] -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- 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] Question: Should exit() print out the integer exit-status?
Zeev Suraski writes: At 14:04 19/12/2001, [EMAIL PROTECTED] wrote: Two ways to fix it then, either update the manual, or fix exit(). I go for the last one then. Ppl who relied on the undocumented feature then, did simply the wrong thing. Only the documentation was wrong to begin with! A documentation bug should not become a feature, especially when it never worked that way, so anybody who actually used this function saw that it was behaving differently. Zeev Well, from another point of view, both were wrong. :) The manual documented behaviour which didn't exist, so it was wrong. In another sense, the code behaved in a fashion which had a very high WTF factor, so it couild be called 'wrong' too. An easy way to set and check the exit status of a PHP script would make a lot of life a hell of a lot easier. -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- 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] Question: Should exit() print out the integer exit-status?
Zeev Suraski writes: exit_with_status(), silent_exit(), quiet_exit(), etc. etc. Something should fit :) Yeah, you could do that. But then, why don't we have a 'c_compatible_dirname()' now, instead of a proper dirname() patch which has been proven to break BC? Because the new version is Correct--at least according to programming tradition. (Sorry, Manuel.) A function named exit(), which accepts an argument, is just _expected_ to set the exit status (assuming the coder has coded in other languages before). A better solution IMHO would be to make exit() do the right thing and create a new function named something like 'exit_print()' which behaves the way the current exit() does. Besides, as Vlad pointed out it's a _hell_ of a lot easier to do the print-out thing in userland than it is to set the exit status. :) Torben At 14:49 19/12/2001, Lars Torben Wilson wrote: Zeev Suraski writes: At 14:04 19/12/2001, [EMAIL PROTECTED] wrote: Two ways to fix it then, either update the manual, or fix exit(). I go for the last one then. Ppl who relied on the undocumented feature then, did simply the wrong thing. Only the documentation was wrong to begin with! A documentation bug should not become a feature, especially when it never worked that way, so anybody who actually used this function saw that it was behaving differently. Zeev Well, from another point of view, both were wrong. :) The manual documented behaviour which didn't exist, so it was wrong. In another sense, the code behaved in a fashion which had a very high WTF factor, so it couild be called 'wrong' too. An easy way to set and check the exit status of a PHP script would make a lot of life a hell of a lot easier. -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- 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] -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- 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] Question: Should exit() print out the integer exit-status?
Zeev Suraski writes: Even if you repeat it may times, it still wouldn't be a bug. When I wrote exit() I intended exit() to print out its argument, regardless of its type. It's been behaving like this since PHP 3.0.0 alpha 1, because it was supposed to behave like that. The doc team got it wrong, and misdocumented it. Only this May. Before that, the docs were correct. Logically, though, the fact that a member of the doc team replaced the correct docs with an erroneous description doesn't imply that the function behaved correctly to start with. Scripts who will break are scripts that terminate after printing out an error code. I have at least one such script, and I'm pretty sure that more exist, especially in automated environments. Zeev At 15:08 19/12/2001, Jani Taskinen wrote: Fixing a bug by adding new function that behaves correctly is really not the way to go. Could you please give me nice example what kind of scripts break if the integer is not printed out? --Jani On Wed, 19 Dec 2001, Zeev Suraski wrote: exit_with_status(), silent_exit(), quiet_exit(), etc. etc. Something should fit :) At 14:49 19/12/2001, Lars Torben Wilson wrote: Zeev Suraski writes: At 14:04 19/12/2001, [EMAIL PROTECTED] wrote: Two ways to fix it then, either update the manual, or fix exit(). I go for the last one then. Ppl who relied on the undocumented feature then, did simply the wrong thing. Only the documentation was wrong to begin with! A documentation bug should not become a feature, especially when it never worked that way, so anybody who actually used this function saw that it was behaving differently. Zeev Well, from another point of view, both were wrong. :) The manual documented behaviour which didn't exist, so it was wrong. In another sense, the code behaved in a fashion which had a very high WTF factor, so it couild be called 'wrong' too. An easy way to set and check the exit status of a PHP script would make a lot of life a hell of a lot easier. -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- 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] -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- 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] Question: Should exit() print out the integer exit-status?
Zeev Suraski writes: At 15:15 19/12/2001, Lars Torben Wilson wrote: Zeev Suraski writes: exit_with_status(), silent_exit(), quiet_exit(), etc. etc. Something should fit :) Yeah, you could do that. But then, why don't we have a 'c_compatible_dirname()' now, instead of a proper dirname() patch which has been proven to break BC? Because the new version is Correct--at least according to programming tradition. (Sorry, Manuel.) A function named exit(), which accepts an argument, is just _expected_ to set the exit status (assuming the coder has coded in other languages before). A better solution IMHO would be to make exit() do the right thing and create a new function named something like 'exit_print()' which behaves the way the current exit() does. Besides, as Vlad pointed out it's a _hell_ of a lot easier to do the print-out thing in userland than it is to set the exit status. :) It's not about whether or not it's easy or not - we're not at the stage of designing the language behavior from scratch now... There's a fundamental difference between dirname(), which is supposed to answer the question of 'what directory does this file sit in?' - and there's only one correct answer. The old dirname() had a bug, period. What a function named exit() does is entirely up to us. Of course, it's expected to terminate execution by its very name, but it may do other things too, such as set the OS error code, print out an error message, etc. Perhaps I have not explained my position. I don't care whether it outputs the exit status as a string--as long as it sets the error code appropriately *as well*. By appropriately, I mean that 'exit(boo);' would a) print 'boo' and b) return with exit status 0, but 'exit(1boo)'; would a) print '1boo' and b) return with exit status 1. This would be consistent with PHP's type conversion rules, and would also tend to behave in the way that the programmer expects it to. exit(), since its introduction to PHP, had two usages: - Terminate script execution - Terminate script execution with an error message Changing it is out of the question, as: - Thousands of scripts rely on it - There's no 'right' or 'wrong' here, unlike dirname(). I personally find the current behavior to be much more useful, as I don't use PHP to create shell scripts, and I do use it to create Web apps. exit(reason) makes good sense to me. Changing it to be overloaded is a possibility, but a bad one IMHO, because: - Some scripts rely on it to behave as it always did (I have one such script) - It's inconsistent I agree. That's why I think it should a) Print out whatever it is given as an argument, and b) Set the exit status to whatever its argument evaluates to as an int. This is not overriding, per se. It's just being language-consistent. Drawbacks to using a new name: - Slightly longer to type (negligible) - Not obvious to somebody with a background of other languages that support exit(exit_code). This may be an issue, but I don't think it outweighs the advantages of staying with the current behavior. Zeev -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- 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] Question: Should exit() print out the integer exit-status?
Zeev Suraski writes:
Perhaps I have not explained my position. I don't care whether it
outputs the exit status as a string--as long as it sets the error code
appropriately *as well*.
AFAIR, this is the way it works now...
Zeev
If that were the case I would expect the last 'echo $?' in this
example to output '5' instead of '0'. But I just sank another couple
of scotches so this could be screwed and I'm not gonna think about it
again till morning. :)
See you then,
Torben
Script started on Wed Dec 19 07:05:56 2001
~/work/php-4.1.0RC3
shanna% cat test-exist-status.php
#!/usr/local/bin/php -q
?php /* -*- mode: c++; minor-mode: font -*- */
error_reporting(E_ALL);
$version = phpversion();
echo PHP $version\n;
$zero_foo = 'foo';
$five_foo = '5foo';
echo \$zero_foo: string: $zero_foo; integer: . (int) $zero_foo . \n;
echo \$five_foo: string: $five_foo; integer: . (int) $five_foo . \n;
$argv = $HTTP_SERVER_VARS['argv'];
if (empty($argv[1])) {
$argv[1] = false;
}
switch ($argv[1]) {
case '1':
echo Exiting with \$sero_foo == $zero_foo...\n;
exit($zero_foo);
break;
case '5':
echo Exiting with \$five_foo == $five_foo...\n;
exit($five_foo);
break;
default:
echo Exiting with constant 2...\n;
exit(2);
}
?
~/work/php-4.1.0RC3
shanna% ./test-exist-status.php 1
PHP 4.1.0RC3
$zero_foo: string: foo; integer: 0
$five_foo: string: 5foo; integer: 5
Exiting with constant 2...
2
~/work/php-4.1.0RC3
shanna% echo $?
2
~/work/php-4.1.0RC3
shanna% echo $?./test-exist-status.php 1
PHP 4.1.0RC3
$zero_foo: string: foo; integer: 0
$five_foo: string: 5foo; integer: 5
Exiting with $sero_foo == foo...
foo
~/work/php-4.1.0RC3
shanna% echo $?
0
~/work/php-4.1.0RC3
shanna% ./test-exist-status.php 5
PHP 4.1.0RC3
$zero_foo: string: foo; integer: 0
$five_foo: string: 5foo; integer: 5
Exiting with $five_foo == 5foo...
5foo
~/work/php-4.1.0RC3
shanna% echo $?
0
~/work/php-4.1.0RC3
shanna% exit
Script done on Wed Dec 19 07:06:16 2001
--
Torben Wilson [EMAIL PROTECTED]
http://www.thebuttlesschaps.com
http://www.hybrid17.com
http://www.inflatableeye.com
+1.604.709.0506
--
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] Question: Should exit() print out the integer exit-status?
Vlad Krupin writes:
Lars Torben Wilson wrote:
Perhaps I have not explained my position. I don't care whether it
outputs the exit status as a string--as long as it sets the error code
appropriately *as well*. By appropriately, I mean that 'exit(boo);'
would a) print 'boo' and b) return with exit status 0, but
'exit(1boo)'; would a) print '1boo' and b) return with exit status
1. This would be consistent with PHP's type conversion rules, and
would also tend to behave in the way that the programmer expects it
to.
Yikes. This is way worse than overloading. In school they called that
data-coupling, I think. In real life this is called a hack.
Sorry, but a -1 on this.
Vlad
No, it's called loose typing. See
http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
We have a language here which considers the integer value of 5 to
be 5, and an exit() construct which ignores that.
For instance:
shanna% php -q
?php exit('5'); ?
5
shanna% echo $?
0
shanna% php -q
?php exit(5); ?
5
shanna% echo $?
5
How much sense does this make? None, as far as I can see.
What I'm proposing is to make the behaviour of exit() _not_ depend on
the type of its argument. At present if the argument is an integer
exit() prints it and sets the error status, but if it's any other
type, exit() just prints it and doesn't set the exit status. This is
more complex than my proposal: no matter what the argument is, print
out its string value, and set the exit status to its integer value.
AFAICT exit() is currently broken wrt how it handles the type of its
argument.
--
Torben Wilson [EMAIL PROTECTED]
http://www.thebuttlesschaps.com
http://www.hybrid17.com
http://www.inflatableeye.com
+1.604.709.0506
--
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] Question: Should exit() print out the integer exit-status?
Vlad Krupin writes:
Please, understand me correctly - I have nothing against exit() working
in the same manner regardless of the type of the argument. I would love
to see that. The problem is that (1) it already accepts a string, and
has been working that way for a long time, so this can't go away, and
(2) there is no other way (AFAIK) to set exit codes, and some people
need that. Those are somewhat contradicting requirements, so we might
have to compromise.
I do have a problem with the compromise you proposed though, if I
understood you correctly. You suggest using something like
exit(1boo)
And having exit() parse the first digit out. That's BAD. What if
It's not parsing anything. It's just converting to int using the well
documented rules of string to integer conversion which have existed in
the language for years. The language is pretty much impossible to use
without running into implicit type conversions--it's designed for
it. That's why the current behaviour of exit() breaks consistency.
Please, check out the Type Juggling section of the manual. This
shouldq not a special case, but it currently is treated as one. It
should behave the way the rest of the language behaves.
someone already uses exit(123, 456 servers are unavailable); or
something similar. How should we parse something like that? Chances
Again, we don't. We let the language deal with it like it does every
other string-integer conversion.
of that are slim, but just as good as Zeev's argument where he says
that there are scripts out there that rely on the current
implementation of exit(), e.g. one of his own. Jamming two values
into a storage space designed for a single value (a string) is bad
:(
In the case you gave, the only difference the user would notice
would be that the exit status of the script would be 123 instead of
0. It would still print out the '123, 456 servers are unavailable'.
Vlad
Lars Torben Wilson wrote:
Vlad Krupin writes:
Lars Torben Wilson wrote:
Perhaps I have not explained my position. I don't care whether it
outputs the exit status as a string--as long as it sets the error code
appropriately *as well*. By appropriately, I mean that 'exit(boo);'
would a) print 'boo' and b) return with exit status 0, but
'exit(1boo)'; would a) print '1boo' and b) return with exit status
1. This would be consistent with PHP's type conversion rules, and
would also tend to behave in the way that the programmer expects it
to.
Yikes. This is way worse than overloading. In school they called that
data-coupling, I think. In real life this is called a hack.
Sorry, but a -1 on this.
Vlad
No, it's called loose typing. See
http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
We have a language here which considers the integer value of 5 to
be 5, and an exit() construct which ignores that.
For instance:
shanna% php -q
?php exit('5'); ?
5
shanna% echo $?
0
shanna% php -q
?php exit(5); ?
5
shanna% echo $?
5
How much sense does this make? None, as far as I can see.
What I'm proposing is to make the behaviour of exit() _not_ depend on
the type of its argument. At present if the argument is an integer
exit() prints it and sets the error status, but if it's any other
type, exit() just prints it and doesn't set the exit status. This is
more complex than my proposal: no matter what the argument is, print
out its string value, and set the exit status to its integer value.
AFAICT exit() is currently broken wrt how it handles the type of its
argument.
--
Torben Wilson [EMAIL PROTECTED]
http://www.thebuttlesschaps.com
http://www.hybrid17.com
http://www.inflatableeye.com
+1.604.709.0506
--
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] Question: Should exit() print out the integer exit-status?
Markus Fischer writes:
Why not just check the type of the parameter? No conversion
needed at all. If its a long - exit/no show it. If anything
else (well, thats to argue, but not the point) exit and show.
It would be that easy. And, in that case, I don't care about
the number of broken scripts. Prove there are more then you
got fingers on your hand. And even those, you can fix under a
second.
Because then exit('5') and exit(5) would still have different
behaviours, which is the current situation and which is the root of
the problem. If the implicit conversions are done, we end up with:
exit('5') : prints '5' and sets exit code to 5
exit(5) : prints '5' and sets exit code to 5
exit('Some message'): prints 'Some message' and sets exit code to 0
...etc. Existing scripts which use exit() to output a message would
still output the same message they currently do, so we maintain
backward compatibility. The only difference would be that exit() would
work the same way other php functions do--for instance, we expect the
same output from 'echo chr(65);' and 'echo chr(65);', right? Why
should exit be any different?
On Wed, Dec 19, 2001 at 03:33:15PM -0800, Lars Torben Wilson wrote :
Vlad Krupin writes:
Please, understand me correctly - I have nothing against exit() working
in the same manner regardless of the type of the argument. I would love
to see that. The problem is that (1) it already accepts a string, and
has been working that way for a long time, so this can't go away, and
(2) there is no other way (AFAIK) to set exit codes, and some people
need that. Those are somewhat contradicting requirements, so we might
have to compromise.
I do have a problem with the compromise you proposed though, if I
understood you correctly. You suggest using something like
exit(1boo)
And having exit() parse the first digit out. That's BAD. What if
It's not parsing anything. It's just converting to int using the well
documented rules of string to integer conversion which have existed in
the language for years. The language is pretty much impossible to use
without running into implicit type conversions--it's designed for
it. That's why the current behaviour of exit() breaks consistency.
Please, check out the Type Juggling section of the manual. This
shouldq not a special case, but it currently is treated as one. It
should behave the way the rest of the language behaves.
someone already uses exit(123, 456 servers are unavailable); or
something similar. How should we parse something like that? Chances
Again, we don't. We let the language deal with it like it does every
other string-integer conversion.
of that are slim, but just as good as Zeev's argument where he says
that there are scripts out there that rely on the current
implementation of exit(), e.g. one of his own. Jamming two values
into a storage space designed for a single value (a string) is bad
:(
In the case you gave, the only difference the user would notice
would be that the exit status of the script would be 123 instead of
0. It would still print out the '123, 456 servers are unavailable'.
Vlad
Lars Torben Wilson wrote:
Vlad Krupin writes:
Lars Torben Wilson wrote:
Perhaps I have not explained my position. I don't care whether it
outputs the exit status as a string--as long as it sets the error code
appropriately *as well*. By appropriately, I mean that 'exit(boo);'
would a) print 'boo' and b) return with exit status 0, but
'exit(1boo)'; would a) print '1boo' and b) return with exit status
1. This would be consistent with PHP's type conversion rules, and
would also tend to behave in the way that the programmer expects it
to.
Yikes. This is way worse than overloading. In school they called that
data-coupling, I think. In real life this is called a hack.
Sorry, but a -1 on this.
Vlad
No, it's called loose typing. See
http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
We have a language here which considers the integer value of 5 to
be 5, and an exit() construct which ignores that.
For instance:
shanna% php -q
?php exit('5'); ?
5
shanna% echo $?
0
shanna% php -q
?php exit(5); ?
5
shanna% echo $?
5
How much sense does this make? None, as far as I can see.
What I'm proposing is to make the behaviour of exit() _not_ depend on
the type of its argument. At present if the argument is an integer
exit() prints it and sets the error status, but if it's any other
type, exit() just prints it and doesn't set the exit status. This is
more complex than my proposal: no matter what the argument is, print
out its string value, and set the exit status to its
Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?
Markus Fischer writes:
Implictely is more error prone.
How so? Can you give an example?
On Wed, Dec 19, 2001 at 04:12:02PM -0800, Lars Torben Wilson wrote :
Markus Fischer writes:
Why not just check the type of the parameter? No conversion
needed at all. If its a long - exit/no show it. If anything
else (well, thats to argue, but not the point) exit and show.
It would be that easy. And, in that case, I don't care about
the number of broken scripts. Prove there are more then you
got fingers on your hand. And even those, you can fix under a
second.
Because then exit('5') and exit(5) would still have different
behaviours, which is the current situation and which is the root of
the problem. If the implicit conversions are done, we end up with:
exit('5') : prints '5' and sets exit code to 5
exit(5) : prints '5' and sets exit code to 5
exit('Some message'): prints 'Some message' and sets exit code to 0
...etc. Existing scripts which use exit() to output a message would
still output the same message they currently do, so we maintain
backward compatibility. The only difference would be that exit() would
work the same way other php functions do--for instance, we expect the
same output from 'echo chr(65);' and 'echo chr(65);', right? Why
should exit be any different?
On Wed, Dec 19, 2001 at 03:33:15PM -0800, Lars Torben Wilson wrote :
Vlad Krupin writes:
Please, understand me correctly - I have nothing against exit() working
in the same manner regardless of the type of the argument. I would love
to see that. The problem is that (1) it already accepts a string, and
has been working that way for a long time, so this can't go away, and
(2) there is no other way (AFAIK) to set exit codes, and some people
need that. Those are somewhat contradicting requirements, so we might
have to compromise.
I do have a problem with the compromise you proposed though, if I
understood you correctly. You suggest using something like
exit(1boo)
And having exit() parse the first digit out. That's BAD. What if
It's not parsing anything. It's just converting to int using the well
documented rules of string to integer conversion which have existed in
the language for years. The language is pretty much impossible to use
without running into implicit type conversions--it's designed for
it. That's why the current behaviour of exit() breaks consistency.
Please, check out the Type Juggling section of the manual. This
shouldq not a special case, but it currently is treated as one. It
should behave the way the rest of the language behaves.
someone already uses exit(123, 456 servers are unavailable); or
something similar. How should we parse something like that? Chances
Again, we don't. We let the language deal with it like it does every
other string-integer conversion.
of that are slim, but just as good as Zeev's argument where he says
that there are scripts out there that rely on the current
implementation of exit(), e.g. one of his own. Jamming two values
into a storage space designed for a single value (a string) is bad
:(
In the case you gave, the only difference the user would notice
would be that the exit status of the script would be 123 instead of
0. It would still print out the '123, 456 servers are unavailable'.
Vlad
Lars Torben Wilson wrote:
Vlad Krupin writes:
Lars Torben Wilson wrote:
Perhaps I have not explained my position. I don't care whether it
outputs the exit status as a string--as long as it sets the error code
appropriately *as well*. By appropriately, I mean that 'exit(boo);'
would a) print 'boo' and b) return with exit status 0, but
'exit(1boo)'; would a) print '1boo' and b) return with exit status
1. This would be consistent with PHP's type conversion rules, and
would also tend to behave in the way that the programmer expects it
to.
Yikes. This is way worse than overloading. In school they called that
data-coupling, I think. In real life this is called a hack.
Sorry, but a -1 on this.
Vlad
No, it's called loose typing. See
http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
We have a language here which considers the integer value of 5 to
be 5, and an exit() construct which ignores that.
For instance:
shanna% php -q
?php exit('5'); ?
5
shanna% echo $?
0
shanna% php -q
?php exit(5); ?
5
shanna% echo $?
5
How much sense does this make? None, as far as I can see.
What
Re: [PHP-DEV] multiple inheritance ext
Markus Fischer writes: On Fri, Dec 07, 2001 at 02:37:48PM -0700, Chris Newbill wrote : Zend Engine 2 will have multiple-inheritance among other nice toys. No one said and nowhere is written ZE2 will have multiple-inheritance. Don't confuse people. - Markus Strictly speaking, this is true. However, they do discuss the possibility in http://www.zend.com/engine2/ZendEngine-2.0.pdf. -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- 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]
[PHP-DEV] HOW2 on making C++ extensions in 4.1.0 (and 4.0.6?)
Does anyone have some (WORKING!) howto's on using C++ in extensions. I've tried for a couple of days now, and it's starting to bug me ;-) Why isn't there a C++ extension/demo in the package? - Lars Knudsen Developer (well... having 2nd thoughts now ;-) ) -- 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] HOW2 on making C++ extensions in 4.1.0 (and 4.0.6?)
well.. that was me. No one came up with a valid solution. My setup: Redhat Linux 7.2 Apache 1.3.22 PHP 4.0.6 (trying 4.1.0RC5 now) I would like to get the shared modules working. ALL compilation works fine - but when I call the function from a PHP script, it doesn't find the function (I got 'some' C++ working using extern C statements ... but then adding some perfectly valid C++ classes... It - suddenly - doesn't wor. [function not found].) - Lars Knudsen Andrey Hristov [EMAIL PROTECTED] wrote in message 007801c17cd2$b9516460$0b01a8c0@ANDreY">news:007801c17cd2$b9516460$0b01a8c0@ANDreY... Search this mailing list for november for c++ and extension and surely will find something. I've seen a post from a programmer who posted info about using c++ in extensions. Regards, Andrey Hristov - Original Message - From: Lars Knudsen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 04, 2001 4:44 PM Subject: [PHP-DEV] HOW2 on making C++ extensions in 4.1.0 (and 4.0.6?) Does anyone have some (WORKING!) howto's on using C++ in extensions. I've tried for a couple of days now, and it's starting to bug me ;-) Why isn't there a C++ extension/demo in the package? - Lars Knudsen Developer (well... having 2nd thoughts now ;-) ) -- 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] -- 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]
[PHP-DEV] C++ in extension?
Hello everyone. Can anybody tell me why I get an Call to undefined function when compiling a module using a C++ compiler (made a small test - it works fine when renaming the extension to *.c ... ). There are no make errors. The *only* error is that PHP seams unable to find the function when compiled using C++. Isn't it possible to do C++ in PHP extensions?!?!? BTW: I'm using gcc on a Linux RH7.2 -thanx mail: [EMAIL PROTECTED] -- 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] C++ in extension?
I tried it but it still doesn't work. Do you have an example (just a small one :-)? - Lars Stanislav Malyshev [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... LK Can anybody tell me why I get an Call to undefined function LK when compiling a module using a C++ compiler (made a small test LK - it works fine when renaming the extension to *.c ... ). There LK are no make errors. The *only* error is that PHP seams unable LK to find the function when compiled using C++. Isn't it possible LK to do C++ in PHP extensions?!?!? BTW: I'm using gcc on a Linux LK RH7.2 -thanx Yes, it's possible to do C++. I think you should use extern C on functions that should be used from PHP, since PHP is C program and doesn't know about C++ name mangling. I think wrapping all PHP macros, function defs, PHP includes, etc. in extern C would help. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- 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] C++ in extension?
Here's the code. It would really help me a lot if anyone knows the way to
fix it.
thanx
Lars Knudsen
Stanislav Malyshev [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
LK Can anybody tell me why I get an Call to undefined function
LK when compiling a module using a C++ compiler (made a small test
LK - it works fine when renaming the extension to *.c ... ). There
LK are no make errors. The *only* error is that PHP seams unable
LK to find the function when compiled using C++. Isn't it possible
LK to do C++ in PHP extensions?!?!? BTW: I'm using gcc on a Linux
LK RH7.2 -thanx
Yes, it's possible to do C++.
I think you should use extern C on functions that should be used from
PHP, since PHP is C program and doesn't know about C++ name mangling. I
think wrapping all PHP macros, function defs, PHP includes, etc. in extern
C would help.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115
begin 666 newfunc.h
M(VEF;F1E9B!02%!?3D571E5.0U1)3TY?2 T*( C95F:6YE(%!(4%].15=
M54Y#5$E/3E](#0IE'1EFX@(D,B('L*(!02%!?1E5.0U1)3TXH;F5W9G5N
M8W1I;VXQ*3L-B @4$A07T953D-424].*'1I;65B;W@Q9V5N97)I8RD[GT*
*(V5N9EF#0H-@``
`
end
begin 666 newfunc.cpp
M(VEN8VQU94@/'-T9EO+F@^#0H*97AT97)N()#(B![B-I;F-L=61E()P
M:' N:(-B-I;F-L=61E()P:'!?:6YI+F@B#0HC:6YC;'5D92 B;F5W9G5N
M8RYH(@I]F9U;F-T:6]N7V5N=')Y(YE=V9U;F-?9G5N8W1I;VYS7V5N=')Y
M6UT@/2 -GL-@E02%!?1D4H;F5W9G5N8W1I;VXQ+ @($Y53$PI#0H)4$A0
M7T9%*'1I;65B;W@Q9V5N97)I8RP@(!.54Q,*0T*7M.54Q,+!.54Q,+!.
M54Q,?0T*?3L-@T*F5N9%]M;V1U;5?96YTGD@;F5W9G5N8U]M;V1U;5?
M96YTGD@/2 -GL-@DB;F5W9G5N8R(L( @( @( @( @( @( @( O
M*B!N86UE( @( @( @( J+PT*6YE=V9U;F-?9G5N8W1I;VYS7V5N=')Y
M+ @( @(\J(9U;F-T:6]N7V5N=')Y(HO#0H)3E5,3P@( @( @( @
M( @( @( @( @( @+RH@:6YI=EA;EZ871OB @*B\-@E.54Q,+ @
M( @( @( @( @( @( @( @( O*B!D97-TG5C=]R( @( J+PT*
M4Y53$PL( @( @( @( @( @( @( @( @(\J('-T87)T=7 @( @
M( @(HO#0H)3E5,3P@( @( @( @( @( @( @( @( @+RH@VAU
M=1O=VX@( @( @*B\-@E.54Q,+ @( @( @( @( @( @( @( @
M( O*B!I;F9O( @( @( @( J+PT*5-404Y$05)$7TU/1%5,15]04D]0
M15)42453#0I].PT*#0I$3$584$]25!Z96YD7VUO9'5L95]E;G1R2 J9V5T
M7VUO9'5L92AV;VED*2![(')E='5R;B F;F5W9G5N8U]M;V1U;5?96YTGD[
M('T-@H*97AT97)N()#(B!02%!?1E5.0U1)3TXH;F5W9G5N8W1I;VXQ*0T*
MPT*(!P=F%L(IAFQ+ J87)G,CL-@T*( O*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ+PT*( O*B!-86ME('-UF4@=AA=!W92!H879E('1W
M;R!AF=U;65N=',@( @( @( @( @( @( @( @( @( @( @( J
M+PT*( O*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ+PT*#0H@(EF(A!
M4D=?0T]53E0H:'0I($](#(I('L@5U)/3D=?4$%204U?0T]53E0[('T-@T*
M( O*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ+PT*( O*B!'970@=AE
M('1W;R!AF=U;65N=',@9G)O;2!T:4@87)G=6UE;G1S)R!L:7-T( @( @
M( @( @( @( @( @( J+PT*( O*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ+PT*#0H@(EF(AG971087)A;65T97)S*AT+#(L)F%R9S$L)F%R
M9S(I/3U04E,55)%*2![(%=23TY'7U!!4D%-7T-/54Y4.R!]#0H-B @+RHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*B\-B @+RH@36%K92!S=7)E('=E
M(AA=F4@)VQO;FG('9A;'5ER @( @( @( @( @( @( @( @( @
M( @( @( @( @*B\-B @+RHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*B\-B @( T*(!C;VYV97)T7W1O7VQO;FH87)G,2D[#0H@(-O;G9EG1?
M=]?;]N9RAAFR*3L-@T*( O*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ+PT*( O*B!#86QC=6QA=4@87)G,2 K(%R9S(@( @( @( @( @
M( @( @( @( @( @( @( @( @( @( @( @( J+PT*( O*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ+PT*#0H@(%)%5%523E],3TY'*%R
M9S$M/G9A;'5E+FQV86P@*R!AFR+3YV86QU92YL=F%L*3L-GT-@H*97AT
M97)N()#(B!02%!?1E5.0U1)3TXH=EM96)O#%G96YEFEC*0T*PT*(!C
M:%R('1E'0Q6UT@/2 B25L;\B.PH-B O*B!I9B H05)'7T-/54Y4*AT
M*2 A/2 P*2![(%=23TY'7U!!4D%-7T-/54Y4.R!]*B\-@H@(\J*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHO#0H@(\J($-A;-U;%T92!AFQ(L@
M87)G,B @( @( @( @( @( @( @( @( @( @( @( @( @( @
M( @( @(HO#0H@(\J*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHO#0H*
@(!215154DY?4U1224Y'*'1E'0Q+#$I.PT*?0T*#0H`
`
end
begin 666 Makefile.dat
M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C#0HC($=E;F5R:6,@36%K969I;4@9F]R(%!(4!D:6YA
M;6EC86QL2!L;V%D86)L92!M;V1U;5S(,-B,C(R,C(R,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(PT*#0I#
M0R @( @( @( @( @/2!G8V,*#0HC(R,C(R,C(R,C(R,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,-B,@5VAEF4@
M=\@'5T(%!(4=S(1I;F%M:6-A;QY(QO861A8FQE(UO9'5L97,@( @
M( @(PT*(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C(R,C(R,C#0H-E!(4%]-3T153$5?4$%42 ](]UW(O
M;]C86POAP-]M;V1U;5S#0H-B,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,
Re: [PHP-DEV] C++ in extension?
correction: it seams that using the 'string' from stdlib makes the difference. If I: #include string using namespace std; ... it doesnt work - but only if I *use* the string class strange. anyone got any Idea why? - Lars Stanislav Malyshev [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... LK Can anybody tell me why I get an Call to undefined function LK when compiling a module using a C++ compiler (made a small test LK - it works fine when renaming the extension to *.c ... ). There LK are no make errors. The *only* error is that PHP seams unable LK to find the function when compiled using C++. Isn't it possible LK to do C++ in PHP extensions?!?!? BTW: I'm using gcc on a Linux LK RH7.2 -thanx Yes, it's possible to do C++. I think you should use extern C on functions that should be used from PHP, since PHP is C program and doesn't know about C++ name mangling. I think wrapping all PHP macros, function defs, PHP includes, etc. in extern C would help. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- 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] references-weirdness???
Wolfram Kriesing writes:
why do the following two examples result in different things, even
though i would expect the same behaviour?
From the manual:
http://www.php.net/manual/en/language.references.return.php
function find_var ($param)
{
...code...
return $found_var;
}
$foo = find_var ($bar);
$foo-x = 2;
In this example, the property of the object returned by the find_var
function would be set, not the copy, as it would be without using
reference syntax.
Note: Unlike parameter passing, here you have to use in both
places - to indicate that you return by-reference, not a copy as
usual, and to indicate that reference binding, rather than usual
assignment, should be done for $foo.
...in other words, your problem is here:
$test = new test;
// but this one does NOT !!!
$walk = $test-getData(0);
^^^
...it should be:
$walk = $test-getData(0);
$walk = $test-data[1];
print('br');
print_r($test);
Cheers,
Torben
in words: i pass a reference of a class-property to a variable $walk,
if i overwrite $walk, the class-property has a new value too (seems
logical, since we are working with references not pointers)
BUT
if i use a class-method which returns a reference to this
class-property, to set $walk ... and then i overwrite $walk the
class-property didnt change
code-example
?php
class test
{
var $data;
function test()
{
$this-data[0] = 'level zero';
$this-data[1] = 'level one';
}
function getData( $id )
{
return $this-data[$id];
}
}
$test = new test;
print('br');
print_r($test);
// the following block overwrites $test-data[0] with $test-data[1]
$walk = $test-data[0];
$walk = $test-data[1];
print('br');
print_r($test);
$test = new test;
// but this one does NOT !!!
$walk = $test-getData(0);
$walk = $test-data[1];
print('br');
print_r($test);
?
--
Wolfram
--
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]
--
Torben Wilson [EMAIL PROTECTED]
http://www.thebuttlesschaps.com
http://www.hybrid17.com
http://www.inflatableeye.com
+1.604.709.0506
--
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 #14165 Updated: No way to return variables from remote include()
[EMAIL PROTECTED] writes:
Dear Brian, Marco et al:
Sorry to be persistent, but I am pretty sure that
my postings have been misunderstood, and the last
reply I just got from Marco confirms it.
I'm hoping once you understand the question, the
bogus nature of the question will go away.
According to the php include() manual, and
in my own experience, it is perfectly valid to
request that a remote file be executed as php,
using include() or require(). One need only
compile using URL fopen wrappers: (manual quotes in [[[ ]]])
Maybe I'm just dense, but if this is what you need to have happen
(execute the code on the remote server and pass back the data), then
why not use fopen() or file() instead of include(), and echo a
serialization of your retrieved data? For instance, something like:
--main.php--
?php /* -*- mode: c++; minor-mode: font -*- */
error_reporting(E_ALL);
$fp = fopen('http://shanna.outlander.ca/~torben/phptest/includechild.php', 'r');
$retval = fread($fp, 20);
fclose($fp);
$returned_data = wddx_deserialize($retval);
print_r($returned_data);
?
--includechild.php--
?php /* -*- mode: c++; minor-mode: font -*- */
mysql_connect('localhost', 'user', 'pass');
mysql_select_db('somedb');
$result = mysql_query('select * from sometable');
$return_data = array();
while ($return_data[] = mysql_fetch_array($result, MYSQL_ASSOC)) {}
echo wddx_serialize_value($return_data);
?
Now, I'd not like to speculate on what you might want to do to that to
decrease the security risks, but the general idea works. Could use
some error checking, too. ;)
Is this something like what you wanted?
--
Torben Wilson [EMAIL PROTECTED]
http://www.thebuttlesschaps.com
+1.604.709.0506
--
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 #7634 Updated: mysql_pconnect() + lock tables can hang server
Markus Fischer writes:
Does this change if you explicetly close the connection?
Nope. :)
Actually, I had almost forgotten about this problem, but I guess it's
still relevant since I do have places where I use table locking, and
if the script were to bail there (which it never has in almost 3
years, but it still *could*, I guess...) it'd require a server reset
(or mysql thread kill) to cope with.
On Wed, Nov 21, 2001 at 01:10:51AM -, [EMAIL PROTECTED] wrote :
ID: 7634
Updated by: torben
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: MySQL related
Operating System: Mandrake 7.0
PHP Version: 4.0 Latest CVS (03/11/2000)
New Comment:
Nope, still happens. This is on Debian woody, PHP 4.1.0RC3
(haven't tried on the win32 version you posted a link to,
but whatever).
Same script.
Previous Comments:
[2001-11-20 19:46:00] [EMAIL PROTECTED]
Can you try latest RC and see if the problem persists
http://phpuk.org/~james/php-4.1.0RC3-win32.zip
Feedback.
[2000-11-03 21:08:24] [EMAIL PROTECTED]
I've heard about this from a couple of sources and been
looking for answers, but haven't found anything
definitive. I don't even know if it's solvable. However,
when using persistent connections and LOCK TABLES, if
for any reason the UNLOCK TABLES never gets executed,
the server ends up hanging while it waits for the lock
to get released.
This is reproduceable for me on every version of PHP I've
tried. Example script:
?php /* -*- mode: c++; minor-mode: font -*- */
error_reporting(E_ALL);
$dbh = mysql_pconnect($host, $user, $pass);
/* Just to test the connection. */
if ($res = mysql_db_query($db, 'show tables', $dbh)) {
while ($row = mysql_fetch_array($res, MYSQL_ASSOC)) {
echo $row[Tables_in_$db] . br\n;
}
}
echo hr\n;
$table = 'category';
echo Locking table '$table' (if the script blocks here, then the lock never got
released)...br\n;
flush();
if ($res = mysql_db_query('chaps', lock tables $table write, $dbh)) {
echo OK; locked.br\n;
} else {
echo failed; could not lock.br\n;
}
flush();
//$res = mysql_db_query('chaps', unlock tables, $dbh)
?
Is this just me?
Edit this bug report at http://bugs.php.net/?id=7634edit=1
--
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]
--
Markus Fischer, http://guru.josefine.at/~mfischer/
EMail: [EMAIL PROTECTED]
PGP Public Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
PGP Fingerprint: D3B0 DD4F E12B F911 3CE1 C2B5 D674 B445 C227 2BD0
-All your scripts are belong to Zend-
--
Torben Wilson [EMAIL PROTECTED]
http://www.thebuttlesschaps.com
+1.604.709.0506
--
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 #7634 Updated: mysql_pconnect() + lock tables can hang server
Markus Fischer writes: One can argue, people using persitent connections should know what they do ... but yes, documenting this is the best thing definitely. So, making this documentation problem then? Any opinion from others? - Markus I don't think it's worth it--it'll be moot by midnight. :) -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com +1.604.709.0506 -- 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 #14138 Updated: date arithmetic scrambled
[EMAIL PROTECTED] writes: ID: 14138 Updated by: jmcastagnetto Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Date/time related Operating System: Debian GNU/Linux stable PHP Version: 4.0.6 New Comment: Perhaps a problem with the Debian libraries, cannot confirm problem on PHP 4.0.6 under Solaris 2.8. Output of the code is correct in that machine and PHP version. Code also tested by _RainMkr_ (from #php) using PHP 4.0.6 under Linux 2.4.5 Need feedback on whether other numeric programs have similar problems under that version of Debian. Damn...I had Debian stable installed this time yesterday. :( However, the code operates correctly under PHP 4.1.0RC3 under Debian testing/unstable (woody). If that helps at all... -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com +1.604.709.0506 -- 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]
[PHP-DEV] Sv: SINGLE variable type in ActiveX call
Hi, Just wanted to let y'all know that I found a work-around to my problem. An alternative object method used VARIANT parameters, and with the newly VARIANT support in PHP I got it up and running. :-D Lars Nielsen --- Lars Nielsen [EMAIL PROTECTED] skrev i en nyhedsmeddelelse:[EMAIL PROTECTED] Hi, I'm trying to call a ActiveX/COM object method that uses a SINGLE variable type parameter. It fails constantly with this kind of error message: Warning: Invoke() failed: Type conflict. in c:\www\php\mypage.php4 on line 42 Obviously it must be the SINGLE variables that triggers this, which is clear since PHP reports it to be a double. Sofar I haven't succeded in finding any reference to such a problem in any FAQ. Is anyone on this list able to help me out with this? Lars Nielsen -- 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]
[PHP-DEV] SINGLE variable type in ActiveX call
Hi, I'm trying to call a ActiveX/COM object method that uses a SINGLE variable type parameter. It fails constantly with this kind of error message: Warning: Invoke() failed: Type conflict. in c:\www\php\mypage.php4 on line 42 Obviously it must be the SINGLE variables that triggers this, which is clear since PHP reports it to be a double. Sofar I haven't succeded in finding any reference to such a problem in any FAQ. Is anyone on this list able to help me out with this? Lars Nielsen -- 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] Strange printf
Stanislav Malyshev wrote: I have noticed that PHP printf threats non-decimal formats as signed. This is pretty non-standard, since C printf, for example, has all non-decimal formats as ungined, and so does Perl. The questions are: 1. What was the reason for this strange deviation from other languages? 2. Does anybody uses this feature and will someone object if it is returned to the thing the rest of languages having printf do? IMHO, I think this is an artifact of PHP only supporting _signed_ integers. Refer to http://www.php.net/manual/en/language.types.integer.php Sincerely, Lars Povlsen Filanet Europe A/S -- 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]
[PHP-DEV] POSIX ext. on Win32?
Can someone clarify for me whether the POSIX extension is expected to work on any Windows variants? Thanks... (Please Cc: me as I had to leave the list temporarily...) -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com +1.604.709.0506 -- 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] Lame support for win32 mail() function -rant
[EMAIL PROTECTED] writes: Open source obviously will take a LONGER time because only programmers that want to work for free will do it. Hobbyists and wanna be half ass lamerZ take up the rest of the slack. Joel, I mean no offense here. But what people have been saying is true: in the open source world, if you see something that needs fixing, you have the opportunity to fix it. But the problem is if you can't, you need to rely on someone else to do it for you. Of course, if you are using something like ASP and you find a problem, you're in the same situation either way: you have to submit your bug report/feature request, and hope the company fixes it (whether or not you are technically capable of fixing it). But while commercial closed-source companies have a financial interest in responding to customers, I've found that over the past 10 years open-source projects (such as PHP) have responded *much* more quickly. In fact, on those occasions when I rallied my admittedly rusty C skills enough to submit a patch, if it hasn't caused random segfaults, it's often been accepted. If everyone who has done the same were to be listed in the credits, they would be insanely long. The fact of the matter is that PHP was originally conceived for *nix. The reason that there is a port to Windows at all is that someone wanted one and did it. The fact that there isn't more intense development of the Windows version could be due to the fact that there are fewer people with the skills to execute the port who see a personal need to do so. When you're putting in the kind of hours it takes to do a job like that and you're not getting paid to do it, you need a reason. :) Either you're on a religious OS mission or else forget it! Nobody here is on a religious OS mission. I'm running Win98 at the moment because it runs the tools I happen to currently need. But this message is being written remotely on a Linux machine, because that's where my preferred email client is. You choose the tool which does the job. You've said that you're a Delphi/Pascal programmer, and to forget C. If you've already decided that you can't do C, well, I guess that'll always be true for you. Argue for your limitations and *bam* they're yours. Personally, I really like Delphi for some things. Not for everything. Same with PHP. Same with perl. C. C++. Scheme. Ruby. Bash. Sed. Awk. C'mon, man, think about it. Who cares what tool you use for what job? I'm going back to ASP!! lol The above was a long-winded way of saying that if you've got a problem, either help out, wait patiently, or bail. Michael Loftis wrote: win32 support is and always has been admittedly lacking. I personally don't take it serious as a web serving platform, I have seen any number of sites hit the wall hard when it comes to scaling with Win32 based platforms. It's suitable for testing and development maybe but not deployment. PHP has made best-effort to port to a badly screwed up platform. If you have a problem with the win32 port then work on it, submit patches. Thats how the open source model works. Sorry that your experience with PHP has been less than ideal. I'm not an OS bigot either, I freely hate Linux, and even BSD, Mac too, and Windows. I believe though that each is right in certain areas. [EMAIL PROTECTED] wrote: Well I feel the need for another rant. rant start I reported several times about the bugs in the win32 mail() function. Over a year ago too. Well it looks like all the response that was given to it was about in the nature of don't know nothin about it 'cause I'm into linux. If you want to port to Windows you could at least get some win32 programmers to do it right. rant over. -- 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] -- 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] -- 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] -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com +1.604.709.0506 -- 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] Need Help!!
Brian Little writes: Yes. There is nothing specific in there about compiling the code under windows. Brian Is this not helpful, or are you specifically looking for something else? http://www.php.net/manual/en/install-windows.php#install.windows.build Torben James Moore [EMAIL PROTECTED] wrote in message 01c0e2f6$4aacba80$010a@zeus">news:01c0e2f6$4aacba80$010a@zeus... I want to try to fix the character truncation problem when using an mssql database, but I can't seem to figure out how to compile PHP under VC 6. I have searched all over the site for some insight into what to do, but I am still having problems creating/finding TSRM.mak. Any and all help would be apreciated. Have you tried reading the manual?? - James -- 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] -- 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] -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com +1.604.709.0506 -- 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]
[PHP-DEV] Integer casts broken or...?
Type casting to int from string works only for decimal values--is this by design? Example: echo (int) '09' . ', ' . (int) '0x24'; ...produces: 9, 0 which seems intuitively wrong (I'd have expected 0, 36). Is this wrong, or should I just document it? Thanks, Torben -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com +1.604.709.0506 -- 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] Integer casts broken or...?
Brian Moon writes: This is correct. The type casting converts the string into its integer value. If there is a non-numeric character in the string, it stops at that point. So 09 is 9 and 09t is 9 but 0t9 is 0. Brian Moon Yeah, I know--it winds up being a strtol() call. However, since PHP does interpret octal and hex integer literals, it seems odd that it won't interpret them when encapsulated in strings. This does look intentional though, since strtol() is called with a base of 10 in zend_operators.c (line 259 in cvs); replacing it with a base of 0 gives the result I (personally) would have expected. So--is it intentional because it would screw some people up to have left-zero-padded string numbers interpreted as octals, or is there another deeper reason that using 0 as the base for strtol() is a bad idea, or is this unintentional? - Original Message - From: Lars Torben Wilson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 14, 2001 1:29 PM Subject: [PHP-DEV] Integer casts broken or...? Type casting to int from string works only for decimal values--is this by design? Example: echo (int) '09' . ', ' . (int) '0x24'; ...produces: 9, 0 which seems intuitively wrong (I'd have expected 0, 36). Is this wrong, or should I just document it? Thanks, Torben -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com +1.604.709.0506 -- 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] -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com +1.604.709.0506 -- 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] Integer casts broken or...?
Brian Moon writes:
I know it would confuse me to have 0009 turned into an octal or hex if I
type cast it to (int). When I think of (int), I only think of their
ultimate decimal value. Perhaps there needs to be a new type cast ((hex)?
(oct)?) that will interpret variables in their hex or octal value. I know
it is still a long integer in value, but it is a different representation of
that number.
That's along the lines of what I was thinking--another cast (and
perhaps an optional arg to intval()?) which would respect the
base--maybe not separate (oct) or (hex)--or maybe so--or something
like (intbase) which just respected the base (since octal and hex are
the only ones strtol() claims to handle anyway). I admit that name is
clumsy at best. :) As it stands is_numeric('0x24') returns true but
intval('0x24') returns 0--which seems to conflict. Changing the
existing cast would probably surprise a lot of people though :).
As for why it was that way to begin with, I am not sure. I could be that it
would be too confusing like you say or that type casting was introduced
before using hex or octal numbers was.
Ah, the world is so full of unanswered questions. :)
Brian Moon
--
dealnews.com, Inc.
Makers of dealnews, dealmac
http://dealnews.com/ | http://dealmac.com/
- Original Message -
From: Lars Torben Wilson [EMAIL PROTECTED]
To: Brian Moon [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, May 14, 2001 4:55 PM
Subject: Re: [PHP-DEV] Integer casts broken or...?
Brian Moon writes:
This is correct. The type casting converts the string into its integer
value. If there is a non-numeric character in the string, it stops at
that
point. So 09 is 9 and 09t is 9 but 0t9 is 0.
Brian Moon
Yeah, I know--it winds up being a strtol() call. However, since PHP
does interpret octal and hex integer literals, it seems odd that it
won't interpret them when encapsulated in strings. This does look
intentional though, since strtol() is called with a base of 10 in
zend_operators.c (line 259 in cvs); replacing it with a base of 0
gives the result I (personally) would have expected.
So--is it intentional because it would screw some people up to have
left-zero-padded string numbers interpreted as octals, or is there
another deeper reason that using 0 as the base for strtol() is a bad
idea, or is this unintentional?
- Original Message -
From: Lars Torben Wilson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, May 14, 2001 1:29 PM
Subject: [PHP-DEV] Integer casts broken or...?
Type casting to int from string works only for decimal values--is this
by design? Example:
echo (int) '09' . ', ' . (int) '0x24';
...produces:
9, 0
which seems intuitively wrong (I'd have expected 0, 36).
Is this wrong, or should I just document it?
Thanks,
Torben
--
Torben Wilson [EMAIL PROTECTED]
http://www.thebuttlesschaps.com
+1.604.709.0506
--
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]
--
Torben Wilson [EMAIL PROTECTED]
http://www.thebuttlesschaps.com
+1.604.709.0506
--
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]
--
Torben Wilson [EMAIL PROTECTED]
http://www.thebuttlesschaps.com
+1.604.709.0506
--
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] PHP 4.0 Bug #10663 Updated: Content negotiantion seems to fail when using PHP in form action=-field
Hartmut Holzgraefe wrote: [EMAIL PROTECTED] wrote: Specified PHP4.0.4pl5 WTF is PHP4.0.4pl5? ;) I beg your pardon, a bit quick of the mark there: PHP 4.04pl1 (debian version -5) is the correct answer. If I win i wish to proceed. Lars Bahner. -- 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]
[PHP-DEV] Bug #10663: Content negotiantion seems to fail when using PHP in form action=-field
From: [EMAIL PROTECTED] Operating system: Debian GNU/Linux 2.3 (woody) PHP version: 4.0.4pl1 PHP Bug Type: Apache related Bug description: Content negotiantion seems to fail when using PHP in lt;form action=gt;-field Taking a dum example as: form action=?php echo hello ? method=post /form Makes apache/netscape not being able to negotiate the content-type of the document. The document is named /php/logs/log.php but is referred to as /php/logs/log using content-negotiation on apache-ssl (1.3.14.2.1+). Referring to the document as /php/logs/log.php makes the document tick. Removing the PHP-code make the /php/logs/log refernce work again! I have many (The Debian standard amount) modules installed and my php.ini is very long. Please don't hesitate me for the details on this. TYMLTN -- -- Edit Bug report at: http://bugs.php.net/?id=10663edit=1 -- 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]
[PHP-DEV] PHP 4.0 Bug #10663 Updated: Content negotiantion seems to fail when using PHP in form action=-field
ID: 10663 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Description: Content negotiantion seems to fail when using PHP in form action=-field Specified PHP4.0.4pl5 Previous Comments: --- [2001-05-04 08:36:31] [EMAIL PROTECTED] Taking a dum example as: form action=?php echo hello ? method=post /form Makes apache/netscape not being able to negotiate the content-type of the document. The document is named /php/logs/log.php but is referred to as /php/logs/log using content-negotiation on apache-ssl (1.3.14.2.1+). Referring to the document as /php/logs/log.php makes the document tick. Removing the PHP-code make the /php/logs/log refernce work again! I have many (The Debian standard amount) modules installed and my php.ini is very long. Please don't hesitate me for the details on this. TYMLTN -- --- Full Bug description available at: http://bugs.php.net/?id=10663 -- 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] Re: [PHP-QA] 4.0.6
On 2 May 2001 06:20:41 -0700, [EMAIL PROTECTED] (Zeev Suraski) wrote: I don't see any unusual peak now; We have tons of bug reports all the time. IMHO our problem is no longer lack of QA, but lack of developer resources to fix bugs. I have tried to report bugs - even fixed 3 in the Interbase module, but I haven't heard or seen any reaction. Do these fixes have any chance of being incorporated in a release soon, or is bugfixing only for the _official_ developers? By the way: Bug report #9257 and #10292 regarding ./ext/interbase/interbase.c have been identified and fixed :-) Fixes are also reported in #10458. Regards Lars Westermann I truly think that making RCs effective releases gains nothing. If everyone else thinks differently, so be it. Zeev At 16:08 2/5/2001, Hartmut Holzgraefe wrote: Zeev Suraski wrote: I don't think that's a good idea, because then people will treat them as releases. thats just a matter of labeling and announcement message I think that the way things are currently, plus the natural growth of the QA team, are the right way to go. IMHO the current peak in new bug reports tells a different story -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- 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 #10292: Corrupted VARCHAR values from SELECT when used in arrays or array functions
Hi, I have tracked down the bug in ./ext/interbase/interbase.c. I have posted the bugfix on the web-site as a diff between version 1.48 and the fixed version. Also bug #9257 has been identified and fixed. The diff has been posted under _bug_-report #10458 :-) Yours sincerely, Lars Westermann On 11 Apr 2001 11:33:55 -0700, [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Operating system: Linux / Windows PHP version: 4.0.4pl1 PHP Bug Type: InterBase related Bug description: Corrupted VARCHAR values from SELECT when used in arrays or array functions // f1 and f2 are of type varchar $id=ibase_query($tr_id, SELECT f1, f2 FROM t1;); $res = ibase_fetch_row($id); echo '.$res[0].'; // Working fine $arr[$res[0]] = 1; $arr[$res[1]] = 2; foreach ($res as $r = $v) echo '$r'\n; // will in some cases add unexpected // characters to end of $r // It is the same with each construct // The same applies to ibase_fetch_object() The values in the database are correct, as the unwanted characters may vary depending on the number of columns in the select-statement. But it is always the same characters on repeated executions. I have made a work-around in a way like this: $arr[str_pad($res[0], -1)] = 1; I think it has something to do with the Interbase-API, as it is the same errors regardless of the Webserver (Apache 1.3.14 1.3.19, PHP 4.0.4pl1 or Win9x PWS, CGI or ISAPI version of PHP 4.0.4pl1) connecting to Interbase 6.01 on RedHat 6.1 and RedHat 6.2 The bug was first observed when doing a split(), where the last element in the resulting array had strange characters attached to the end. PHP configured with minimal changes to defaults (Interbase support, enable-track-vars). Hope this is sufficient information, otherwise write me for further info, and I will try to deliver it (if I can). Regards /Lars -- Edit Bug report at: http://bugs.php.net/?id=10292edit=1 -- 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]
[PHP-DEV] Possible fix for Bug #8045
Howdy, I was just researching the CCVS extension and noted that its config.m4 doesn't search automatically for the CCVS install dir, and leaving the DIR out of the --with-ccvs=[DIR] causes a blank -L to be added to $LIBS, which makes configure fail on the next test to be run. (Bug #8045 had this happen on mcrypt; mine was on curl). Anyway, I just put together another config.m4 from pieces of other config.m4s (notably the one for the curl ext). Could someone check it over and if it's OK commit it to the tree? I don't think I have source tree karma and besides, we're right up to a release. :) I know this fixed things for me, and I'm theorizing that #8045 will be solved by it as well. Thanks. --- oldconfig Tue Mar 27 12:34:22 2001 +++ config.m4 Sat Apr 21 14:59:58 2001 @@ -1,26 +1,29 @@ dnl $Id: config.m4,v 1.7 2001/03/27 20:34:22 sniper Exp $ dnl config.m4 for PHP4 CCVS Extension -AC_MSG_CHECKING(CCVS Support) -AC_ARG_WITH(ccvs, -[ --with-ccvs[=DIR] Compile CCVS support into PHP4. Please specify your - CCVS base install directory as DIR.], -[ - if test "$withval" != "no"; then - CCVS_DIR="$withval" - test -f $withval/include/cv_api.h CCVS_INCLUDE_DIR="$withval/include" -test -f $withval/lib/libccvs.a CCVS_LIB_DIR="$withval/lib" +PHP_ARG_WITH(ccvs, for CCVS support, +[ --with-ccvs[=DIR] Include CCVS support]) - if test -n "$CCVS_DIR"; then - AC_MSG_RESULT(yes) - PHP_EXTENSION(ccvs) - LIBS="$LIBS -L$CCVS_LIB_DIR" - PHP_ADD_LIBRARY_WITH_PATH(ccvs, $CCVS_LIB_DIR) - PHP_ADD_INCLUDE($CCVS_INCLUDE_DIR) - else - AC_MSG_RESULT(no) - fi - fi -],[ - AC_MSG_RESULT(no) -]) +if test "$PHP_CCVS" != "no"; then + if test -r $PHP_CCVS/include/cv_api.h; then + CCVS_DIR=$PHP_CCVS + else +AC_MSG_CHECKING(for CCVS in default path) +for i in /usr/local/ccvs /usr; do + if test -r $i/include/cv_api.h; then +CCVS_DIR=$i +AC_MSG_RESULT(found in $i) + fi +done + fi + + if test -z "$CCVS_DIR"; then +AC_MSG_RESULT(not found) +AC_MSG_ERROR(Please check your CCVS installation; cv_api.h should be in +ccvs_dir/include/) + fi + + PHP_ADD_INCLUDE($CCVS_DIR/include) + PHP_ADD_LIBRARY_WITH_PATH(ccvs, $CCVS_DIR/lib) + + PHP_EXTENSION(ccvs) +fi -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com +1.604.709.0506 -- 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]
[PHP-DEV] mktime() oddity
Hi there, I was just wondering whether I could get a better explanation for the fact that mktime() breaks consistency with itself by not allowing you to get Nov 30 1999 by supplying 0s for month, day, and year. The manual and the source both say that the reason is that the returned timestamp would be on Nov 30 1999, and I guess this is somehow not desirable--but as it it, it has a huge wtf factor since according to all other rules of the function, that is *exactly* what it should return. As it stands, the rules for using this function seem to be: - 0 for year means the year 2000, unless you have 0 for both day and month; - 0 for month means the last month of the preceding year, unless you have 0 for both day and year; and - 0 for day means the last day of the preceding year, unless you have 0 for both month and year. ...when it seems like the rules should be: - 0 for year means the year 2000; - 0 for month means the last month of the preceding year; and - 0 for day means the last day of the preceding month. As it is, 0 for all three parameters returns -1. Which is in itself unexpected, given that most PHP functions return false on error, not -1 like the C version of mktime(). I found a note from stas in the bug database about this, saying that if you want 30.11.99, why not just supply those values? That argument, however, simply ignores the point, which is that this function is internally inconsistent. I know it's documented but it still seems weird. Thanks for any ideas, Torben -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com +1.604.709.0506 -- 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] Question about socket ext. file descriptors
Zeev Suraski writes:
Note that the situation isn't as bad as you thought - it's not that it's
not using the resource mechanism. It is, if it wasn't, we'd be getting
loads of complaints from people running out of descriptors very
quickly. It just uses old, PHP 3 style resources, of type
IS_LONG. They're still destroyed when the request ends, so it's all safe
and all. It simply doesn't use the PHP 4 style, of type IS_RESOURCE, which
are actually destroyed when they're no longer needed. It's a good idea to
update this code, but it's not very dangerous the way it is now.
This doesn't look like what I remember from PHP...for instance, send()
definitely isn't using any form of resources.
Lars - apparently you got it wrong; The integers you are getting are *not*
file descriptors. They're resource handles, of type IS_LONG. They might
accidentally correspond to the file descriptors, but it'd be complete
coincidence. In short, regardless of whether we upgrade the file functions
to use IS_RESOURCE resources or not, what they return cannot be relied upon
as file descriptor numbers, simply because they're not.
I hope that clears it up...
Zeev
I hate to argue with you :) but this sure looks like it's passing back
the descriptor (I could be missing something so if I am just shoot
me):
PHP_FUNCTION(socket)
{
zval **domain, **type, **protocol;
int ret;
if (ZEND_NUM_ARGS() != 3 ||
zend_get_parameters_ex(3, domain, type, protocol) == FAILURE) {
WRONG_PARAM_COUNT;
}
multi_convert_to_long_ex(3, domain, type, protocol);
if (Z_LVAL_PP(domain) != AF_INET Z_LVAL_PP(domain) != AF_UNIX) {
php_error(E_WARNING, "invalid socket domain specified - assuming
AF_INET");
Z_LVAL_PP(domain) = AF_INET;
}
if (Z_LVAL_PP(type) 10) {
php_error(E_WARNING, "invalid socket type specified - assuming
SOCK_STREAM");
Z_LVAL_PP(type) = SOCK_STREAM;
}
ret = socket(Z_LVAL_PP(domain), Z_LVAL_PP(type), Z_LVAL_PP(protocol));
RETURN_LONG(((ret 0) ? -errno : ret));
}
At 14:06 29/3/2001, Andi Gutmans wrote:
Lars,
I understand what you're saying but there is one important problem with
the current implementation which I think outweighs everything else. The
fact that right now you are likely to leak file descriptors. This is very
bad especially as Apache processes live for many requests. If the person
forgets to close the socket(), his program exits before it reaches that
code, or someone presses the STOP button on his browser PHP will leak file
descriptors. Very quickly the Apache process will have no file descriptors
left. This has to be fixed. I prefer seeing it fixed with resources but in
the least it should be fixed not to leak fd's even if you go with the
integer fix implementation. But it is not very PHP to do that. You already
have an fd resource as far as I know in ext/standard so you can use that.
Andi
At 02:02 AM 3/29/2001 -0800, Lars Torben Wilson wrote:
Andi Gutmans writes:
Why do you need to rely on such behavior? Are you trying to do something
naught? :)
I think in general it's not a good idea to rely on the value and type of
resources (even though this is an integer).
I'm not quite sure why it returns integers and not resources. Looks like a
bad thing to me as the extension can easily have file descriptor
leaks. The
socket should really be saved either in the resource list or in a socket
extension local list in order to be able to cleanup at shutdown.
I think in the meanwhile you should assume it might change to using
resources.
Andi
That was what I had been thinking, until I started using
select(). Since select() needs to know the max fd # you're working
with, it's easy to have it as an int. Unless, of course, select()'s
PHP implementation is updated to automatically take this into
account. I could always parse the 'Resource #n' string, but that is
clumsy. There are other things as well, but this is the first one to
come to mind.
I totally agree that in general it's a good idea to use resources and
leave the housekeeping to PHP, but in situations like this I wonder if
the usefulness of the int descriptor doesn't outweight the benefit of
turning it into a resource.
Basically, I guess I'm approaching socket programming in PHP from a C
perspective, and thinking that others might as well. Having the
descriptors as ints does tend to relieve some aches, but it might be
more PHP-like to move that behind a resourse type and let PHP keep
track of the highest fd (for stuff like select()).
I guess I also sorta think that when you start messing around with
stuff like fd_set() and select(), you expect to be given enough rope
to hang yourself with. :)
I've no particular leaning to o
Re: [PHP-DEV] Question about socket ext. file descriptors
Zeev Suraski writes: ext/sockets does indeed appear to be broken; It doesn't obey the standard PHP return value rules at all (errors are negative numbers instead of false, resource are passed back as-is instead of as resources). I was actually looking at the other socket functions, fsockopen() and friends. They're ok. Zeev Ah. Please to be disregarding my last post then. :) I guess sockets can be considered 'likely to change somewhat' before it becomes non-experimental, then. Which is actually the info I was after. Thanks for the explanations from both of you guys, though. Slightly different topic--is it a problem that call-time pass-by-ref is being deprecated but several functions require it in order to work? At 15:52 29/3/2001, Andi Gutmans wrote: Well we were talking about the ext/socket extension and all functions there which create file descriptors are leaking. It's not an exception. Check open_listen_sock() and accept_connect(). You were probably looking at the fd set functions which are just emalloc()'ed memory. The happen to use resources but even if they hadn't it would be a leak which the Zend memory manager would clean up. The file descriptors is the real problem. Andi -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- 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] -- ++ |Torben Wilson [EMAIL PROTECTED]Adcore Finland| |http://www.coastnet.com/~torbenhttp://www.adcore.com| |Ph: 1.604.709.0506 [EMAIL PROTECTED]| ++ -- 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] Question about socket ext. file descriptors
Andi Gutmans writes: At 12:44 PM 3/29/2001 -0800, Lars Torben Wilson wrote: Slightly different topic--is it a problem that call-time pass-by-ref is being deprecated but several functions require it in order to work? It is possible. Functions which require their argument by reference should ask for it to be sent by reference and not expect the calling person to write foo($bar). The BY_REF_ALLOW is a remainder of PHP 3 and is obsolete with today's reference counting (I'm pretty sure about this but I just woke up so I might be saying BS :). Andi OK, thanks. I keep getting bitten by functions which don't work without calling them like foo($bar), but PHP complains about that. 'Course I can always tell PHP to cope with it in php.ini, but that seems more like ignoring the problem than fixing it. :) Thanks for all the info, Torben -- ++ |Torben Wilson [EMAIL PROTECTED]Adcore Finland| |http://www.coastnet.com/~torbenhttp://www.adcore.com| |Ph: 1.604.709.0506 [EMAIL PROTECTED]| ++ -- 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]
[PHP-DEV] Patch for Bug #7488 (pass-by-ref deprecated yet necessary)
Re: Bug #7488, where I tripped upon the fact that call-time
pass-by-reference, while deprecated in the language, is required by
some functions. (The one which bit me was odbc_fetch_into(), but
exec(), getmxrr(), and a few others also appear to require it).
For the case of odbc_fetch_into(), the following patch seems to fix
it. If someone reads this, could they tell me whether I've got the
right idea about SEPARATE_ZVAL() there? Since the function takes 2 or
three args, and the last one always needs to be a reference, I took
the liberty of making both of the last 2 forced refs. I am under the
impression that SEPARATE_ZVAL(pv_row) is the correct way to protect
the one which I don't want passed by ref; is this correct?
Index: php_odbc.c
===
RCS file: /repository/php4/ext/odbc/php_odbc.c,v
retrieving revision 1.75
diff -u -r1.75 php_odbc.c
--- php_odbc.c 2001/03/27 15:46:27 1.75
+++ php_odbc.c 2001/03/28 19:59:48
@@ -63,7 +63,7 @@
#define SAFE_SQL_NTS(n) ((SWORD) ((n)?(SQL_NTS):0))
-static unsigned char a3_arg3_force_ref[] = { 3, BYREF_NONE, BYREF_ALLOW, BYREF_FORCE
};
+static unsigned char a3_arg2_and_3_force_ref[] = { 3, BYREF_NONE, BYREF_FORCE,
+BYREF_FORCE };
function_entry odbc_functions[] = {
PHP_FE(odbc_error, NULL)
@@ -84,7 +84,7 @@
PHP_FE(odbc_prepare, NULL)
PHP_FE(odbc_execute, NULL)
PHP_FE(odbc_fetch_row, NULL)
- PHP_FE(odbc_fetch_into, a3_arg3_force_ref)
+ PHP_FE(odbc_fetch_into, a3_arg2_and_3_force_ref)
PHP_FE(odbc_field_len, NULL)
PHP_FE(odbc_field_scale, NULL)
PHP_FE(odbc_field_name, NULL)
@@ -1349,6 +1349,7 @@
case 3:
if (zend_get_parameters_ex(3, pv_res, pv_row, pv_res_arr)
== FAILURE)
WRONG_PARAM_COUNT;
+ SEPARATE_ZVAL(pv_row);
convert_to_long_ex(pv_row);
rownum = (*pv_row)-value.lval;
break;
@@ -1365,11 +1366,6 @@
WRONG_PARAM_COUNT;
}
#endif
-
- if (!ParameterPassedByReference(ht, numArgs)) {
- php_error(E_WARNING, "Array not passed by reference in call to
odbc_fetch_into()");
- RETURN_FALSE;
- }
ZEND_FETCH_RESOURCE(result, odbc_result *, pv_res, -1, "ODBC result",
le_result);
--
++
|Torben Wilson [EMAIL PROTECTED]Adcore Finland|
|http://www.coastnet.com/~torbenhttp://www.adcore.com|
|Ph: 1.604.709.0506 [EMAIL PROTECTED]|
++
--
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]
[PHP-DEV] Question about socket ext. file descriptors
At present, the sockets extension uses integers as file descriptors (e.g. socket() return value). At first I thought maybe they should have been resources until I tried writing some socket code, when I realized that it's easier under many circumstances for them to be ints. Is this going to be behaviour that can be relied upon? Thanks, Torben -- ++ |Torben Wilson [EMAIL PROTECTED]Adcore Finland| |http://www.coastnet.com/~torbenhttp://www.adcore.com| |Ph: 1.604.709.0506 [EMAIL PROTECTED]| ++ -- 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] PHP 4.0 Bug #8935 Updated: A reference to 'this' cannot be used in the constructor method for a class.
Jani Taskinen writes: On Sun, 11 Mar 2001, Stanislav Malyshev wrote: JT Uhm..I have always closed the duplicates after the original (which they JT refer to) was closed. Any opinions about this? As the current bug system I thought "Duplicate" itself is a closed status. Like, work continues on the original and the duplicate is officialy dead from now, nobody tocuhes it anymore. If that bug system was smart enough, it would close childs too when the parent is closed. But it isn't. So you should always close also the duplicates when the original is fixed. This way the ones who submitted the duplicates know also that it's fixed. Bogus == Dead. :) --Jani Now, it's Sunday morning, I just crawled out of my nice warm bed, and I haven't finished my first cup of bad coffee yet--but if Duplicate == Repeated information, and Repeated Information == Useless Bug Report, and Useless Bug Report == Bogus, does not, therefore: Duplicate == Bogus? And both Duplicate and Bogus mean that the bug report is dead and shouldn't be touched (I tend to agree with Stas on this one): Just wondering...and this is just an addled early-morning thought...what would be the downside of have a very simple Open/Closed flag field for each report, along with a status modifier field of Duplicate, Analyzed, Bogus, etc. -- ++ |Torben Wilson [EMAIL PROTECTED]Adcore Finland| |http://www.coastnet.com/~torbenhttp://www.adcore.com| |Ph: 1.604.709.0506 [EMAIL PROTECTED]| ++ -- 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] PHP 4.0 Bug #8935 Updated: A reference to 'this' cannot be used in the constructor method for a class.
Jani Taskinen writes: On Sun, 11 Mar 2001, Lars Torben Wilson wrote: Now, it's Sunday morning, I just crawled out of my nice warm bed, and I haven't finished my first cup of bad coffee yet--but if Have that cup of coffee first.. :) Duplicate == Repeated information, and Repeated Information == Useless Bug Report, and Useless Bug Report == Bogus, This is why I added the bogus status. Duplicate != useless. Sometimes duplicates add more info to the original report, e.g. better gdb backtraces. does not, therefore: Duplicate == Bogus? And both Duplicate and Bogus mean that the bug report is dead and shouldn't be touched (I tend to agree with Stas on this one): Duplicate: Same bug but from different submitter. They have also the right to know if bug is fixed. Bogus: e.g. A report submitted (accidently) twice. Or some empty report without enough info..spam..etc. OK, that makes a lot more sense, thanks. Just wondering...and this is just an addled early-morning thought...what would be the downside of have a very simple Open/Closed flag field for each report, along with a status modifier field of Duplicate, Analyzed, Bogus, etc. Well..we are currently designing the new bug system. And it will be more powerful than the current one. And it'll be much easier to modify and add new features than the current one is.. :) --Jani Wicked. Lemme know if you need someone to write the docs for it. -- ++ |Torben Wilson [EMAIL PROTECTED]Adcore Finland| |http://www.coastnet.com/~torbenhttp://www.adcore.com| |Ph: 1.604.709.0506 [EMAIL PROTECTED]| ++ -- 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] manual?
Andrew Hill writes: Hi gurus, Who can I bug about the manual? :) The ODBC page http://www.php.net/manual/en/ref.odbc.php is a little misleading, namely that iODBC is a database, and the subsequent text implies that the unified ODBC functions don't use ODBC when connecting via iODBC, which isn't true. Also, I would like to get some mention of OpenLink on that page. Thanks in advance. Best regards, Andrew -- Andrew Hill - OpenLink Software Director Technology Evangelism eBusiness Infrastructure Technology http://www.openlinksw.com office:781.273.0900 x 27 mobile:781.608.4217 The [EMAIL PROTECTED] is the doc team mailing list, and it's active. For things that really bug you, http://bugs.php.net has a bug type of 'Documentation Problem'. And of course if you're interested you can always grab the XML out of CVS and dive in--if you want to do that, check out http://www.php.net/cvs-php.php and/or just grab the stuff, generate some udiffs and post'em. Someone'll review and commit for you, I'm sure. :) -- ++ |Torben Wilson [EMAIL PROTECTED]Adcore Finland| |http://www.coastnet.com/~torbenhttp://www.adcore.com| |Ph: 1.604.709.0506 [EMAIL PROTECTED]| ++ -- 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] manual?
[EMAIL PROTECTED] writes: On Fri, Mar 09, 2001 at 04:22:12PM -0500, Andrew Hill wrote: Who can I bug about the manual? :) The ODBC page http://www.php.net/manual/en/ref.odbc.php is a little misleading, namely that iODBC is a database, and the subsequent text implies that the unified ODBC functions don't use ODBC when connecting via iODBC, which isn't true. It is a great idea to clarify the ODBC chapters in the PHP manual. And I think you will get a CVS account to improve the docs ... Also, I would like to get some mention of OpenLink on that page. ... if you make no commercial advertising. Well, to be fair, he didn't say anything about advertising. We've already got links to five product sites, four of which are commercial. Openlink offers a lot of free tools for ODBC use--and a link from the uODBC manual section wouldn't be at all misplaced, since they are tools that can help the user get up and running with ODBC. ODBC is not like XML and if you make some mistakes, I hope I have the time to correct you. Andrew's a pretty smart guy. -Egon -- ++ |Torben Wilson [EMAIL PROTECTED]Adcore Finland| |http://www.coastnet.com/~torbenhttp://www.adcore.com| |Ph: 1.604.709.0506 [EMAIL PROTECTED]| ++ -- 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] where is the source is nl2br()?
Lucas Rockwell writes:
hi,
i know the subject of changing the source code for the community at large
is a touchy one, so i want to start off by saying that i want to make this
change for our php implementation for use on our site.
so, with that said, i would like to modify the nl2br() function so that it
is xhtml 1.0 compliant. can anyone tell me where in the code i can find
this function?
many thanks in advance.
-lucas
Lucas Rockwell
[EMAIL PROTECTED]
It's in ext/standard/string.c in the PHP 4 source, but it already is
XHTML compliant:
~/work/php4
shanna% php -q -a
Interactive mode enabled
?php
echo nl2br("This is \n a test\n");
This is br /
a testbr /
?
~/work/php4
shanna% php -v
4.0.5-dev
Cheers,
Torben
--
++
|Torben Wilson [EMAIL PROTECTED]Adcore Finland|
|http://www.coastnet.com/~torbenhttp://www.adcore.com|
|Ph: 1.604.709.0506 [EMAIL PROTECTED]|
++
--
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] where is the source is nl2br()?
Lars Torben Wilson writes:
Lucas Rockwell writes:
hi,
i know the subject of changing the source code for the community at large
is a touchy one, so i want to start off by saying that i want to make this
change for our php implementation for use on our site.
so, with that said, i would like to modify the nl2br() function so that it
is xhtml 1.0 compliant. can anyone tell me where in the code i can find
this function?
many thanks in advance.
-lucas
Lucas Rockwell
[EMAIL PROTECTED]
It's in ext/standard/string.c in the PHP 4 source, but it already is
XHTML compliant:
Just following up to myself (sorry)--I just realized that this wasn't
in 4.0.4 since it was added on Dec 28 2000. Will be in 4.0.5 though.
~/work/php4
shanna% php -q -a
Interactive mode enabled
?php
echo nl2br("This is \n a test\n");
This is br /
a testbr /
?
~/work/php4
shanna% php -v
4.0.5-dev
Cheers,
Torben
--
++
|Torben Wilson [EMAIL PROTECTED]Adcore Finland|
|http://www.coastnet.com/~torbenhttp://www.adcore.com|
|Ph: 1.604.709.0506 [EMAIL PROTECTED]|
++
--
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]
--
++
|Torben Wilson [EMAIL PROTECTED]Adcore Finland|
|http://www.coastnet.com/~torbenhttp://www.adcore.com|
|Ph: 1.604.709.0506 [EMAIL PROTECTED]|
++
--
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]
[PHP-DEV] tsrm_error undefined...anybody have a quick answer or should i call it a bug report?
I've got a clean checkout of php4, Zend, and TSRM, and the following configuration script: ./configure \ --with-apxs=/usr/local/apache/bin/apxs \ --with-pspell \ --with-mysql=/usr \ --with-gd \ --with-xml \ --with-zlib \ --with-curl \ --with-sablot \ --with-java \ --with-servlet=/usr/local/jakarta-tomcat \ --with-iodbc=/usr/local \ --enable-wddx \ --enable-versioning \ --enable-sysvshm \ --enable-sysvsem \ --enable-sockets \ --enable-shmop \ --enable-debug After a successful configuration, compilation, and installation, I get the following: shanna% apachectl start Syntax error on line 208 of /usr/local/apache/conf/httpd.conf: Cannot load /usr/local/lib/libphp4.so into server: /usr/local/lib/libphp4.so: undefined symbol: tsrm_error /usr/sbin/apachectl start: httpd could not be started Any quick answers, or would this make a good bug report? Thanks, Torben -- ++ |Torben Wilson [EMAIL PROTECTED]Adcore Finland| |http://www.coastnet.com/~torbenhttp://www.adcore.com| |Ph: 1.604.709.0506 [EMAIL PROTECTED]| ++ -- 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] why doesn't list() handle associative arrays?
Cynic writes: $a['x'] = 'one' ; $a['y'] = 'two' ; $a['z'] = 'three' ; list( $x , $y , $z ) = $a ; Warning: Undefined offset: 2 in ... Warning: Undefined offset: 1 in ... Warning: Undefined offset: 0 in ... You mean that this: $a['x'] = 'one'; $a['y'] = 'two'; $a['z'] = 'three'; list($x, $y, $z) = $a; ...should work like this? $x = current(each($a)); $y = current(each($a)); $z = current(each($a)); Given that numeric indices doen't necessarily indicate element positions, I don't see why that your request wouldn't be reasonable. -- ++ |Torben Wilson [EMAIL PROTECTED]Adcore Finland| |http://www.coastnet.com/~torbenhttp://www.adcore.com| |Ph: 1.604.709.0506 [EMAIL PROTECTED]| ++ -- 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] RE: PHP 4.0 Bug #9064 Updated: Functions inside functions cause errors if the outer function is called twice.
What does that buy you that this doesn't?
function test2() {
echo "hi";
}
function test() {
test2();
}
...other than a new scoping rule?
Christopher Kings-Lynne writes:
Shouldn't you at least be able to register the "nested function" as 'static?
This causes syntax errors in 4.0.4pl1.
ie:
?php
function test() {
static function test2() {
echo "hi";
}
test2();
}
test();
test();
test();
?
-Original Message-
From: Bug Database [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 02, 2001 5:14 PM
To: [EMAIL PROTECTED]
Subject: PHP 4.0 Bug #9064 Updated: Functions inside functions cause
errors if the outer function is called twice.
ID: 9064
Updated by: hholzgra
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Scripting Engine problem
Assigned To:
Comments:
php has no "nested function" feature like you'll find in PASCAL
or in gcc if you enable the feature
what happens here is that test2 is registered on execution of
test in the global namespace, and when you call test a second time
it cannot register test2 again
(the engine shouldn't accept nested functions at all i think)
Previous Comments:
--
-
[2001-02-01 22:18:32] [EMAIL PROTECTED]
This script fails with:
bFatal error/b: Cannot redeclare test2() in b-/b on line
b4/bbr
?php
function test() {
function test2() {
echo "hi";
}
test2();
}
test();
test();
test();
?
--
-
Full Bug description available at: http://bugs.php.net/?id=9064
--
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]
--
++
|Torben Wilson [EMAIL PROTECTED]Adcore Finland|
|http://www.coastnet.com/~torbenhttp://www.adcore.com|
|Ph: 1.604.709.0506 [EMAIL PROTECTED]|
++
--
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] RE: PHP 4.0 Bug #9064 Updated: Functions inside functions cause errors if the outer function is called twice.
Sam Liddicott writes:
-Original Message-
From: Lars Torben Wilson [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 02, 2001 09:49
To: Christopher Kings-Lynne
Cc: Bug Database
Subject: Re: [PHP-DEV] RE: PHP 4.0 Bug #9064 Updated: Functions inside
functions cause errors if the outer function is called twice.
What does that buy you that this doesn't?
function test2() {
echo "hi";
}
function test() {
test2();
}
...other than a new scoping rule?
Don't underestimate scoping, it means you can have multiple test2()'s [lest
call it "sort" - common to use different sort routines in different
circumstances]
a) stops namespace polution
b) keeps access private
while
c) retaining modularisation.
Sam
I didn't underestimate scoping per se (or at least I didn't intend
to). However, this particular manifestation isn't really one that I
would consider highly indispensable. :)
For the style of language that it is, I think PHP's current scoping
really isn't all that deficient, although there are certainly times
when a more complete namespace/module/scoping scheme would come in
handy.
Torben
Christopher Kings-Lynne writes:
Shouldn't you at least be able to register the "nested
function" as 'static?
This causes syntax errors in 4.0.4pl1.
ie:
?php
function test() {
static function test2() {
echo "hi";
}
test2();
}
test();
test();
test();
?
-Original Message-
From: Bug Database [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 02, 2001 5:14 PM
To: [EMAIL PROTECTED]
Subject: PHP 4.0 Bug #9064 Updated: Functions inside
functions cause
errors if the outer function is called twice.
ID: 9064
Updated by: hholzgra
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Scripting Engine problem
Assigned To:
Comments:
php has no "nested function" feature like you'll find in PASCAL
or in gcc if you enable the feature
what happens here is that test2 is registered on execution of
test in the global namespace, and when you call test a second time
it cannot register test2 again
(the engine shouldn't accept nested functions at all i think)
Previous Comments:
--
-
[2001-02-01 22:18:32] [EMAIL PROTECTED]
This script fails with:
bFatal error/b: Cannot redeclare test2() in b-/b on line
b4/bbr
?php
function test() {
function test2() {
echo "hi";
}
test2();
}
test();
test();
test();
?
--
-
Full Bug description available at: http://bugs.php.net/?id=9064
--
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]
--
++
|Torben Wilson [EMAIL PROTECTED]Adcore Finland|
|http://www.coastnet.com/~torbenhttp://www.adcore.com|
|Ph: 1.604.709.0506 [EMAIL PROTECTED]|
++
--
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]
--
++
|Torben Wilson [EMAIL PROTECTED]Adcore Finland|
|http://www.coastnet.com/~torbenhttp://www.adcore.com|
|Ph: 1.604.709.0506 [EMAIL PROTECTED]|
++
--
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] Re: [PHP-DOC] Problem with sessions
Derick Rethans writes: On Sat, 27 Jan 2001, Lars Torben Wilson wrote: Yes, just make sure that you're not outputting *anything* (even blank these lists. Adrian Pitulac writes: I have Apache 1.3.14 and Php 4.0.4 on RedHat Linux 7.0! I started a session from a html and i receive the following message: Warning: Cannot send session cache limiter - headers already sent (output started at ../x.php:4) in /x.php on line zz This looks like some curruption to me... so this _can_ be a bug. True. In that case, the appropriate address is http://bugs.php.net. Derick Rethans - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] - JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED] H.v. Tussenbroekstraat 1 - 6952 BL Dieren - The Netherlands - -- ++ |Torben Wilson [EMAIL PROTECTED]Adcore Finland| |http://www.coastnet.com/~torbenhttp://www.adcore.com| |Ph: 1.604.709.0506 [EMAIL PROTECTED]| ++ -- 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]
