[PHP-DEV] Bug #10680 Updated:

[hholzgra]

ID: 10680
Updated by: hholzgra
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: *General Issues
PHP Version: 4.0.5
Assigned To: 
Comments:

this is a bug database, not a support forum

please ask one of the resources listed
under http://php.net/support.php, especially
the php-general mailing list

Previous Comments:
---

[2001-05-05 01:43:39] [EMAIL PROTECTED]
i run a php file under command line.i find it is difficult to pass an argument .Can 
you give me a help?

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10680&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10679 Updated: IMAP_UID doen't return what it should

[chagenbu]

ID: 10679
Updated by: chagenbu
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: IMAP related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

this is not what the uid is. see previous closed bug report.

Previous Comments:
---

[2001-05-04 19:30:07] [EMAIL PROTECTED]
From: "Rick Gigger" <[EMAIL PROTECTED]>  All email messages have a unique 
identifier.  It is a long string that ususally contains a domiain name or ip address.  
It is unique to all email addresses in the world.  It would be much, much more useful 
if imap_uid would return that instead.

Previous Comments:
---

[2001-05-03 15:36:24] [EMAIL PROTECTED]
You might have the wrong idea of what uid is - what do you expect it to be? On pop 
servers the message uid will very likely just _be_ the message number...

---

[2000-10-27 03:30:55] [EMAIL PROTECTED]
When I call connect to a qmail pop server and call imap_uid all it does is return the 
message number back to me.  It DOES NOT return the uid.  I have to call imap_header 
for that and it is very slow.

---

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10679&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10680:

[freeaudit]

From: [EMAIL PROTECTED]
Operating system: linux
PHP version:  4.0.5
PHP Bug Type: *General Issues
Bug description:  

i run a php file under command line.i find it is difficult to pass an argument .Can 
you give me a help?


-- 
Edit Bug report at: http://bugs.php.net/?id=10680&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mysql php_mysql.c php_mysql.h

[Sebastian Bergmann]

Zeev Suraski wrote:
> zeevFri May  4 18:42:15 2001 EDT
> 
>   Modified files:
> /php4/ext/mysql php_mysql.c php_mysql.h
>   Log:
>   emalloc()'d strings must be freed before the request shutdown;
>   Rule of the thumb:  initialize in RINIT, clean in RSHUTDOWN

php_mysql.c
D:\Programme\MS Visual
Studio\Projekte\php\php4\ext\mysql\php_mysql.c(334) : err
or C2065: 'mysql_globals' : not declared variable
D:\Programme\MS Visual
Studio\Projekte\php\php4\ext\mysql\php_mysql.c(334) : err
or C2223: Left part of '->connect_error' must point to a struct/union
D:\Programme\MS Visual
Studio\Projekte\php\php4\ext\mysql\php_mysql.c(335) : err
or C2223: Left part of '->connect_error' must point to a struct/union
D:\Programme\MS Visual
Studio\Projekte\php\php4\ext\mysql\php_mysql.c(335) : err
or C2198: '_efree' : Not enough parameters

-- 
 sebastian bergmann[EMAIL PROTECTED]
   http://www.sebastian-bergmann.de

 bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.de

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] bugs.php.net fails again..

[Jani Taskinen]

Warning:  MySQL Connection Failed: Can't create a new thread (errno
11). If you are not out of available memory, you can consult the manual
for a possible OS-dependent bug
 in /local/Web/sites/phpweb/bugs.php on line 77
Unable to connect to SQL server.


This is now 3/4th time in short time I get this.
WTF is going on with that server?

--Jani



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10580 Updated: Access Violation using ADODB

[jason]

ID: 10580
User Update by: [EMAIL PROTECTED]
Old-Status: Closed
Status: Open
Bug Type: COM related
Description: Access Violation using ADODB

Same bug, access violation using ADODB and MSXML Parser,
but using a 4.0.6 build, dated 2001-05-04.


Previous Comments:
---

[2001-05-04 11:29:31] [EMAIL PROTECTED]
This is now fixed in CVS. Fix will be in 4.0.6.

--Jani


---

[2001-05-04 10:28:01] [EMAIL PROTECTED]
same as #10594

---

[2001-05-01 11:05:52] [EMAIL PROTECTED]
If it helps, here is the error message:

PHP has encountered an Access Violation at 2474FF04

I got the following error messages when using MSXML Parser 3.01 to load an XML string:

PHP has encountered an Access Violation at 011C2655

and

PHP has encountered an Access Violation at 011C265B


---

[2001-05-01 10:54:02] [EMAIL PROTECTED]
Access Violation on this line:

$fields = $rs->Fields;

where $rs is the recordset from the database.
Error occurs with PHP 4.0.5 final release,
and does not occur with PHP 4.0.5 RC1.


---


Full Bug description available at: http://bugs.php.net/?id=10580


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10539 Updated: still - unresolved reference to compress

[dtalk]

ID: 10539
User Update by: [EMAIL PROTECTED]
Old-Status: Closed
Status: Open
Bug Type: Compile Failure
Description: still - unresolved reference to compress

Still fails, but error in config.log is quite puzzling. yp would suggest an 
NIS-related problem, but we don't use it ...

[snip]
configure:4786: gcc -o conftest -g -O2  -D_POSIX_PTHREAD_SEMANTICS  conftest.c 
-lsocket  1>&5
Undefined   first referenced
 symbol in file
yp_get_default_domain   /var/tmp/ccpTQEla.o  (symbol belongs to implicit 
dependen
cy /usr/lib/libnsl.so.1)
ld: fatal: Symbol referencing errors. No output written to conftest
collect2: ld returned 1 exit status
configure: failed program was:
#line 4763 "configure"
[snip]

Doesn't look relevant this time, but here's the output of 
/usr/local/mysql-3.23.37/bin/mysql_config --libs:  
/usr/local/mysql-3.23.37/bin/mysql_config: !: not found
 -L'/usr/local/mysql-3.23.37/lib/mysql' -lmysqlclient -lz -lcrypt -lgen -lsocket -lnsl 
-lm 

thanks again. -d

Previous Comments:
---

[2001-05-01 20:23:55] [EMAIL PROTECTED]
Should be fixed in CVS now.
If not, reopen with the output of this command:

/usr/local/mysql-3.23.37/bin/mysql_config --libs

--Jani


---

[2001-04-30 18:21:23] [EMAIL PROTECTED]
Thanks for your response. Info you requested is below.  I'm afraid I don't know what 
to look for in this case, so let me know if you need anything else. -d

Output of 'ldd /usr/local/mysql-3.23.37/lib/mysql/libmysqlclient.so':

libcrypt_i.so.1 =>   /usr/lib/libcrypt_i.so.1
libgen.so.1 =>   /usr/lib/libgen.so.1
libsocket.so.1 =>/usr/lib/libsocket.so.1
libnsl.so.1 =>   /usr/lib/libnsl.so.1
libm.so.1 => /usr/lib/libm.so.1
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 =>/usr/lib/libdl.so.1
libmp.so.2 =>/usr/lib/libmp.so.2
/usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1

I verified that all these libraries are present.

config.log info:

Run 1:
 ./configure --with-mysql=/usr/local/mysql-3.23.37 --with -apache=../apache_1.3.
19 --enable-track-vars --with-imap=../imap-2001.BETA.SNAP-0104241750 --enable-sy
svsem --enable-sysvshm

Prodiced this in config.log 
configure:49857: checking whether to include zlib support
No other messages related to zlib.

Run 2:
 ./configure --with-mysql=/usr/local/mysql-3.23.37 --with -apache=../apache_1.3.
19 --enable-track-vars --with-imap=../imap-2001.BETA.SNAP-0104241750 --enable-sy
svsem --enable-sysvshm --with-zlib=/usr/local/zlib-1.1.3

aborts with:
configure: error: Zlib module requires zlib >= 1.0.9.

and this in config.log:

configure:49857: checking whether to include zlib support
configure:50058: checking for gzgets in -lz
configure:50077: gcc -o conftest -g -O2  -D_POSIX_PTHREAD_SEMANTICS -DSUPPORT_UT
F8 -DXML_BYTE_ORDER=21 -L/usr/local/zlib-1.1.3/lib  -R/usr/ucblib -L/usr/ucblib 
-R/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2 -L/usr/local/lib/gcc-lib/sp
arc-sun-solaris2.8/2.95.2 -R/usr/local/src/www/imap-2001.BETA.SNAP-0104241750/c-
client -L/usr/local/src/www/imap-2001.BETA.SNAP-0104241750/c-client -R/usr/local
/mysql-3.23.37/lib/mysql -L/usr/local/mysql-3.23.37/lib/mysql conftest.c -lz  -l
mysqlclient -lcrypt -lresolv -lresolv -lm -ldl -lnsl -lsocket  -lsocket -lgcc 1>
&5
Undefined   first referenced
 symbol in file
 uncompress  /usr/local/mysql-3.23.37/lib/mysql/libmysql
c
 lient.so
 compress/usr/local/mysql-3.23.37/lib/mysql/libmysql
c
 lient.so
 ld: fatal: Symbol referencing errors. No output written to conftest
 collect2: ld returned 1 exit status
 configure: failed program was:
 #line 50066 "configure"

Tried editing configure, change line # 14725 to:
 14725  LIBS="$LIBS -lz"
Get same result as Run #2 above.



---

[2001-04-29 22:23:04] [EMAIL PROTECTED]
What does 
'ldd /usr/local/mysql-3.23.37/lib/mysql/libmysqlclient.so'
output?

What is in config.log about zlib??

--Jani


---

[2001-04-28 13:33:01] [EMAIL PROTECTED]
Solaris 8 / gcc.  Unresolved symbol errors during php
configure.  I have seen lots of information about this,
but none of the fixes I've encountered have worked.  I have:

- tried adding -lz to LTLIBRARY_LDFLAGS in Makefile
- tried adding --with-zlib-dir=/usr/local/zlib-1.1.3
- tried adding --with-zlib, or --with-zlib=/usr/local/zlib-1.1.3
- changed LIBS="-$LIBS -lz" in configure
- tried installing zlib to system location (--prefix=/usr)
- obtained latest CVS tree and built, with same results.

Out

[PHP-DEV] Bug #8949 Updated: imap_8bit() does not encode leading dots correctly

[vlad]

ID: 8949
Updated by: vlad
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: IMAP related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

Not really a bug, but a known problem with buggy MTA's and clients. Also, fixing it 
would need to be done within the c-client, not PHP, and I don't think UW people will 
like to make their c-client less RFC-compliant. :( Details below.


RFC2045 section 6.7 part (2) says:

>(Literal representation) Octets with decimal values of
>33 through 60 inclusive, and 62 through 126, inclusive,
>MAY be represented as the US-ASCII characters which
>correspond to those octets (EXCLAMATION POINT through
>LESS THAN, and GREATER THAN through TILDE, respectively).


Dot has a code of 46. Reading further says that characters !"#$@[\]^`{|}~ should be 
encoded too if we desire greater compatibility with some MTA's, but again, there no 
mention of '.'.

!!!HOWEVER!!! Reading bolow in definitions of safe characters:

>safe-char :=  60 inclusive, and 62 through 126.
> ; Characters not listed as "mail-safe" in
> ; RFC 2049 are also not recommended.


RFC 2049 Section 3 item (8) says:
>(8)   Some mail transport agents will corrupt data that
>includes certain literal strings.  In particular, a
>period (".") alone on a line is known to be corrupted
>by some (incorrect) SMTP implementations, and a line
>that starts with the five characters "From " (the fifth
>character is a SPACE) are commonly corrupted as well.
>A careful composition agent can prevent these
>corruptions by encoding the data (e.g., in the quoted-
>printable encoding using "=46rom " in place of "From "
>at the start of a line, and "=2E" in place of "." alone
>on a line).
>
>Please note that the above list is NOT a list of >recommended practices for MTAs.  
>RFC 821 MTAs are
>prohibited from altering the character of white space or
>wrapping long lines.  These BAD and invalid practices are
>known to occur on established networks, and
>implementations should be robust in dealing with the bad
>effects they can cause.

In other words, some mail clients and MTA's are known to mess this up. Yet, it is not 
the PHP or even c-client problem really.


Previous Comments:
---

[2001-01-27 03:42:25] [EMAIL PROTECTED]
The imap_8bit() function does not duplicate leading dots, which may cause a message to 
be cut off if it has a single dot on a line. Also, mail clients such as Outlook 2000 
will strip these leading dots, which can cause an URL to be mangled if it is split 
along a dot (this is how I discovered the bug). To fix, replace any dots at the very 
start of a quoted-printable encoded line with 2 dots. (.hello becomes ..hello, etc)

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8949&edit=2


-- 
PHP Development Mailing List 
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] Zend API changes

[Vlad Krupin]

Isn't that how it already works? bug list doesn't seem too much of a 
burden for me:) I just fix a bug at a time at my own leisurly pace. 
Although it would be nice to know what's more critical to fix and what's 
not. Otherwise I pick my own random bugs...

Vlad


Billy Rose wrote:

> It is obvious that this project has a tremendous amount of effort from many
> people. Would it make sense to have someone, or a small group of people,
> whose task is to handle all of the release / testing issues? They would be
> "handed" over a release candidate from the development group to test and
> collect reports on. They then verify and classify all bugs and send reports
> back to the development team on a pre-determined time schedule, i.e. every 4
> hours or such. As the test person / group collects reports, the development
> team works on new features / already known issues. Once new issues are
> reported, they are fixed and marked off the report list. After the release
> candidate is declared stable, it is put out there. This keeps the burden of
> trying to maintain a bug list, and deal with release issues off of the main
> pipeline of the development team. What do you think?
> 
> - Original Message -
> From: "Zeev Suraski" <[EMAIL PROTECTED]>
> To: "Billy Rose" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Friday, May 04, 2001 6:33 PM
> Subject: Re: [PHP-DEV] Zend API changes
> 
> 
>> You can always suggest... :)
>> 
>> At 02:14 5/5/2001, Billy Rose wrote:
>> 
>>> The company I work for has a very quick bug turn over rate. I was
>> 
> wondering
> 
>>> if I may make a few suggestions concerning release issues / bugtracking?
>>> 
>>> - Original Message -
>>> From: "Zeev Suraski" <[EMAIL PROTECTED]>
>>> To: "Hartmut Holzgraefe" <[EMAIL PROTECTED]>
>>> Cc: <[EMAIL PROTECTED]>
>>> Sent: Friday, May 04, 2001 1:27 PM
>>> Subject: Re: [PHP-DEV] Zend API changes
>>> 
>>> 
 At 21:05 4/5/2001, Hartmut Holzgraefe wrote:
 
> PS: about the "welcome" thing above ...
> 
> -  you should know that i have put a lot of work into the manual
>(both english and german) and the function tables
 
 Hartmut,
 
 I wasn't trying to understate your work on the manual;  I told you
 personally that the function reference mechanism that you build was
>>> 
> very
> 
 impressive and useful.  I wasn't being sarcastic when I invited you
>>> 
> (and
> 
 anyone else) to help document the Zend API.  I know I won't be getting
 around to doing it in the near future, so if nobody else does it,
>>> 
> it'll
> 
 simply remain undone.
 
> -  afair there was someone who started to write a 'extension
>building manual' or something about a year ago and it was you
>, Zeev, who told him that this was useless effort as this was
>already beeing taken care off (without pointing him to this
>project or inviting him to join it)
>correct me if i'm wrong as i do not have found this posting
>in my archives yet
 
 You're not wrong;  It's been done and published
 (http://www.zend.com/apidoc/), and is the base for additional work
>>> 
> that I
> 
 invited people to improve on.
 
 Zeev
 
 
 --
 Zeev Suraski <[EMAIL PROTECTED]>
 CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
 
 
 --
 PHP Development Mailing List 
 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 
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>> 
>> --
>> Zeev Suraski <[EMAIL PROTECTED]>
>> CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
>> 
>> 
>> --
>> PHP Development Mailing List 
>> 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #7531 Updated: imap_qprint faultly returns empty string

[vlad]

ID: 7531
Updated by: vlad
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: IMAP related
PHP Version: 4.0.1pl2
Assigned To: 
Comments:

That's not a bug. This is a malformed quoted-printable encoding (read FRC 2045 section 
6.7). 

If you try to do imap_qprint("=\r\nE9") (which is found in line 3 of your example), 
it's not gonna work, and neither will quoted_printable_decode(). Both will print 
return "E9", and not the character encoded.

You can't see any output at all because don't even use "\r\n", but just "\n", which is 
not RFC compliant by itself (but nobody seems to care).

In short, this is not a bug, and the difference between imap_qprint() and 
quoted_printable_decode() is that one does not produce any result at all, while the 
other produces bogus result (although it does it's best to guess what you meant and 
fails).

Vlad


Previous Comments:
---

[2000-10-30 10:00:20] [EMAIL PROTECTED]
I just found a mail body which is not decoded properly
by imap_qprint() (returning empty string), but is 
decoded the right way by quoted_printable_decode()

the string is the following (not including the -- lines)
-
>Monsieur, A la suite de l'envoi d'un bon vert pour la 
connection =E0=20 resulb, nous n'avons toujours pas 
de nouvelles. Le payement a-t'il bien =E9t=E9 effectu=
E9? sinon pourriez-vous nous=20 prevenir s'il vous 
plait et dans le cas contraire dans combien=20 de 
temps aurons-nous une adresse IP? =20 Je vous 
serais gr=E9 de me tenir au courant. Merci d'avance 
Sadia >> Monsieur, >> >> >>Notre service 
d'embryologie mol=E9culaire aimerait faire une 
demande pour >>la connection d'un nouvel ordinateur 
=E0 resulb. Nous comptons effectuer >>le paiement 
des 4000 Bef par bon vert , vous serait-il possible de 
nous >>faire parvenir le num=E9ro de compte vers 
lequel nous devons effectuer le >>virement. >> >>Je 
vous remercie d'avance. >> >>Sadia > >Bonjour, > >Il 
suffit de mettre le num=E9ro du cl=E9 d'imputation 
dans la case r=E9serv=E9 >au titulaire du compte et 
pour le reste c'est la secr=E9taire de notre >service qui 
s'en occupe. > >Bien =E0 vous, Kurosh Mahmoudi >=
3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3 D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D >SERVICE RESEAU > >CP 
197 >AVENUE F.D. ROOSEVELT 50 >B-1050 
BRUXELLES >TEL. 32-2-650 37 10 >FAX. 32-2-650 37 
40 >E-MAIL:[EMAIL PROTECTED] >=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D =
3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3D > > >
-

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=7531&edit=2


-- 
PHP Development Mailing List 
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] Zend API changes

[Sean R. Bright]

Billy:

Meet the QA team :)  [EMAIL PROTECTED]

> -Original Message-
> From: Billy Rose [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 04, 2001 7:53 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] Zend API changes
> 
> 
> It is obvious that this project has a tremendous amount of 
> effort from many
> people. Would it make sense to have someone, or a small group 
> of people,
> whose task is to handle all of the release / testing issues? 
> They would be
> "handed" over a release candidate from the development group 
> to test and
> collect reports on. They then verify and classify all bugs 
> and send reports
> back to the development team on a pre-determined time 
> schedule, i.e. every 4
> hours or such. As the test person / group collects reports, 
> the development
> team works on new features / already known issues. Once new issues are
> reported, they are fixed and marked off the report list. 
> After the release
> candidate is declared stable, it is put out there. This keeps 
> the burden of
> trying to maintain a bug list, and deal with release issues 
> off of the main
> pipeline of the development team. What do you think?
> 
> - Original Message -
> From: "Zeev Suraski" <[EMAIL PROTECTED]>
> To: "Billy Rose" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Friday, May 04, 2001 6:33 PM
> Subject: Re: [PHP-DEV] Zend API changes
> 
> 
> > You can always suggest... :)
> >
> > At 02:14 5/5/2001, Billy Rose wrote:
> > >The company I work for has a very quick bug turn over rate. I was
> wondering
> > >if I may make a few suggestions concerning release issues 
> / bugtracking?
> > >
> > >- Original Message -
> > >From: "Zeev Suraski" <[EMAIL PROTECTED]>
> > >To: "Hartmut Holzgraefe" <[EMAIL PROTECTED]>
> > >Cc: <[EMAIL PROTECTED]>
> > >Sent: Friday, May 04, 2001 1:27 PM
> > >Subject: Re: [PHP-DEV] Zend API changes
> > >
> > >
> > > > At 21:05 4/5/2001, Hartmut Holzgraefe wrote:
> > > > >PS: about the "welcome" thing above ...
> > > > >
> > > > >-  you should know that i have put a lot of work into 
> the manual
> > > > >(both english and german) and the function tables
> > > >
> > > > Hartmut,
> > > >
> > > > I wasn't trying to understate your work on the manual;  
> I told you
> > > > personally that the function reference mechanism that 
> you build was
> very
> > > > impressive and useful.  I wasn't being sarcastic when I 
> invited you
> (and
> > > > anyone else) to help document the Zend API.  I know I 
> won't be getting
> > > > around to doing it in the near future, so if nobody 
> else does it,
> it'll
> > > > simply remain undone.
> > > >
> > > > >-  afair there was someone who started to write a 'extension
> > > > >building manual' or something about a year ago and 
> it was you
> > > > >, Zeev, who told him that this was useless effort 
> as this was
> > > > >already beeing taken care off (without pointing him to this
> > > > >project or inviting him to join it)
> > > > >correct me if i'm wrong as i do not have found this posting
> > > > >in my archives yet
> > > >
> > > > You're not wrong;  It's been done and published
> > > > (http://www.zend.com/apidoc/), and is the base for 
> additional work
> that I
> > > > invited people to improve on.
> > > >
> > > > Zeev
> > > >
> > > >
> > > > --
> > > > Zeev Suraski <[EMAIL PROTECTED]>
> > > > CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> > > >
> > > >
> > > > --
> > > > PHP Development Mailing List 
> > > > 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 
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >To contact the list administrators, e-mail: 
> [EMAIL PROTECTED]
> >
> > --
> > Zeev Suraski <[EMAIL PROTECTED]>
> > CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> >
> >
> > --
> > PHP Development Mailing List 
> > 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 
> 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10678 Updated: distinction between false and "0" (string)

[ms]

ID: 10678
User Update by: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *General Issues
Description: distinction between false and "0" (string)

ah .. sorry. thanks for the explanation.


Previous Comments:
---

[2001-05-04 19:34:48] [EMAIL PROTECTED]
This has been discussed several times on the mailing lists;
check the archives at http://marc.theaimsgroup.com.

The answer is in the manual: 

http://www.php.net/manual/en/language.operators.comparison.php

Basically, 0 is a false value but is of type int. You want
to test for a return value of false (type boolean), so you
need the 'identical' comparison operator: '==='.

$haystack = '1230';
if (strstr($haystack, '0') === false) {
echo "oh non";
}


---

[2001-05-04 19:21:26] [EMAIL PROTECTED]

There is a subtle problem with functions returning 'false' as
an return status indication.

Take for example strstr(haystack, needle). 

The function returns 'false' to indicate that  could not
be found in  or returns the substring of haystack
starting with 

With certain strings the above assertion is not true with php:

$haystack='1230';

if (strstr($haystack,"0")==false)
{ echo ' oh no.. '; }



---


Full Bug description available at: http://bugs.php.net/?id=10678


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10665 Updated: Requesting additional functions in OpenSSL module (working patch available)

[wez]

ID: 10665
Updated by: wez
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Feature/Change Request
PHP Version: 4.0.5
Assigned To: wez
Comments:

It's now in CVS; please verify that it works and I'll close this report.

Thanks for the patch!

--Wez.

Previous Comments:
---

[2001-05-04 12:48:31] [EMAIL PROTECTED]
I'll review it, and probably commit it.

--Wez.

---

[2001-05-04 10:47:13] [EMAIL PROTECTED]
I'd like to use more of the RSA functions that OpenSSL provides. What I needed most 
was the possibility to encrypt something with your private key directly. I've made a 
patch that works fine for me and might be of use to others, too. I only tested it with 
OpenSSL 0.9.6a.

As the patch is 7kb, I just put the link to it here: 
http://global.team17.com/php-4.0.5-rsa.patch

The new functions are:

openssl_private_encrypt
openssl_private_decrypt
openssl_public_encrypt
openssl_public_decrypt

Cheers,

Sascha Kettler

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10665&edit=2


-- 
PHP Development Mailing List 
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] Zend API changes

[Billy Rose]

It is obvious that this project has a tremendous amount of effort from many
people. Would it make sense to have someone, or a small group of people,
whose task is to handle all of the release / testing issues? They would be
"handed" over a release candidate from the development group to test and
collect reports on. They then verify and classify all bugs and send reports
back to the development team on a pre-determined time schedule, i.e. every 4
hours or such. As the test person / group collects reports, the development
team works on new features / already known issues. Once new issues are
reported, they are fixed and marked off the report list. After the release
candidate is declared stable, it is put out there. This keeps the burden of
trying to maintain a bug list, and deal with release issues off of the main
pipeline of the development team. What do you think?

- Original Message -
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Billy Rose" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, May 04, 2001 6:33 PM
Subject: Re: [PHP-DEV] Zend API changes


> You can always suggest... :)
>
> At 02:14 5/5/2001, Billy Rose wrote:
> >The company I work for has a very quick bug turn over rate. I was
wondering
> >if I may make a few suggestions concerning release issues / bugtracking?
> >
> >- Original Message -
> >From: "Zeev Suraski" <[EMAIL PROTECTED]>
> >To: "Hartmut Holzgraefe" <[EMAIL PROTECTED]>
> >Cc: <[EMAIL PROTECTED]>
> >Sent: Friday, May 04, 2001 1:27 PM
> >Subject: Re: [PHP-DEV] Zend API changes
> >
> >
> > > At 21:05 4/5/2001, Hartmut Holzgraefe wrote:
> > > >PS: about the "welcome" thing above ...
> > > >
> > > >-  you should know that i have put a lot of work into the manual
> > > >(both english and german) and the function tables
> > >
> > > Hartmut,
> > >
> > > I wasn't trying to understate your work on the manual;  I told you
> > > personally that the function reference mechanism that you build was
very
> > > impressive and useful.  I wasn't being sarcastic when I invited you
(and
> > > anyone else) to help document the Zend API.  I know I won't be getting
> > > around to doing it in the near future, so if nobody else does it,
it'll
> > > simply remain undone.
> > >
> > > >-  afair there was someone who started to write a 'extension
> > > >building manual' or something about a year ago and it was you
> > > >, Zeev, who told him that this was useless effort as this was
> > > >already beeing taken care off (without pointing him to this
> > > >project or inviting him to join it)
> > > >correct me if i'm wrong as i do not have found this posting
> > > >in my archives yet
> > >
> > > You're not wrong;  It's been done and published
> > > (http://www.zend.com/apidoc/), and is the base for additional work
that I
> > > invited people to improve on.
> > >
> > > Zeev
> > >
> > >
> > > --
> > > Zeev Suraski <[EMAIL PROTECTED]>
> > > CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> > >
> > >
> > > --
> > > PHP Development Mailing List 
> > > 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 
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
> --
> Zeev Suraski <[EMAIL PROTECTED]>
> CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
>
>
> --
> PHP Development Mailing List 
> 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10448 Updated: PHP core dumps after array_init

[bfoddy]

ID: 10448
User Update by: [EMAIL PROTECTED]
Old-Status: Open
Status: Duplicate
Bug Type: Reproduceable crash
Description: PHP core dumps after array_init

I believe the root cause of this is a dupe of 2220.
I used a DL module with debugging turned on.

Previous Comments:
---

[2001-04-22 23:46:33] [EMAIL PROTECTED]
I've found that any PHP function can cause a core dump (Seg Fault) if it performs an 
array_init (return_value) function, and then subsequently returns with RETURN_FALSE or 
RETURN_TRUE without adding any values to the array.  Perhaps occurs under other 
conditions also.

This can easily occur in code if after the array_init call
the program encounters a to which it wants to return ERROR
for.

Have I violated any Zend don't-do's by this?

---


Full Bug description available at: http://bugs.php.net/?id=10448


-- 
PHP Development Mailing List 
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] openssl module for php

[Wez Furlong]

I've applied Saschas patch to latest CVS;
it's more or less gone in as supplied, although I've slightly modified
resource allocation/checking (if emalloc fails then PHP dies, so there is
no need to check the return value) and made the padding constants case
sensitive in "php space".

Sascha, I would be really grateful if you could check out the latest CVS
and test the code to verify that it behaves correctly (or at least behaves
in the same way as your original patch for PHP 4.0.5).

This might make it into 4.0.6 due for the "release process" shortly.

--Wez.




-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10678 Updated: distinction between false and "0" (string)

[torben]

ID: 10678
Updated by: torben
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: *General Issues
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

This has been discussed several times on the mailing lists;
check the archives at http://marc.theaimsgroup.com.

The answer is in the manual: 

http://www.php.net/manual/en/language.operators.comparison.php

Basically, 0 is a false value but is of type int. You want
to test for a return value of false (type boolean), so you
need the 'identical' comparison operator: '==='.

$haystack = '1230';
if (strstr($haystack, '0') === false) {
echo "oh no\n";
}


Previous Comments:
---

[2001-05-04 19:21:26] [EMAIL PROTECTED]

There is a subtle problem with functions returning 'false' as
an return status indication.

Take for example strstr(haystack, needle). 

The function returns 'false' to indicate that  could not
be found in  or returns the substring of haystack
starting with 

With certain strings the above assertion is not true with php:

$haystack='1230';

if (strstr($haystack,"0")==false)
{ echo ' oh no.. '; }



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10678&edit=2


-- 
PHP Development Mailing List 
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] Zend API changes

[Zeev Suraski]

You can always suggest... :)

At 02:14 5/5/2001, Billy Rose wrote:
>The company I work for has a very quick bug turn over rate. I was wondering
>if I may make a few suggestions concerning release issues / bugtracking?
>
>- Original Message -
>From: "Zeev Suraski" <[EMAIL PROTECTED]>
>To: "Hartmut Holzgraefe" <[EMAIL PROTECTED]>
>Cc: <[EMAIL PROTECTED]>
>Sent: Friday, May 04, 2001 1:27 PM
>Subject: Re: [PHP-DEV] Zend API changes
>
>
> > At 21:05 4/5/2001, Hartmut Holzgraefe wrote:
> > >PS: about the "welcome" thing above ...
> > >
> > >-  you should know that i have put a lot of work into the manual
> > >(both english and german) and the function tables
> >
> > Hartmut,
> >
> > I wasn't trying to understate your work on the manual;  I told you
> > personally that the function reference mechanism that you build was very
> > impressive and useful.  I wasn't being sarcastic when I invited you (and
> > anyone else) to help document the Zend API.  I know I won't be getting
> > around to doing it in the near future, so if nobody else does it, it'll
> > simply remain undone.
> >
> > >-  afair there was someone who started to write a 'extension
> > >building manual' or something about a year ago and it was you
> > >, Zeev, who told him that this was useless effort as this was
> > >already beeing taken care off (without pointing him to this
> > >project or inviting him to join it)
> > >correct me if i'm wrong as i do not have found this posting
> > >in my archives yet
> >
> > You're not wrong;  It's been done and published
> > (http://www.zend.com/apidoc/), and is the base for additional work that I
> > invited people to improve on.
> >
> > Zeev
> >
> >
> > --
> > Zeev Suraski <[EMAIL PROTECTED]>
> > CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> >
> >
> > --
> > PHP Development Mailing List 
> > 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 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10679: IMAP_UID doen't return what it should

[rick]

From: [EMAIL PROTECTED]
Operating system: Seawolf (Red hat)
PHP version:  4.0.4pl1
PHP Bug Type: IMAP related
Bug description:  IMAP_UID doen't return what it should

From: "Rick Gigger" <[EMAIL PROTECTED]>  All email messages have a unique 
identifier.  It is a long string that ususally contains a domiain name or ip address.  
It is unique to all email addresses in the world.  It would be much, much more useful 
if imap_uid would return that instead.

Previous Comments:
---

[2001-05-03 15:36:24] [EMAIL PROTECTED]
You might have the wrong idea of what uid is - what do you expect it to be? On pop 
servers the message uid will very likely just _be_ the message number...

---

[2000-10-27 03:30:55] [EMAIL PROTECTED]
When I call connect to a qmail pop server and call imap_uid all it does is return the 
message number back to me.  It DOES NOT return the uid.  I have to call imap_header 
for that and it is very slow.

---


-- 
Edit Bug report at: http://bugs.php.net/?id=10679&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10678: distinction between false and "0" (string)

[ms]

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.0.4pl1
PHP Bug Type: *General Issues
Bug description:  distinction between false and "0" (string)


There is a subtle problem with functions returning 'false' as
an return status indication.

Take for example strstr(haystack, needle). 

The function returns 'false' to indicate that  could not
be found in  or returns the substring of haystack
starting with 

With certain strings the above assertion is not true with php:

$haystack='1230';

if (strstr($haystack,"0")==false)
{ echo ' oh no.. '; }




-- 
Edit Bug report at: http://bugs.php.net/?id=10678&edit=1



-- 
PHP Development Mailing List 
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] 4.1 & Declaration Case Persistance

[Zeev Suraski]

Guys,

We're not holding votes about this stuff.  Definitely not now.
Without trying to initiate a discussion, please bear in mind that if we 
break compatibility completely, we're screwing companies that chose 
PHP.  It'll put PHP in a very unprofessional light.

Food for thought;  We're way too far away from this to even discuss it.

Zeev

At 22:51 4/5/2001, Wez Furlong wrote:
>"Sterling Hughes" <[EMAIL PROTECTED]> wrote:
> > On Fri, 4 May 2001, Chuck Hagenbuch wrote:
> > > That's a problem with it being an option, yes. I'd vote for
> > > just making php case sensitive, period.
> > +1 for that! :)
>
>+1
>
>--Wez.
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
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] Zend API changes

[Billy Rose]

The company I work for has a very quick bug turn over rate. I was wondering
if I may make a few suggestions concerning release issues / bugtracking?

- Original Message -
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Hartmut Holzgraefe" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, May 04, 2001 1:27 PM
Subject: Re: [PHP-DEV] Zend API changes


> At 21:05 4/5/2001, Hartmut Holzgraefe wrote:
> >PS: about the "welcome" thing above ...
> >
> >-  you should know that i have put a lot of work into the manual
> >(both english and german) and the function tables
>
> Hartmut,
>
> I wasn't trying to understate your work on the manual;  I told you
> personally that the function reference mechanism that you build was very
> impressive and useful.  I wasn't being sarcastic when I invited you (and
> anyone else) to help document the Zend API.  I know I won't be getting
> around to doing it in the near future, so if nobody else does it, it'll
> simply remain undone.
>
> >-  afair there was someone who started to write a 'extension
> >building manual' or something about a year ago and it was you
> >, Zeev, who told him that this was useless effort as this was
> >already beeing taken care off (without pointing him to this
> >project or inviting him to join it)
> >correct me if i'm wrong as i do not have found this posting
> >in my archives yet
>
> You're not wrong;  It's been done and published
> (http://www.zend.com/apidoc/), and is the base for additional work that I
> invited people to improve on.
>
> Zeev
>
>
> --
> Zeev Suraski <[EMAIL PROTECTED]>
> CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
>
>
> --
> PHP Development Mailing List 
> 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 
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] __FILE__ constant

[Jon Parise]

On Fri, May 04, 2001 at 06:31:37PM -0400, Jon Parise wrote:

> > >works fine here. Or do you meant something
> > > else, Chuck?
> > 
> > The value is set; it's just missing all path delimiters. So if the file is
> > actually /var/www/foo/bar.php, echo __FILE__ gives me "varwwwfooobar.php".
> > Which means that dirname(__FILE__) returns incorrect results.
> 
> It's working fine here, too.
 
Woops, scratch that.  I see the problem now, too.  It was
introduced sometime between May 2nd (my last build) and today.
Because now files in the Zend repository have changed in that
window, I think it's probably a PHP bug.

-- 
Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

-- 
PHP Development Mailing List 
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] __FILE__ constant

[Jon Parise]

On Fri, May 04, 2001 at 04:28:56PM -0400, Chuck Hagenbuch wrote:

> >works fine here. Or do you meant something
> > else, Chuck?
> 
> The value is set; it's just missing all path delimiters. So if the file is
> actually /var/www/foo/bar.php, echo __FILE__ gives me "varwwwfooobar.php".
> Which means that dirname(__FILE__) returns incorrect results.

It's working fine here, too.

-- 
Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

-- 
PHP Development Mailing List 
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] 4.1 & Declaration Case Persistance

[Joe Brown]

1++;

""Wez Furlong"" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "Sterling Hughes" <[EMAIL PROTECTED]> wrote:
> > On Fri, 4 May 2001, Chuck Hagenbuch wrote:
> > > That's a problem with it being an option, yes. I'd vote for
> > > just making php case sensitive, period.
> > +1 for that! :)
>
> +1
>
> --Wez.
>
>
> --
> PHP Development Mailing List 
> 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 4.0 Bug #10675 Updated: Executing background job from PHP causes session lock-up

[Joe Brown]

This sounds as if it may be a disk caching issue.

Is your session data stored in files (the default)?

flush() dumps io to the web browser, is there a file_flush()?

<[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> ID: 10675
> User Update by: [EMAIL PROTECTED]
> Status: Open
> Bug Type: *Session related
> Description: Executing background job from PHP causes session lock-up
>
> Executed a perl script in the background like this:
> perl scriptname.pl $otherParams 2> /dev/null 1> /dev/null
>
> Perl script forks and parent dies, so PHP "should" see the script as
finished
> immediately, perl child does work in background (takes a few minutes to
run).
>
> PHP script that spawned perl script completes OK, browser stops waiting
for more data from
> php script as it should.
>
> However, when using the same browser window (or one from browser's
file->new window) no
> other pages that referrence the session will load in the browser.  If we
force the session
> to destroy just after the system() call, other scripts load just fine.
Also, other
> scripts work just fine if we start a new browser from scratch (creates new
session).
>
> So it appears that the PHP session is getting messed up somehow b/c of the
background
> system/exec/`` call.  This seems to prevent the following pages from
loading the session
> properly and therefore they will not run.
>
>
> One other thing, once the child perl script is finally complete everything
starts working again, i.e.-the session is OK again.
>
> Previous Comments:
> --
-
>
> [2001-05-04 15:22:47] [EMAIL PROTECTED]
> Executed a perl script in the background like this:
> perl scriptname.pl $otherParams 2> /dev/null 1> /dev/null
>
> Perl script forks and parent dies, so PHP "should" see the script as
finished immediately, perl child does work in background (takes a few
minutes to run).
>
> PHP script that spawned perl script completes OK, browser stops waiting
for more data from php script as it should.
>
> However, when using the same browser window (or one from browser's
file->new window) no other pages that referrence the session will load in
the browser.  If we force the session to destroy just after the system()
call, other scripts load just fine.  Also, other scripts work just fine if
we start a new browser from scratch (creates new session).
>
> So it appears that the PHP session is getting messed up somehow b/c of the
background system/exec/`` call.  This seems to prevent the following pages
from loading the session properly and therefore they will not run.
>
> --
-
>
>
> Full Bug description available at: http://bugs.php.net/?id=10675
>
>
> --
> PHP Development Mailing List 
> 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] CVS Account Request

[CVS Account Request]

Full name: Stephen Schadt
Email: [EMAIL PROTECTED]
ID: sschadt
Purpose: Bug testing and comments for OpenLink ODBC

-- 
PHP Development Mailing List 
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] 4.1 & Declaration Case Persistance

[Shaun Batterton]

Y'all need to stop.  If this feature is optional, then it won't affect any
existing scripts, and on the other hand, people may actually benifit from
the change.  If someone uses the optional feature, and it makes that
script non-portable then that is that person's problem.  This is just a
roadblock that happens when you mix a case sensitive OS with a case
insensitive language.  It's similar to mysql database names being case
sensitive to some extent because a database cooresponds to a directory.

Zeev already said it would be a feature in a future release.  Nuff said.

Shaun


On Fri, 4 May 2001, Colin Viebrock wrote:

> > The question was under what key the class entry should be stored...  At
> any
> > rate, it's a non-issue;  Saving the 'beautiful' version of the class name
> > is possible, but is a bit hacky IMHO.  There should be an optional case
> > sensitive mode, and we'll introduce one in one of the future versions of
> PHP.
> 
> Yeah ... I posted before reading the remainder of the thread. :)
> 
> One "problem" with case sensitivity (perhaps) is that it may make some
> scripts non-portable.
> 
> Say I develop a super-duper PEAR class using case-sensitive code (cause
> that's what I have on my server).  Someone who is running PHP in
> case-insensitive mode will complain when my code says:
> 
> if (get_class($foo)=='Some_Class_Name')) { ...
> 
> So all code that might be shared either a) needs to only us lowercase names,
> b) coders need to implicity lowercase their comparisons by changing the
> above line to:
> 
> if (strtolower(get_class($foo))=='some_class_name')) { ...
> 
> or c) we also need a way to switch between sensitivity modes through PHP
> code (either an ini_set() call, or something else).
> 
> Also, case-sensitivity means I can write code with functions like
> StrReplace() and MySQL_Fetch_Row(), which will seriously cause problems on
> non-case-sensitive installs ... unless all variations of PHP functions are
> reserved.
> 
> - Colin
> 
> 
> 

-- 


-- 
PHP Development Mailing List 
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] openssl module for php

[Sascha Kettler]

> On Fri, May 04, 2001 at 09:09:51PM +0100, Wez Furlong wrote:
> > On 2001-05-04 20:47:25, "Stig Venaas" <[EMAIL PROTECTED]> wrote:
> > > Even though it is 4 functions, I think users will find it easier to
> > > work with functions called openssl_public_encrypt,
> > > openssl_private_decrypt etc. It also separates them from possible
> > > symmetric enryption later on.
> > 
> > So are we looking at openssl_asym_public_encrypt() (or is the asym part
> > redundant by implication?).
> 
> I think that's pretty clear, but...

But?

> > IMHO, I prefer to spell it out - especially to those new to openssl (I'm
> > fairly new to it!) it helps to have things spelled out.  That way, you
> > don't have to be an openssl hacker to benefit from the PHP interface.
> >  
> > > I think it's generally better to not alter arguments, better return it
> > > this way. Is it good enough to report errors by returning an empty
> > > string? I think so.
> > 
> > Can an empty string become an non-empty string when encrypted?
> > If so, when we decrypt it, we will not be able to distinguish
> > thecorrectly decrypted empty string from an error condition.
> 
> Good point
> 
> > We could return false (as is the convention), but then everyone would
> > have to use === to check it correctly.
> 
> Yes, and not everyone will...
> 
> Sascha also has a point regarding consistency with the existing
> functions, and I was the one who chose that interface... The reason
> was to have something that looked a bit like the C API, and to make
> the interface as clear as possible.
> 
> So, I withdraw that comment (:
> 
> I don't know for sure and I don't care to check right now, do you know
> if we always can see if the key is public or private? In that case, we
> don't need separate functions. Rather than showing my ignorance, I
> should investigate myself I guess (:

We could do that, but then we'd have to add something else telling the user
this isn't symmetric encryption :)

> Well, I think I'll leave this to you, haven't got that much sensible
> to say, and I'm busy with something else...

I prefer to have it separate, but that's just my personal opinion.

Sascha


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10677: Session lifetimes beyond browse on per session basis

[andrew]

From: [EMAIL PROTECTED]
Operating system: Linux (RH6)
PHP version:  4.0.4pl1
PHP Bug Type: Feature/Change Request
Bug description:  Session lifetimes beyond browse on per session basis

Something that's been requested in the annoated manuals but I don't see an actual 
feature request.

The problem is that while there is a session.gc_maxlifetime option in the ini file for 
dealing with the lifetime of session data, there is no way to set this on a per 
session level.

Eg. I have a login class that uses sessions to maintain data. It works fine so long as 
I don't want my login sessions to outlast the browser. Once I decided I wanted that to 
at least be an option of my class (set through a method) I had to perform a 
work-around of the session.cookie_lifetime INI file settings (since the 
session_set_cookie_params() call doesn't seem to work properly, or at least the way I 
wanted it to). 

At any rate, I managed to get around this problem and everything was working fine, but 
every so often (seemingly without ryhme or reason) when I returned to my example page 
the login class would come to a screaming halt and die(). After debugging for quite 
some time, I determined that it was because although I had managed to extend the life 
of the session id (though another cookie of my own and some funky hand-waving logic) 
the session DATA had expired after 1440 seconds, or 24 minutes. I got this number from 
the INI file as it was the value set for session.gc_maxlifetime.

Unfortunately, there is no way to extend this lifetime value through PHP; only via the 
ini file. This is not a viable solution however, when you run multiple virtual hosts 
on your server with the same PHP (as I do) and some of them have different login 
requirements (some more secure than others; some want the login to expire with the 
browser, others want it to last a week, etc.)

So my feature request is for a session_set_data_lifetime() function (and probably a 
get() equivilant for completeness). I'd also like it if the 
session_set_cookie_params() function actually worked like I think it should (and not, 
as it says cryptically, 'only for the duration of the script')

Thank you.



-- 
Edit Bug report at: http://bugs.php.net/?id=10677&edit=1



-- 
PHP Development Mailing List 
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] openssl module for php

[Sascha Kettler]

> > I've used SSLeay back in 1996 once, and then a few weeks ago for my
> patch.
> > You don't need to be an openssl expert, but as with all cryptography you
> > should have some basic understanding before using it.
> 
> which is why i'm still confused on how you intend to get any of the
> openssl functions to simply figure out the key type it is.  especially if
you
> store it in PEM, much less DSA.

The PHP code uses PEM_ASN1_read_bio to parse the PEM. This function works
for both RSA and DSA key stored in PEM. It returns a pointer to a EVP_PKEY
structure, which in turn has a variable type that tells which type of key this
is.

Sascha


-- 
PHP Development Mailing List 
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] __FILE__ constant

[Chuck Hagenbuch]

Quoting Sebastian Bergmann <[EMAIL PROTECTED]>:

>works fine here. Or do you meant something
> else, Chuck?

The value is set; it's just missing all path delimiters. So if the file is
actually /var/www/foo/bar.php, echo __FILE__ gives me "varwwwfooobar.php".
Which means that dirname(__FILE__) returns incorrect results.

-chuck

--
"My intuitive grasp of math often leads me astray." -me

-- 
PHP Development Mailing List 
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] openssl module for php

[Stig Venaas]

On Fri, May 04, 2001 at 09:09:51PM +0100, Wez Furlong wrote:
> On 2001-05-04 20:47:25, "Stig Venaas" <[EMAIL PROTECTED]> wrote:
> > Even though it is 4 functions, I think users will find it easier to
> > work with functions called openssl_public_encrypt,
> > openssl_private_decrypt etc. It also separates them from possible
> > symmetric enryption later on.
> 
> So are we looking at openssl_asym_public_encrypt() (or is the asym part
> redundant by implication?).

I think that's pretty clear, but...
> 
> IMHO, I prefer to spell it out - especially to those new to openssl (I'm
> fairly new to it!) it helps to have things spelled out.  That way, you
> don't have to be an openssl hacker to benefit from the PHP interface.
>  
> > I think it's generally better to not alter arguments, better return it
> > this way. Is it good enough to report errors by returning an empty
> > string? I think so.
> 
> Can an empty string become an non-empty string when encrypted?
> If so, when we decrypt it, we will not be able to distinguish the correctly
> decrypted empty string from an error condition.

Good point

> We could return false (as is the convention), but then everyone would have
> to use === to check it correctly.

Yes, and not everyone will...

Sascha also has a point regarding consistency with the existing
functions, and I was the one who chose that interface... The reason
was to have something that looked a bit like the C API, and to make
the interface as clear as possible.

So, I withdraw that comment (:

I don't know for sure and I don't care to check right now, do you know
if we always can see if the key is public or private? In that case, we
don't need separate functions. Rather than showing my ignorance, I
should investigate myself I guess (:

Well, I think I'll leave this to you, haven't got that much sensible
to say, and I'm busy with something else...

Stig

-- 
PHP Development Mailing List 
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] openssl module for php

[spencer 'sporty' portee]

> I've used SSLeay back in 1996 once, and then a few weeks ago for my patch.
> You don't need to be an openssl expert, but as with all cryptography you
> should have some basic understanding before using it.

which is why i'm still confused on how you intend to get any of the openssl functions 
to simply figure out the key type it is.  especially if you store it in PEM, much less 
DSA.



-- 
PHP Development Mailing List 
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] openssl module for php

[Sascha Kettler]

> On 2001-05-04 20:47:25, "Stig Venaas" <[EMAIL PROTECTED]> wrote:
> > Even though it is 4 functions, I think users will find it easier to
> > work with functions called openssl_public_encrypt,
> > openssl_private_decrypt etc. It also separates them from possible
> > symmetric enryption later on.
> 
> So are we looking at openssl_asym_public_encrypt() (or is the asym part
> redundant by implication?).

It is redundant for me, but I've got no idea what other people think.

> IMHO, I prefer to spell it out - especially to those new to openssl (I'm
> fairly new to it!) it helps to have things spelled out.  That way, you
> don't have to be an openssl hacker to benefit from the PHP interface.

I've used SSLeay back in 1996 once, and then a few weeks ago for my patch.
You don't need to be an openssl expert, but as with all cryptography you
should have some basic understanding before using it.

> > I think it's generally better to not alter arguments, better return it
> > this way. Is it good enough to report errors by returning an empty
> > string? I think so.
> 
> Can an empty string become an non-empty string when encrypted?
> If so, when we decrypt it, we will not be able to distinguish the
> correctly decrypted empty string from an error condition.

Not when encrypting, but if you encrypt an empty string and then decrypt it,
it will become the empty string again.

> We could return false (as is the convention), but then everyone would have
> to use === to check it correctly.
> 
> If an empty string is not a valid return result, then we are OK.

It's invalid on encryption, but valid on decryption.

Sascha


-- 
PHP Development Mailing List 
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] openssl module for php

[Sascha Kettler]

> On 2001-05-04 20:21:28, "Sascha Kettler" <[EMAIL PROTECTED]> wrote:
> > Sounds ok, although I wouldn't call it openssl_key_* but openssl_asym_*
> > similar.
> 
> Yeah, that sounds better.
> 
> > I don't know what people would prefer: Separate functions or a
> > boolean. What's the general opinion on that?
> 
> IMHO, openssl_asym_public_encrypt is just a bit too long for a function
> name.

public/private_encrypt/decrypt should imply use of an asymmetric encryption,
at least it does for me. So then there's no need for the _asym bit (which
was just a replacement for openssl_key_encrypt, as this wasn't saying anything
about asymmetric encryption).

> I suppose a more sensible way is to define some constants (sth like):
> OPENSSL_ENC_PUBLIC and OPENSSL_ENC_PRIVATE so that the parameter has an
> instant obvious meaning (compared to just true/false).
> 
> Mind you: strlen(constant) + strlen(openssl_asym_encrypt) >
> strlen(openssl_asym_public_encrypt)...
> 
> I suppose it's just psychological, but shorter function names seem shorter
> overall (to me anyway).

No problem with that, saves me some typing (or doing a wrapper with a
shorter name) ;)

Sascha


-- 
PHP Development Mailing List 
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] __FILE__ constant

[Sebastian Bergmann]

Chuck Hagenbuch wrote:
> It was a change in Zend (I'm nearly positive) that broke the __FILE__
>  constant. I've heard one person verify this and one person say it 
> works for them; can people running latest cvs (and latest cvs of 
> Zend, as well) say if it works for them or not?

   works fine here. Or do you meant something
else, Chuck?

-- 
 sebastian bergmann[EMAIL PROTECTED]
   http://www.sebastian-bergmann.de

 bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.de

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10674 Updated: I cannot confoigure php4 with postgres sql

[sniper]

ID: 10674
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: *General Issues
PHP Version: 4.0.4
Assigned To: 
Comments:

This is not a support forum. Ask these questions on 
[EMAIL PROTECTED] or [EMAIL PROTECTED]



Previous Comments:
---

[2001-05-04 13:51:24] [EMAIL PROTECTED]
How can u configure php4 to work with postgres sql.
It works fine with mysql.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10674&edit=2


-- 
PHP Development Mailing List 
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] openssl module for php

[Wez Furlong]

On 2001-05-04 20:21:28, "Sascha Kettler" <[EMAIL PROTECTED]> wrote:
> Sounds ok, although I wouldn't call it openssl_key_* but openssl_asym_*
> similar.

Yeah, that sounds better.

> I don't know what people would prefer: Separate functions or a
> boolean. What's the general opinion on that?

IMHO, openssl_asym_public_encrypt is just a bit too long for a function
name.

I suppose a more sensible way is to define some constants (sth like):
OPENSSL_ENC_PUBLIC and OPENSSL_ENC_PRIVATE so that the parameter has an
instant obvious meaning (compared to just true/false).

Mind you: strlen(constant) + strlen(openssl_asym_encrypt) >
strlen(openssl_asym_public_encrypt)...

I suppose it's just psychological, but shorter function names seem shorter
overall (to me anyway).

--Wez.



-- 
PHP Development Mailing List 
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] openssl module for php

[Wez Furlong]

On 2001-05-04 20:47:25, "Stig Venaas" <[EMAIL PROTECTED]> wrote:
> Even though it is 4 functions, I think users will find it easier to
> work with functions called openssl_public_encrypt,
> openssl_private_decrypt etc. It also separates them from possible
> symmetric enryption later on.

So are we looking at openssl_asym_public_encrypt() (or is the asym part
redundant by implication?).

IMHO, I prefer to spell it out - especially to those new to openssl (I'm
fairly new to it!) it helps to have things spelled out.  That way, you
don't have to be an openssl hacker to benefit from the PHP interface.
 
> I think it's generally better to not alter arguments, better return it
> this way. Is it good enough to report errors by returning an empty
> string? I think so.

Can an empty string become an non-empty string when encrypted?
If so, when we decrypt it, we will not be able to distinguish the correctly
decrypted empty string from an error condition.

We could return false (as is the convention), but then everyone would have
to use === to check it correctly.

If an empty string is not a valid return result, then we are OK.

--Wez.




-- 
PHP Development Mailing List 
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] 4.1 & Declaration Case Persistance

[Wez Furlong]

"Sterling Hughes" <[EMAIL PROTECTED]> wrote:
> On Fri, 4 May 2001, Chuck Hagenbuch wrote:
> > That's a problem with it being an option, yes. I'd vote for
> > just making php case sensitive, period.
> +1 for that! :)

+1 

--Wez.


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] __FILE__ constant

[Chuck Hagenbuch]

It was a change in Zend (I'm nearly positive) that broke the __FILE__
constant. I've heard one person verify this and one person say it works for
them; can people running latest cvs (and latest cvs of Zend, as well) say if
it works for them or not?

I tried to poke around in Zend a bit to see what might have done it, but
it's a pain to look through histories without a cvsweb interface, and I
didn't see anything obvious.

It's probably something small, but it's severely breaking some of my code.
Could a Zend guru take a look at it?

Thanks,
-chuck

--
...and remember: elmo is _not_ an insertion toy.

-- 
PHP Development Mailing List 
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] openssl module for php

[Sascha Kettler]

[...]
> Even though it is 4 functions, I think users will find it easier to
> work with functions called openssl_public_encrypt,
> openssl_private_decrypt etc. It also separates them from possible
> symmetric enryption later on.
> 
> How about returning the result like this:
> 
> string openssl_public_encrypt(
>   string data,
>   mixed key,
>   [int padding]
> );
> 
> I think it's generally better to not alter arguments, better return it
> this way. Is it good enough to report errors by returning an empty
> string? I think so.

I did my patch so it looks like the other openssl functions, so I guess we
should continue using that way of returning through arguments (or change all
functions to return a string to be consistent throughout the module). But from
a user's point of view it's better to keep the current API.

As for reporting errors by returning FALSE, this seems to be a normal
practice in PHP. Also, we shouldn't return any textual error messages, as
unexperienced users might display them to the user and thereby helping attackers gain
information about the private key (see D. Bleichenbacher. Chosen Ciphertext
Attacks against Protocols Based on the RSA Encryption Standard PKCS #1.
Advances in Cryptology-Crypto '98).

Sascha


-- 
PHP Development Mailing List 
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] Zend API changes

[Hartmut Holzgraefe]

Sterling Hughes wrote:
> > neither the book chapter you defined to be the official documentation
> > nor the readme files describe the complete api
> >
> > e.g. it's very hard to get the clue what all the *FETCH macros are good
> > for from the so called official documentation
> >
> 
> do you still need an explanation? the source makes it pretty clear to
> me...

no, its clear to me to, although it took some time of browsing around
on lxr.php.net and bonsai.php.net to get the message
but the fetch macros are rather essential IMHO and AFAIR they were 
mentioned only once in a subsentence (or even in brackets) without
further description


> > thats why i talk about a *reference* documentation that explains the
> > API funktion by function in manpage style
> >
> 
> Well maybe not manpage style.  I think there should be some Javadoc-like
> comments in the Zend source, the same way the apache portable runtime is
> documented or state threads library is (yeah, yeah, I know, don't end
> sentences with prepositions :).

any reference style will do as long as one can find the answer to
'wtf does zend_xxx() do?' quickly, something embeded in the source
the way e.g. javadoc does it would sure be nice

 
> > i've been into all this for more than a year now and i still have
> > lots of open questions about a lot of things even after doing a *lot*
> > of "Read the source, Luke" and this is, well, lets say 'suboptimal'
> >
> 
> Well what are the questions, you can always ask them on the list in the
> absence of some API documentation.

no questions i need answers for (yet), just a lot of loose ends
 
> > for stuff as complex (and as stuffed with preprocessor magic) like
> > the Zend Engine it is usually a very bad idea to have people write
> > the docs for it that didn't build it
> > 
> I don't know about that.  Most of the zend engine is pretty clear to me,
> especially so the API portions (ok, zend_alloc.c is a bit gnarly, but the
> rest of the engine is pretty clear :)

it may be pretty clear to you, it is clear enough for me now, but the
usual
c coder wanting to code an extensions most likely doesn't like the idea
of looking for clues on lxr.php.net and bonsai.php.net as soon as he has
reached a point where the documentation doesn't help him anymore



> > thats like playing "Stille Post" (afaik this game is called "telephone"
> > in the US) or like babelfish translating a text from one language to
> > another and back: very funny results but not very helpfull
> > 
> Perhaps describing the internals of the engine would be like that, but the
> common api is pretty easy to use and describe.  I might not have said this
> a year ago, but..

imagine someone with an intermediate knowledge of C wanting to code an
extension. his knowledge might be good enough to integrate his stuff,
but with the current state of the documentation he will most likely not
do it as it would involve a lot of extra source reading and figuring 
things out too
a lot of people, especially those that do not use php themselves, will
give up on this or will produce ugly code

and this does not only hurt php, it especially hurts Zend IMHO

how should one put trust in the products or especially in the support 
programm of a company that is not able or willing to provide proper docs
for its central product that all the other ones are built upon?




PS: maybe i've been bitten by bad API documentation to much in the last
few weeks (non-php products in this case)



-- 
Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10675 Updated: Executing background job from PHP causes session lock-up

[millz]

ID: 10675
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: *Session related
Description: Executing background job from PHP causes session lock-up

Executed a perl script in the background like this:
perl scriptname.pl $otherParams 2> /dev/null 1> /dev/null

Perl script forks and parent dies, so PHP "should" see the script as finished
immediately, perl child does work in background (takes a few minutes to run).

PHP script that spawned perl script completes OK, browser stops waiting for more data 
from
php script as it should.

However, when using the same browser window (or one from browser's file->new window) 
no
other pages that referrence the session will load in the browser.  If we force the 
session
to destroy just after the system() call, other scripts load just fine.  Also, other
scripts work just fine if we start a new browser from scratch (creates new session).

So it appears that the PHP session is getting messed up somehow b/c of the background
system/exec/`` call.  This seems to prevent the following pages from loading the 
session
properly and therefore they will not run.


One other thing, once the child perl script is finally complete everything starts 
working again, i.e.-the session is OK again.  

Previous Comments:
---

[2001-05-04 15:22:47] [EMAIL PROTECTED]
Executed a perl script in the background like this:
perl scriptname.pl $otherParams 2> /dev/null 1> /dev/null

Perl script forks and parent dies, so PHP "should" see the script as finished 
immediately, perl child does work in background (takes a few minutes to run).

PHP script that spawned perl script completes OK, browser stops waiting for more data 
from php script as it should.

However, when using the same browser window (or one from browser's file->new window) 
no other pages that referrence the session will load in the browser.  If we force the 
session to destroy just after the system() call, other scripts load just fine.  Also, 
other scripts work just fine if we start a new browser from scratch (creates new 
session).

So it appears that the PHP session is getting messed up somehow b/c of the background 
system/exec/`` call.  This seems to prevent the following pages from loading the 
session properly and therefore they will not run.

---


Full Bug description available at: http://bugs.php.net/?id=10675


-- 
PHP Development Mailing List 
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] openssl module for php

[Stig Venaas]

On Fri, May 04, 2001 at 09:21:28PM +0200, Sascha Kettler wrote:
> > On 2001-05-04 17:59:03, "Stig Venaas" <[EMAIL PROTECTED]> wrote:
> > > followed up on that. It would be good if you and Sascha Kettler could
> > > agree on how the API should be
> > 
> > How about:
> > 
> > openssl_key_encrypt(
> >   string data,  // to encrypt
> >   string &crypted,  // encrypted result
> >   mixed key, // key to use
> >   bool public, // true if you want public key, false for private key
> >   [int padding] // optional padding
> > );

Even though it is 4 functions, I think users will find it easier to
work with functions called openssl_public_encrypt,
openssl_private_decrypt etc. It also separates them from possible
symmetric enryption later on.

How about returning the result like this:

string openssl_public_encrypt(
  string data,
  mixed key,
  [int padding]
);

I think it's generally better to not alter arguments, better return it
this way. Is it good enough to report errors by returning an empty
string? I think so.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 4.0 Bug #10668 Updated: preg_replace backquote failure

[Andrei Zmievski]

On Fri, 04 May 2001, [EMAIL PROTECTED] wrote:
> ID: 10668
> User Update by: [EMAIL PROTECTED]
> Status: Analyzed
> Bug Type: PCRE related
> Description: preg_replace backquote failure
> 
> H'm...  I'm confused. :-)  To complicate things further, the e-mails display half as 
>many backslashes as the web page. :-)  Since I'm not sure what you mean, I'll 
>exhaustively list the behaviors:
> 
> The following:
> 
>   $str = "abc'''def";
>   function f($s) { var_dump($s); return "x"; }
>   print preg_replace("/c(.*)d/e", "f('\\1')", $str);
> 
> gives the error messages I posted earlier.  (That's two backslashes before the 1.)

Ok, this example does not give me any errors. Can you try the latest CVS
and see if that works for you?

-Andrei
* What were the first 15 billion years of the universe like for you? *

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10639 Updated: include() & require()

[sniper]

ID: 10639
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Old-Bug Type: *Function Specific
Bug Type: Scripting Engine problem
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

Please add some short example scripts into this bug report.
Which explains what you're trying to do.

--Jani

Previous Comments:
---

[2001-05-03 13:08:14] [EMAIL PROTECTED]
On AIX 4.3.3(ML6) with PHP and Apache from IBM's Linux Toolbox the functions include() 
and require() don't work correctly. If these functions are used, a "page not found" 
error occures.


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10639&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10668 Updated: preg_replace backquote failure

[smoonen]

ID: 10668
User Update by: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: PCRE related
Description: preg_replace backquote failure

H'm...  I'm confused. :-)  To complicate things further, the e-mails display half as 
many backslashes as the web page. :-)  Since I'm not sure what you mean, I'll 
exhaustively list the behaviors:

The following:

  $str = "abc'''def";
  function f($s) { var_dump($s); return "x"; }
  print preg_replace("/c(.*)d/e", "f('\\1')", $str);

gives the error messages I posted earlier.  (That's two backslashes before the 1.)

The following:

  $str = "abc'''def";
  function f($s) { var_dump($s); return "x"; }
  print preg_replace("/c(.*)d/e", "f('1')", $str);

gives the result:

  string(2) "\1" abxef

which isn't what I want.  (That's four backslashes before the 1.)

Prefixing the "1" with one or three backslashes in each case emits an ASCII x'01'.

None of which are what I want to occur...



Previous Comments:
---

[2001-05-04 15:17:51] [EMAIL PROTECTED]
Oops, \1 instead of 1.

---

[2001-05-04 15:17:15] [EMAIL PROTECTED]
Ok, I made a little mistake, use "f('\\1')" rather than "f('1')".

---

[2001-05-04 13:59:27] [EMAIL PROTECTED]
Oddly, I get the following error:

  Warning: Unexpected character in input: '' (ASCII=92) state=1 in 
/home/groups/t/ta/tavi/htdocs/playground/test.php(4) : regexp code on line 1

  Parse error: parse error in /home/groups/t/ta/tavi/htdocs/playground/test.php(4) : 
regexp code on line 1

  Fatal error: Failed evaluating code: f(''\\''') in 
/home/groups/t/ta/tavi/htdocs/playground/test.php on line 4

PHP compile options may be seen at:

  http://tavi.sourceforge.net/playground/phpinfo.php


---

[2001-05-04 12:58:12] [EMAIL PROTECTED]
Can you explain why you think it fails? The following sample (slightly modified from 
yours to dump the $s parameter to function):

$str = "abc'\\''def";
function f($s) { var_dump($s); return "x"; }
print preg_replace("/c(.*)d/e", "f('\1')", $str);

outputs:

string(5) "'\''"
abxef

As it should.

---

[2001-05-04 11:44:19] [EMAIL PROTECTED]
The following code succeeds on PHP 4.03 and PHP 4.04pl1, but fails on PHP 4.05:

  $str = "abc'\\''def";
  function f($s) { return "x"; }
  print preg_replace("/c(.*)d/e", "f('\1')", $str, -1);

This seems to expose *two* underlying bugs:

  1) There appears to be some problem in the regex state
 machine
  2) There is a definite problem with the replacement of
 the backreference with its corresponding string.


---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=10668


-- 
PHP Development Mailing List 
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] Zend API changes

[Wez Furlong]

On 2001-05-04 19:59:23, "Andrei Zmievski" <[EMAIL PROTECTED]> wrote:
> On Fri, 04 May 2001, Sterling Hughes wrote:
> > Well maybe not manpage style.  I think there should be some
Javadoc-like
> > comments in the Zend source, the same way the apache portable runtime
is

I remember the Amiga coding convention for "autodocs", where you
essentially embedded you man page (less "rich formatting") in your code,
much like we have javadoc today

> Actually manpage style Zend API docs would be cool. Then in vim you
> just hit K when the cursor is over a function and it gives you manpage
> for it. :)


Cool - I didn't know that about vim.  Manpages are well under-rated.  I
really miss being able to call up the docs I need "instantly", especially
with large projects (like OSF/DCE/ and Anything on windows), and especially
with GNU info..


Isn't there a docbook -> man stylesheet?  Since we have most docs as
docbook, it would make sense to have the Zend API documented in that way,
although I can see it being a pain if the zend guys tweak a function and
then have to go to the trouble of finding the relevant docbook page, etc.
etc.

Perhaps we could embed the docs as docbook fragments in the source?
(although that might be a bit heavy).

Just my GBP 0.02 (2 pence).

--Wez.



-- 
PHP Development Mailing List 
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] 4.1 & Declaration Case Persistance

[Wez Furlong]

On 2001-05-04 20:01:42, "Colin Viebrock" <[EMAIL PROTECTED]> wrote:
> One "problem" with case sensitivity (perhaps) is that it may make some
> scripts non-portable.
> 
> Say I develop a super-duper PEAR class using case-sensitive code (cause
> that's what I have on my server).  Someone who is running PHP in
> case-insensitive mode will complain when my code says:
> if (get_class($foo)=='Some_Class_Name')) { ...

So why not make it plain that it will only run under PHP 4.1 with
case-sensitivity enabled?

The whole point is that it is a compatibility breaking change, and the case
sensitivity switch is really only there to help migrate "legacy" code.

Just my HO.

--Wez.


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10676: sybase_connect

[sthomas]

From: [EMAIL PROTECTED]
Operating system: Redhat 6.2
PHP version:  4.0.5
PHP Bug Type: Sybase-ct (ctlib) related
Bug description:  sybase_connect

We've been having problems with this since php 4.0.3.  Here is a
full backtrace of a running (not for long) httpd child that dies as
soon as sybase_connect is called.  You'll notice the segfault
complains at mail.c.  Since sybase has nothing to do with this
file, I'm guessing there's a crosslink somewhere in the PHP
code, or a pointer that is getting lost somewhere.

---
Attaching to program: /usr/sbin/httpd, Pid 4719
Reading symbols from /lib/libpam.so.0...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /home/sybase/lib/libinsck.so...done.
Reading symbols from /home/sybase/lib/libsybtcl.so...done.
Reading symbols from /home/sybase/lib/libintl.so...done.
Reading symbols from /home/sybase/lib/libcomn.so...done.
Reading symbols from /home/sybase/lib/libct.so...done.
Reading symbols from /home/sybase/lib/libcs.so...done.
Reading symbols from /usr/lib/libpq.so...done.
Reading symbols from /usr/lib/libmcrypt.so.4...done.
Reading symbols from /usr/lib/libltdl.so.0...done.
Reading symbols from /usr/lib/libttf.so.2...done.
Reading symbols from /usr/lib/libpng.so.2...done.
Reading symbols from /usr/lib/libz.so.1...done.
Reading symbols from /usr/lib/libgd.so.1...done.
Reading symbols from /lib/libresolv.so.2...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libcrypt.so.1...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /usr/X11R6/lib/libXpm.so.4...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /lib/libnss_files.so.2...done.
Reading symbols from /lib/libnss_nisplus.so.2...done.
Reading symbols from /lib/libnss_nis.so.2...done.
0x402dfa02 in __libc_accept () from /lib/libc.so.6
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x819dcaf in net_close (stream=0x82d1b90) at mail.c:4857
4857mail.c: No such file or directory.
(gdb) bt
#0  0x819dcaf in net_close (stream=0x82d1b90) at mail.c:4857
#1  0x40093557 in np_io_close () from /home/sybase/lib/libct.so
#2  0x4009c327 in ct__tds_closeconn () from /home/sybase/lib/libct.so
#3  0x40063a3d in com__async_runstack () from /home/sybase/lib/libcomn.so
#4  0x40063939 in com__async_poll_state () from /home/sybase/lib/libcomn.so
#5  0x4006377f in com__async_do_poll () from /home/sybase/lib/libcomn.so
#6  0x400631eb in com_async_poll () from /home/sybase/lib/libcomn.so
#7  0x400a3ac1 in ct__api_async () from /home/sybase/lib/libct.so
#8  0x400a62c2 in ct__api_close () from /home/sybase/lib/libct.so
#9  0x400a63d1 in ct_close () from /home/sybase/lib/libct.so
#10 0x8114034 in _close_sybase_link (rsrc=0x832aea4) at php_sybase_ct.c:158
#11 0x812dd6a in list_entry_destructor (ptr=0x832aea4) at zend_list.c:258
#12 0x812cc3e in zend_hash_del_key_or_index (ht=0x82ab1c8, arKey=0x0,
nKeyLength=0, h=1, flag=1) at zend_hash.c:535
#13 0x812daaf in zend_list_delete (id=1) at zend_list.c:59
#14 0x8129457 in _zval_dtor (zvalue=0x832840c) at zend_variables.c:80
#15 0x81238c2 in _zval_ptr_dtor (zval_ptr=0x82cb5c8)
at zend_execute_API.c:261
#16 0x812ccd9 in zend_hash_destroy (ht=0x82ab0ac) at zend_hash.c:564
#17 0x8123752 in shutdown_executor () at zend_execute_API.c:165
#18 0x8129e07 in zend_deactivate () at zend.c:525
#19 0x80a7422 in php_request_shutdown (dummy=0x0) at main.c:688
#20 0x80a55ba in php_apache_request_shutdown ()
#21 0x8155c6e in run_cleanups ()
#22 0x815449d in ap_clear_pool ()
#23 0x8154511 in ap_destroy_pool ()
#24 0x816c1e2 in ap_destroy_sub_req ()
#25 0x807ffc8 in handle_include ()
#26 0x8082fc5 in send_parsed_content ()
#27 0x808359d in send_parsed_file ()
#28 0x8158f53 in ap_invoke_handler ()
#29 0x816ca99 in process_request_internal ()
#30 0x816cafc in ap_process_request ()
#31 0x81640ce in child_main ()
#32 0x816430c in make_child ()
#33 0x8164686 in perform_idle_server_maintenance ()
#34 0x8164bc5 in standalone_main ()
#35 0x8165183 in main ()
#36 0x402459cb in __libc_start_main (main=0x8164e3c , argc=3,
argv=0xb954, init=0x8070c34 <_init>, fini=0x81e4c8c <_fini>,
rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xb94c)
at ../sysdeps/generic/libc-start.c:92



-- 
Edit Bug report at: http://bugs.php.net/?id=10676&edit=1



-- 
PHP Development Mailing List 
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] openssl module for php

[Sascha Kettler]

> On 2001-05-04 18:22:03, "Sascha Kettler" <[EMAIL PROTECTED]> wrote:
> > You won't need to pass the algorithm by an arg, as the key already
> contains
> > the algorithm identification (pkey->type). I haven't used any DSA
> encryption
> > yet, but maybe you can just add the code to the switch statements.
> 
> Yes, I've just found that out.  I don't suppose that you know off hand a
> future-proof method of calling a cipher so we don't have to "case" each
> possibility? (I'm not sure such a method exists, but you never know...)

You could use EVP_PKEY_encrypt (openssl-0.9.6a/crypto/evp/p_enc.c), but that
only supports RSA and only PKCS1_PADDING. I'm not even sure it can encrypt
using a private key...

I'm not even sure you can do all this with DSA, I'll read the appropriate
sections in AC and HAC to be sure.

Sascha


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10675: Executing background job from PHP causes session lock-up

[millz]

From: [EMAIL PROTECTED]
Operating system: RedHat 6.2
PHP version:  4.0.5
PHP Bug Type: *Session related
Bug description:  Executing background job from PHP causes session lock-up

Executed a perl script in the background like this:
perl scriptname.pl $otherParams 2> /dev/null 1> /dev/null

Perl script forks and parent dies, so PHP "should" see the script as finished 
immediately, perl child does work in background (takes a few minutes to run).

PHP script that spawned perl script completes OK, browser stops waiting for more data 
from php script as it should.

However, when using the same browser window (or one from browser's file->new window) 
no other pages that referrence the session will load in the browser.  If we force the 
session to destroy just after the system() call, other scripts load just fine.  Also, 
other scripts work just fine if we start a new browser from scratch (creates new 
session).

So it appears that the PHP session is getting messed up somehow b/c of the background 
system/exec/`` call.  This seems to prevent the following pages from loading the 
session properly and therefore they will not run.


-- 
Edit Bug report at: http://bugs.php.net/?id=10675&edit=1



-- 
PHP Development Mailing List 
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] openssl module for php

[Sascha Kettler]

> On 2001-05-04 17:59:03, "Stig Venaas" <[EMAIL PROTECTED]> wrote:
> > followed up on that. It would be good if you and Sascha Kettler could
> > agree on how the API should be
> 
> How about:
> 
> openssl_key_encrypt(
>   string data,  // to encrypt
>   string &crypted,  // encrypted result
>   mixed key, // key to use
>   bool public, // true if you want public key, false for private key
>   [int padding] // optional padding
> );
> 
> and:
> 
> openssl_key_decrypt(
>   string data,  // to decrypt
>   string &decrypted,  // decrypted result
>   mixed key, // key to use
>   bool public, // true if you want public key, false for private key
>   [int padding] // optional padding
> );
> 
> Where key can specify the key using the extended syntax added in 4.0.6
> (see
> php manual online for more info).
> 
> This rolls 4 functions into two.
> The relevant cipher is encoded in the key.
> 
> Thoughts? Comments? Suggestions?

Sounds ok, although I wouldn't call it openssl_key_* but openssl_asym_* or
similar. I don't know what people would prefer: Separate functions or a
boolean. What's the general opinion on that?

Sascha


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10668 Updated: preg_replace backquote failure

[andrei]

ID: 10668
Updated by: andrei
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: PCRE related
PHP Version: 4.0.5
Assigned To: 
Comments:

Oops, \\1 instead of \1.

Previous Comments:
---

[2001-05-04 15:17:15] [EMAIL PROTECTED]
Ok, I made a little mistake, use "f('\\1')" rather than "f('1')".

---

[2001-05-04 13:59:27] [EMAIL PROTECTED]
Oddly, I get the following error:

  Warning: Unexpected character in input: '' (ASCII=92) state=1 in 
/home/groups/t/ta/tavi/htdocs/playground/test.php(4) : regexp code on line 1

  Parse error: parse error in /home/groups/t/ta/tavi/htdocs/playground/test.php(4) : 
regexp code on line 1

  Fatal error: Failed evaluating code: f(''\\''') in 
/home/groups/t/ta/tavi/htdocs/playground/test.php on line 4

PHP compile options may be seen at:

  http://tavi.sourceforge.net/playground/phpinfo.php


---

[2001-05-04 12:58:12] [EMAIL PROTECTED]
Can you explain why you think it fails? The following sample (slightly modified from 
yours to dump the $s parameter to function):

$str = "abc'\\''def";
function f($s) { var_dump($s); return "x"; }
print preg_replace("/c(.*)d/e", "f('\1')", $str);

outputs:

string(5) "'\''"
abxef

As it should.

---

[2001-05-04 11:44:19] [EMAIL PROTECTED]
The following code succeeds on PHP 4.03 and PHP 4.04pl1, but fails on PHP 4.05:

  $str = "abc'\\''def";
  function f($s) { return "x"; }
  print preg_replace("/c(.*)d/e", "f('\1')", $str, -1);

This seems to expose *two* underlying bugs:

  1) There appears to be some problem in the regex state
 machine
  2) There is a definite problem with the replacement of
 the backreference with its corresponding string.


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10668&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10668 Updated: preg_replace backquote failure

[andrei]

ID: 10668
Updated by: andrei
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: PCRE related
PHP Version: 4.0.5
Assigned To: 
Comments:

Ok, I made a little mistake, use "f('1')" rather than "f('\1')".

Previous Comments:
---

[2001-05-04 13:59:27] [EMAIL PROTECTED]
Oddly, I get the following error:

  Warning: Unexpected character in input: '' (ASCII=92) state=1 in 
/home/groups/t/ta/tavi/htdocs/playground/test.php(4) : regexp code on line 1

  Parse error: parse error in /home/groups/t/ta/tavi/htdocs/playground/test.php(4) : 
regexp code on line 1

  Fatal error: Failed evaluating code: f(''\\''') in 
/home/groups/t/ta/tavi/htdocs/playground/test.php on line 4

PHP compile options may be seen at:

  http://tavi.sourceforge.net/playground/phpinfo.php


---

[2001-05-04 12:58:12] [EMAIL PROTECTED]
Can you explain why you think it fails? The following sample (slightly modified from 
yours to dump the $s parameter to function):

$str = "abc'\\''def";
function f($s) { var_dump($s); return "x"; }
print preg_replace("/c(.*)d/e", "f('\1')", $str);

outputs:

string(5) "'\''"
abxef

As it should.

---

[2001-05-04 11:44:19] [EMAIL PROTECTED]
The following code succeeds on PHP 4.03 and PHP 4.04pl1, but fails on PHP 4.05:

  $str = "abc'\\''def";
  function f($s) { return "x"; }
  print preg_replace("/c(.*)d/e", "f('\1')", $str, -1);

This seems to expose *two* underlying bugs:

  1) There appears to be some problem in the regex state
 machine
  2) There is a definite problem with the replacement of
 the backreference with its corresponding string.


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10668&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #9571 Updated: Undefined symbols in apache build using PHP 4.0.4pl1

[ahill]

ID: 9571
Updated by: ahill
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: ODBC related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:



Previous Comments:
---

[2001-04-16 22:34:28] [EMAIL PROTECTED]
can we get one of the OpenLink people to comment on this please?  

---

[2001-03-16 19:48:56] [EMAIL PROTECTED]
Reclassified. 


---

[2001-03-07 11:54:12] [EMAIL PROTECTED]
Many thanks, that did it.  4.0.5 Dev built with:

./configure --with-mysql=/export/db/mysql 
--with-apache=/export/home/temp/apache_1.3.14 --with-pgsql=/export/home/app/pgsql 
--with-openlink --with-dom=/usr/local --with-zlib-dir=/usr/local --with-gd=/usr/local 
--with-xpm-dir=/usr/local --with-t1lib=/usr/local --with-tiff-dir=/usr/local 
--with-png-dir=/usr/local --with-jpeg-dir=/usr/local --with-pdflib=/usr/local 
--with-ttf=/usr/local --enable-debug --enable-magic-quotes --enable-libgcc 
--enable-calendar --enable-ftp --enable-gd-imgstrttf --enable-gd-native-ttf 
--enable-trans-sid --enable-shmop --enable-track-vars

Note that v.4 of the Openlink dirver manager no longer uses (or includes with the 
distribution) the file iodbc.h.  This file has been replaced with sqltypes.h (located 
in /odbcsdk/include).  The file php_odbc.h includes iodbc.h at 
or about line 128, so the build fails.  The solution is to remove the reference to 
iodbc.h.  The file sqltypes.h is included within sql.h, which is included within 
isql.h, which is included at line 129 of php_odbc.h.  Placing iodbc.h (from a previous 
installation, say) into the include directory breaks the build with type definition 
errors.



---

[2001-03-06 06:21:34] [EMAIL PROTECTED]
Please try the latest CVS snapshot from http://snaps.php.net/

--Jani


---

[2001-03-06 00:43:54] [EMAIL PROTECTED]
Same problem as in Bug #9161 - Undefined Symbol errors.

./configure --with-mysql=/export/db/mysql 
--with-apache=/export/home/temp/apache_1.3.14 --with-pgsql=/export/
home/app/pgsql --with-openlink --with-dom=shared,/usr/local --with-zlib=/usr/local 
--with-gd --with-tiff-dir=/usr/local --with-jpeg-dir=/usr/local 
--with-pdflib=/usr/local --with-ttf=shared,/usr/local
 --enable-debug --enable-magic-quotes --enable-libgcc --enable-calendar --enable-ftp 
--enable-gd-imgstrttf --
enable-track-vars

First was getting errors like:

Undefined  First referenced
  symbolin file
some_png_symbol   modules/php4/libphp4.a(libpng.o)

 adding --with-gd=shared,/usr/local got past it, but then

isinfmodules/php4/libphp4.a(mod_php4.o)

 after several clean make, clean installs, finally went into config.cache and set 
isinf to 'no'.  Clean make, clean install of PHP, reconfig apache with 
--activate-module, make and she finally built and started right up.

Seems to be some issue with the shared libs also maybe smells like Solaris not 
having ldconfig?

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9571&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10369 Updated: Openlink4/ODBC odbc_field_type returns nothing

[ahill]

ID: 10369
Updated by: ahill
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: ODBC related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

Firstly, please use --with-iodbc instead of --with-iodbc.
Also, this is most likely not a PHP issue but a database specific issue, and will only 
occur in cases where the corresponding database CLI call doesn't work natively.

Please test this with the latest OpenLink drivers and open a support case at 
http://www.openlinksw.com/support/suppindx.htm if the problem persists.



Previous Comments:
---

[2001-04-17 20:12:15] [EMAIL PROTECTED]
This script reproduces the problem:



Test odbc_field_type


Results";
   echo "The Query is: $sqln";
   echo '';
   $ind=1;
   echo "NamesTypes";
   while($ind<=$cols_count){
 echo "";
 echo "" . $cols_name[$ind] . "n";
 echo "" . $cols_types[$ind] . "n";
 echo "";
 $ind++;
   }
   odbc_free_result($result);
}else{
   echo "Cannot execute query";
}
  }else{
echo "Cannot prepare query";
  }
}
?>


I compiled PHP standard, I simply run ./configure with openlink option , run make and 
make install.
I can retrieve column name information and also data but I can't retrieve the column 
SQL Type. I asked Openlink and they said that is a PHP issue.

I'm using Openlink Multi-tier Driver for accessing a MS SQL Server 7 Database on a 
Windows NT box from PHP scripts running on the Apache Web Server on a Linux Box
OpenLink Version 4
PHP Version 4.0.4pl1
Linix SuSE 6.1 Kernel Version 2.2.7
Apache Version 1.3
PHP is running as a Loadable Apache Module


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10369&edit=2


-- 
PHP Development Mailing List 
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] 4.1 & Declaration Case Persistance

[Sterling Hughes]

On Fri, 4 May 2001, Chuck Hagenbuch wrote:

> Quoting Colin Viebrock <[EMAIL PROTECTED]>:
>
> > One "problem" with case sensitivity (perhaps) is that it may make some
> > scripts non-portable.
>
> That's a problem with it being an option, yes. I'd vote for just making php
> case sensitive, period.
>

+1 for that! :)

-Sterling



-- 
PHP Development Mailing List 
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] 4.1 & Declaration Case Persistance

[Chuck Hagenbuch]

Quoting Colin Viebrock <[EMAIL PROTECTED]>:

> One "problem" with case sensitivity (perhaps) is that it may make some
> scripts non-portable.

That's a problem with it being an option, yes. I'd vote for just making php
case sensitive, period.

-chuck

--
must... find... acorns... *thud*

-- 
PHP Development Mailing List 
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] openssl module for php

[Wez Furlong]

On 2001-05-04 18:22:03, "Sascha Kettler" <[EMAIL PROTECTED]> wrote:
> You won't need to pass the algorithm by an arg, as the key already
contains
> the algorithm identification (pkey->type). I haven't used any DSA
encryption
> yet, but maybe you can just add the code to the switch statements.

Yes, I've just found that out.  I don't suppose that you know off hand a
future-proof method of calling a cipher so we don't have to "case" each
possibility? (I'm not sure such a method exists, but you never know...)

--Wez.





-- 
PHP Development Mailing List 
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] openssl module for php

[Wez Furlong]

On 2001-05-04 19:05:05, "spencer 'sporty' portee"
<[EMAIL PROTECTED]> wrote:
> > On Fri, May 04, 2001 at 07:22:03PM +0200, Sascha Kettler wrote:
> > > You won't need to pass the algorithm by an arg, as the key already
contains
> > > the algorithm identification (pkey->type). I haven't used any DSA
encryption
> > > yet, but maybe you can just add the code to the switch statements.
> 
> but if its pem encoded, you need to use a proper algorithm to read it
in,
no?
> 
> ala PEM_ASN1_read_bio( ... )

 key = (EVP_PKEY *) PEM_ASN1_read_bio(
   (char *(*)())d2i_PrivateKey,
PEM_STRING_EVP_PKEY, b,
NULL, NULL, passphrase);

We currently use this code for the private key, so it looks like we don't
care what kind of key it is; openssl figures it out and we can find out by
looking at key->type.

Or am I missing something?

--Wez.


-- 
PHP Development Mailing List 
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] openssl module for php

[Wez Furlong]

On 2001-05-04 17:59:03, "Stig Venaas" <[EMAIL PROTECTED]> wrote:
> followed up on that. It would be good if you and Sascha Kettler could
> agree on how the API should be

How about:

openssl_key_encrypt(
  string data,  // to encrypt
  string &crypted,  // encrypted result
  mixed key, // key to use
  bool public, // true if you want public key, false for private key
  [int padding] // optional padding
);

and:

openssl_key_decrypt(
  string data,  // to decrypt
  string &decrypted,  // decrypted result
  mixed key, // key to use
  bool public, // true if you want public key, false for private key
  [int padding] // optional padding
);

Where key can specify the key using the extended syntax added in 4.0.6 (see
php manual online for more info).

This rolls 4 functions into two.
The relevant cipher is encoded in the key.

Thoughts? Comments? Suggestions?

--Wez.


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #9571 Updated: Undefined symbols in apache build using PHP 4.0.4pl1

[ahill]

ID: 9571
Updated by: ahill
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: ODBC related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

This is true.  To follow the standard more closely we have removed some files and 
standardized the iODBC Driver Manager SDK.  

The current SDK is contained here:
ftp://www.openlinksw.com/open40/l2ko.taz

I did not find that the compile fails however.  One reason is probably because using 
--with-openlink is no longer the recommended option.  

Using --with-iodbc should work in all cases.


Previous Comments:
---

[2001-04-16 22:34:28] [EMAIL PROTECTED]
can we get one of the OpenLink people to comment on this please?  

---

[2001-03-16 19:48:56] [EMAIL PROTECTED]
Reclassified. 


---

[2001-03-07 11:54:12] [EMAIL PROTECTED]
Many thanks, that did it.  4.0.5 Dev built with:

./configure --with-mysql=/export/db/mysql 
--with-apache=/export/home/temp/apache_1.3.14 --with-pgsql=/export/home/app/pgsql 
--with-openlink --with-dom=/usr/local --with-zlib-dir=/usr/local --with-gd=/usr/local 
--with-xpm-dir=/usr/local --with-t1lib=/usr/local --with-tiff-dir=/usr/local 
--with-png-dir=/usr/local --with-jpeg-dir=/usr/local --with-pdflib=/usr/local 
--with-ttf=/usr/local --enable-debug --enable-magic-quotes --enable-libgcc 
--enable-calendar --enable-ftp --enable-gd-imgstrttf --enable-gd-native-ttf 
--enable-trans-sid --enable-shmop --enable-track-vars

Note that v.4 of the Openlink dirver manager no longer uses (or includes with the 
distribution) the file iodbc.h.  This file has been replaced with sqltypes.h (located 
in /odbcsdk/include).  The file php_odbc.h includes iodbc.h at 
or about line 128, so the build fails.  The solution is to remove the reference to 
iodbc.h.  The file sqltypes.h is included within sql.h, which is included within 
isql.h, which is included at line 129 of php_odbc.h.  Placing iodbc.h (from a previous 
installation, say) into the include directory breaks the build with type definition 
errors.



---

[2001-03-06 06:21:34] [EMAIL PROTECTED]
Please try the latest CVS snapshot from http://snaps.php.net/

--Jani


---

[2001-03-06 00:43:54] [EMAIL PROTECTED]
Same problem as in Bug #9161 - Undefined Symbol errors.

./configure --with-mysql=/export/db/mysql 
--with-apache=/export/home/temp/apache_1.3.14 --with-pgsql=/export/
home/app/pgsql --with-openlink --with-dom=shared,/usr/local --with-zlib=/usr/local 
--with-gd --with-tiff-dir=/usr/local --with-jpeg-dir=/usr/local 
--with-pdflib=/usr/local --with-ttf=shared,/usr/local
 --enable-debug --enable-magic-quotes --enable-libgcc --enable-calendar --enable-ftp 
--enable-gd-imgstrttf --
enable-track-vars

First was getting errors like:

Undefined  First referenced
  symbolin file
some_png_symbol   modules/php4/libphp4.a(libpng.o)

 adding --with-gd=shared,/usr/local got past it, but then

isinfmodules/php4/libphp4.a(mod_php4.o)

 after several clean make, clean installs, finally went into config.cache and set 
isinf to 'no'.  Clean make, clean install of PHP, reconfig apache with 
--activate-module, make and she finally built and started right up.

Seems to be some issue with the shared libs also maybe smells like Solaris not 
having ldconfig?

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9571&edit=2


-- 
PHP Development Mailing List 
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] 4.1 & Declaration Case Persistance

[Colin Viebrock]

> The question was under what key the class entry should be stored...  At
any
> rate, it's a non-issue;  Saving the 'beautiful' version of the class name
> is possible, but is a bit hacky IMHO.  There should be an optional case
> sensitive mode, and we'll introduce one in one of the future versions of
PHP.

Yeah ... I posted before reading the remainder of the thread. :)

One "problem" with case sensitivity (perhaps) is that it may make some
scripts non-portable.

Say I develop a super-duper PEAR class using case-sensitive code (cause
that's what I have on my server).  Someone who is running PHP in
case-insensitive mode will complain when my code says:

if (get_class($foo)=='Some_Class_Name')) { ...

So all code that might be shared either a) needs to only us lowercase names,
b) coders need to implicity lowercase their comparisons by changing the
above line to:

if (strtolower(get_class($foo))=='some_class_name')) { ...

or c) we also need a way to switch between sensitivity modes through PHP
code (either an ini_set() call, or something else).

Also, case-sensitivity means I can write code with functions like
StrReplace() and MySQL_Fetch_Row(), which will seriously cause problems on
non-case-sensitive installs ... unless all variations of PHP functions are
reserved.

- Colin


-- 
PHP Development Mailing List 
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] Zend API changes

[Andrei Zmievski]

On Fri, 04 May 2001, Sterling Hughes wrote:
> Well maybe not manpage style.  I think there should be some Javadoc-like
> comments in the Zend source, the same way the apache portable runtime is
> documented or state threads library is (yeah, yeah, I know, don't end
> sentences with prepositions :).

Actually manpage style Zend API docs would be cool. Then in vim you
just hit K when the cursor is over a function and it gives you manpage
for it. :)

-Andrei

"Computers are useless. They can only give you answers."
   --Pablo Picasso

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] php got stomped on in shootout, but shouldn't have...

[hzimmer]

>   Howdy.  So I was checking out Perl, Ruby, and Java's
> performance specs on a language shootout, and PHP got stomped on.
> It was safely sitting at the bottom of the list (check out the score
> card page).
>
> 
> http://www.bagley.org/~doug/shootout/

Ouch, this sucks...  cool fucking site, though.  Has anyone
done any benchmarks on this kinda stuff to see if PHP's faster than
Java or how it stacks up to C?  -Hans

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10137 Updated: Apache repots a crash afer executing the php script

[jmoore]

ID: 10137
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Unknown/Other Function
PHP Version: 4.0.1pl2
Assigned To: 
Comments:

No feedback. Closing

Previous Comments:
---

[2001-04-03 11:02:45] [EMAIL PROTECTED]
1. Upgrade to 4.0.4pl1
2. If problem persists, add the shortest possible script
into this bug report which can be used to reproduce this.

--Jani


---

[2001-04-03 10:48:26] [EMAIL PROTECTED]
Description:
I create an object from a class which contains an internal variable which stores 
another object. This another object-constructor requires a parameter of the "parent" 
object. The constructor itself stores this value in an internal variable. No more 
Action is done! But after the execution of the script apache reports an error message!

My Modules are:imap
ldap, pgsql, mysql, zlib, yp, xml, standard, session, posix, pcre, gettext, gd, dba, 
db, apache

My configure-line is:
'./configure' '--target=i386-redhat-linux' '--prefix=/usr' 
'--with-config-file-path=/etc'
  '--disable-debug' '--enable-pic' '--enable-inline-optimization' 
'--with-apxs=/usr/sbin/apxs'
  '--disable-static' '--with-exec-dir=/usr/bin' '--with-regex=system' 
'--with-gettext' '--with-gd'
  '--with-jpeg-dir=/usr' '--with-png' '--with-zlib' '--with-db2' 
'--with-db3' '--with-gdbm'
  '--enable-debugger' '--enable-magic-quotes' '--enable-safe-mode' 
'--enable-sysvsem'
  '--enable-sysvshm' '--enable-track-vars' '--enable-yp' '--enable-ftp' 
'--without-mysql' '--with-xml'

My Backtrace is:
#0  0x404ddc75 in _efree () from /home/oliverh/httpd/modules/libphp4.so
(gdb) bt
#0  0x404ddc75 in _efree () from /home/oliverh/httpd/modules/libphp4.so
#1  0x404de1cb in shutdown_memory_manager ()
   from /home/oliverh/httpd/modules/libphp4.so
#2  0x4050e86c in php_request_shutdown ()
   from /home/oliverh/httpd/modules/libphp4.so
#3  0x4050c497 in php_apache_request_shutdown ()
   from /home/oliverh/httpd/modules/libphp4.so
#4  0x80510cb in ap_run_cleanup ()
#5  0x804ff82 in ap_clear_pool ()
#6  0x804ffe8 in ap_destroy_pool ()
#7  0x804ff6c in ap_clear_pool ()
#8  0x805c5fb in ap_child_terminate ()
#9  0x805cc4b in ap_child_terminate ()
#10 0x805cf2a in ap_child_terminate ()
#11 0x805d39b in ap_child_terminate ()
#12 0x805d928 in main ()
#13 0x4014db65 in __libc_start_main (main=0x805d5f0 , argc=3, 
ubp_av=0xb99c, init=0x804f084 <_init>, fini=0x807e45c <_fini>, 
rtld_fini=0x4000df24 <_dl_fini>, stack_end=0xb994)
at ../sysdeps/generic/libc-start.c:111



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10137&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10124 Updated: Cookies are being read

[jmoore]

ID: 10124
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Apache related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

No feedback. Closing

Previous Comments:
---

[2001-04-02 18:24:51] [EMAIL PROTECTED]
Which browser is the faulty one? Does some other version/browser work?

--Jani




---

[2001-04-02 17:26:28] [EMAIL PROTECTED]
I have been running the latest version of PHP without any problems, and over the 
weekend I install the latest secure patch from Microsoft, and then that is when i 
noticed that sessions on my local server were being increased each page view, do to 
that apache wasn't reading the cookie properly. After inspecting and reinstalling, the 
only thing I found to fix the problem was installing PHP 3..

I hope this helps, seeing it is my first report, also where does when one go to get an 
older stable version of 4?

Thanks

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10124&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10666 Updated: preg_replace 'e' modifier

[smoonen]

ID: 10666
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: PCRE related
Description: preg_replace 'e' modifier

Also, as a merely informational aside, PHP's use of $1 is in this instance actually 
incompatible with Perl.  Perl, in a s///e expression, treats $n as a variable rather 
than expanding it in-place.

Hence my preference. :-)


Previous Comments:
---

[2001-05-04 13:55:39] [EMAIL PROTECTED]
Okay.  Then I have a problem with how backslash escaping is inconsistently applied 
when using \1 and $1.

Specifically, consider the following:

  function f($x) { print $x; }
  $s = "a' \ "b";
  $s = preg_replace('/a(.*)b/e', 'f("$1")', $s, -1);

The single quote is escaped; I'd rather it weren't but that's okay.  But the backslash 
itself isn't escaped!  This prevents me from running stripslashes() on the match, 
since I can't guarantee that every backslash has been properly escaped.

Worse, the following will actually fail:

  function f($x) { print $x; }
  $s = "a' " \b";
  $s = preg_replace('/a(.*)b/e', 'f("$1")', $s, -1);

Since the final backslash hasn't been escaped, it actually slurps up the second 
double-quote in 'f("$1")'!

I'd like to see either of the following:

  1. $1 treated as a "real" variable, rather than a string
 substitution.  This is convenient, since it saves me
 having to call stripslashes().

  2. Backslash escapes consistently applied in backrefs.
 Specifically, escape existing backslashes in the match.
 Presently, I can't perform a stripslashes() -- and in
 some cases, as indicated above, it fails altogether!


---

[2001-05-04 13:02:59] [EMAIL PROTECTED]
$n notation was introduced to be similar to Perl. It is exactly equivalent to \n.

You can't simply use f($1) in the evaluation string because $1 is replaced with the 
matched contents and after replacement it becomes, in your example, f(abc def), which 
is not valid PHP code. So you have to use f("$1") or f('$1').

The fact that it backslash-escapes single and double quotes in matches before 
substituting $1 is a feature, not a bug, otherwise you'd have a really hard time 
figuring out which quotes go where when using evaluation strings.

---

[2001-05-04 11:27:54] [EMAIL PROTECTED]
Formerly, preg_replace's "e" modifier inserted extraneous backslashes in 
backreferences of "\1" or '\1' form.

Ostensibly, the $1 backreference form was added to fix this.  However, the following 
code fails:

  function f($x) { return 'yo'; }
  $s = "xyzabc def123";
  $s = preg_replace('/(abc def)/e', 'f($1)', $s, -1);

It seems to be trying to evaluate $1 as code, rather than as a variable containing the 
contents "abc def".

This is borne out by the fact that the following succeeds:

  $s = preg_replace('/(abc def)/e', 'f("$1")', $s, -1);

But "$1" and '$1' are no better than "\1" and '\1', since it still inserts extraneous 
backslashes before single quotes or double quotes (respectively)!!!

I was sincerely hoping that PHP 4.04 and 4.05 would fix this oversight, since my web 
application depends on it.  I'm keeping my fingers crossed that it's just me doing 
something wrong, though I doubt it...


---


Full Bug description available at: http://bugs.php.net/?id=10666


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10118 Updated: mysql_query() shows unwanted warnings when no result set returned.

[jmoore]

ID: 10118
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: MySQL related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

No feedback. Closing

Previous Comments:
---

[2001-04-02 13:10:08] [EMAIL PROTECTED]
can you provide an example script plus its output?

---

[2001-04-02 13:02:30] [EMAIL PROTECTED]


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10118&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10106 Updated: Garbage files created when trying to load an extension which doesn't exist(?)

[jmoore]

ID: 10106
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: *Configuration Issues
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

No feedback. Closing

Previous Comments:
---

[2001-04-02 06:40:12] [EMAIL PROTECTED]
I can't reproduce this with latest CVS. Please try the latest snapshot from 
http://snaps.php.net/

--Jani


---

[2001-04-01 22:51:43] [EMAIL PROTECTED]
The line:

extension=satellite.so

in /usr/local/lib/php.ini causes garbage files being created in root (/) directory:
e.g.

-rw-rw-r--   1 root root 2184 Mar 30 14:05 P}5@P}5@`?
-rw-rw-r--   1 root root  364 Apr  2 02:45 P?*@P?*@@?
-rw-rw-r--   1 root root  182 Mar 30 14:31 P?*@P?*@`?
-rw-rw-r--   1 root root  182 Mar 30 14:57 ]???t?.?

Contents of file looks like:

[25-Mar-2001 01:50:18] PHP Warning:  Unable to load dynamic library './satellite.so' - 
./satellite.so: cannot open shared object file: No such file or directory in Unknown 
on line 0
[26-Mar-2001 00:50:28] PHP Warning:  Unable to load dynamic library './satellite.so' - 
./satellite.so: cannot open shared object file: No such file or directory in Unknown 
on line 0
[26-Mar-2001 10:58:29] PHP Warning:  Unable to load dynamic library './satellite.so' - 
./satellite.so: cannot open shared object file: No such file or directory in Unknown 
on line 0

php info:
'./configure' '--with-apache=../apache_1.3.14' '--enable-track-vars' '--enable-ftp' 
'--with-gd=/home/nick/graph/gd-1.8.3' '--with-msql' '--with-mysql=/var/lib/mysql' 
'--with-xml=../expat/xmlparse' '--enable-wddx' '--enable-bcmath' 
'--with-sybase=/opt/sybase-11.9.2' '--enable-sockets' '--without-imap-ssl'

php ini file (error/log section)

error_reporting =   E_ALL & ~E_NOTICE   ; Show all errors except for 
notices
display_errors  =   On  ; Print out errors (as a part of the output)
; For production web sites, you're 
strongly encouraged
; to turn this feature off, and use 
error logging instead (see below).
; Keeping display_errors enabled on a 
production web site may reveal
; security information to end users, 
such as file paths on your Web server,
; your database schema or other 
information.
display_startup_errors = On ; Even when display_errors is on, errors that 
occur during
; PHP's 
startup sequence are not displayed.  It's strongly
; recommended 
to keep display_startup_errors off, except for
; when 
debugging.
log_errors  =   On  ; Log errors into a log file (server-specific 
log, stderr, or error_log (below))
; As stated above, you're strongly 
advised to use error logging in place of
; error displaying on production web 
sites.
track_errors=   Off ; Store the last error/warning message in 
$php_errormsg (boolean)
;error_prepend_string = ""   ; string to output before an error 
message
;error_append_string = ""; string to output after an error 
message
;error_log  =   /tmp/php_errors ; log errors to specified file
error_log   =   syslog  ; log errors to syslog (Event Log on NT, not 
valid in Windows 95)
warn_plus_overloading   =   Off ; warn if the + operator is used with 
strings


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10106&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #9172 Updated: fopen-wrapper does not work

[jmoore]

ID: 9172
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Filesystem function related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

No feedback. Closing

Previous Comments:
---

[2001-04-03 15:04:31] [EMAIL PROTECTED]
Is HAVE_GETADDRINFO defined in your main/php_config.h ?

--Jani


---

[2001-02-08 06:55:53] [EMAIL PROTECTED]
Under AIX,  php_hostconnect() in network.c fails, causing require("some_url") to
fail.  The reason is that (*sal)->sa_family is 0, which causes the socket-opening
to fail.

As a workaround I included a (*sal)->sa_family = AF_INET right before the
call of socket().

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9172&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #8727 Updated: Post problem with thttpd

[jmoore]

ID: 8727
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Other web server
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

No feedback. Closing

Previous Comments:
---

[2001-04-02 05:51:48] [EMAIL PROTECTED]
Can't reproduce this one with latest CVS. Can you please try latest snapshot from 
http://snaps.php.net/ ??

--Jani


---

[2001-01-15 17:15:29] [EMAIL PROTECTED]
I can only get the first 16 post vars.  Found bug #6269 that seems close to this one.
My setup: thttpd-2.20 php-4.0.4.pl1 and php-4.0.3.pl1
Linux 2.2.x with libc


php-configure: './configure' '--prefix=/usr' '--with-thttpd=../thttpd-2.20b' 
'--with-config-file-path=/etc' '--disable-debug' '--without-openssl' 
'--with-mysql=/usr' '--enable-trans-sid'

The same script works just fine with apache/php. Can post source for the php script if 
needed. Server did not crash, just missing vars.

BTW: using thttpd because the target system is an embedded
x86 system.

Ben R. Adams <[EMAIL PROTECTED]>


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8727&edit=2


-- 
PHP Development Mailing List 
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] Zend API changes

[Sterling Hughes]

On Fri, 4 May 2001, Hartmut Holzgraefe wrote:

> Zeev Suraski wrote:
> >
> > Hope is always a good thing :)
> > There's a good starting point already, people are more than welcome to
> > extend it.
>
> besides all political/philosophical issues (licensing and such ...)
>
> i am talking about a *reference* documentation, not a manual or howto
>

I'll agree this is needed (however, I no longer have an impetus to create
it :)


> neither the book chapter you defined to be the official documentation
> nor the readme files describe the complete api
>
> e.g. it's very hard to get the clue what all the *FETCH macros are good
> for from the so called official documentation
>

do you still need an explanation? the source makes it pretty clear to
me...

> thats why i talk about a *reference* documentation that explains the
> API funktion by function in manpage style
>

Well maybe not manpage style.  I think there should be some Javadoc-like
comments in the Zend source, the same way the apache portable runtime is
documented or state threads library is (yeah, yeah, I know, don't end
sentences with prepositions :).

> i've been into all this for more than a year now and i still have
> lots of open questions about a lot of things even after doing a *lot*
> of "Read the source, Luke" and this is, well, lets say 'suboptimal'
>

Well what are the questions, you can always ask them on the list in the
absence of some API documentation.

> for stuff as complex (and as stuffed with preprocessor magic) like
> the Zend Engine it is usually a very bad idea to have people write
> the docs for it that didn't build it
>

I don't know about that.  Most of the zend engine is pretty clear to me,
especially so the API portions (ok, zend_alloc.c is a bit gnarly, but the
rest of the engine is pretty clear :)

> thats like playing "Stille Post" (afaik this game is called "telephone"
> in the US) or like babelfish translating a text from one language to
> another and back: very funny results but not very helpfull
>

Perhaps describing the internals of the engine would be like that, but the
common api is pretty easy to use and describe.  I might not have said this
a year ago, but..

.Sterling


-- 
PHP Development Mailing List 
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] Zend API changes

[Zeev Suraski]

At 21:05 4/5/2001, Hartmut Holzgraefe wrote:
>PS: about the "welcome" thing above ...
>
>-  you should know that i have put a lot of work into the manual
>(both english and german) and the function tables

Hartmut,

I wasn't trying to understate your work on the manual;  I told you 
personally that the function reference mechanism that you build was very 
impressive and useful.  I wasn't being sarcastic when I invited you (and 
anyone else) to help document the Zend API.  I know I won't be getting 
around to doing it in the near future, so if nobody else does it, it'll 
simply remain undone.

>-  afair there was someone who started to write a 'extension
>building manual' or something about a year ago and it was you
>, Zeev, who told him that this was useless effort as this was
>already beeing taken care off (without pointing him to this
>project or inviting him to join it)
>correct me if i'm wrong as i do not have found this posting
>in my archives yet

You're not wrong;  It's been done and published 
(http://www.zend.com/apidoc/), and is the base for additional work that I 
invited people to improve on.

Zeev


--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10670 Updated: Compile as Apache 2.0 module fails

[sas]

ID: 10670
Updated by: sas
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Compile Failure
PHP Version: 4.0.5
Assigned To: 
Comments:

You need a newer Apache version then.  PHP contains the latest API changes of Apache 
2.0. You might want to try an Apache 2.0 snapshot as available from 
http://dev.apache.org/

Previous Comments:
---

[2001-05-04 12:22:44] [EMAIL PROTECTED]

When compileing PHP 4.0.5 as an Apache 2.0.16 module
the following errors occour:

...
...
sapi_apache2.c: In function `php_input_filter':
sapi_apache2.c:248: too many arguments to function `ap_get_brigade'
sapi_apache2.c: In function `php_register_hook':
sapi_apache2.c:443: warning: passing arg 2 of `ap_register_input_filter' from 
incompatible pointer type
make[3]: *** [sapi_apache2.lo] Error 1
...
...

PHP was configured with the following options:

./configure --with-apxs2=/path/to/apache2/bin/apxs --with-mysql --enable-sysvsem 
--enable-sysvshm --enable-track-vars

Apache 2.0.16 was configured with the following options:

./configure --prefix=/path/to/apache2 --enable-so --with-mpm=threaded 



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10670&edit=2


-- 
PHP Development Mailing List 
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] Zend API changes

[Joe Brown]

Well you should, damnit!

;-)

"Zeev Suraski" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
At 20:20 4/5/2001, Björn Schotte wrote:
>* Zeev Suraski wrote:
> > There's a good starting point already, people are more than welcome to
> > extend it.
>
>I don't understand why people should work in their spare-time
>on a tool which is published under the Zend Licence (which is
>similar to QPL). As we know of QPL, all developer's seem to
>be equal, but some seem to be more equal.

You don't have to;  It just so happens that I don't have to either.

Zeev


--
PHP Development Mailing List 
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 
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] Zend API changes

[Zeev Suraski]

At 20:20 4/5/2001, Björn Schotte wrote:
>* Zeev Suraski wrote:
> > There's a good starting point already, people are more than welcome to
> > extend it.
>
>I don't understand why people should work in their spare-time
>on a tool which is published under the Zend Licence (which is
>similar to QPL). As we know of QPL, all developer's seem to
>be equal, but some seem to be more equal.

You don't have to;  It just so happens that I don't have to either.

Zeev


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: SV: [PHP-DEV] erealloc and the API

[Zeev Suraski]

At 20:32 4/5/2001, Johan Ekenberg wrote:
>Zeev,
>
>thanks, that made all the difference!
>
>I got a suggestion from another PHP-developer that mixing calls to
>emalloc() and strcpy() might be a problem. Is this so?

Not it's not;  A block you get from emalloc() is very much the same as a 
block you get from malloc(), as far as what you can do with it.  The only 
difference is that you have to use efree()/erealloc() etc. instead of 
free()/realloc(), when you manipulate that block.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: Bug #10642 Updated: error connecting to database

[David Miller]

I didn't include a path on the configure. (I used the PHP libs?)

- Original Message -
From: "Bug Database" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 04, 2001 1:02 PM
Subject: Bug #10642 Updated: error connecting to database


> ID: 10642
> Updated by: sniper
> Reported By: [EMAIL PROTECTED]
> Old-Status: Open
> Status: Closed
> Old-Bug Type: *Install and Config
> Bug Type: MySQL related
> PHP Version: 4.0.5
> Assigned To:
> Comments:
>
> Fixed in CVS now.
> I assume you used the builtin mysql libs instead
> of the external ones.
>
> --Jani
>
>
> Previous Comments:
> --
-
>
> [2001-05-03 17:30:45] [EMAIL PROTECTED]
> Duplicate of #10612, but the fix described in 10612 didn't take care of
the problem for me.
>
> Please look into this.
>
> Thanks.
>
> --
-
>
> [2001-05-03 14:04:37] [EMAIL PROTECTED]
> duplicate of #10612
>
> --
-
>
> [2001-05-03 13:57:05] [EMAIL PROTECTED]
> Identical problem as Bug#10612.
>
> I installed the CVS php4-200105030445 and still have the same problem.
>
> Your help would be appreciated.
>
> --
-
>
>
>
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at
http://bugs.php.net/?id=10642&edit=2
>
>


-- 
PHP Development Mailing List 
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] openssl module for php

[spencer 'sporty' portee]

> On Fri, May 04, 2001 at 07:22:03PM +0200, Sascha Kettler wrote:
> > You won't need to pass the algorithm by an arg, as the key already contains
> > the algorithm identification (pkey->type). I haven't used any DSA encryption
> > yet, but maybe you can just add the code to the switch statements.

but if its pem encoded, you need to use a proper algorithm to read it in, no?

ala PEM_ASN1_read_bio( ... ) 


-- 
PHP Development Mailing List 
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] Zend API changes

[Hartmut Holzgraefe]

Zeev Suraski wrote:
> 
> Hope is always a good thing :)
> There's a good starting point already, people are more than welcome to
> extend it.

besides all political/philosophical issues (licensing and such ...)

i am talking about a *reference* documentation, not a manual or howto

neither the book chapter you defined to be the official documentation
nor the readme files describe the complete api 

e.g. it's very hard to get the clue what all the *FETCH macros are good
for from the so called official documentation

thats why i talk about a *reference* documentation that explains the 
API funktion by function in manpage style 

i've been into all this for more than a year now and i still have 
lots of open questions about a lot of things even after doing a *lot*
of "Read the source, Luke" and this is, well, lets say 'suboptimal'

for stuff as complex (and as stuffed with preprocessor magic) like
the Zend Engine it is usually a very bad idea to have people write
the docs for it that didn't build it

thats like playing "Stille Post" (afaik this game is called "telephone"
in the US) or like babelfish translating a text from one language to
another and back: very funny results but not very helpfull

don't get me wrong, the Engine is a very impressive piece of work
(although i do not really like the license, but i can live with it)
but with reference documentation that deserves this name it would
still be far better.

PS: about the "welcome" thing above ...

-  you should know that i have put a lot of work into the manual
   (both english and german) and the function tables

-  afair there was someone who started to write a 'extension 
   building manual' or something about a year ago and it was you
   , Zeev, who told him that this was useless effort as this was 
   already beeing taken care off (without pointing him to this
   project or inviting him to join it)
   correct me if i'm wrong as i do not have found this posting
   in my archives yet

-- 
Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10642 Updated: error connecting to database

[sniper]

ID: 10642
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Old-Bug Type: *Install and Config
Bug Type: MySQL related
PHP Version: 4.0.5
Assigned To: 
Comments:

Fixed in CVS now. 
I assume you used the builtin mysql libs instead
of the external ones.

--Jani


Previous Comments:
---

[2001-05-03 17:30:45] [EMAIL PROTECTED]
Duplicate of #10612, but the fix described in 10612 didn't take care of the problem 
for me.

Please look into this.

Thanks.

---

[2001-05-03 14:04:37] [EMAIL PROTECTED]
duplicate of #10612

---

[2001-05-03 13:57:05] [EMAIL PROTECTED]
Identical problem as Bug#10612.

I installed the CVS php4-200105030445 and still have the same problem.

Your help would be appreciated.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10642&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10612 Updated: error connecting to database

[sniper]

ID: 10612
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: *Install and Config
PHP Version: 4.0.5
Assigned To: 
Comments:

Now this should really be fixed. 
As you propably used the builtin mysql libs instead of
the external ones.

--Jani


Previous Comments:
---

[2001-05-03 02:02:13] [EMAIL PROTECTED]
This should be fixed in CVS. Please try the latest CVS
snapshot from http://snaps.php.net/ 
If it doesn't work either, reopen this bug report.

--Jani


---

[2001-05-02 10:53:40] [EMAIL PROTECTED]
I upgraded from php-4.0.3pl1 to 4.0.5 as a DSO in apache and now php cannot connect to 
MySQL database 

Warning: MySQL Connection Failed: Can't connect to local MySQL server through socket 
'/tmp/mysql.sock' (111) in /httpd/sites/55lo/html/mainfile.php on line 17
Unable to select database

what have I done

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10612&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10668 Updated: preg_replace backquote failure

[smoonen]

ID: 10668
User Update by: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: PCRE related
Description: preg_replace backquote failure

Oddly, I get the following error:

  Warning: Unexpected character in input: '\' (ASCII=92) state=1 in 
/home/groups/t/ta/tavi/htdocs/playground/test.php(4) : regexp code on line 1

  Parse error: parse error in /home/groups/t/ta/tavi/htdocs/playground/test.php(4) : 
regexp code on line 1

  Fatal error: Failed evaluating code: f('\''\'') in 
/home/groups/t/ta/tavi/htdocs/playground/test.php on line 4

PHP compile options may be seen at:

  http://tavi.sourceforge.net/playground/phpinfo.php


Previous Comments:
---

[2001-05-04 12:58:12] [EMAIL PROTECTED]
Can you explain why you think it fails? The following sample (slightly modified from 
yours to dump the $s parameter to function):

$str = "abc'\\''def";
function f($s) { var_dump($s); return "x"; }
print preg_replace("/c(.*)d/e", "f('\1')", $str);

outputs:

string(5) "'\''"
abxef

As it should.

---

[2001-05-04 11:44:19] [EMAIL PROTECTED]
The following code succeeds on PHP 4.03 and PHP 4.04pl1, but fails on PHP 4.05:

  $str = "abc'\\''def";
  function f($s) { return "x"; }
  print preg_replace("/c(.*)d/e", "f('\1')", $str, -1);

This seems to expose *two* underlying bugs:

  1) There appears to be some problem in the regex state
 machine
  2) There is a definite problem with the replacement of
 the backreference with its corresponding string.


---


Full Bug description available at: http://bugs.php.net/?id=10668


-- 
PHP Development Mailing List 
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] Zend API changes

[James Moore]

> * James Moore wrote:
> > And the point of this other than trying to start a flame war was Bjorn?
>
> I'm not starting a flame war.

I just didnt understand what your comments possibly had to do with the Zend
API docs. AFIAK they arnt QPL'd (and if they are it doesnt really matter
although they should be under a publication license)..

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10666 Updated: preg_replace 'e' modifier

[smoonen]

ID: 10666
User Update by: [EMAIL PROTECTED]
Old-Status: Closed
Status: Open
Bug Type: PCRE related
Description: preg_replace 'e' modifier

Okay.  Then I have a problem with how backslash escaping is inconsistently applied 
when using \\1 and $1.

Specifically, consider the following:

  function f($x) { print $x; }
  $s = "a' \\ \"b";
  $s = preg_replace('/a(.*)b/e', 'f("$1")', $s, -1);

The single quote is escaped; I'd rather it weren't but that's okay.  But the backslash 
itself isn't escaped!  This prevents me from running stripslashes() on the match, 
since I can't guarantee that every backslash has been properly escaped.

Worse, the following will actually fail:

  function f($x) { print $x; }
  $s = "a' \" \\b";
  $s = preg_replace('/a(.*)b/e', 'f("$1")', $s, -1);

Since the final backslash hasn't been escaped, it actually slurps up the second 
double-quote in 'f("$1")'!

I'd like to see either of the following:

  1. $1 treated as a "real" variable, rather than a string
 substitution.  This is convenient, since it saves me
 having to call stripslashes().

  2. Backslash escapes consistently applied in backrefs.
 Specifically, escape existing backslashes in the match.
 Presently, I can't perform a stripslashes() -- and in
 some cases, as indicated above, it fails altogether!


Previous Comments:
---

[2001-05-04 13:02:59] [EMAIL PROTECTED]
$n notation was introduced to be similar to Perl. It is exactly equivalent to \n.

You can't simply use f($1) in the evaluation string because $1 is replaced with the 
matched contents and after replacement it becomes, in your example, f(abc def), which 
is not valid PHP code. So you have to use f("$1") or f('$1').

The fact that it backslash-escapes single and double quotes in matches before 
substituting $1 is a feature, not a bug, otherwise you'd have a really hard time 
figuring out which quotes go where when using evaluation strings.

---

[2001-05-04 11:27:54] [EMAIL PROTECTED]
Formerly, preg_replace's "e" modifier inserted extraneous backslashes in 
backreferences of "\1" or '\1' form.

Ostensibly, the $1 backreference form was added to fix this.  However, the following 
code fails:

  function f($x) { return 'yo'; }
  $s = "xyzabc def123";
  $s = preg_replace('/(abc def)/e', 'f($1)', $s, -1);

It seems to be trying to evaluate $1 as code, rather than as a variable containing the 
contents "abc def".

This is borne out by the fact that the following succeeds:

  $s = preg_replace('/(abc def)/e', 'f("$1")', $s, -1);

But "$1" and '$1' are no better than "\1" and '\1', since it still inserts extraneous 
backslashes before single quotes or double quotes (respectively)!!!

I was sincerely hoping that PHP 4.04 and 4.05 would fix this oversight, since my web 
application depends on it.  I'm keeping my fingers crossed that it's just me doing 
something wrong, though I doubt it...


---


Full Bug description available at: http://bugs.php.net/?id=10666


-- 
PHP Development Mailing List 
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] openssl module for php

[Stig Venaas]

On Fri, May 04, 2001 at 07:22:03PM +0200, Sascha Kettler wrote:
> You won't need to pass the algorithm by an arg, as the key already contains
> the algorithm identification (pkey->type). I haven't used any DSA encryption
> yet, but maybe you can just add the code to the switch statements.

Ah yes, I was a bit quick there. Anyway, I wanted to make sure you talked
to each other so that we might get the best possible API. It's nice to see
that so many of you want to extend the OpenSSL extension I started on. I
only put in what I needed hoping that others would pick up (:

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10674: I cannot confoigure php4 with postgres sql

[cjmena1]

From: [EMAIL PROTECTED]
Operating system: solaris 2.7
PHP version:  4.0.4
PHP Bug Type: *General Issues
Bug description:  I cannot confoigure php4 with postgres sql

How can u configure php4 to work with postgres sql.
It works fine with mysql.


-- 
Edit Bug report at: http://bugs.php.net/?id=10674&edit=1



-- 
PHP Development Mailing List 
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] Zend API changes

[Björn Schotte]

* James Moore wrote:
> And the point of this other than trying to start a flame war was Bjorn?

I'm not starting a flame war.

Björn.

-- 
PHP Development Mailing List 
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] Zend API changes

[James Moore]

> > There's a good starting point already, people are more than welcome to 
> > extend it.
> 
> I don't understand why people should work in their spare-time
> on a tool which is published under the Zend Licence (which is
> similar to QPL). As we know of QPL, all developer's seem to
> be equal, but some seem to be more equal.
> 
> As you know from Daniel Grossmann, I'm not the only one
> who has this opinion.

And the point of this other than trying to start a flame war was Bjorn?

- James

-- 
PHP Development Mailing List 
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] 4.1 & Declaration Case Persistance

[Shaun Batterton]

Good work Zeev.  It's for a good cause.  Everyone else just seems to be
whining... "i don't wanna".

Shaun


On Fri, 4 May 2001, Zeev Suraski wrote:

> The question was under what key the class entry should be stored...  At any 
> rate, it's a non-issue;  Saving the 'beautiful' version of the class name 
> is possible, but is a bit hacky IMHO.  There should be an optional case 
> sensitive mode, and we'll introduce one in one of the future versions of PHP.
> 
> Zeev
> 
> At 18:04 4/5/2001, Colin Viebrock wrote:
> > > I don't think it is trivial to implement this without:
> > > a) Creating a second version of our hash tables (I don't like duplicate
> >code).
> > > b) Adding more complexity to the already complex hash tables.
> >
> >I don't know enough about Zend internals to speak with any authority, but
> >wouldn't an "easy" way of doing this be to:
> >
> >a) store *only* the mixed case version of the class name in the hash table,
> >and
> >b) change get_class(), etc. so that they automatically pass the result
> >through strtolower() (or whatever) first ... unless the optional second
> >argument is passed, in which case it's just returned as is.
> >
> >You wouldn't need a bigger nor an additional hash table, AFAICT, and only
> >what I imagine is relatively minor code changes to the get_class(), etc.
> >functions.
> >
> >- Colin
> >
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 
> --
> Zeev Suraski <[EMAIL PROTECTED]>
> CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> 
> 
> 

-- 


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: SV: [PHP-DEV] erealloc and the API

[Sterling Hughes]

On Fri, 4 May 2001, Johan Ekenberg wrote:

> Zeev,
>
> thanks, that made all the difference!
>
> I got a suggestion from another PHP-developer that mixing calls to
> emalloc() and strcpy() might be a problem. Is this so?
>

No, I've never experienced a problem.

-Sterling


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #10673: CURL/PHP causes lengthy Apache Keepalive

[Sterling Hughes]

Working with user off the mailing list (I don't want to flood it :)...

Please keep this bug open for now :)))


On 4 May 2001 [EMAIL PROTECTED] wrote:

> From: [EMAIL PROTECTED]
> Operating system: Linux
> PHP version:  4.0.4pl1
> PHP Bug Type: cURL related
> Bug description:  CURL/PHP causes lengthy Apache Keepalive
>
> Greetings. I have Apache/1.3.14 (Unix) running with
> PHP/4.0.4pl1 installed as a module and CURL 7.7.1 added to
> that. Our web sites need to fetch a request from a remote
> ad server in real-time as each page is generated. If $adr
> is the request, I used to use:
>
> $success = @readfile($adr);
>
> But then I found CURL and saw that is (a) was more robust
> and (b) seems to be more efficient than readfile. So I now
> use CURL in he following way:
>
> $aje_ch = @curl_init($adr);
> @curl_setopt ($aje_ch, CURLOPT_TIMEOUT, 1);
> @curl_setopt ($aje_ch, CURLOPT_MUTE, 1);
> @curl_exec ($aje_ch);
> @curl_close ($aje_ch);
>
> This works great, except that if I have "Keepalive on" in
> my Apache configuration file, the httpd server sits in
> keepalive state for FAR longer when using CURL than it does
> when using readfile. In the course of 2 or 3 hours, my
> server would normally be at about 150 httpd processes
> running at any given point in time. But when using CURL, it
> jumps to 650 httpd processes, with the lions share (99%) of
> those sitting in the keepalive state for very long. It
> seems like the CURL requests are causing Apache to set its
> Keepalive timeout to something much higher than it should
> be. Setting "keepalive off" in Apache's conf file works
> around this problem, but decreases server efficiency. I'd
> love to solve this problem.
>
> Please help! :-)
>
> For the record, this was posted to the cURL bug tracker
> over on SourceForge
> (http://sourceforge.net/tracker/?func=detail&atid=100976&ai
> d=418860&group_id=976), and we went through quite a few
> gyrations with no success.  Specifically, we tried
> disabling KeepAlive on the REMOTE server to see if that had
> any affect, and it did not.  It seems not to matter what we
> request from, rather that any requests using
> PHP/cURL/Apache result in the LOCAL Apache bloating out of
> control with KeepAlive requests.  Reverting back to
> readfile() based requests solves this problem but, well,
> cURL is better.  ;-)
>
> All help would be appreciated, and I am available and
> willing to test anything on our servers.
>
> Thanks!
>
> -Dave
>
>
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

SV: [PHP-DEV] erealloc and the API

[Johan Ekenberg]

Zeev,

thanks, that made all the difference!

I got a suggestion from another PHP-developer that mixing calls to
emalloc() and strcpy() might be a problem. Is this so?

/Johan

> erealloc() (like realloc()) returns a pointer to the
> realloc'd string.  It
> may or may not be the same pointer you specifed in the first
> argument.  So,
> your code should look like:
> ...
> tmp_variable = erealloc(tmp_variable, ...);
>
> Otherwise, you're going to have both a bug and if it doesn't
> crash you, a
> leak :)
>
> Zeev
>
> At 19:49 4/5/2001, Johan Ekenberg wrote:
> >I have a question regarding the API, something that bit me
> while I was
> >working with the php_imap code:
> >
> >Basically I did this (pseudocode):
> >
> >char init_value[10] = "foobar";
> >
> >tmp_variable = emalloc(strlen(init_value) + 1);
> >strcpy(tmp_variable, init_value);
> >while(condition) {
> >   erealloc(tmp_variable, strlen(tmp_variable) +
> >strlen(stuff_to_be_added) + 1);
> >   sprintf(tmp_variable, "%s%s", tmp_variable,
> stuff_to_be_added);
> >}
> >other_variable = emalloc(strlen(tmp_variable) + 1);
> >strcpy(other_variable, tmp_variable);
> >efree(tmp_variable);
> >
> >This produced some very weird results. At best I got messages about
> >leeking memory from tmp_variable, at worst there were
> segfaults in the
> >PHP memory manager, particularly in libc5 calling free() from
> >php_module_shutdown() if I recall correctly. Finally I ended
> up doing a
> >lot of copying to and from temporary variables without using
> erealloc().
> >But IMHO the code would be smaller and more consistent using
> erealloc().
> >
> >Did I miss something obvious? Any references to existing API
> docs where
> >this is documented would be greatly appreciated.
> >
> >Please cc replies to me, since I'm currently not subscribed to this
> >list.
> >
> >Best regards,
> >/Johan Ekenberg
> >
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >To contact the list administrators, e-mail:
> [EMAIL PROTECTED]
>
> --
> Zeev Suraski <[EMAIL PROTECTED]>
> CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10673: CURL/PHP causes lengthy Apache Keepalive

[dave]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0.4pl1
PHP Bug Type: cURL related
Bug description:  CURL/PHP causes lengthy Apache Keepalive

Greetings. I have Apache/1.3.14 (Unix) running with 
PHP/4.0.4pl1 installed as a module and CURL 7.7.1 added to 
that. Our web sites need to fetch a request from a remote 
ad server in real-time as each page is generated. If $adr 
is the request, I used to use: 

$success = @readfile($adr); 

But then I found CURL and saw that is (a) was more robust 
and (b) seems to be more efficient than readfile. So I now 
use CURL in he following way: 

$aje_ch = @curl_init($adr); 
@curl_setopt ($aje_ch, CURLOPT_TIMEOUT, 1); 
@curl_setopt ($aje_ch, CURLOPT_MUTE, 1); 
@curl_exec ($aje_ch); 
@curl_close ($aje_ch); 

This works great, except that if I have "Keepalive on" in 
my Apache configuration file, the httpd server sits in 
keepalive state for FAR longer when using CURL than it does 
when using readfile. In the course of 2 or 3 hours, my 
server would normally be at about 150 httpd processes 
running at any given point in time. But when using CURL, it 
jumps to 650 httpd processes, with the lions share (99%) of 
those sitting in the keepalive state for very long. It 
seems like the CURL requests are causing Apache to set its 
Keepalive timeout to something much higher than it should 
be. Setting "keepalive off" in Apache's conf file works 
around this problem, but decreases server efficiency. I'd 
love to solve this problem. 

Please help! :-) 

For the record, this was posted to the cURL bug tracker 
over on SourceForge 
(http://sourceforge.net/tracker/?func=detail&atid=100976&ai
d=418860&group_id=976), and we went through quite a few 
gyrations with no success.  Specifically, we tried 
disabling KeepAlive on the REMOTE server to see if that had 
any affect, and it did not.  It seems not to matter what we 
request from, rather that any requests using 
PHP/cURL/Apache result in the LOCAL Apache bloating out of 
control with KeepAlive requests.  Reverting back to 
readfile() based requests solves this problem but, well, 
cURL is better.  ;-)

All help would be appreciated, and I am available and 
willing to test anything on our servers.

Thanks! 

-Dave   


-- 
Edit Bug report at: http://bugs.php.net/?id=10673&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #10644: __FILE__ missing path delimiters

[Chuck Hagenbuch]

Quoting Jani Taskinen <[EMAIL PROTECTED]>:

> You're american, right? :)

Guilty as charged. :)

> Try checking it today..now it says 4/5/2001 (4th of May 2001).
> This is of course 'wrong' as it should be 04.05.2001 which is the correct
> way to show dates. Should it be changed? (just cosmetics, IMO)

Ah. Actually, the "correct" way I've seen endorsed that has no ambiguity is
2001-05-04. And yes, I think it should be changed. It's not just cosmetics;
it's geniunely ambiguous and confusing.

> >filename with no path delimiters. For example, if the script is
> >/var/www/foo.php, __FILE__ contains 'varwwwfoo.php'.
> 
> Works for me.

Are you sure you have the latest Zend, also? I just updated and rebuilt
everything and it's still broken.

-chuck

--
It takes 170 decibels to rupture the human eardrum.
Less, if Celine Dion is singing.

-- 
PHP Development Mailing List 
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] openssl module for php

[Sascha Kettler]

> On 2001-05-04 17:59:03, "Stig Venaas" <[EMAIL PROTECTED]> wrote:
> > This sounds good, please have a look at bug report 10665 by
> > [EMAIL PROTECTED], he has implemented RSA encryption, and [EMAIL PROTECTED]
> > followed up on that. It would be good if you and Sascha Kettler could
> > agree on how the API should be, Wez and maybe I also might have some
> > thoughts. I'm not sure, but rather than having separate functions for
> > each algorithm, it might be better to have encrypt and decrypt
> functions
> > that take algorithm as a parameter. I'm Cc'ing Sascha and Wez.
> 
> I'll probably tweak Sascha's patch to take the cipher as an arg (and add
> similar support to the S/MIME functions while I'm at it).
> 
> Let me know if any of you have any comments - I'm going to look at the
> patch now and have a play with it.

You won't need to pass the algorithm by an arg, as the key already contains
the algorithm identification (pkey->type). I haven't used any DSA encryption
yet, but maybe you can just add the code to the switch statements.

Sascha


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]