Re: [PHP-DEV] Fwd: [PHP-CVS] cvs: php4 /ext/bcmath bcmath.c/ext/bcmath/libbcmath/src bcmath.h init.c output.c raise.c raisemod.c recmul.csqrt.c str2num.c zero.c
I have backups of number.c and number.h but I see them in Attic/ so it might be better to restore them so that we keep the history. Anyone know how to do it? mv Attic/number* . doesn't seem to work. Andi At 10:08 PM 11/20/2002 +0200, Andi Gutmans wrote: There seems to be some bug in CVS. After I reverted this patch number.c and number.h from within ext/bcmath are missing. If I erase them and do a cvs update I don't get them anymore. I definitely didn't remove them. Anyone have any idea? Andi From: Andi Gutmans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 20 Nov 2002 19:48:13 - Subject: [PHP-CVS] cvs: php4 /ext/bcmath bcmath.c /ext/bcmath/libbcmath/src bcmath.h init.c output.c raise.c raisemod.c recmul.c sqrt.c str2num.c zero.c X-Bogosity: No, tests=bogofilter, spamicity=0.255710, version=0.8.0 andiWed Nov 20 14:48:13 2002 EDT Modified files: /php4/ext/bcmathbcmath.c /php4/ext/bcmath/libbcmath/src bcmath.h init.c output.c raise.c raisemod.c recmul.c sqrt.c str2num.c zero.c Log: - Intermediate commit which works on making bcmath thread-safe. -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Fwd: [PHP-CVS] cvs: php4 /ext/bcmath bcmath.c /ext/bcmath/libbcmath/src bcmath.h init.c output.c raise.c raisemod.c recmul.c sqrt.c str2num.c zero.c
well. the cvs log for these files show Zeev deleted them 3 years ago (after removing the content). They were GPL'ed, so clearly deleting them was the only option... number.c 1.7 zeev3 yearsWe'll have to live without these files somehow. number.h 1.5 zeev3 yearsWe'll have to live without these files somehow. http://cvs.php.net/cvs.php/php4/ext/bcmath?login=2sa=1 obviously your commit revert caused the files to diseapear from your checkout -- but i noticed them in my checkouts, and they were still present. more cvs wierdness, and more reason to look for an alternative. -- james -Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 8:14 PM To: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Fwd: [PHP-CVS] cvs: php4 /ext/bcmath bcmath.c /ext/bcmath/libbcmath/src bcmath.h init.c output.c raise.c raisemod.c recmul.c sqrt.c str2num.c zero.c I have backups of number.c and number.h but I see them in Attic/ so it might be better to restore them so that we keep the history. Anyone know how to do it? mv Attic/number* . doesn't seem to work. Andi At 10:08 PM 11/20/2002 +0200, Andi Gutmans wrote: There seems to be some bug in CVS. After I reverted this patch number.c and number.h from within ext/bcmath are missing. If I erase them and do a cvs update I don't get them anymore. I definitely didn't remove them. Anyone have any idea? Andi From: Andi Gutmans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 20 Nov 2002 19:48:13 - Subject: [PHP-CVS] cvs: php4 /ext/bcmath bcmath.c /ext/bcmath/libbcmath/src bcmath.h init.c output.c raise.c raisemod.c recmul.c sqrt.c str2num.c zero.c X-Bogosity: No, tests=bogofilter, spamicity=0.255710, version=0.8.0 andiWed Nov 20 14:48:13 2002 EDT Modified files: /php4/ext/bcmathbcmath.c /php4/ext/bcmath/libbcmath/src bcmath.h init.c output.c raise.c raisemod.c recmul.c sqrt.c str2num.c zero.c Log: - Intermediate commit which works on making bcmath thread-safe. -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Fwd: [PHP-CVS] cvs: php4 /ext/bcmath bcmath.c/ext/bcmath/libbcmath/src bcmath.h init.c output.c raise.c raisemod.c recmul.csqrt.c str2num.c zero.c
Yeah. Well they definitely existed because the author removed the GPL restriction and I was building it two hours ago :) Andi At 08:40 PM 11/20/2002 +, James Cox wrote: well. the cvs log for these files show Zeev deleted them 3 years ago (after removing the content). They were GPL'ed, so clearly deleting them was the only option... number.c 1.7 zeev3 yearsWe'll have to live without these files somehow. number.h 1.5 zeev3 yearsWe'll have to live without these files somehow. http://cvs.php.net/cvs.php/php4/ext/bcmath?login=2sa=1 obviously your commit revert caused the files to diseapear from your checkout -- but i noticed them in my checkouts, and they were still present. more cvs wierdness, and more reason to look for an alternative. -- james -Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 8:14 PM To: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Fwd: [PHP-CVS] cvs: php4 /ext/bcmath bcmath.c /ext/bcmath/libbcmath/src bcmath.h init.c output.c raise.c raisemod.c recmul.c sqrt.c str2num.c zero.c I have backups of number.c and number.h but I see them in Attic/ so it might be better to restore them so that we keep the history. Anyone know how to do it? mv Attic/number* . doesn't seem to work. Andi At 10:08 PM 11/20/2002 +0200, Andi Gutmans wrote: There seems to be some bug in CVS. After I reverted this patch number.c and number.h from within ext/bcmath are missing. If I erase them and do a cvs update I don't get them anymore. I definitely didn't remove them. Anyone have any idea? Andi From: Andi Gutmans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 20 Nov 2002 19:48:13 - Subject: [PHP-CVS] cvs: php4 /ext/bcmath bcmath.c /ext/bcmath/libbcmath/src bcmath.h init.c output.c raise.c raisemod.c recmul.c sqrt.c str2num.c zero.c X-Bogosity: No, tests=bogofilter, spamicity=0.255710, version=0.8.0 andiWed Nov 20 14:48:13 2002 EDT Modified files: /php4/ext/bcmathbcmath.c /php4/ext/bcmath/libbcmath/src bcmath.h init.c output.c raise.c raisemod.c recmul.c sqrt.c str2num.c zero.c Log: - Intermediate commit which works on making bcmath thread-safe. -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: PHP-QA Test Failed for 20021027
Hi, Can I see the log (bug16069.out) and the output of phpinfo() generated by the cli binary he built? I guess ICONV library identification was failed since FreeBSD version was also installed, and then preferred to libiconv by configure. Anyway I cannot confirm it now as I have no FreeBSD-installed box in hand. Moriyoshi Melvyn Sopacua [EMAIL PROTECTED] wrote: Something goes wrong here: SKIP Translit failure [ext/iconv/tests/translit-failure.phpt] (reason: ICONV_IMPL != libiconv) SKIP Translit UTF-8 quotes [ext/iconv/tests/translit-utf8.phpt] (reason: ICONV_IMPL != libiconv) --with-iconv=/usr/local, which is FreeBSD port libiconv 1.8_1 FreeBSD 4.7-STABLE via make world, 26/10 = FAILED TEST SUMMARY - Bug #16069 [ext/iconv/tests/bug16069.phpt] = gmake: *** [test] Error 1 With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_execute.c phpdoc/scripts revcheck.php
Nothign to worry, you triggered a race condition of the
script which generates this messages. We've seen this not the
first time.
Actually, someone else commited something the very same
moment it seems:
2002-10-23 22:26 tom
* revcheck.php:
added file-sizes to files without rev-tag, changed
size-limit for critical files from 10 to 3kB
and
2002-10-23 22:26 andi
* zend_execute.c:
- Make Ts access a macro. I need this for my next patch
which should
- improve performance but not sure yet if it will.
On Wed, Oct 23, 2002 at 10:33:00PM +0200, Andi Gutmans wrote :
Any idea how that revcheck.php diff got into my Engine 2 patch? I commited
from within the Zend/ directory.
Should something be reverted there?
Andi
Delivered-To: [EMAIL PROTECTED]
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
list-help: mailto:zend-engine-cvs-help;lists.php.net
list-unsubscribe: mailto:zend-engine-cvs-unsubscribe;lists.php.net
list-post: mailto:zend-engine-cvs;lists.php.net
Delivered-To: mailing list [EMAIL PROTECTED]
From: Andi Gutmans [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Wed, 23 Oct 2002 20:26:27 -
X-Spam-Status: No, tests=bogofilter, spamicity=0.0% likelihood
Subject: [ZEND-ENGINE-CVS] cvs: ZendEngine2 /
zend_execute.c phpdoc/scripts revcheck.php
andiWed Oct 23 16:26:27 2002 EDT
Modified files:
/phpdoc/scripts revcheck.php
/ZendEngine2zend_execute.c
Log:
- Make Ts access a macro. I need this for my next patch which should
- improve performance but not sure yet if it will.
--
Zend Engine CVS Mailing List (http://cvs.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Index: phpdoc/scripts/revcheck.php
diff -u phpdoc/scripts/revcheck.php:1.30 phpdoc/scripts/revcheck.php:1.31
--- phpdoc/scripts/revcheck.php:1.30 Mon Oct 7 16:40:28 2002
+++ phpdoc/scripts/revcheck.php Wed Oct 23 16:26:27 2002
@@ -50,7 +50,7 @@
// A file is criticaly outdated' if
define(ALERT_REV, 10); // translation is 10 or more revisions behind the en one
-define(ALERT_SIZE, 10); // translation is 10 or more kB smaller than the en one
+define(ALERT_SIZE, 3); // translation is 3 or more kB smaller than the en one
define(ALERT_DATE, -30); // translation is 30 or more days older than the en one
// Revision marks used to flag files
@@ -231,10 +231,10 @@
}
// Get the parameter if we have it
-list($trans_file) = func_get_args();
+list($trans_file, $en_size, $trans_size, $size_diff) = func_get_args();
-// Push file name with missing tag on the list
-$missing_tags[] = substr($trans_file, strlen($DOCDIR));
+// Push data of file with missing tag onto the list
+$missing_tags[] = array(substr($trans_file, strlen($DOCDIR)), $en_size,
$trans_size, $size_diff);
}
// Collect files by status mark
@@ -323,14 +323,6 @@
$trans_tag = get_tag($trans_file, \\S*);
}
-// If we found no revision tag, then collect this
-// file in the missing tags list
-if (count($trans_tag) == 0) {
-files_by_mark(REV_NOTAG, 1);
-missing_tag($trans_file, $DOCDIR);
-return FALSE;
-}
-
// Distribute values in separate vars for further processing
list(, $this_rev, $this_maint, $this_status) = $trans_tag;
@@ -361,6 +353,14 @@
$trans_date = intval((time() - filemtime($trans_file)) / 86400);
$date_diff = $en_date - $trans_date;
+// If we found no revision tag, then collect this
+// file in the missing tags list
+if (count($trans_tag) == 0) {
+files_by_mark(REV_NOTAG, 1);
+missing_tag($trans_file, $en_size, $trans_size, $size_diff);
+return FALSE;
+}
+
// Make decision on file category by revision, date and size
if ($rev_diff === 0) {
$status_mark = REV_UPTODATE;
@@ -375,9 +375,6 @@
// Store files by status, and by maintainer too
files_by_mark ($status_mark, 1);
files_by_maint($status_mark, $this_maint);
-
-if ($rev_diff === 0 $this_maint == )
-echo $file.br\n;
return array(
full_name = $file,
@@ -999,24 +996,27 @@
if ($count 0) {
print a name=\misstags\/a .
table width=\400\ border=\0\ cellpadding=\3\ cellspacing=\1\
align=\center\\n.
- trth class=bluebFiles without Revision-comment ($count
files):/b/th/tr\n;
+ tr class=blueth rowspan=2bFiles without Revision-comment ($count
files):/b/th.
+ th colspan=3Sizes in kB/th/tr\n.
+ tr class=bluethen/thth$LANG/ththdiff/th/tr\n;
foreach($missing_tags as $val) {
// Shorten the filename (we have directory headers)
-$short_file = basename($val);
+$short_file = basename($val[0]);
// Guess the new directory from the full name of the file
-$new_dir =
Re: [PHP-DEV] Fwd: Re: [sab-php] sablotron instalation
On Tue, 8 Oct 2002, Melvyn Sopacua wrote: By the way: what about nuking ext/sablot? [derick@kossu php-4.3.0dev]$ ls -l ext/sablot ls: ext/sablot: No such file or directory It's already nuked :) Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: PHP fopen() CRLF Injection]
On Thu, Sep 12, 2002 at 10:47:12AM +0100, James Cox wrote: Stefan, is this really worth it? I think this will break too many scripts. -- james My change only changes parse_url() to remove characters that are invalid in urls. If such characters occur in an url that is passed to parse_url() this is DANGEROUS. And using such an url makes no sense cause whereever you store it and reread it is simply an invalid url. So if any script fails because of my change it is a bug in the script. (i cannot imagine a legal use of control characters in urls in any script ...) Stefan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: PHP fopen() CRLF Injection]
Hey, AFAIK Stefan already took care of this. Stefan? Derick On Thu, 12 Sep 2002, Yasuo Ohgaki wrote: FYI We got close one that Jani mentioned in bug db :) It's user's problem, but I'm sure there are many scripts do not check user input enough. We're probably better to mention security risks more in the manual... -- Yasuo Ohgaki Original Message Subject: PHP fopen() CRLF Injection Date: Mon, 9 Sep 2002 23:23:01 +0200 (CEST) From: Ulf Harnhammar [EMAIL PROTECTED] To: [EMAIL PROTECTED] PHP fopen() CRLF Injection PROGRAM: PHP VENDOR: The PHP Group [EMAIL PROTECTED] HOMEPAGE: http://www.php.net/ VULNERABLE VERSIONS: 4.1.2, 4.2.2, 4.2.3, latest CVS, possibly others IMMUNE VERSIONS: none, but workarounds exist SEVERITY: medium DESCRIPTION: PHP is a widely-used Open Source general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. Its syntax draws upon C, Java, and Perl, and is easy to learn. PHP runs on many different platforms and can be used as a standalone executable or as a module under a variety of Web servers. It has excellent support for databases, XML, LDAP, IMAP, Java, various Internet protocols, and general data manipulation, and is extensible via its powerful API. (direct quote from the program's project page at Freshmeat) PHP is published under the terms of The PHP License. It is installed on millions of web servers. SUMMARY: fopen(), file() and other functions in PHP have a vulnerability that makes it possible to add extra HTTP headers to HTTP queries. Attackers may use it to escape certain restrictions, like what host to access on a web server. In some cases, this vulnerability even opens up for arbitrary net connections, turning some PHP scripts into proxies and open mail relays. TECHNICAL DETAILS: PHP has several functions that take filenames as one of their arguments: fopen(), file() and some others. If allow_url_fopen is set to On in php.ini, those functions also accept URLs instead of regular files, and they connect to the server in question with the correct protocol. This functionality is vulnerable to some CRLF Injection attacks. 1) We start with the simple attacks. Let's say that this PHP snippet is saved as snippet.php: ?php echo 'pre'; print_r(file(http://www.site1.st/api?sunnan=$sunnanvind=$vind;)); echo '/pre'; ? If an attacker surfs to: snippet.php?sunnan=visbyvind=gotland%20HTTP/1.0%0D%0AHost%3A%20www. site2.st%0D%0AUser-Agent%3A%20Ulf/0.0%0D%0AReferer%3A%20http%3A%2F %2Fwww.gnuheter.org%2F%0D%0ACookie%3A%20user%3Dulf%0D%0A%0D%0A (should be on one line) this HTTP query will be sent to www.site1.st: GET /api?sunnan=visbyvind=gotland HTTP/1.0 Host: www.site2.st User-Agent: Ulf/0.0 Referer: http://www.gnuheter.org/ Cookie: user=ulf HTTP/1.0 Host: www.site1.st User-Agent: PHP/4.1.2 As you can see, the real headers from PHP are sent as well, but the web server ignores them, as we send two CRLFs before them to indicate that the headers are over. Using this technique, we can add arbitrary user agents, referers and cookies. We can also break out of restrictions and access site2.st instead of the site site1.st that snippet.php tries to restrict us to, if site1.st and site2.st are virtual hosts on the same machine. 2) If the PHP script is even worse, like this one called dotcom.php: ?php $fp = fopen($url, 'r'); fpassthru($fp); ? we can connect to arbitrary ports and send (almost) arbitrary commands, thus turning the dotcom.php script into a proxy and an open mail relay. If we surf to: dotcom.php?url=http%3A%2F%2Fmail.site1.st%3A25%2F+HTTP/1.0%0D%0AHELO+ my.own.machine%0D%0AMAIL+FROM%3A%3Cme%40my.own.machine%3E%0D%0ARCPT+ TO%3A%3Cinfo%40site1.st%3E%0D%0ADATA%0D%0Ai+will+never+say+the+word+ PROCRASTINATE+again%0D%0A.%0D%0AQUIT%0D%0A%0D%0A (should be on one line) the PHP interpreter will connect to mail.site1.st on port 25, and send the following commands: GET / HTTP/1.0 HELO my.own.machine MAIL FROM:[EMAIL PROTECTED] RCPT TO:[EMAIL PROTECTED] DATA i will never say the word PROCRASTINATE again . QUIT HTTP/1.0 Host: mail.site1.st:25 User-Agent: PHP/4.1.2 Both PHP and the MTA will complain, but the mail is still sent. FURTHER READING: For more information about this group of problems, read my CRLF Injection paper, which is available at http://online.securityfocus.com/archive/1/271515 COMMUNICATION WITH VENDOR: All contact methods I could find were very public, like mailing lists and bug tracking systems. I ended up entering this security hole into their bug tracking system (as number 19160) on the 28th of August. The PHP developers are working on fixing this bug, but nothing have been committed to their CVS yet. I am releasing this anyway, as it is already public in their bug tracking system and as Matthew
Re: [PHP-DEV] [Fwd: PHP fopen() CRLF Injection]
Hi, We got close one that Jani mentioned in bug db :) It's user's problem, but I'm sure there are many scripts do not check user input enough. We're probably better to mention security risks more in the manual... I fixed this issue in CVS in the way that parse_url() removes control chars from urls when it splits them but infact any url passed to fopen MUST be urlencode()d. Stefan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: REJECTED:5.1.0.14.2.20020607225328.03df2740@127.0.0.1
Somebody from PRESENCE-GROUP.COM is subscribed to php-dev list and is
filtering mail through spamcop or something program. I am getting
them to.
Brian
At 10:58 PM +0300 6/7/02, Andi Gutmans wrote:
Any idea why I got this when posting to php-dev?
Andi
Delivered-To: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED] (reject)
Date: Thu, 06 Jun 2002 08:50:05 -0700
X-Autogenerated: Reply
To: Andi Gutmans [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
Subject: REJECTED: [EMAIL PROTECTED]
X-Autogenerated: UNSOLICITED ELECTRONIC COMMUNICATION
Sender: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Original-Message-ID: [EMAIL PROTECTED]
Original-Sender: Andi Gutmans [EMAIL PROTECTED]
Original-Subject: Re: [PHP-DEV] Zend Engine expert wanted
Original-Date: Fri, 07 Jun 2002 22:53:42 +0300
SERVICE of LEGAL NOTICE:
Pursuant to California Law (cref. California Business Professions Code
§§ 17538.4, 17538.45 (2001)), the message referenced herein, uniquely
identified by the following Internet messaging headers:
{
Original-Message-ID:
[EMAIL PROTECTED]
Original-Sender: Andi Gutmans [EMAIL PROTECTED]
Original-Subject: Re: [PHP-DEV] Zend Engine expert wanted
Original-Date: Fri, 07 Jun 2002 22:53:42 +0300
}
has been categorized as either Unsolicited Bulk E-mail (UBE), or
Unsolicited Commercial E-Mail (UCE).
Your server is one of those included in the headers of the message, and
thus has been deemed an offending server used in the delivery of
this message.
California Law establishes Civil Right of Action against violators:
In addition to any other action available under law, any
electronic mail service provider whose policy on unsolicited
electronic mail advertisements is violated as provided in this
section may bring a civil action to recover the actual monetary loss
suffered by that provider by reason of that violation, or liquidated
damages of fifty dollars ($50) for each electronic mail message
initiated or delivered in violation of this section, up to a maximum
of twenty-five thousand dollars ($25,000) per day, whichever amount
is greater.
Your cooperation, as outlined below, is REQUIRED by California Law.
To avoid being cited as an accomplice in this matter, PRESENCE-GROUP.COM
requires you to take immediate and appropriate actions to stop the problem
in the future. You are to notify us within three (3) days of those actions.
Our experience shows that all legitimate Internet providers take
immediate action.
If your server is an offending server in the *origination* of this message,
PRESENCE-GROUP.COM demands that you provide us with the name, mailing address
and other contact information of the originator of this message.
If you furnish PRESENCE-GROUP.COM with this information, PRESENCE-GROUP.COM
will release you from liability in this incident. Merely telling us you have
cancelled or deleted the account is *not* adequate to satisfy the
PRESENCE-GROUP.COM policy.
If your server is an offending server in the *relay* of this message,
PRESENCE-GROUP.COM demands that you take measures to stop the open relay
from your insecure mailserver.
If you do not furnish PRESENCE-GROUP.COM with the information we
have requested,
or provide us only with auto-responder or form messages,
PRESENCE-GROUP.COM will
consider how often your server is involved with UBE/UCE. We may then:
1. Block access to from your server.
2. Deem you to be a co-conspirator in the delivery of
UBE/UCE messages.
3. Hold you liable for fees damages.
There is no need for you to send your appropriate use policy to us;
As stated by law,
it is our policy that governs.
In order to provide required response to this notice, or if you
believe you have
received this notice in error, please forward your communication to:
[EMAIL PROTECTED], with the words SPAM EXCEPTION
exactly included in
the message Subject: header.
Further, you may choose to notify your intended recipient by an additional,
alternate method requesting that they address this matter with the
PRESENCE-GROUP.COM mail server administrator.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: REJECTED: 5.1.0.14.2.20020607225328.03df2740@127.0.0.1
I got it too..
- brad
--- Andi Gutmans [EMAIL PROTECTED] wrote:
Any idea why I got this when posting to php-dev?
Andi
Delivered-To: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED] (reject)
Date: Thu, 06 Jun 2002 08:50:05 -0700
X-Autogenerated: Reply
To: Andi Gutmans [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
Subject: REJECTED: [EMAIL PROTECTED]
X-Autogenerated: UNSOLICITED ELECTRONIC COMMUNICATION
Sender: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Original-Message-ID: [EMAIL PROTECTED]
Original-Sender: Andi Gutmans [EMAIL PROTECTED]
Original-Subject: Re: [PHP-DEV] Zend Engine expert wanted
Original-Date: Fri, 07 Jun 2002 22:53:42 +0300
SERVICE of LEGAL NOTICE:
Pursuant to California Law (cref. California Business Professions Code
§§ 17538.4, 17538.45 (2001)), the message referenced herein, uniquely
identified by the following Internet messaging headers:
{
Original-Message-ID:
[EMAIL PROTECTED]
Original-Sender: Andi Gutmans [EMAIL PROTECTED]
Original-Subject: Re: [PHP-DEV] Zend Engine expert
wanted
Original-Date: Fri, 07 Jun 2002 22:53:42 +0300
}
has been categorized as either Unsolicited Bulk E-mail (UBE), or
Unsolicited Commercial E-Mail (UCE).
Your server is one of those included in the headers of the message, and
thus has been deemed an offending server used in the delivery of this
message.
California Law establishes Civil Right of Action against violators:
In addition to any other action available under law, any
electronic mail service provider whose policy on unsolicited
electronic mail advertisements is violated as provided in this
section may bring a civil action to recover the actual monetary
loss
suffered by that provider by reason of that violation, or
liquidated
damages of fifty dollars ($50) for each electronic mail message
initiated or delivered in violation of this section, up to a
maximum
of twenty-five thousand dollars ($25,000) per day, whichever amount
is greater.
Your cooperation, as outlined below, is REQUIRED by California Law.
To avoid being cited as an accomplice in this matter, PRESENCE-GROUP.COM
requires you to take immediate and appropriate actions to stop the problem
in the future. You are to notify us within three (3) days of those actions.
Our experience shows that all legitimate Internet providers take immediate
action.
If your server is an offending server in the *origination* of this message,
PRESENCE-GROUP.COM demands that you provide us with the name, mailing
address
and other contact information of the originator of this message.
If you furnish PRESENCE-GROUP.COM with this information, PRESENCE-GROUP.COM
will release you from liability in this incident. Merely telling us you have
cancelled or deleted the account is *not* adequate to satisfy the
PRESENCE-GROUP.COM policy.
If your server is an offending server in the *relay* of this message,
PRESENCE-GROUP.COM demands that you take measures to stop the open relay
from your insecure mailserver.
If you do not furnish PRESENCE-GROUP.COM with the information we have
requested,
or provide us only with auto-responder or form messages,
PRESENCE-GROUP.COM will
consider how often your server is involved with UBE/UCE. We may then:
1. Block access to from your server.
2. Deem you to be a co-conspirator in the delivery of UBE/UCE
messages.
3. Hold you liable for fees damages.
There is no need for you to send your appropriate use policy to us; As
stated by law,
it is our policy that governs.
In order to provide required response to this notice, or if you believe
you have
received this notice in error, please forward your communication to:
[EMAIL PROTECTED], with the words SPAM EXCEPTION exactly
included in
the message Subject: header.
Further, you may choose to notify your intended recipient by an additional,
alternate method requesting that they address this matter with the
PRESENCE-GROUP.COM mail server administrator.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Sorry! Re: [PHP-DEV] Fwd: REJECTED:5.1.0.14.2.20020607225328.03df2740@127.0.0.1
sorry abt that .. an overzealous SPAM filter triggered on your three
exclamation points . in your SUBJECT
should be fixed now :-S
--On Friday, June 7, 2002 10:58 PM +0300 Andi Gutmans [EMAIL PROTECTED] wrote:
Any idea why I got this when posting to php-dev?
Andi
Delivered-To: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED] (reject)
Date: Thu, 06 Jun 2002 08:50:05 -0700
X-Autogenerated: Reply
To: Andi Gutmans [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
Subject: REJECTED: [EMAIL PROTECTED]
X-Autogenerated: UNSOLICITED ELECTRONIC COMMUNICATION
Sender: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Original-Message-ID: [EMAIL PROTECTED]
Original-Sender: Andi Gutmans [EMAIL PROTECTED]
Original-Subject: Re: [PHP-DEV] Zend Engine expert wanted
Original-Date: Fri, 07 Jun 2002 22:53:42 +0300
SERVICE of LEGAL NOTICE:
Pursuant to California Law (cref. California Business Professions Code
§§ 17538.4, 17538.45 (2001)), the message referenced herein, uniquely
identified by the following Internet messaging headers:
{
Original-Message-ID:
[EMAIL PROTECTED]
Original-Sender: Andi Gutmans [EMAIL PROTECTED]
Original-Subject: Re: [PHP-DEV] Zend Engine expert
wanted Original-Date: Fri, 07 Jun 2002 22:53:42 +0300
}
has been categorized as either Unsolicited Bulk E-mail (UBE), or
Unsolicited Commercial E-Mail (UCE).
Your server is one of those included in the headers of the message, and
thus has been deemed an offending server used in the delivery of this
message.
California Law establishes Civil Right of Action against violators:
In addition to any other action available under law, any
electronic mail service provider whose policy on unsolicited
electronic mail advertisements is violated as provided in this
section may bring a civil action to recover the actual monetary
loss suffered by that provider by reason of that violation, or
liquidated damages of fifty dollars ($50) for each electronic
mail message initiated or delivered in violation of this
section, up to a maximum of twenty-five thousand dollars
($25,000) per day, whichever amount is greater.
Your cooperation, as outlined below, is REQUIRED by California Law.
To avoid being cited as an accomplice in this matter, PRESENCE-GROUP.COM
requires you to take immediate and appropriate actions to stop the
problem in the future. You are to notify us within three (3) days of
those actions. Our experience shows that all legitimate Internet
providers take immediate action.
If your server is an offending server in the *origination* of this
message, PRESENCE-GROUP.COM demands that you provide us with the name,
mailing address and other contact information of the originator of this
message. If you furnish PRESENCE-GROUP.COM with this information,
PRESENCE-GROUP.COM will release you from liability in this incident.
Merely telling us you have cancelled or deleted the account is *not*
adequate to satisfy the PRESENCE-GROUP.COM policy.
If your server is an offending server in the *relay* of this message,
PRESENCE-GROUP.COM demands that you take measures to stop the open
relay from your insecure mailserver.
If you do not furnish PRESENCE-GROUP.COM with the information we have
requested,
or provide us only with auto-responder or form messages,
PRESENCE-GROUP.COM will
consider how often your server is involved with UBE/UCE. We may then:
1. Block access to from your server.
2. Deem you to be a co-conspirator in the delivery of UBE/UCE
messages.
3. Hold you liable for fees damages.
There is no need for you to send your appropriate use policy to us; As
stated by law,
it is our policy that governs.
In order to provide required response to this notice, or if you believe
you have
received this notice in error, please forward your communication to:
[EMAIL PROTECTED], with the words SPAM EXCEPTION exactly
included in
the message Subject: header.
Further, you may choose to notify your intended recipient by an
additional, alternate method requesting that they address this matter
with the PRESENCE-GROUP.COM mail server administrator.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Sorry! Re: [PHP-DEV] Fwd: REJECTED: 5.1.0.14.2.20020607225328.03df2740@127.0.0.1
Richard S. Blake [EMAIL PROTECTED] wrote: sorry abt that .. an overzealous SPAM filter triggered on your three exclamation points . in your SUBJECT should be fixed now :-S you should further fix your spam system to bounce to the SMTP envelope sender instead of whatever broken thing it is doing now. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: Re: libxml2 - php
Hello, as you see he also gave the good reasons why NOT bundling it with PHP for which I am too. - Markus On Wed, May 29, 2002 at 04:53:48PM -0700, brad lafountain wrote : --- Daniel Veillard [EMAIL PROTECTED] wrote: Date: Wed, 29 May 2002 23:28:11 +0200 From: Daniel Veillard [EMAIL PROTECTED] To: brad lafountain [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: libxml2 - php Reply-to: [EMAIL PROTECTED] On Wed, May 29, 2002 at 10:35:44AM -0700, brad lafountain wrote: Hello, I'm a developer for php. We were recently talking about bundling libxml2 with the php distribution. I'm not to sure about the licensing issues involved here but I figured I'd just ask you and get your permission. Let me know your thoughts/concerns. libxml2 is licenced under the MIT Licence, I honnestly don't think bundling would be a problem at that level. However on a practical basis it would be better that you use the existing shared library if libxml2 is already installed on the system rather than always including it in the PHP module/binary. Others Apache modules may use libxml2 too and sharing the same instance can make a big change. for maintainance too ! Daniel -- Daniel Veillard | Red Hat Network http://redhat.com/products/network/ [EMAIL PROTECTED] | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Wishlist: http://guru.josefine.at/~mfischer/wishlist -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: new dns function, gethostent]
At 23:13 18.04.2002, Shane Caraveo wrote:
Hi everyone,
I have a need not fullfilled by the current short set of dns functions
(no way to retrieve aliases), so I wrote a 'gethostent' function, which
accepts either hostname or ip, and returns a hash equivelant of the C
hostent struct. patch is attached, if no objections in the next couple
hours I'll commit it.
Shane
Why not use a more meaningful functionname? Something like gethostentry?
? dns.diff
Index: basic_functions.c
===
RCS file: /repository/php4/ext/standard/basic_functions.c,v
retrieving revision 1.470
diff -d -u -r1.470 basic_functions.c
--- basic_functions.c 16 Apr 2002 22:14:19 - 1.470
+++ basic_functions.c 18 Apr 2002 20:50:42 -
-406,6 +406,7
PHP_FE(gethostbyaddr,
NULL)
PHP_FE(gethostbyname,
NULL)
PHP_FE(gethostbynamel,
NULL)
+ PHP_FE(gethostent,
NULL)
#if HAVE_RES_SEARCH !(defined(__BEOS__) || defined(PHP_WIN32))
PHP_FE(checkdnsrr,
NULL)
Index: dns.c
===
RCS file: /repository/php4/ext/standard/dns.c,v
retrieving revision 1.38
diff -d -u -r1.38 dns.c
--- dns.c 28 Feb 2002 08:26:44 - 1.38
+++ dns.c 18 Apr 2002 20:50:42 -
-63,7 +63,7
#include dns.h
/* }}} */
-static char *php_gethostbyaddr(char *ip);
+struct hostent *php_gethostbyaddr(char *ip);
static char *php_gethostbyname(char *name);
/* {{{ proto string gethostbyaddr(string ip_address)
-71,7 +71,8
PHP_FUNCTION(gethostbyaddr)
{
zval **arg;
- char *addr;
+ char *addr, *ip;
+ struct hostent *hp;
if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, arg) ==
FAILURE) {
ZEND_WRONG_PARAM_COUNT();
-79,7 +80,14
convert_to_string_ex(arg);
- addr = php_gethostbyaddr(Z_STRVAL_PP(arg));
+ip = Z_STRVAL_PP(arg);
+ hp = php_gethostbyaddr(ip);
+ if (!hp) {
+ addr = estrdup(ip);
+ } else {
+ addr = estrdup(hp-h_name);
+ }
+
if(addr == NULL) {
#if HAVE_IPV6 !defined(__MacOSX__)
-96,9 +104,80
}
/* }}} */
+
+/* {{{ proto string gethostent(string ip_address|host)
+ Get the Internet hostent structure corresponding to a given IP address
or host name */
+PHP_FUNCTION(gethostent)
+{
+ zval **arg, *hostent_alias=NULL, *hostent_addr_list=NULL;
+ char *ip;
+ struct hostent *hp;
+ struct in_addr in;
+ int i;
+
+ if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, arg) ==
FAILURE) {
+ ZEND_WRONG_PARAM_COUNT();
+ }
+
+ convert_to_string_ex(arg);
+
+ /* start with clean arrays */
+ pval_destructor(return_value);
+ if ( array_init(return_value) == FAILURE ) {
+ RETURN_FALSE;
+ }
+
+ ip = Z_STRVAL_PP(arg);
+ hp = php_gethostbyaddr(ip);
+ if (!hp) {
+ /* not an ip address, try it as a hostname */
+ hp = gethostbyname(ip);
+ }
+
+if (!hp) {
+ RETVAL_FALSE;
+ }
+
+ MAKE_STD_ZVAL(hostent_alias);
+ MAKE_STD_ZVAL(hostent_addr_list);
+ if ( array_init(hostent_alias) == FAILURE ||
+array_init(hostent_addr_list) == FAILURE) {
+ RETURN_FALSE;
+ }
+
+ add_assoc_string(return_value, name, hp-h_name, 1);
+ add_assoc_long(return_value, addrtype, hp-h_addrtype);
+ add_assoc_long(return_value, length, hp-h_length);
+ /* make a sublist of aliases */
+ if (hp-h_aliases[0]) {
+ for (i = 0 ; hp-h_aliases[i] != 0 ; i++) {
+ add_next_index_string(hostent_alias,
hp-h_aliases[i], 1);
+ }
+ zend_hash_update(return_value-value.ht, aliases,
strlen(aliases) + 1, (void *)hostent_alias, sizeof(zval *), NULL);
+ } else {
+ add_assoc_null(return_value, aliases);
+ }
+ if (hp-h_addr_list[0]) {
+ for (i = 0 ; hp-h_addr_list[i] != 0 ; i++) {
+ in = *(struct in_addr *) hp-h_addr_list[i];
+ add_next_index_string(hostent_addr_list,
inet_ntoa(in), 1);
+ if (i ==0) {
+ add_assoc_string(return_value, addr,
inet_ntoa(in), 1);
+ }
+ }
+ zend_hash_update(return_value-value.ht, addr_list,
strlen(addr_list) + 1, (void *)hostent_addr_list, sizeof(zval *), NULL);
+ } else {
+ add_assoc_null(return_value, addr);
+ add_assoc_null(return_value,
Re: [PHP-DEV] [Fwd: posix_uname another bug @^|[@#\@^#~@{[?]
Why do you think apache gets a segfault?
The only thing is the the 'domainname' key is missing from
the hash although it should display the content of
__domainname (on non-bsd systems)
I'm willing to fix it if someone comes up with a proper patch
that also honors BSD. It's not very critical I think (until I
miss the obvious).
- Markus
On Sun, Mar 24, 2002 at 12:16:41PM +0100, Vergoz Michael (SYSDOOR) wrote :
Date: Sun, 24 Mar 2002 12:03:42 +0100
From: Vergoz Michael (SYSDOOR) [EMAIL PROTECTED]
Subject: posix_uname another bug @^|[@#\@^#~@{[?
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214
To: php-qa [EMAIL PROTECTED]
From - Sun Mar 24 12:03:43 2002
X-Mozilla-Status2:
refere include file : sys/utsname.h !
You can see if the macro __USE_GNU is set the char returned are
'domainname' else the char are '__domainname' #@\[@~\
You know this function can do a apache segfault ?!
Becarful cuz domainename doesn't exist on freebsd !
there is the current (PHP-4.2.0RC1) code on : ext/posix/posix.c
/* {{{ proto array posix_uname(void)
Get system name (POSIX.1, 4.4.1) */
PHP_FUNCTION(posix_uname)
{
struct utsname u;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, ) == FAILURE)
return;
if (uname(u) 0) {
POSIX_G(last_error) = errno;
RETURN_FALSE;
}
if (array_init(return_value) == FAILURE) {
// TODO: Should we issue a warning here so we don't have ambiguity
// with the above return value ?
RETURN_FALSE;
}
add_assoc_string(return_value, sysname, u.sysname, 1);
add_assoc_string(return_value, nodename, u.nodename, 1);
add_assoc_string(return_value, release, u.release, 1);
add_assoc_string(return_value, version, u.version, 1);
add_assoc_string(return_value, machine, u.machine, 1);
#ifdef _GNU_SOURCE/* i'm okay */
add_assoc_string(return_value, domainname, u.domainname, 1); /* -
{|^@#\|^[#\ */
#endif
}
/* }}} */
/*Fixed
code--*/
/* {{{ proto array posix_uname(void)
Get system name (POSIX.1, 4.4.1) */
PHP_FUNCTION(posix_uname)
{
struct utsname u;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, ) == FAILURE)
return;
if (uname(u) 0) {
POSIX_G(last_error) = errno;
RETURN_FALSE;
}
if (array_init(return_value) == FAILURE) {
// TODO: Should we issue a warning here so we don't have ambiguity
// with the above return value ?
RETURN_FALSE;
}
add_assoc_string(return_value, sysname, u.sysname, 1);
add_assoc_string(return_value, nodename, u.nodename, 1);
add_assoc_string(return_value, release, u.release, 1);
add_assoc_string(return_value, version, u.version, 1);
add_assoc_string(return_value, machine, u.machine, 1);
#ifdef _GNU_SOURCE
#ifdef __USE_GNU
add_assoc_string(return_value, domainname, u.domainname, 1);
#else
add_assoc_string(return_value, domainname, u.__domainname, 1);
#endif
#endif
}
/* }}} */
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
Please always Cc to me when replying to me on the lists.
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: posix_uname another bug @^|[@#\@^#~@{[?]
have you reveiv the pgsql.c optimization code ?
(is nothing to fix le utsname ;))
another question : how to become a php developer ?
- Original Message -
From: Markus Fischer [EMAIL PROTECTED]
To: Vergoz Michael (SYSDOOR) [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, March 24, 2002 12:51 PM
Subject: Re: [PHP-DEV] [Fwd: posix_uname another bug @^|[@#\@^#~@{[?]
Why do you think apache gets a segfault?
sorry not segfault but compilation problem ;)
The only thing is the the 'domainname' key is missing from
the hash although it should display the content of
__domainname (on non-bsd systems)
I'm willing to fix it if someone comes up with a proper patch
that also honors BSD. It's not very critical I think (until I
miss the obvious).
- Markus
On Sun, Mar 24, 2002 at 12:16:41PM +0100, Vergoz Michael (SYSDOOR) wrote :
Date: Sun, 24 Mar 2002 12:03:42 +0100
From: Vergoz Michael (SYSDOOR) [EMAIL PROTECTED]
Subject: posix_uname another bug @^|[@#\@^#~@{[?
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8)
Gecko/20020214
To: php-qa [EMAIL PROTECTED]
From - Sun Mar 24 12:03:43 2002
X-Mozilla-Status2:
refere include file : sys/utsname.h !
You can see if the macro __USE_GNU is set the char returned are
'domainname' else the char are '__domainname' #@\[@~\
You know this function can do a apache segfault ?!
Becarful cuz domainename doesn't exist on freebsd !
there is the current (PHP-4.2.0RC1) code on : ext/posix/posix.c
/* {{{ proto array posix_uname(void)
Get system name (POSIX.1, 4.4.1) */
PHP_FUNCTION(posix_uname)
{
struct utsname u;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, ) == FAILURE)
return;
if (uname(u) 0) {
POSIX_G(last_error) = errno;
RETURN_FALSE;
}
if (array_init(return_value) == FAILURE) {
// TODO: Should we issue a warning here so we don't have
ambiguity
// with the above return value ?
RETURN_FALSE;
}
add_assoc_string(return_value, sysname, u.sysname, 1);
add_assoc_string(return_value, nodename, u.nodename, 1);
add_assoc_string(return_value, release, u.release, 1);
add_assoc_string(return_value, version, u.version, 1);
add_assoc_string(return_value, machine, u.machine, 1);
#ifdef _GNU_SOURCE/* i'm okay */
add_assoc_string(return_value, domainname, u.domainname, 1); /* -
{|^@#\|^[#\ */
#endif
}
/* }}} */
/*Fixed
code--*/
/* {{{ proto array posix_uname(void)
Get system name (POSIX.1, 4.4.1) */
PHP_FUNCTION(posix_uname)
{
struct utsname u;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, ) == FAILURE)
return;
if (uname(u) 0) {
POSIX_G(last_error) = errno;
RETURN_FALSE;
}
if (array_init(return_value) == FAILURE) {
// TODO: Should we issue a warning here so we don't have
ambiguity
// with the above return value ?
RETURN_FALSE;
}
add_assoc_string(return_value, sysname, u.sysname, 1);
add_assoc_string(return_value, nodename, u.nodename, 1);
add_assoc_string(return_value, release, u.release, 1);
add_assoc_string(return_value, version, u.version, 1);
add_assoc_string(return_value, machine, u.machine, 1);
#ifdef _GNU_SOURCE
#ifdef __USE_GNU
add_assoc_string(return_value, domainname, u.domainname, 1);
#else
add_assoc_string(return_value, domainname, u.__domainname, 1);
#endif
#endif
}
/* }}} */
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
Please always Cc to me when replying to me on the lists.
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: posix_uname another bug @^|[@#\@^#~@{[?]
Vergoz Michael wrote: have you reveiv the pgsql.c optimization code ? (is nothing to fix le utsname ;)) No. I didn't get any patch. Could mail me. another question : how to become a php developer ? Submit sevral patches? then apply CVS account? -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: [PATCH] add appname argument to sybase_connect]
Hello, I applied it. Can you also write some documentation about it? regards, Derick On Wed, 6 Mar 2002, Christophe Sollet wrote: Hello, I resubmit this patch again since i didn't get any reply from my previous post. Please get a look at it and, at least, let me know if you think this patch is useless... If not, it would be great if it can be merged before 22:00 ;) Thanks, Christophe. Original Message Subject: [PATCH] add appname argument to sybase_connect Date: Mon, 04 Mar 2002 17:28:55 +0100 From: Christophe Sollet [EMAIL PROTECTED] Organization: Coleebris To: [EMAIL PROTECTED] Attached patch add an optional 'appname' argument to sybase_connect (both ct and db interface). The first goal of this patch is, obviously, to be able to set the appname to something more informative that just 'PHP 4.0' if your db server is php dedicaced. Futhermore, it's allow to make separate connections in the same script to the same db since the appname become part of the hashed details : It's needed when, for example, you have a connection inside a transaction and you have to make a query that can't be done inside this transaction. Without this patch, this sort of things is impossible in PHP (or you have to play with the case of the username to fool the hashed_details...). The patch is well tested with the ct interface (applied on our systems from several weeks) and poorly tested with the db interface (simple connect test). Could someone review it and commit it (it's against current CVS) ? Christophe. -- -- Christophe Sollet [EMAIL PROTECTED] http://www.coleebris.com Tél: 01.40.50.60.47 Fax: 01.40.50.67.66 -- -- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Site Resource Manager - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: [PATCH] add appname argument to sybase_connect]
[EMAIL PROTECTED] wrote: Hello, I applied it. Can you also write some documentation about it? Thanks. At least, i can try... : int sybase_connect ( string servername, string username, string password [, string charset [, string appname]]) int sybase_pconnect ( string servername, string username, string password [, string charset [, string appname]]) optional argument appname : set the appname used by the sybase connection to something else than the default string PHP 4.0. This string will appear in the table sysprocesses (or in the Sybase GUI) and can be used to track connections more easely. As a side effect, it can be used to create distinct connections. This can be usefull sometimes : $c1 = sybase_connect(servername, username, password, charset, c1); $c2 = sybase_connect(servername, username, password, charset, c2); c1 : begin transaction c1 : ... query ... c2 : make a query that can't be achieved in trans. (ie. create temp table without DDL_IN_TRANS on tempdb). c1 : ... query ... c1 : commit|rollback transaction Hope that can help, Christophe. -- -- Christophe Sollet [EMAIL PROTECTED] http://www.coleebris.com Tél: 01.40.50.60.47 Fax: 01.40.50.67.66 -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: [PHP-CVS] cvs: php4 /ext/mcve mcve.c]
Hi, On Thu, 28 Feb 2002 17:48:57 +0100 Sebastian Bergmann [EMAIL PROTECTED] wrote: Next, we heavily support the MacOS X community, but last I checked, PEAR wouldn't even compile on OS X, so this would inhibit OS X users from using our module. PEAR is a repository, it is not supposed to compile. If there are installation problems, please open a bug report on http://bugs.php.net/ Last, what exactly is PEAR / PECL ? I can't find anyone to give me a good explaination ... Most people don't know it's actual purpose, and people that seem to know, say it isn't organized/finalized http://pear.php.net/ Jan -- Q: Thank Jan? A: http://geschenke.an.dasmoped.net/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: [PHP-CVS] cvs: php4 /ext/mcve mcve.c]
Sebastian Bergmann wrote: First of all, why does this not belong in ext/ as CCVS/CyberCash/etc does ? The extensions you mention will be moved to PEAR / PECL in due time At the moment we would like to see no new extensions added to /php4/ext/ -- Sebastian Bergmann http://sebastian-bergmannde/ http://phpOpenTrackerde/ Did I help you? Consider a gift: http://wishlistsebastian-bergmannde/ -- PHP Development Mailing List http://wwwphpnet/ To unsubscribe, visit: http://wwwphpnet/unsubphp
Re: [PHP-DEV] Fwd: Zend debug server trouble
Hey, Wrong list again... call/write Zend for support. Zend's commercial products have nothing to do with PHP. Derick On Thu, 21 Feb 2002, bvr wrote: I tried and posted this on php-general first, but didn't get a reply. If anyone can help me out, please reply to my private address for i'm not on this list. thanks, bvr. ==BEGIN FORWARDED MESSAGE== Hi, I'm trying to install the debug server for linux, but having trouble to make it work for remote clients through Apache. I installed the debug server and compiled php with --enable-debug The debug server works when I use the 'gdbclient -c' command. The Zend studio windows client debugs fine using local php.exe . When I click 'Go' in Zend studio a dialog pops up saying it could not establish a connection. I went through the troubleshooting list in the dialog but to no avail. When I look at the apache logs, there's just the plain request the IDE did, and there's no errors. When I paste the request into my browser I get 'document contains no data'. phpinfo() reports the following: ZEND_DEBUGenabled Please help! bvr. ===END FORWARDED MESSAGE=== -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: Zend debug server trouble
At 16:37 21/02/2002, [EMAIL PROTECTED] wrote: Hey, Wrong list again... call/write Zend for support. Zend's commercial products have nothing to do with PHP. They have everything to do with PHP, but they're not a part of the PHP project :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: Zend debug server trouble
On Thu, 2002-02-21 at 11:17, Zeev Suraski wrote: At 16:37 21/02/2002, [EMAIL PROTECTED] wrote: Hey, Wrong list again... call/write Zend for support. Zend's commercial products have nothing to do with PHP. They have everything to do with PHP, but they're not a part of the PHP project :) Zeev I thought you guys made ASP tools : ) j/k -jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FWD: possible bug in date() function
Chris Newbill wrote: Ehh...from manual n - month without leading zeros; i.e. 1 to 12 So yeah it would print 2th. Cause today is the 10th. The format does not make sense much, though. I guess 1th, 2th are correct English now, instead of 1st, 2nd. ;) -- Yasuo Ohgaki -Chris -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 10, 2002 12:47 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] FWD: possible bug in date() function From php-general. 2th of Feb. is odd, isn't? Someone may want to take a look at it. -- Yasuo Ohgaki Laserjetter wrote: I've just realised that the suffix for the day of the month is correct for today (1013336429) but it isn't the 2nd today and my clock is set right. Anyone got any ideas? Laserjetter [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Using the code below: $buffer['Last_access'] = 1013336429; $date = date(H:i D, nS M Y,$buffer['Last_access']); print $date; prints 10:20 Sun, 2th Feb 2002 I didnt know there was a 2th of February!! Is this a bug and do I get a prize for finding it? ;o) LJ -- Yasuo Ohgaki _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FWD: possible bug in date() function
Yasuo Ohgaki [EMAIL PROTECTED] wrote: Chris Newbill wrote: Ehh...from manual n - month without leading zeros; i.e. 1 to 12 So yeah it would print 2th. Cause today is the 10th. The format does not make sense much, though. sure it does. the 'bug' reporter had a bogus date format. $date = date(H:i D, nS M Y,$buffer['Last_access']); 'nS' means 'month'.'daysuffix'. (so on february 10, you would get '2th'.) they really wanted 'jS'. the documentation wasn't clear that 'S' pertained to the day of the month. i've checked in a clarification. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] FWD: possible bug in date() function
What? The original format string was: H:i D, nS M Y which is the part that makes no sense. He/She should be using: H:i D, jS M Y In other words, RTFM: http://www.php.net/date -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Monday, February 11, 2002 8:21 PM To: Chris Newbill Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] FWD: possible bug in date() function Chris Newbill wrote: Ehh...from manual n - month without leading zeros; i.e. 1 to 12 So yeah it would print 2th. Cause today is the 10th. The format does not make sense much, though. I guess 1th, 2th are correct English now, instead of 1st, 2nd. ;) -- Yasuo Ohgaki -Chris -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 10, 2002 12:47 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] FWD: possible bug in date() function From php-general. 2th of Feb. is odd, isn't? Someone may want to take a look at it. -- Yasuo Ohgaki Laserjetter wrote: I've just realised that the suffix for the day of the month is correct for today (1013336429) but it isn't the 2nd today and my clock is set right. Anyone got any ideas? Laserjetter [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Using the code below: $buffer['Last_access'] = 1013336429; $date = date(H:i D, nS M Y,$buffer['Last_access']); print $date; prints 10:20 Sun, 2th Feb 2002 I didnt know there was a 2th of February!! Is this a bug and do I get a prize for finding it? ;o) LJ -- Yasuo Ohgaki _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FWD: possible bug in date() function
Sean R. Bright wrote: What? The original format string was: H:i D, nS M Y which is the part that makes no sense. He/She should be using: As I mentioned, it does not make sense to me also. Some people may want to use nS for some reason, though. BTW, since iS works, I think it's easy to make nS work as well. I'm talking about consistency of behavior. It's not big deal, though. -- Yasuo Ohgaki H:i D, jS M Y In other words, RTFM: http://www.php.net/date -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Monday, February 11, 2002 8:21 PM To: Chris Newbill Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] FWD: possible bug in date() function Chris Newbill wrote: Ehh...from manual n - month without leading zeros; i.e. 1 to 12 So yeah it would print 2th. Cause today is the 10th. The format does not make sense much, though. I guess 1th, 2th are correct English now, instead of 1st, 2nd. ;) -- Yasuo Ohgaki -Chris -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 10, 2002 12:47 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] FWD: possible bug in date() function From php-general. 2th of Feb. is odd, isn't? Someone may want to take a look at it. -- Yasuo Ohgaki Laserjetter wrote: I've just realised that the suffix for the day of the month is correct for today (1013336429) but it isn't the 2nd today and my clock is set right. Anyone got any ideas? Laserjetter [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Using the code below: $buffer['Last_access'] = 1013336429; $date = date(H:i D, nS M Y,$buffer['Last_access']); print $date; prints 10:20 Sun, 2th Feb 2002 I didnt know there was a 2th of February!! Is this a bug and do I get a prize for finding it? ;o) LJ -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] FWD: possible bug in date() function
The format specifiers are just place holders, they don't modify the behavior of adjacent specifiers. 'iS' does not work. 'S' is tied directly to the current day of the month, so the only thing that makes sense while using 'S' is either 'd' or 'j' (i.e. 'dS' or 'jS'). I suppose we could introduce new 'english suffix' specifiers for month of the year, etc, etc. but that is just cludgy and confusing, IMHO. Sean -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Monday, February 11, 2002 9:26 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: 'Chris Newbill' Subject: Re: [PHP-DEV] FWD: possible bug in date() function Sean R. Bright wrote: What? The original format string was: H:i D, nS M Y which is the part that makes no sense. He/She should be using: As I mentioned, it does not make sense to me also. Some people may want to use nS for some reason, though. BTW, since iS works, I think it's easy to make nS work as well. I'm talking about consistency of behavior. It's not big deal, though. -- Yasuo Ohgaki H:i D, jS M Y In other words, RTFM: http://www.php.net/date -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Monday, February 11, 2002 8:21 PM To: Chris Newbill Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] FWD: possible bug in date() function Chris Newbill wrote: Ehh...from manual n - month without leading zeros; i.e. 1 to 12 So yeah it would print 2th. Cause today is the 10th. The format does not make sense much, though. I guess 1th, 2th are correct English now, instead of 1st, 2nd. ;) -- Yasuo Ohgaki -Chris -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 10, 2002 12:47 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] FWD: possible bug in date() function From php-general. 2th of Feb. is odd, isn't? Someone may want to take a look at it. -- Yasuo Ohgaki Laserjetter wrote: I've just realised that the suffix for the day of the month is correct for today (1013336429) but it isn't the 2nd today and my clock is set right. Anyone got any ideas? Laserjetter [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Using the code below: $buffer['Last_access'] = 1013336429; $date = date(H:i D, nS M Y,$buffer['Last_access']); print $date; prints 10:20 Sun, 2th Feb 2002 I didnt know there was a 2th of February!! Is this a bug and do I get a prize for finding it? ;o) LJ -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FWD: possible bug in date() function
Sean R. Bright wrote: The format specifiers are just place holders, they don't modify the behavior of adjacent specifiers. 'iS' does not work. 'S' is tied directly to the current day of the month, so the only thing that makes sense while using 'S' is either 'd' or 'j' (i.e. 'dS' or 'jS'). I suppose we could introduce new 'english suffix' specifiers for month of the year, etc, etc. but that is just cludgy and confusing, IMHO. Sean No problem at all with me :) I guess Jim already clarified about these in the manual. -- Yasuo Ohgaki -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Monday, February 11, 2002 9:26 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: 'Chris Newbill' Subject: Re: [PHP-DEV] FWD: possible bug in date() function Sean R. Bright wrote: What? The original format string was: H:i D, nS M Y which is the part that makes no sense. He/She should be using: As I mentioned, it does not make sense to me also. Some people may want to use nS for some reason, though. BTW, since iS works, I think it's easy to make nS work as well. I'm talking about consistency of behavior. It's not big deal, though. -- Yasuo Ohgaki H:i D, jS M Y In other words, RTFM: http://www.php.net/date -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Monday, February 11, 2002 8:21 PM To: Chris Newbill Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] FWD: possible bug in date() function Chris Newbill wrote: Ehh...from manual n - month without leading zeros; i.e. 1 to 12 So yeah it would print 2th. Cause today is the 10th. The format does not make sense much, though. I guess 1th, 2th are correct English now, instead of 1st, 2nd. ;) -- Yasuo Ohgaki -Chris -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 10, 2002 12:47 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] FWD: possible bug in date() function From php-general. 2th of Feb. is odd, isn't? Someone may want to take a look at it. -- Yasuo Ohgaki Laserjetter wrote: I've just realised that the suffix for the day of the month is correct for today (1013336429) but it isn't the 2nd today and my clock is set right. Anyone got any ideas? Laserjetter [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Using the code below: $buffer['Last_access'] = 1013336429; $date = date(H:i D, nS M Y,$buffer['Last_access']); print $date; prints 10:20 Sun, 2th Feb 2002 I didnt know there was a 2th of February!! Is this a bug and do I get a prize for finding it? ;o) LJ -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Yasuo Ohgaki _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity:Conclusion(?)]
After careful consideration on the CS issue I must say I agree with John here. The _only_ case where I feel CS is a problem, is when dealing with other environments. But the price for changing this today is simply too high. It should have been done in PHP 3.0. We have other BC issues to soak our brains in. HOWEVER, I would like to suggest one compromise: storing class names (and maybe function names) exactly as they were spelled in the definition, and have get_class() etc. return that version instead of the lowercased one. This would at least make us able to expose interfaces with the intended case. -1 from me on case sensitivity in ZE2, +1 on storing pretty names - Stig On Wed, 2002-02-06 at 20:52, Andi Gutmans wrote: I very much agree with this Email and am -1. Andi At 11:01 PM 2/6/2002 +0800, John Lim wrote: Thanks for posting this request for comments, Yasuo. I think from a C developer's point of view, it makes perfect sense to have case-sensitivity. From a scripting point-of-view, I think it is a step backward. Studies by the Python group have shown that case-sensitivity is a serious barrier for beginners. I also think that a significant number of PHP users who do *not* program in C, C++ or languages which require case-sensitivity would be most unhappy. These people would definitely not visit php.dev or Zend2 lists, so I think opinions here are skewed (not twisted!) Backward compatibility is a headache also as many PHP libraries written by other people have weird case conventions, and not having a standard PHP coding style will mean our code will be a mess as we have to adhere to different coding styles. We have been trained in Javascript and C to spell the standard libraries in a standard way. But what is the correct spelling of OCIPLogon (or was that ociplogon, or was that ociPLogon)? Who knows and I think moany people would not want to care. I certainly don't. In the C library, I'm used to having all lowercase functions, but it will look wierd if PEAR DB follows one convention, PHP extensions follow another, and my code follows a different one. Without case-sensitivity, I can use a consistent code style for functions everywhere for OciPLogon (hah, another spelling variation!) I think PHP5 is a bit late in the game to change course so radically for so little benefit. This will stir up a hornets nest which would be better directed at fixing bugs, writing code, and finding happiness and peace. My PHP 5 cents worth. John Lim Perhaps someone could cc this to the Zend2 lists as I don't read it. Thanks. Thies C. Arntzen [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Wed, Feb 06, 2002 at 07:40:18PM +0900, Yasuo Ohgaki wrote: Hi all, I'm posting this for those who are not subscribing Zend Engine 2 list. Many of developers seems to have case sensitivity for class/function names. However, we need vote for if PHP5 will have case sensitive class/function/constant names. If you have comments, please submit one. PS: We know we can cheat. Let's hope nobody cheat :) You can read Zend Engne 2 list archive at http://www.zend.com/lists.php besides the BC mess i'm all for it (make PHP5 case-sensite). tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity:Conclusion(?)]
Because PHP has gotten about a million more users since then? - Stig On Thu, 2002-02-07 at 00:57, Jason Greene wrote: If everyone has been able to adapt to case sensitive variable names, why can they not adapt to case sensitive function names? -Jason On Wed, 2002-02-06 at 09:01, John Lim wrote: Thanks for posting this request for comments, Yasuo. I think from a C developer's point of view, it makes perfect sense to have case-sensitivity. From a scripting point-of-view, I think it is a step backward. Studies by the Python group have shown that case-sensitivity is a serious barrier for beginners. I also think that a significant number of PHP users who do *not* program in C, C++ or languages which require case-sensitivity would be most unhappy. These people would definitely not visit php.dev or Zend2 lists, so I think opinions here are skewed (not twisted!) Backward compatibility is a headache also as many PHP libraries written by other people have weird case conventions, and not having a standard PHP coding style will mean our code will be a mess as we have to adhere to different coding styles. We have been trained in Javascript and C to spell the standard libraries in a standard way. But what is the correct spelling of OCIPLogon (or was that ociplogon, or was that ociPLogon)? Who knows and I think moany people would not want to care. I certainly don't. In the C library, I'm used to having all lowercase functions, but it will look wierd if PEAR DB follows one convention, PHP extensions follow another, and my code follows a different one. Without case-sensitivity, I can use a consistent code style for functions everywhere for OciPLogon (hah, another spelling variation!) I think PHP5 is a bit late in the game to change course so radically for so little benefit. This will stir up a hornets nest which would be better directed at fixing bugs, writing code, and finding happiness and peace. My PHP 5 cents worth. John Lim Perhaps someone could cc this to the Zend2 lists as I don't read it. Thanks. Thies C. Arntzen [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Wed, Feb 06, 2002 at 07:40:18PM +0900, Yasuo Ohgaki wrote: Hi all, I'm posting this for those who are not subscribing Zend Engine 2 list. Many of developers seems to have case sensitivity for class/function names. However, we need vote for if PHP5 will have case sensitive class/function/constant names. If you have comments, please submit one. PS: We know we can cheat. Let's hope nobody cheat :) You can read Zend Engne 2 list archive at http://www.zend.com/lists.php besides the BC mess i'm all for it (make PHP5 case-sensite). tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Jason T. Greene Internet Software Engineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Use PHP: http://www.php.net -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Casesensitivity: Conclusion(?)]
Yes, this is going to be a problem.
I have thought one a way of dealing with it. Let people declare in
their code that major version of PHP they have written their code for,
and issue possible ambigous context warnings unless it's declared
written for PHP 5. For example, the code:
function bar()
class foo {
function foo() {
bar();
}
function bar() {
}
}
Could emit an ambiguity warning by default, but if you stick using_php
5; or something like that at the very beginning, you say yes I know of
all the issues involved with PHP 5 and get no warning.
Andi, would something like this be possible without more than negligible
overhead?
- Stig
On Thu, 2002-02-07 at 09:35, Yasuo Ohgaki wrote:
To upgrade from PHP4 to PHP5, most users should
carefully change/test existing script unless
their scripts are completely OO or non-OO.
This BC problem is worse than case sensitive names, IMHO.
(BTW, I like ZE2 way than ZE1 way) PHP5 may call wrong
function unless user change their code ;)
Case of names can be easily converted by program.
And error with case sentive names is easier to
understand what/where is wrong.
[yohgaki@dev ze2]$ php name_space7.php
bar::bar()
foo()
[yohgaki@dev ze2]$ php-ze2 name_space7.php
bar::bar()
bar::foo()
[yohgaki@dev ze2]$ cat name_space7.php
?php
$var = 'ABC';
function foo() {
echo foo()\n;
}
class bar {
function bar()
{
echo bar::bar()\n;
foo();
}
function foo()
{
echo bar::foo()\n;
}
}
$obj = new bar;
?
[yohgaki@dev ze2]$
--
Yasuo Ohgaki
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
On Wed, 2002-02-06 at 22:36, Jani Taskinen wrote: Many scripts will break anyway if you update to PHP 5.. +1 (still) for case-sensitivity which would make the language more conistent. Or if this is ruled out, then let's make all variables and constants case-insensitive too. It is so confusing for all the newbies when $FOO isn't same as $foo. No more confusing than today. I dare say that making functions case sensitive would easily confuse _many_ more users than those who are confused by $foo/$FOO. I agree that CS would be more consistent, but it's just that we're thinking about it too late. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity:
Stig S. Bakken wrote: Because PHP has gotten about a million more users since then? Good point. I also think less number of impacts for existing code is preferred. Since many people believe ini option for case sensitivity will lead bad compatibility problem like register_globals, I might write a patch for ZE2 to show it may not. I have to check current ZE2 code if it's feasible or not to be sure ;) -- Yasuo Ohgaki - Stig On Thu, 2002-02-07 at 00:57, Jason Greene wrote: If everyone has been able to adapt to case sensitive variable names, why can they not adapt to case sensitive function names? -Jason On Wed, 2002-02-06 at 09:01, John Lim wrote: Thanks for posting this request for comments, Yasuo. I think from a C developer's point of view, it makes perfect sense to have case-sensitivity. From a scripting point-of-view, I think it is a step backward. Studies by the Python group have shown that case-sensitivity is a serious barrier for beginners. I also think that a significant number of PHP users who do *not* program in C, C++ or languages which require case-sensitivity would be most unhappy. These people would definitely not visit php.dev or Zend2 lists, so I think opinions here are skewed (not twisted!) Backward compatibility is a headache also as many PHP libraries written by other people have weird case conventions, and not having a standard PHP coding style will mean our code will be a mess as we have to adhere to different coding styles. We have been trained in Javascript and C to spell the standard libraries in a standard way. But what is the correct spelling of OCIPLogon (or was that ociplogon, or was that ociPLogon)? Who knows and I think moany people would not want to care. I certainly don't. In the C library, I'm used to having all lowercase functions, but it will look wierd if PEAR DB follows one convention, PHP extensions follow another, and my code follows a different one. Without case-sensitivity, I can use a consistent code style for functions everywhere for OciPLogon (hah, another spelling variation!) I think PHP5 is a bit late in the game to change course so radically for so little benefit. This will stir up a hornets nest which would be better directed at fixing bugs, writing code, and finding happiness and peace. My PHP 5 cents worth. John Lim Perhaps someone could cc this to the Zend2 lists as I don't read it. Thanks. Thies C. Arntzen [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Wed, Feb 06, 2002 at 07:40:18PM +0900, Yasuo Ohgaki wrote: Hi all, I'm posting this for those who are not subscribing Zend Engine 2 list. Many of developers seems to have case sensitivity for class/function names. However, we need vote for if PHP5 will have case sensitive class/function/constant names. If you have comments, please submit one. PS: We know we can cheat. Let's hope nobody cheat :) You can read Zend Engne 2 list archive at http://www.zend.com/lists.php besides the BC mess i'm all for it (make PHP5 case-sensite). tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Jason T. Greene Internet Software Engineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Use PHP: http://www.php.net -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Yasuo Ohgaki Please CC me when you reply to news/list messages. Do not reply only to me :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] FWD: possible bug in date() function
Ehh...from manual n - month without leading zeros; i.e. 1 to 12 So yeah it would print 2th. Cause today is the 10th. -Chris -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 10, 2002 12:47 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] FWD: possible bug in date() function From php-general. 2th of Feb. is odd, isn't? Someone may want to take a look at it. -- Yasuo Ohgaki Laserjetter wrote: I've just realised that the suffix for the day of the month is correct for today (1013336429) but it isn't the 2nd today and my clock is set right. Anyone got any ideas? Laserjetter [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Using the code below: $buffer['Last_access'] = 1013336429; $date = date(H:i D, nS M Y,$buffer['Last_access']); print $date; prints 10:20 Sun, 2th Feb 2002 I didnt know there was a 2th of February!! Is this a bug and do I get a prize for finding it? ;o) LJ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
Yasuo Ohgaki wrote:
Case of names can be easily converted by program.
do you think it will be easy in this situation?:
?php
function myCompare($arg1,$arg2) {
}
[...]
$sorted_array=usort($array,myCompare);
[...]
$sorted_array=usort($array,mycompare);
[...]
?
and, by the way: what kind of a program is going to convert this?
a shell script? what about windows users?
a php script? what about users that just want to install a product
written for php 4 in a php 5 environment where they do not have
any shell access or where no php cli is installed?
--
Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77
Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns
in Halle 6 auf Ihren Besuch am Stand H 18
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [Zend Engine 2] Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity:Conclusion(?)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After careful consideration on the CS issue I must say I agree with John here. The _only_ case where I feel CS is a problem, is when dealing with other environments. But the price for changing this today is simply too high. It should have been done in PHP 3.0. We have other BC issues to soak our brains in. Actually i should agree with that, because it sounds reasonable. But there are a few things that hinder me. PHP isn't really case-insensitiv, as variable names are already case-sensitiv. Thus beginners are even more confused. Try to explain a beginner that functions are case-insensitive, variables are case-sensitive and constants can be either or. Isn't _that_ confusing ? Have you ever been looking to a beginners BASIC code? John may be right when he says, that it is easier to start with an case-insensitiv language. Case sensitiv languages may be a pain in the ass at first, but as soon as you understand things, your code will be ways cleaner. Natural languages (English, German, ... everything else ?) are case-sensitiv too. oR HavE yOu evEr seEn soMEonE wRITiNg lIKE thIs ? HOWEVER, I would like to suggest one compromise: storing class names (and maybe function names) exactly as they were spelled in the definition, and have get_class() etc. return that version instead of the lowercased one. This would at least make us able to expose interfaces with the intended case. -1 from me on case sensitivity in ZE2, +1 on storing pretty names would be an a acceptable solution, but would lead to further inconsistency, as one could write case-sensitiv extensions (i'd do :). harald. -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBPGJX+a1+myS9SSHxEQLSeQCgoelqujswN1pu62yq+/YDb0F6Y7YAoNcE AKSYHB14fFa8F9ohf0wxDTX4 =M455 -END PGP SIGNATURE- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
At 07:58 AM 2/7/2002 +0100, Stig S. Bakken wrote: After careful consideration on the CS issue I must say I agree with John here. The _only_ case where I feel CS is a problem, is when dealing with other environments. But the price for changing this today is simply too high. It should have been done in PHP 3.0. We have other BC issues to soak our brains in. HOWEVER, I would like to suggest one compromise: storing class names (and maybe function names) exactly as they were spelled in the definition, and have get_class() etc. return that version instead of the lowercased one. This would at least make us able to expose interfaces with the intended case. -1 from me on case sensitivity in ZE2, +1 on storing pretty names I agree and I'll try and check if pretty names can be handled. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
Andi Gutmans wrote: At 07:58 AM 2/7/2002 +0100, Stig S. Bakken wrote: *SNIP* I agree and I'll try and check if pretty names can be handled. Errors with case senstive names are intuitive to fix. While errors with name space change is _not_ intuitive to where and what is wrong. If we didn't make function/class case sensitive now, it would be really _bad_ choice and would regert in near future (Some person said it should be done for PHP3, why not for PHP5?) Users who want to upgrade PHP4 = PHP5 should edit/convert/ test their scripts anyway. Benefits of case sensitive names are not enough? -- Yasuo Ohgaki _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
However, we need vote for if PHP5 will have case sensitive class/function/constant names. +1 for case-sensitive everything Cheerio, Marc. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclus ion(?)]
Marc Boeren wrote: +1 for case-sensitive everything so you volunter to rewrite all the code that uses oci or gd extension now but uses it all lowercase? ;) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
However, we need vote for if PHP5 will have case sensitive class/function/constant names. +1 for case-sensitive everything -1. Differentiating two objects only by the case of their names seems absurd to me. This is not how humans function. Ease of implementation is the only thing speaking for case-sensitiveness in my book. Case-insensitiveness is always more work. But I think it's well worth the trouble. Hence case-insensitive, case-preserving is my suggestion. --Marko -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclus ion(?)]
+1 for case-sensitive everything so you volunter to rewrite all the code that uses oci or gd extension now but uses it all lowercase? ;) I didn't say +1 for lower-case everything! (although that is my preference, for functionnames at least ;-) Cheerio, Marc. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclus ion(?)]
+1 for case-sensitive everything -1. Differentiating two objects only by the case of their names seems absurd to me. This is not how humans function. I don't think people should write code that differentiates by case, but case-sensitive coding leads to consistency in naming, so you will not read MySQL_ConneCt somewhere and mysql_connect somewhere else, while it means the same thing... An unwanted side-effect is that it allows people to differentiate using case. Cheerio, Marc. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclus ion(?)]
Marc Boeren wrote: +1 for case-sensitive everything so you volunter to rewrite all the code that uses oci or gd extension now but uses it all lowercase? ;) I didn't say +1 for lower-case everything! (although that is my preference, for functionnames at least ;-) oci and gd extensions had mixed-case names for ages, but you see both mixed- and all-lower case usage all over the place now no matter how the function names themselves will be in the future, case-sensitivity will break app. half of the existing code using them we've been fighting about backwards compatibilty issues far less critical than this and usualy have decided to keep bc where possible until it really does hurt to much, all these efforts would become useless if we introduced a bc breaking change as far reaching as this just for cosmetic/esthetic reasons ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclus ion(?)]
On Wed, Feb 06, 2002 at 11:01:21AM +, Marko Karppinen wrote : However, we need vote for if PHP5 will have case sensitive class/function/constant names. +1 for case-sensitive everything -1. Differentiating two objects only by the case of their names seems absurd to me. This is not how humans function. Ease of implementation is the only thing speaking for case-sensitiveness in my book. You have the wrong book then. Painless integration with other technologies is the main argument (.NET, SOAP, SRM [didn't forget it this time, Derick ;)]) Case-insensitiveness is always more work. But I think it's well worth the trouble. I admit it will definitely raise the bar for newbies a bit. -- Please always Cc to me when replying to me on the lists. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
oci and gd extensions had mixed-case names for ages, but you see both mixed- and all-lower case usage all over the place now OK, I see your point. I'll start writing a little shellscript that recursively crawls through your filesystem, updating every text-file against a list of function-names and lowercasing everything else... *grin* My preference is still to use case-sensitivity, but the BC-argument is a very good one (the only one? :) against it... so it depends on how much BC will be broken anyway by other changes... Cheerio, Marc. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
Marc wrote: I don't think people should write code that differentiates by case, but case-sensitive coding leads to consistency in naming, so you will not read MySQL_ConneCt somewhere and mysql_connect somewhere else, while it means the same thing... If you just want to promote case-accurate usage of the built-in functions, you could just start throwing E_NOTICEs or E_WARNINGs when the functions are called with a differing case. Being case-sensitive just for this seems overkill to me. --Marko -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclus ion(?)]
Hartmut Holzgraefe wrote: Marc Boeren wrote: +1 for case-sensitive everything so you volunter to rewrite all the code that uses oci or gd extension now but uses it all lowercase? ;) Andrei has been wrote conversion program. I don't know the details, but it may do better job than making all to lowercase (?) -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclus ion(?)]
Yasuo Ohgaki wrote: Andrei has been wrote conversion program. I don't know the details, but it may do better job than making all to lowercase (?) will it also detect and rewrite the usage of function/method names in strings used for eg. callback handlers? -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
On Wed, Feb 06, 2002 at 07:40:18PM +0900, Yasuo Ohgaki wrote: Hi all, I'm posting this for those who are not subscribing Zend Engine 2 list. Many of developers seems to have case sensitivity for class/function names. However, we need vote for if PHP5 will have case sensitive class/function/constant names. If you have comments, please submit one. PS: We know we can cheat. Let's hope nobody cheat :) You can read Zend Engne 2 list archive at http://www.zend.com/lists.php besides the BC mess i'm all for it (make PHP5 case-sensite). tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclus ion(?)]
--- Marko Karppinen [EMAIL PROTECTED] wrote: However, we need vote for if PHP5 will have case sensitive class/function/constant names. +1 for case-sensitive everything -1. Differentiating two objects only by the case of their names seems absurd to me. This is not how humans function. Ease of implementation is the only thing speaking for case-sensitiveness in my book. Case-insensitiveness is always more work. But I think it's well worth the trouble. Hence case-insensitive, case-preserving is my suggestion. I believe that it should be up to the developer. Add a variable in php.ini that sets a PHP instance as case sensitive. Brent __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
On Wed, 6 Feb 2002, Brent R. Matzelle wrote: --- Marko Karppinen [EMAIL PROTECTED] wrote: However, we need vote for if PHP5 will have case sensitive class/function/constant names. +1 for case-sensitive everything -1. Differentiating two objects only by the case of their names seems absurd to me. This is not how humans function. Ease of implementation is the only thing speaking for case-sensitiveness in my book. Case-insensitiveness is always more work. But I think it's well worth the trouble. Hence case-insensitive, case-preserving is my suggestion. I believe that it should be up to the developer. Add a variable in php.ini that sets a PHP instance as case sensitive. This kind of thing is a big pain when you are using a server you have no control over. It's not so much of a pig as magic_quotes_gpc, but... Gary [ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
Thanks for posting this request for comments, Yasuo. I think from a C developer's point of view, it makes perfect sense to have case-sensitivity. From a scripting point-of-view, I think it is a step backward. Studies by the Python group have shown that case-sensitivity is a serious barrier for beginners. I also think that a significant number of PHP users who do *not* program in C, C++ or languages which require case-sensitivity would be most unhappy. These people would definitely not visit php.dev or Zend2 lists, so I think opinions here are skewed (not twisted!) Backward compatibility is a headache also as many PHP libraries written by other people have weird case conventions, and not having a standard PHP coding style will mean our code will be a mess as we have to adhere to different coding styles. We have been trained in Javascript and C to spell the standard libraries in a standard way. But what is the correct spelling of OCIPLogon (or was that ociplogon, or was that ociPLogon)? Who knows and I think moany people would not want to care. I certainly don't. In the C library, I'm used to having all lowercase functions, but it will look wierd if PEAR DB follows one convention, PHP extensions follow another, and my code follows a different one. Without case-sensitivity, I can use a consistent code style for functions everywhere for OciPLogon (hah, another spelling variation!) I think PHP5 is a bit late in the game to change course so radically for so little benefit. This will stir up a hornets nest which would be better directed at fixing bugs, writing code, and finding happiness and peace. My PHP 5 cents worth. John Lim Perhaps someone could cc this to the Zend2 lists as I don't read it. Thanks. Thies C. Arntzen [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Wed, Feb 06, 2002 at 07:40:18PM +0900, Yasuo Ohgaki wrote: Hi all, I'm posting this for those who are not subscribing Zend Engine 2 list. Many of developers seems to have case sensitivity for class/function names. However, we need vote for if PHP5 will have case sensitive class/function/constant names. If you have comments, please submit one. PS: We know we can cheat. Let's hope nobody cheat :) You can read Zend Engne 2 list archive at http://www.zend.com/lists.php besides the BC mess i'm all for it (make PHP5 case-sensite). tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
Title: RE: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)] Thies C. Arntzen writes: On Wed, Feb 06, 2002 at 07:40:18PM +0900, Yasuo Ohgaki wrote: Hi all, I'm posting this for those who are not subscribing Zend Engine 2 list. Many of developers seems to have case sensitivity for class/function names. However, we need vote for if PHP5 will have case sensitive class/function/constant names. If you have comments, please submit one. PS: We know we can cheat. Let's hope nobody cheat :) You can read Zend Engne 2 list archive at http://www.zend.com/lists.php besides the BC mess i'm all for it (make PHP5 case-sensite). tc IMHO, while the benefits of this feature may be obvious to the C and C++ world, it has little tangible benefit to the average user. Quite the opposite actually. It'll make PHP much more difficult to 'jump into', which in my view is one of its most important features, if not THE most important. The BC issue is also so profound, it's bound to be a horrible mess for _very_ little gain. With all due respect, I would be a -1 for this. Mike Robinson IT/Developer - Torstar Media Group Television Phone: 416.945.8786 Fax: 416.869.4566 Email: [EMAIL PROTECTED] To find out more about what we can do for you, please visit us at: http://www.tmgtv.ca/ and http://www.thestar.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclus ion(?)]
While I agree with Marko's vote (I'm also very much against it), I derive my conclusion from a whole different perspective. Guys, we are not next to the drawing board right now. The specs were defined and the layout was laid years ago. At this point in time we're only supposed to change something like that if there's an overwhelming reason to do it, and none of the reasons mentioned falls into that category. The reasons to move to case sensitivity and the alternative ways we should handle them, in my opinion, are: - Speed. We can probably improve the typical case so that it's not any slower in runtime. - Interaction with external component systems - we can have case sensitivity implemented at the module level, especially with the Engine 2 infrastructure, and still remain case insensitive for regular PHP objects. - It's just right. Well, I can totally agree with that, but only if we were next to the drawing board, which we're not. Zeev At 01:01 PM 2/6/2002, Marko Karppinen wrote: However, we need vote for if PHP5 will have case sensitive class/function/constant names. +1 for case-sensitive everything -1. Differentiating two objects only by the case of their names seems absurd to me. This is not how humans function. Ease of implementation is the only thing speaking for case-sensitiveness in my book. Case-insensitiveness is always more work. But I think it's well worth the trouble. Hence case-insensitive, case-preserving is my suggestion. --Marko -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
I very much agree with this Email and am -1. Andi At 11:01 PM 2/6/2002 +0800, John Lim wrote: Thanks for posting this request for comments, Yasuo. I think from a C developer's point of view, it makes perfect sense to have case-sensitivity. From a scripting point-of-view, I think it is a step backward. Studies by the Python group have shown that case-sensitivity is a serious barrier for beginners. I also think that a significant number of PHP users who do *not* program in C, C++ or languages which require case-sensitivity would be most unhappy. These people would definitely not visit php.dev or Zend2 lists, so I think opinions here are skewed (not twisted!) Backward compatibility is a headache also as many PHP libraries written by other people have weird case conventions, and not having a standard PHP coding style will mean our code will be a mess as we have to adhere to different coding styles. We have been trained in Javascript and C to spell the standard libraries in a standard way. But what is the correct spelling of OCIPLogon (or was that ociplogon, or was that ociPLogon)? Who knows and I think moany people would not want to care. I certainly don't. In the C library, I'm used to having all lowercase functions, but it will look wierd if PEAR DB follows one convention, PHP extensions follow another, and my code follows a different one. Without case-sensitivity, I can use a consistent code style for functions everywhere for OciPLogon (hah, another spelling variation!) I think PHP5 is a bit late in the game to change course so radically for so little benefit. This will stir up a hornets nest which would be better directed at fixing bugs, writing code, and finding happiness and peace. My PHP 5 cents worth. John Lim Perhaps someone could cc this to the Zend2 lists as I don't read it. Thanks. Thies C. Arntzen [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Wed, Feb 06, 2002 at 07:40:18PM +0900, Yasuo Ohgaki wrote: Hi all, I'm posting this for those who are not subscribing Zend Engine 2 list. Many of developers seems to have case sensitivity for class/function names. However, we need vote for if PHP5 will have case sensitive class/function/constant names. If you have comments, please submit one. PS: We know we can cheat. Let's hope nobody cheat :) You can read Zend Engne 2 list archive at http://www.zend.com/lists.php besides the BC mess i'm all for it (make PHP5 case-sensite). tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
Hi, IMHO making PHP case sensitive after being case-INsensitive for so many years is a very bad idea. The reasons are already mentioned on the list. For us (ISP in The Netherlands) the most important one is BC. We would not be able to upgrade any of our servers when this would go into PHP5. A lot of our customers use PHP, and I think almost every customer would have scripts that break. (which is not acceptable ofcouse) Please don't do this... (That's a -1 from me) Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
Many scripts will break anyway if you update to PHP 5.. +1 (still) for case-sensitivity which would make the language more conistent. Or if this is ruled out, then let's make all variables and constants case-insensitive too. It is so confusing for all the newbies when $FOO isn't same as $foo. --Jani On Wed, 6 Feb 2002, Sander Steffann wrote: Hi, IMHO making PHP case sensitive after being case-INsensitive for so many years is a very bad idea. The reasons are already mentioned on the list. For us (ISP in The Netherlands) the most important one is BC. We would not be able to upgrade any of our servers when this would go into PHP5. A lot of our customers use PHP, and I think almost every customer would have scripts that break. (which is not acceptable ofcouse) Please don't do this... (That's a -1 from me) Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
On Wed, 2002-02-06 at 05:37, Marko Karppinen wrote: Markus: You have the wrong book then. Painless integration with other technologies is the main argument (.NET, SOAP, SRM [didn't forget it this time, Derick ;)]) I have some trouble believing that this is a real-world problem. Interfacing with a case-sensitive system is troublesome only when someone actually depends on being able to differentiate two objects only by the case of their names. Have you met such code in the wild? Personally, I've used a case-insensitive but case-preserving file system for more than five years now, while constantly dealing with and mounting volumes from machines with case-sensitive file systems. During this time I have encountered ZERO problems related to incompatible case handling between systems. This leads me to believe that the interop problem you describe is theoretical in nature. Prove me wrong :-) You are wrong. The problem is when you call a case sensitive function name in an external language or interface from php. This causes major lookup and performance problems. -Jason --Marko -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Jason T. Greene Internet Software Engineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Use PHP: http://www.php.net -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
On Wed, 2002-02-06 at 10:13, Zeev Suraski wrote: While I agree with Marko's vote (I'm also very much against it), I derive my conclusion from a whole different perspective. Guys, we are not next to the drawing board right now. The specs were defined and the layout was laid years ago. At this point in time we're only supposed to change something like that if there's an overwhelming reason to do it, and none of the reasons mentioned falls into that category. The reasons to move to case sensitivity and the alternative ways we should handle them, in my opinion, are: - Speed. We can probably improve the typical case so that it's not any slower in runtime. - Interaction with external component systems - we can have case sensitivity implemented at the module level, especially with the Engine 2 infrastructure, and still remain case insensitive for regular PHP objects. - It's just right. Well, I can totally agree with that, but only if we were next to the drawing board, which we're not. You left off language consistency between variable names, and function names. We are already completely redesigning OO which is like standing at the drawing board. -Jason Zeev At 01:01 PM 2/6/2002, Marko Karppinen wrote: However, we need vote for if PHP5 will have case sensitive class/function/constant names. +1 for case-sensitive everything -1. Differentiating two objects only by the case of their names seems absurd to me. This is not how humans function. Ease of implementation is the only thing speaking for case-sensitiveness in my book. Case-insensitiveness is always more work. But I think it's well worth the trouble. Hence case-insensitive, case-preserving is my suggestion. --Marko -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
+1 for case sensitivity On Wed, 2002-02-06 at 15:36, Jani Taskinen wrote: Many scripts will break anyway if you update to PHP 5.. +1 (still) for case-sensitivity which would make the language more conistent. Or if this is ruled out, then let's make all variables and constants case-insensitive too. It is so confusing for all the newbies when $FOO isn't same as $foo. --Jani On Wed, 6 Feb 2002, Sander Steffann wrote: Hi, IMHO making PHP case sensitive after being case-INsensitive for so many years is a very bad idea. The reasons are already mentioned on the list. For us (ISP in The Netherlands) the most important one is BC. We would not be able to upgrade any of our servers when this would go into PHP5. A lot of our customers use PHP, and I think almost every customer would have scripts that break. (which is not acceptable ofcouse) Please don't do this... (That's a -1 from me) Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Jason T. Greene Internet Software Engineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Use PHP: http://www.php.net -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
No need to vote, it won't change anyways :) Derick On 6 Feb 2002, Jason Greene wrote: +1 for case sensitivity On Wed, 2002-02-06 at 15:36, Jani Taskinen wrote: Many scripts will break anyway if you update to PHP 5.. +1 (still) for case-sensitivity which would make the language more conistent. Or if this is ruled out, then let's make all variables and constants case-insensitive too. It is so confusing for all the newbies when $FOO isn't same as $foo. --Jani On Wed, 6 Feb 2002, Sander Steffann wrote: Hi, IMHO making PHP case sensitive after being case-INsensitive for so many years is a very bad idea. The reasons are already mentioned on the list. For us (ISP in The Netherlands) the most important one is BC. We would not be able to upgrade any of our servers when this would go into PHP5. A lot of our customers use PHP, and I think almost every customer would have scripts that break. (which is not acceptable ofcouse) Please don't do this... (That's a -1 from me) Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Jason T. Greene Internet Software Engineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Use PHP: http://www.php.net -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclus ion(?)]
At 02:04 AM 2/7/2002, Jason Greene wrote: You left off language consistency between variable names, and function names. I consider that the 'warm fuzzy feeling' of purity, which I can totally understand and sympathize with. However, this sort of consistency between variables and function names is not mandatory, in my opinion, not mandatory enough to break compatibility in such a broad way, and after such a long time. We are already completely redesigning OO which is like standing at the drawing board. Even with the whole new object API, most of the code would work without modifications (at least mostly all of the PHP object code I got to take a look at). And if it doesn't - turning on PHP 4 compatibility should bridge the gap... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclus ion(?)]
Hi, Even with the whole new object API, most of the code would work without modifications (at least mostly all of the PHP object code I got to take a look at). And if it doesn't - turning on PHP 4 compatibility should bridge the gap... Glad to hear that :) I have been thinking, and breaking BC _could_ be acceptable for us, but only if it is possible to run PHP4 and PHP5 side-by-side in one apache server... (Breaking BC with making everything case sensitive would introduce a nice possibility to clean up a lot of other things that were never doen to maintain BC though, but lets stick to this point for now :) Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclus ion(?)]
At 06:04 PM 2/6/2002 -0600, Jason Greene wrote: On Wed, 2002-02-06 at 10:13, Zeev Suraski wrote: While I agree with Marko's vote (I'm also very much against it), I derive my conclusion from a whole different perspective. Guys, we are not next to the drawing board right now. The specs were defined and the layout was laid years ago. At this point in time we're only supposed to change something like that if there's an overwhelming reason to do it, and none of the reasons mentioned falls into that category. The reasons to move to case sensitivity and the alternative ways we should handle them, in my opinion, are: - Speed. We can probably improve the typical case so that it's not any slower in runtime. - Interaction with external component systems - we can have case sensitivity implemented at the module level, especially with the Engine 2 infrastructure, and still remain case insensitive for regular PHP objects. - It's just right. Well, I can totally agree with that, but only if we were next to the drawing board, which we're not. You left off language consistency between variable names, and function names. We are already completely redesigning OO which is like standing at the drawing board. Engine 2 will not break scripts that badly (at least not in my opinion). The OO stuff is mainly adding new functionality. Changing function names will break scripts badly. There's a huge difference. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: PHP and MySQL 4.0.0]
On Fri, 2 Nov 2001, Jani Taskinen wrote: I have committed a fix for all this. Please check it out, especially the thread-safe stuff. In any case, note, that by default, MySQL is compiled without old-style functions in libs, but references to such functions in all headers are OK, that makes a confusion. -- 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] [Fwd: PHP and MySQL 4.0.0]
I have committed a fix for all this. Please check it out, especially the thread-safe stuff. This diff shows why the HAVE_MYSQL_REAL_CONNECT broke things: http://cvs.php.net/diff.php/php4/ext/mysql/php_mysql.c?r1=1.37r2=1.38f=h :) --Jani On Fri, 2 Nov 2001, Sebastian Bergmann wrote: Timothy Smith wrote: There is an odd conflict with the USE_OLD_FUNCTIONS change in MySQL 4.0. PHP wraps almost all of ext/mysql/php_mysql.c in an #ifdef HAVE_MYSQL_REAL_CONNECT, which is only defined if USE_OLD_FUNCTIONS is defined (in mysql-4.0's mysql.h). So, you have to #define USE_OLD_FUNCTIONS in php_mysql.c before you include mysql.h. Also, you have to make sure your mysql is built with USE_OLD_FUNCTIONS defined. I guess PHP needs to clean this up. But, also, why does MySQL only define HAVE_MYSQL_REAL_CONNECT if USE_OLD_FUNCTIONS is defined? It seems like that is misleading at best. After doing the above, I was able to compile and start up apache with the php4 module. Tim -- 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] [Fwd: PHP and MySQL 4.0.0]
Jani Taskinen wrote: I have committed a fix for all this. Please check it out, especially the thread-safe stuff. Works fine with * PHP built as CGI, Apache 2.0.28-dev and MySQL 3.23.41 with bundled libmysql on Windows * PHP with Apache2Filter SAPI, Apache 2.0.28-dev and MySQL 4.0.0-alpha on Linux 2.4.13 with * --with-mysql=/usr/local/mysql * --with-mysql This diff shows why the HAVE_MYSQL_REAL_CONNECT broke things: http://cvs.php.net/diff.php/php4/ext/mysql/php_mysql.c?r1=1.37r2=1.38f=h -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- 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] fwd: buildconf troubles
On Mon, 17 Sep 2001, Hartmut Holzgraefe wrote: on one of the boxes everything worked fine again after commenting out the DLOPEN_SELF stuff in Zend/Zend.m4 while the other one still gives lots of undefined macros i tried this, all undefined macros go away and php is building for me again. thanks! -- 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] fwd: buildconf troubles
Doug MacEachern wrote: still stuck on this with current cvs, anybody else seeing this? From [EMAIL PROTECTED] Thu Aug 30 09:47:20 2001 -0700 Status: X-Status: X-Keywords: Date: Thu, 30 Aug 2001 09:47:20 -0700 (PDT) From: Doug MacEachern [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: buildconf troubles Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII i've done a fresh checkout and having problems building, below is the output from buildconf. % autoconf --version Autoconf version 2.13 % libtool --version ltmain.sh (GNU libtool) 1.4 (1.920 2001/04/24 23:26:18) any ideas? manualy removing aclocal.m4 before running buildconf should solve this for 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] fwd: buildconf troubles
well, the aclocal.m4 problem was related to me setting the clock back by several month to get going with my SAP R/3 demo system without getting another key (no email access by that time), thus confusing make another possible cause is the dlsym() check in Zend/Zend.m4, line 61ff commenting this out helped on one of my other systems ... -- 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] fwd: buildconf troubles
i had the same effect last week on two SuSE 7.0 systems while a 6.3 with manualy updated libtool worked fine (all with the same autoconf and automake versions) on one of the boxes it helped to comment out the DLOPEN_SELF stuff in Zend/Zend.m4, but the other one is still giving me undefined macros, even after i replaced the SuSE versions of autoconf and automake whith self compiled versions ... -- 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] fwd: buildconf troubles
same problem on two SuSE 7.0 boxes here this week while an older one running SuSE 6.3 and a manually updated libtool 1.4 did work fine (same version numbers of auto* on both of them) on one of the boxes everything worked fine again after commenting out the DLOPEN_SELF stuff in Zend/Zend.m4 while the other one still gives lots of undefined macros -- 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] Fwd: Bug id #12378 2000 is not a leapyear!
Read ext/calendar/gregor.c and you will see that: $leap = $year % 4 == 0; // centennials are only leap years if they are multiples of 400 if ($year % 100 == 0 $year % 400 != 0) $leap = false; (that boils down to somthing simpler) 2000 was definitely a leap year. --Wez. On 26/07/01, Andy [EMAIL PROTECTED] wrote: Is this right??? Also, look at bug #12378 (http://php.net/bugs.php?id=12378) -- Forwarded Message -- Subject: Bug id #12378 2000 is not a leapyear! Date: Thu, 26 Jul 2001 06:01:13 -0400 From: Christian Hansen [EMAIL PROTECTED] Sorry i didn't write on the bugtracing system. I didn't provite a password the first time and is unable to apply my comment there. According to the gregorian calender every data where $year % 4 = 0 is a leapyear unless $year % 400 = 0. Therefore the year 2000 is not a leapyear Greetings from Christian, denmark --- -- 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]
Re: [PHP-DEV] Fwd: [PHP-CVS] cvs: php4(PHP_4_0_5) /ext/standard array.c
I see it in RC7.
On Tue, 24 Apr 2001, Andi Gutmans wrote:
Looks like it got merged before RC7.
Can you check if your source includes this fix?
From: Andrei Zmievski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Mon, 02 Apr 2001 16:12:07 -
Subject: [PHP-CVS] cvs: php4(PHP_4_0_5) /ext/standard array.c
andrei Mon Apr 2 09:12:07 2001 EDT
Modified files: (Branch: PHP_4_0_5)
/php4/ext/standard array.c
Log:
MFH
Index: php4/ext/standard/array.c
diff -u php4/ext/standard/array.c:1.101 php4/ext/standard/array.c:1.101.2.1
--- php4/ext/standard/array.c:1.101 Mon Mar 12 02:14:00 2001
+++ php4/ext/standard/array.c Mon Apr 2 09:12:06 2001
@@ -21,7 +21,7 @@
+--+
*/
-/* $Id: array.c,v 1.101 2001/03/12 10:14:00 stas Exp $ */
+/* $Id: array.c,v 1.101.2.1 2001/04/02 16:12:06 andrei Exp $ */
#include php.h
#include php_ini.h
@@ -2195,7 +2195,7 @@
switch (zend_hash_get_current_key_ex(target_hash,
string_key, str_key_len, num_key, 1, pos)) {
case HASH_KEY_IS_STRING:
Z_STRVAL_P(data) = string_key;
- Z_STRLEN_P(data) = str_key_len;
+ Z_STRLEN_P(data) = str_key_len-1;
Z_TYPE_P(data) = IS_STRING;
break;
case HASH_KEY_IS_LONG:
--
PHP CVS 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]
-Andrei
A room without books is like a body without a soul.
-- Marcus Tullius Cicero (106-43 B.C.)
--
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] Fwd
Well, maybe someone could deny access to mailing list for his email adress? the only thinks he postet has been this letter... (in php-dev and php-pear) Peter Petermann -Original Message- From: Taylor Silvers [mailto:[EMAIL PROTECTED]] Sent: Friday, February 23, 2001 3:30 AM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Fwd Dear Friends Future Millionaire: [...] -- 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] [Fwd: Re: [PHP] Howto return multidimensional arrays from a PHP module]
I were refered to this list...
I found an old entry in the dev archive, explaining that I could achieve
my goals, by "for each inner array you
allocate a zval*, initialize it, add data to it, and add it to the
return value."
But how exactly do I add a zval?
My guess is add_assoc_resource but where do the integer come from?
Is it the returnvalue from array_init(allocatedZvalP)???
Just a snippet I created recently...
ZEND_FUNCTION(dbx_test)
{
zval **args[2];
zval *row[2];
int result;
for (result=0; result2; ++result) {
args[result]=NULL;
}
if (ZEND_NUM_ARGS() !=2 || zend_get_parameters_array_ex(2, args) ==
FAILURE) {
WRONG_PARAM_COUNT;
}
convert_to_long_ex(args[0]);
convert_to_string_ex(args[1]);
if (array_init(return_value) != SUCCESS) {
zend_error(E_ERROR, "Unable to create array for results...");
}
for (result=0; result2; ++result) {
MAKE_STD_ZVAL(rowheader[result]);
if (array_init(rowheader[result]) != SUCCESS) {
zend_error(E_ERROR, "Unable to create array for rowheader
%d...", result);
}
}
for (result=0; result2; ++result) {
MAKE_STD_ZVAL(row[result]);
if (array_init(row[result]) != SUCCESS) {
zend_error(E_ERROR, "Unable to create array for row %d...",
result);
}
}
add_index_string(row[0], 0, "bla00", 1);
add_index_string(row[0], 1, "bla10", 1);
add_index_string(row[1], 0, "bla01", 1);
add_index_string(row[1], 1, "bla11", 1);
zend_hash_index_update(return_value-value.ht, 0, (void *)(row[0]),
sizeof(zval *), NULL);
zend_hash_index_update(return_value-value.ht, 1, (void *)(row[1]),
sizeof(zval *), NULL);
}
Good luck!
Cheerio, Marc.
--
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] [Fwd: Re: [PHP] Howto return multidimensional arraysfrom a PHP module]
I had the same problem. This is, how I managed to do this:
extern "C" int fun1(pval** array) { //this is in c++
//here you generate subarrays - alements are added to the parameter array
//this generates an array of strings
...
int count=;
for (int i=0;icount;i++) {
char* str=estrdup("Array element");
zval* arr_el;
MAKE_STD_ZVAL(arr_el);
ZVAL_STRING(arr_el,str,0);
zend_hash_next_index_insert
((*array)-value.ht,arr_el,sizeof(zval**),NULL);
}
return count;
}
/* {{{ proto array fun2() //this is in standard c
*/
PHP_FUNCTION(konf)
{
//here you generate array with array elements
...
if (array_init(return_value) == FAILURE) {
RETURN_FALSE;
}
for (...) {
zval* arr_element;
MAKE_STD_ZVAL(arr_element);
if (array_init(arr_element) == FAILURE) {
RETURN_FALSE;
}
zend_hash_next_index_insert(
return_value-value.ht,
(void*)arr_element,sizeof(zval*),
NULL);
fun1(arr_element); - now add elements
}
}
/* }}} */
It was something like that It generates two-dimensional array.
Ouuuff... It took me much of time to "develope" this...
And no guarantees ...
--
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]
