[PHP-DEV] Bug #14998: Can't name a class 'Directory'

[dan]

From: [EMAIL PROTECTED]
Operating system: Red Hat Linux 7.0
PHP version:  4.0.5
PHP Bug Type: Class/Object related
Bug description:  Can't name a class 'Directory'

For example, given the code:



PHP gives the error: "Cannot redeclare class directory". Maybe the the
dir() function/class interferes??

Configuration:

'./configure' '--prefix=/usr' '--with-apxs=/usr/sbin/apxs'
'--with-exec-dir=/usr/bin' '--with-config-file-path=/etc/httpd'
'--with-regex=system' '--enable-debugger' '--enable-magic-quotes'
'--enable-sysvshm' '--with-dom' '--enable-force-cgi-redirect'
'--enable-sigchild' '--with-wddx' '--enable-inline-optimization'
'--with-gnu-ld' '--enable-bcmath' '--enable-crypt' '--with-xml'
'--with-sablot' '--enable-dbg=shared' '--with-dbg-profiler'

Thanks.

-- 
Edit bug report at: http://bugs.php.net/?id=14998&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 #11778: french version of manual/fr/function.setcookie.php wrong

[dan]

From: [EMAIL PROTECTED]
Operating system: not applicable
PHP version:  4.0.6
PHP Bug Type: Documentation problem
Bug description:  french version of manual/fr/function.setcookie.php wrong

In the french manual, the function description of setcookie is wrong:
it says that the setcookie function will be performed in reverse order, but that
true only for PHP3.



-- 
Edit Bug report at: http://bugs.php.net/?id=11778&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] PHP 4.0 Bug #10147: DrWatson make a dump when stopping apache service

[dan]

From: [EMAIL PROTECTED]
Operating system: Win2000 Pro
PHP version:  4.0.4pl1
PHP Bug Type: Reproduceable crash
Bug description:  DrWatson make a dump when stopping apache service

Despite previous bug reports that say this is an Apache bug that has been fixed, I 
still get this problem with Apache 1.3.19


-- 
Edit Bug report at: http://bugs.php.net/?id=10147&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] PHP 4.0 Bug #10231: The Icons in the downloadsection of PHP.net are not transparent.

[dan]

From: [EMAIL PROTECTED]
Operating system: Windows 2k
PHP version:  4.0.4pl1
PHP Bug Type: *General Issues
Bug description:  The Icons in the downloadsection of PHP.net are not transparent.




-- 
Edit Bug report at: http://bugs.php.net/?id=10231&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 #10325: Opening database connection breaks ldap

[dan]

From: [EMAIL PROTECTED]
Operating system: Linux 2.4.3
PHP version:  4.0.4pl1
PHP Bug Type: LDAP related
Bug description:  Opening database connection breaks ldap

Opening a database connection breaks LDAP's link index.

Example code:



This generates the error:
PHP Warning: 1 is not a LDAP link index

If you comment out the pg_connect() line, LDAP works fine.
If you pg_close($dbcon) right after the pg_connect(), you still get the PHP error.

This is a definite show stopper considering some people use a database for sessions, 
which means you can't use LDAP
after you start your session.

I'm using the latest openldap 2.0.7 & postgres 7.0.3,
php compiled into apache:
./configure --enable-memory-limit --enable-track-vars --enable-sysvsem 
--enable-sysvshm --with-gd --with-pgsql --with-freetype 
--with-ldap=/usr/local/openldap --with-xml --with-mhash --enable-trans-sid 
--with-kerberos --with-mcrypt --with-apache=../apache_1.3.19 --enable-bcmath 
--with-zlib --with-sockets --enable-inline-optimizations

Please fix soon :)


-- 
Edit Bug report at: http://bugs.php.net/?id=10325&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 #10349: Warning: getrusage() is not supported

[dan]

From: [EMAIL PROTECTED]
Operating system: Windows Nt 4.0
PHP version:  4.0.4pl1
PHP Bug Type: Scripting Engine problem
Bug description:   Warning: getrusage() is not supported   

 Warning: getrusage() is not supported in this PHP build 

 if (function_exists('getrusage')) {

 $dat = getrusage();
  $Str = '';
  foreach ($dat as $k => $v)
  {
  $Str .= $k . $v;
  }


-- 
Edit Bug report at: http://bugs.php.net/?id=10349&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 #10325 Updated: Opening database connection breaks ldap

[dan]

ID: 10325
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: LDAP related
Operating system: Linux 2.4.3
PHP Version: 4.0.4pl1
Description: Opening database connection breaks ldap

User error :)

I was using the integer result from the ldap_bind() operation as the link index. 
ldap_bind() always returned 1 for true, which just happened to be the link index zend 
assigned to the ldap_connect(). The reason it "broke" when I connected to postgres was 
because zend apparantly keeps only 1 link index pool, assigns 1 to the postgres 
connection, then the ldap connection got 2. Also of interest was that the ldap 
connection always got a link index of 2 even after
executing a pg_close(), which I would of assumed would clear the first link index of 1 
for ldap to use.

Dan-

Previous Comments:
---

[2001-05-06 23:32:19] [EMAIL PROTECTED]
Does this happen with PHP 4.0.5 ??
And if so, does it happen with the latest CVS? 
(snapshots: http://snaps.php.net/ )

--Jani


---

[2001-04-14 06:50:50] [EMAIL PROTECTED]
Opening a database connection breaks LDAP's link index.

Example code:



This generates the error:
PHP Warning: 1 is not a LDAP link index

If you comment out the pg_connect() line, LDAP works fine.
If you pg_close($dbcon) right after the pg_connect(), you still get the PHP error.

This is a definite show stopper considering some people use a database for sessions, 
which means you can't use LDAP
after you start your session.

I'm using the latest openldap 2.0.7 & postgres 7.0.3,
php compiled into apache:
./configure --enable-memory-limit --enable-track-vars --enable-sysvsem 
--enable-sysvshm --with-gd --with-pgsql --with-freetype 
--with-ldap=/usr/local/openldap --with-xml --with-mhash --enable-trans-sid 
--with-kerberos --with-mcrypt --with-apache=../apache_1.3.19 --enable-bcmath 
--with-zlib --with-sockets --enable-inline-optimizations

Please fix soon :)

---


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


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10893: Failes to compile "zend_hash.c:257: `LONG_MAX' undeclared"

[dan]

From: [EMAIL PROTECTED]
Operating system: Redhat 6.2 - Linux 2.2.17
PHP version:  4.0.5
PHP Bug Type: Compile Failure
Bug description:  Failes to compile "zend_hash.c:257: `LONG_MAX' undeclared"

Php 4.0.4pl worked fine. When upgrading to 4.0.5 I ran into this compile error. After 
I got this error i tried compiling 4.0.4pl1 and no problems. So I am suspecting it is 
has something to do w/ 4.0.5

CONFIG OPTIONS -
 ./configure  --with-apache=../../../apache_1.3.19 --enable-track-vars --disable-debug 
--with-mysql

COMPILER VOMIT-
/bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main   
-DSUPPORT_UTF8 -DXML_BYTE_ORDER=12  -g -O2 -c zend_hash.c
zend_hash.c: In function `zend_hash_add_or_update':
zend_hash.c:257: `LONG_MAX' undeclared (first use in this function)
zend_hash.c:257: (Each undeclared identifier is reported only once
zend_hash.c:257: for each function it appears in.)
zend_hash.c: In function `zend_hash_del_key_or_index':
zend_hash.c:502: `LONG_MAX' undeclared (first use in this function)
zend_hash.c: In function `zend_hash_find':
zend_hash.c:852: `LONG_MAX' undeclared (first use in this function)
zend_hash.c: In function `zend_hash_exists':
zend_hash.c:902: `LONG_MAX' undeclared (first use in this function)
make[1]: *** [zend_hash.lo] Error 1
make[1]: Leaving directory `/usr/src/apache/modules/php/php-4.0.5/Zend'
make: *** [all-recursive] Error 1


-- 
Edit Bug report at: http://bugs.php.net/?id=10893&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 #13829: scriptname/?var1=var doesnt work

[dan]

From: [EMAIL PROTECTED]
Operating system: RH linux 6.2
PHP version:  4.0.6
PHP Bug Type: *URL Functions
Bug description:  scriptname/?var1=var doesnt work

In php 4.0.5 I used to be able to use the uri
/script.php?var1=va12&var2=val2

I would access this same uri by using /script?var1=val&val2=val2

Since upgrading to 4.0.6 this stopped working.  What was changed in 4.0.6
that made this stop behaving this way?  If it was a bug is there a way I
can emulate it w/ 4.0.6 as some of our site was developed around this

Thanks
Dan 

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


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13994: Can't execute function printer_open

[dan]

From: [EMAIL PROTECTED]
Operating system: windows 2000
PHP version:  4.0.6
PHP Bug Type: Unknown/Other Function
Bug description:  Can't execute function printer_open

using the following function
$handle = printer_open();

I get the error:
Fatal error: Call to undefined function: printer_open()



-- 
Edit bug report at: http://bugs.php.net/?id=13994&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 #14029: can't dynamically load php_printer.dll extension

[dan]

From: [EMAIL PROTECTED]
Operating system: win/2000
PHP version:  4.0.6
PHP Bug Type: Program Execution
Bug description:  can't  dynamically load php_printer.dll extension

In php.ini I have:
enable_dl = On
extension_dir = "c:/PHP/extensions/"

All the extension dll's are in C:/PHP/extensions without any security.

PHP Program

I get the following error:
-
Unable to load dynamic library 'c:/PHP/extension/php_printer.dll' - The
specified procedure could not be found.
---
I have varified the fact that php_printer.dll is there!

I get the same error when I un-comment 
extension=php_printer.dll
in php.ini

Help What am I doing wrong!
How do i get these to load.

Thanks for the help..
Dan

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


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: Re[2]: [PHP-DEV] Designing for PHP4 with PHP5 in mind...

[Dan Hardiker]

> Please run this code and check it output!

I actually did ;) however in retyping (due to circumstances) the code I
had misread the function call as c(&$a); and on replying didt notice my
mistake.

Appologies :P If you change the function call to c(&$a); you will notice
the output being "AAC" :P


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Win32 builds dead?

[Dan Kalowsky]

Seem to be dead on building ext/rpc (fresh CVS).

ext/rpc/php_rpc.h(45) : error C2061: syntax error : indentifier 
'rpc_objects_new'
ext/rpc/php_rpc.h(45) : error C2059: syntax error : ';'
ext/rpc/php_rpc.h(45) : error C2059: syntax error : 'type'

>---<
Dan Kalowsky"I've learned to fake it,
http://www.deadmime.org/~dankand just smile along."
[EMAIL PROTECTED]- "Candy",
[EMAIL PROTECTED]  Iggy Pop


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] roadmap of PHP - where? PHP 5 - when?

[Dan Kalowsky]

Then discontinue it.  End of discussion.

This is an open source project, and I see little to no-advantage to 
it's use outside of creating a rather vile aftertaste in the mouths of 
those developers who are not "invited".

I've heard the arguments for the list, and I can only say they are 
valid reasons.  But you're now making PHP a political project rather 
than a software project.  Thanks.  This is the sort of thing I don't 
want to have to deal with in my personal time.  If you want a private 
list, take PHP out of the Open Source.  If you want to cut down on the 
signal/noise ratio then moderate the list, but don't make it private 
and invite only.

Zeev no matter how you see it or say it, the inclusion of members into 
a "private" mailing list is an exclusive ranking.  You may claim 
otherwise, but all such claims by members of such group will more than 
likely be disregarded.



On Thursday, January 23, 2003, at 11:38 AM, Rasmus Lerdorf wrote:

I had nothing to do with that limited php5 list.  I thought that was
completely bogus myself and argued against it.


>-------<
Dan Kalowsky"Cause fear is strong and love's
http://www.deadmime.org/~dankfor everyone, who isn't me."
[EMAIL PROTECTED]  - "Burden In My Hand",
[EMAIL PROTECTED]  Soundgarden


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Using IMAP with SSL

[Dan Kalowsky]

Within the cvs HEAD there has been a change made recently to use the 
--with-imap-ssl tag if the cclient was built with SSL capabilities.

Unfortunately this breaks the build on my end rather drastically as 
default Darwin builds do not use the //openssl/ method, but rather /usr/lib/libssl*.* and 
/usr/include/openssl/*.h methods.

So this leaves me with the question, does anyone have an idea on how to 
fix this properly before I start hacking at it?  All responses of 
'change your OS' nature will be ignored :)

>---<
Dan Kalowsky"I'll walk a thousand miles just
http://www.deadmime.org/~dankto slip this skin."
[EMAIL PROTECTED]- "Streets of Philadelphia",
[EMAIL PROTECTED]Bruce Springsteen


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Feature Request #5919 case-insensitive version ofstr_replace()

[Dan Kalowsky]

I'd tip my hat towards implementing it.  Pollita has a good point on
consistency and for those who don't know regex's.

On Wed, 29 Jan 2003, Sara Golemon wrote:

> >> I may be wrong since I haven't profiled this, but my understanding is
> >> that str_replace is much faster than doing either of the regex
> >> replacements.  For that reason alone, there is a use for it.
> >
> > Normally it would be quite faster, however once case sensitivity is
> > added to  the mix I believe the speed difference would be minimal.
> >
> I don't even see the speed difference as an issue as much as (A)
> simplicity for the user who hasn't figured out regex yet, (B) consistency
> (we have 'i' versions of most other string functions, why not this one?)
>
> The parameter accepting still needs to be fixed though, I copied most of
> the str_ireplace code from str_replace and forgot to clean that section up
> and make it nicer.  I'll save that for *if* a quorum can be reached to
> include it at all.
>
> On a related topic, the 'boyer' option of str_replace isn't even
> documented.  That alternate method of performing str_replaces look like
> it's a bit more efficient (no benchmarkes atm) but I'm wondering if
> there's a specific reasons why it wasn't documented yet.
>
> -Pollita
>
>
>
>
>

>---<
Dan Kalowsky"I'll walk a thousand miles just
http://www.deadmime.org/~dankto slip this skin."
[EMAIL PROTECTED]- "Streets of Philadelphia",
[EMAIL PROTECTED]Bruce Springsteen

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Mono & PHP

[Dan Hardiker]

Is it true you can catch mono from using php?


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP 5 mailing list

[Dan Kalowsky]

To all concerned,

I would like to request that yet again the PHP5 mailing list be made
public and no longer kept private.  Given that comments in the past few
hours have centered around the existence of the mailing list, it seems
rather absurd to continue the secrecy notion.

To those who will say it is open for joining, I submit to you the
following considerations.  First there is no mention of said mailing list
existing on the mailing-list tab of the PHP main web site.  Second there
is still no publicly viewable record of what has transpired on the
mailing list (which means the 'read the archives' comment is futile).

I for one find it really annoying to find changes to PHP being done
without discussion.  Only later to find through an IRC channel what was
done and why.

>---<
Dan Kalowsky"I'll walk a thousand miles just
http://www.deadmime.org/~dankto slip this skin."
[EMAIL PROTECTED]- "Streets of Philadelphia",
[EMAIL PROTECTED]Bruce Springsteen

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Security question with PHP on Unix / Linux.

[Dan Hardiker]

> At this point of time, I am trying to understand the way security is
> implemented for PHP on Unix / Linux. I mean, how are the different users
> distinguished in Unix / Linux. Do they get to login into the Unix /
> Linux system through separate accounts? In that case, do they have
> separate data space for each user? What is the API that is used to login
> to Unix / Linux. User may enter his username and password on the
> browser, but how do they get translated onto the Unix / Linux box?
>
> The end goal is to separate out uses and to make sure that normal users
> (who do not have admin rights) do not get to read a file, write into a
> file etc from areas that they have no access rights into. How is this
> access rights set in Unix / Linux?

As this shows a basic mis-understanding of the way Unix based /
look-a-like operating systems work, and how PHP is executed... this is
definatly a question for the php "general" list
([EMAIL PROTECTED]).

This forum is for discussion about the constructs that form PHP itself,
not its implementation or its use.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] XSL Transformations

[Dan Hardiker]

> hello... i am new, so i am not sure that i know how to use this. I
> have this problem...i open a connnection, and the content i am getting
> back is xml. I have to transform this (XSLT) and output it in a
> different  format. Can anyone help me with this?

After reading the list sign up page very carefully, I am sure you're aware
that this is not the correct place to ask your question.

You will also know that this sort of question should be asked in
[EMAIL PROTECTED]

Your appologies are accepted.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ODBC Prepare

[Dan Kalowsky]

This is really a support question and is being asked on the wrong list.

But in light of that... PHP's odbc_prepare function should work with 
the '?' option.  It really isn't the one deciding this though, as it's 
more your ODBC Driver.  As far as PEAR is concerned, I have little 
insight into that aspect of PHP.  Your best bet is to ask PEAR 
developers or read the source.

On Monday, February 10, 2003, at 11:48 AM, Adam Voigt wrote:

According to a manual I found on the web for call's to "SQLPrepare"
(referenced in ext/odbc/php_odbc.c) you can implant "?" in place of
variables for statement execution. PearDB makes reference to this
on:

http://pear.php.net/manual/en/core.db.tut_execute.php

So my question is, is PHP's ODBC programming just not setup to handle
this (and is Pear doing this manually with PHP) or am I
mis-understanding
the way the library works in PHP?

Thanks,

Adam Voigt
[EMAIL PROTECTED]


>-------<
Dan Kalowsky"I've learned to fake it,
http://www.deadmime.org/~dankand just smile along."
[EMAIL PROTECTED]- "Candy",
[EMAIL PROTECTED]  Iggy Pop


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Piping to the PHP binary

[Dan Hardiker]

Hey all,

echo "" | /path/to/php

That works on php v4.2.x but Ive got 3 machines on v4.3.x and none of them
seem to respond to the piping of the php config.


v4.2.x Response

[13:56:[EMAIL PROTECTED]:~$ echo "" |
/usr/local/bin/php
X-Powered-By: PHP/4.2.3
Content-type: text/html

hi[13:56:[EMAIL PROTECTED]:~$

v4.3.x Response

[13:58:[EMAIL PROTECTED]:~$ echo "" |
/usr/local/bin/php
Status: 404
Content-type: text/html
X-Powered-By: PHP/4.3.2-dev

No input file specified.
[13:59:[EMAIL PROTECTED]:~$


Anyone else with the same results on a v4.3.x cgi-binary?
Is this modified behavoir limited to me, or expected?

I tried asking php-general@ but no response.


-- 
Dan Hardiker [EMAIL PROTECTED]
ADAM Software & Systems Engineer
First Creative



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Piping to the PHP binary

[Dan Hardiker]

Hi,

So there is no upgrade path for the cgi - it's lost this functionality?
(please confirm, as that breaks backward compatability for alot of my
scripts)

Surely the CGI should be able to handle piping too? [btw: if I build a CLI
version, I get the same problem... Im guessing that its caused by one of
the modules included]

Im just rebuilding my CLI binary, but here is a listing of the php CGI's
modules, incase the CGI binary is supposed to accept piping:

[14:06:[EMAIL PROTECTED]:~$ /usr/local/bin/php-4.3.2 -v
PHP 4.3.2-dev (cgi), Copyright (c) 1997-2003 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies
[14:06:[EMAIL PROTECTED]:~$ /usr/local/bin/php-4.3.2 -m
[PHP Modules]
bcmath
bz2
ctype
curl
dba
domxml
ftp
gd
gettext
hyperwave
iconv
imap
ldap
mbstring
mcal
mcrypt
mcve
mhash
ming
mysql
openssl
overload
pcre
pdf
pgsql
posix
pspell
session
snmp
sockets
standard
tokenizer
wddx
xml
xmlrpc
xslt
zlib

[Zend Modules]

[14:11:[EMAIL PROTECTED]:~$ /usr/local/bin/php-4.1.2 -v
4.1.2
[14:08:[EMAIL PROTECTED]:~$ /usr/local/bin/php-4.1.2 -m
Running PHP 4.1.2
Zend Engine v1.1.1, Copyright (c) 1998-2001 Zend Technologies

[PHP Modules]
xml
standard
sockets
session
posix
pdf
pcre
mysql
ming
imap
gd
zlib

[Zend Modules]
Not Implemented

[14:11:[EMAIL PROTECTED]:~$


> use the cli not cgi:
>
> [EMAIL PROTECTED] moshe]$ php -v
> PHP 4.3.2-dev (cli) (built: Feb 24 2003 18:43:23)
> Copyright (c) 1997-2003 The PHP Group
> Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies
> [EMAIL PROTECTED] moshe]$ echo "" | php
> [EMAIL PROTECTED] moshe]$
>> [13:58:[EMAIL PROTECTED]:~$ echo "" |
>> /usr/local/bin/php
>> Status: 404
>> Content-type: text/html
>> X-Powered-By: PHP/4.3.2-dev
>>
>> No input file specified.
>> [13:59:[EMAIL PROTECTED]:~$


-- 
Dan Hardiker [EMAIL PROTECTED]
ADAM Software & Systems Engineer
First Creative



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [WARNING] Release process for 4.3.2 starts RSN..

[Dan Hardiker]

> Remeber we are volunteers and sometimes we find it more interesting to
> hang out in a pub and drink Finlandia then to release PHP.

Any particular pub? Im up for a few pints ;)


-- 
Dan Hardiker [EMAIL PROTECTED]
ADAM Software & Systems Engineer
First Creative



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [WARNING] Release process for 4.3.2 starts RSN..

[Dan Hardiker]

> Remeber we are volunteers and sometimes we find it more interesting to
> hang out in a pub and drink Finlandia then to release PHP.

Any particular pub? Im up for a few pints ;)


-- 
Dan Hardiker [EMAIL PROTECTED]
ADAM Software & Systems Engineer
First Creative



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP] Re: [PHP-DEV] Is PHP designed (have the capability) to access remote DB?

[Dan Hardiker]

Actually your question relates to the use and functionality of the PHP
language.

If your question was relating to the C code that makes up PHP itself,
which involves accessing remote databases (eg: where abouts in the source
code can I find the handlers for a mysql_connect command)... then your in
the right place [ but even then you'd be told to go read up on the project
first ].

but your not. Please redirect further rants to [EMAIL PROTECTED] where
they will be able to help.

If you have more questions, forward them to [EMAIL PROTECTED], NOT
here.

Thankyou for your time!

> IT IS ABOUT THE DESIGN AND DEVELOPMENT OF PHP
>
>> > Is PHP designed (have the capability) to access remote DB?


-- 
Dan Hardiker [EMAIL PROTECTED]
ADAM Software & Systems Engineer
First Creative



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/db db.c

[Dan Kalowsky]

We did a google search and found absolutely nothing with it mentioned.
Oddly enough, taking out the #if GDBM_FIX breaks the db functions on
FreeBSD

On Mon, 12 Aug 2002, Rasmus Lerdorf wrote:

> Hrm..  I vaguely remember writing this code and dealing with this GDBM_FIX
> thing 5-6 years ago.  If you look in php.h from PHP version 2 you will see
> this:
>
> /*
>  * GDBM_FIX
>  *
>  * Some people have reported problems getting gdbm to work correctly.  If
>  * you are seeing a gdbm compatibility problem, try defining this and
>  * let me know if it fixes your problem.  If it does, please tell me
>  * which version of gdbm you are using
>  */
> /* #define GDBM_FIX 1 */
>
> Hopefully we can safely assume that nobody is using whatever ancient
> version of gdbm that may have had this problem.
>
> -Rasmus
>
> On Tue, 13 Aug 2002, Dan Kalowsky wrote:
>
> > kalowskyTue Aug 13 00:10:31 2002 EDT
> >
> >   Modified files:
> > /php4/ext/dbdb.c
> >   Log:
> >   Fix for Bug #18746 by sfox and I
> >   #What is the GDBM_FIX for anyways, we can find it anywhere?
> >
> >
> > Index: php4/ext/db/db.c
> > diff -u php4/ext/db/db.c:1.73 php4/ext/db/db.c:1.74
> > --- php4/ext/db/db.c:1.73   Fri Jun 28 20:40:34 2002
> > +++ php4/ext/db/db.cTue Aug 13 00:10:31 2002
> > @@ -17,7 +17,7 @@
> > +--+
> >   */
> >
> > -/* $Id: db.c,v 1.73 2002/06/29 00:40:34 sniper Exp $ */
> > +/* $Id: db.c,v 1.74 2002/08/13 04:10:31 kalowsky Exp $ */
> >  #define IS_EXT_MODULE
> >
> >  #ifdef HAVE_CONFIG_H
> > @@ -38,15 +38,11 @@
> >  #include 
> >  #endif
> >
> > -#ifdef PHP_31
> > -#include "os/nt/flock.h"
> > -#else
> >  #ifdef PHP_WIN32
> >  #include "win32/flock.h"
> >  #else
> >  #include 
> >  #endif
> > -#endif
> >
> >  #if HAVE_FCNTL_H
> >  #include 
> > @@ -630,7 +626,12 @@
> > DBM_TYPE dbf;
> >
> > key_datum.dptr = key;
> > +#ifdef PHP_WIN32
> > +   key_datum.dsize = strlen(key+1);
> > +#else
> > key_datum.dsize = strlen(key);
> > +#endif
> > +
> >  #if GDBM_FIX
> > key_datum.dsize++;
> >  #endif
> >
> >
> >
> > --
> > PHP CVS Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>

>---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Method memory handling from an instanced object

[Dan Hardiker]

Hi All,

If I was to code something like:



There are now 2 variables, both with a copy of the object Example in them.
Now, I would expect the variables in the objects to be duplicated (eg: the
memory space for $ex1->abc to be separate from $ex2->abc). However, is the
method definition the same?

Is the method definition and contents duplicated each instancing? (eg: if
I have 100,000 instances of an object with a "print()" method - would that
method be copied to each object - or would the reference the same memory
space).

If the method is shared, then would a static variable in a method be
shared across the entire class - or would it still reference to that
object instance's variable memory space?

If the method is not shared, could this cause an issue with a class that
has a lot of methods being instanced lots of time and taking up lots of
memory?

If anyone can let me know how this conceptually works, and (if possible) why.

Thanks,


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] php_error_docref

[Dan Kalowsky]

A few comments on this.

1) is it possible to cut down on the number of php_error_docref functions
to just one?  I really don't see a reason for this many different formats.

2) Can we please remove the "http://www.php.net/manual/en/blahblahblah";
style of use for this?  It will tend to force users into one language or
another, and not make PHP as friendly/usable to other languages.



>-------<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main network.c

[Dan Kalowsky]

There was a suggestion, I don't remember if it was agreed upon or not.
Regardless as I see it this is still a bug, and until an ini value is
added, this shouldn't be allowed out as-is in the next release.

If an ini value is added by that time though, it would be nice :)

On Tue, 13 Aug 2002, Edin Kadribasic wrote:

> Hello Dan,
>
> Wasn't there an agreement that the timout is going to be a an .ini
> setting whith a default value of 60?
>
> Edin
>
> ----- Original Message -
> From: "Dan Kalowsky" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, August 13, 2002 4:39 PM
> Subject: [PHP-CVS] cvs: php4 /main network.c
>
>
> > kalowsky Tue Aug 13 10:39:03 2002 EDT
> >
> >   Modified files:
> > /php4/main network.c
> >   Log:
> >   Bug Fix #16113, as reflective of a php-dev convo between wez and
> iliaa
> >
> >
> > Index: php4/main/network.c
> > diff -u php4/main/network.c:1.57 php4/main/network.c:1.58
> > --- php4/main/network.c:1.57 Sun Aug 11 07:25:24 2002
> > +++ php4/main/network.c Tue Aug 13 10:39:03 2002
> > @@ -15,7 +15,7 @@
> > | Author: Stig Venaas <[EMAIL PROTECTED]>
> |
> >
> +---
> ---+
> >   */
> > -/* $Id: network.c,v 1.57 2002/08/11 11:25:24 wez Exp $ */
> > +/* $Id: network.c,v 1.58 2002/08/13 14:39:03 kalowsky Exp $ */
> >
> >  /*#define DEBUG_MAIN_NETWORK 1*/
> >  #define MAX_CHUNKS_PER_READ 10
> > @@ -515,7 +515,7 @@
> >
> >   sock->is_blocked = 1;
> >   sock->chunk_size = FG(def_chunk_size);
> > - sock->timeout.tv_sec = -1;
> > + sock->timeout.tv_sec = 60;
> >   sock->socket = socket;
> >
> >   stream = php_stream_alloc_rel(&php_stream_socket_ops, sock,
> persistent, "r+");
> >
> >
> >
> > --
> > PHP CVS Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> >
>

>---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] pair numbers

[Dan Hardiker]

> i,m new in this confference

I think your looking for [EMAIL PROTECTED]

> can u help me with small problem? i,m looking 4 function which checking
> pair int. number true/false (1=false, 2=true, 3=flase, 4=true, etc.)

Seen as this is a quick one ... I think your looking to see if a number is
odd or even... for this you will probably want to check the modulus from
2.

EG: if ($var % 2) { echo "Odd!"; } else { echo "Even!"; }
or a more compact version ... echo ($var%2) ? "Odd!" : "Even!";


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] php_error_docref

[Dan Kalowsky]

On Tue, 13 Aug 2002, Marcus [iso-8859-1] Börger wrote:

> >2) Can we please remove the "http://www.php.net/manual/en/blahblahblah";
> >style of use for this?  It will tend to force users into one language or
> >another, and not make PHP as friendly/usable to other languages.
>
> NO! First you can simply set docref_root in your ini to point to your local
> copy of the manual in whatever language and Second it is a problem of
> the php website. It should automatically redirect from
> php.net/function.
> to php.net/manual//.php

I'm not sure I see the point still.  What I'm proposing is not allowing:

php_error_docref("http://www.php.net/manual/en/function.fopen"; TSRMLS_CC,
E_WARNING, "Spongebob Square Pants rules");

as a valid call from within an extension.  Because this limits anytime
this error occurs to the English manual description only, or any language
which is defined really.  There is no need for this, as you have provided
another option which works much cleaner and better (through the ini
options) in my opinion.  While the PHP website may have a bug (or two) in
it, it's no reason to force end users to be reading languages that they
don't know or prefer.

I have nothing wrong with:

php_error_docref("function.fopen" TSRMLS_CC, E_WARNING, "Spongebob Square
Pants lives in a pineapple under the sea");

To me that should be the recommended method, as it will allow the php.ini
values for language to override everything nicely, and everyone can see
the PHP manual in their desired language.  The error of course is still in
English but thats another matter.

>---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] php_error_docref

[Dan Kalowsky]

On Tue, 13 Aug 2002, Marcus [iso-8859-1] Börger wrote:

> The point is to be able to direct to external sites not on php.net! For
> example
> when a function is just a wrapper around a library then you can use the
> absolute
> form of the docref parameter ("http://") to point to the library's
> website.

Okay thats a point I hadn't thought of.  Though I'm not sure why we'd be
referencing outside sites.  Can we then change the CODING_STANDARD
example to NOT use the php.net website?  Hopefully stopping anyone from
using it as a reference to any php-specific documentation, and only for
external sites.

> NULL or "#" is best here since it allows the phpdoc group to change
> their mind for naming the pages.

Then again, I don't understand what this parameter is for.  If not for the
developer to declare which help file this is in, what is the point?  Yes I
see the anchor tags option, but what is the difference between using an
anchor and declaring specifically?

It just seems that if this variable is going to be 90% of the time (random
guess) NULL, it's not really all the necessary to be included.

And judging from the comment by Gabor, the PHPDOC group isn't going to
change this format anytime soon.

>---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley



--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: trans-sid warning?

[Dan Hardiker]

> I'm not saying cookie based session is perfectly secure, but
> it's obvious to me that URL based session is much less secure
> than cookie one, especially compare to session cookie.

URL based session-id transferal is not much less secure, because all the
user has to do is open up their cache and voila, there is the session id.

I publish e-learning sites to colleges and univercities, and I *still*
find that 80% of the places we deliver to dont have cookies enabled
(because of a paranoid sys-admin ... and with the problems reciently found
in IE, I dont blame them for expecting security holes / bugs, really).

If you are coding a session handler (ontop of the existing php4 set of
session tools) I would expect the following:

 * Browser ID checking (and whatever information can be relied upon (in
certain cases, ip)) to make sure that the session ID hasnt just been cut
n pasted into an emai
 * Time based logout *serverside* and an error message to inform the user
they have been automatically logged out and should they leave their
terminal unattended / stop working with the site - they should do this
themselves.

Security is just an illusion in the end anyway - its the user that is the
prime culprit of security evasion, and the end point is: no matter how you
do it - you have to get a unique session key / id from the client back to
the server in some way. Because this is stored on the client (either as
cookie, url or in the outputed code somewhere), it will always have a
flaw.

> Session cookie is the best way passing session ID.
> Second best is normal cookie, then URL/POST method.

This bit confused me slightly ... whats the difference between a Session
cookie and a Normal cookie?

-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: trans-sid warning?

[Dan Hardiker]

>>This bit confused me slightly ... whats the difference between a
>> Session cookie and a Normal cookie?
>
> It's stored in memory, not on disk.

How you can tell a cookie to be stored in RAM rather than on the HDD, Im
not sure ... but that might mean I need to brush up.

> For the end-user Mr. Priest, this would be considered even 'less
> secure',  because he expects it to be deleted and invalid, but the
> ISP-forced proxy  he's using is logging all headers and Mr. Haxor just
> broke in and used the  session id to get his order form for vanilla
> flavoured condoms.
>
> Now how did that happen? It's a miracle :-)

Now this is where the code dev needs an IQ above 3. *Use IP and Browser
String authentication*

eg: Load up the session ID given, check the ip and browser string
(possibly even referrer) and if they dont match, squeel.

Yes, the browser string and referrer can be faked (although some what
difficultly without a stream dump of the connection, by which point they
have more data than they could hope for... in this case *use https*). The
IP is more difficult to forge... but possible, but I think you catch my
drift.

It does not matter *where* the session id goes client side, it cannot be
trusted. Period.

In order for sessions to work, you must send a session id to the client,
and you must expect to get that back. You have no idea how the client is
storing those cookies and even if you tell the cookie "delete yourself and
never be seen again" (be a ram or hdd cache cookie) you cant rely on that
fact.

If Mr Customer can get in - so can Mr Hacker... simple. Where there is a
will there is a way. All you can guage is the amount that Mr Hacker needs
to know.

At the end of the day - if you want to avoid cookies / session id
insecurities... use a flash interface with xml sockets (blowfish
encrypted).

I wont go into the details here, this has gone far enough off topic.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: trans-sid warning?

[Dan Hardiker]

> URL based sessin management has more risks than cookie's.
> Please advise people to consider risks :)

but cookies arent always enabled (in my area of deployment 90% dont have
them enabled) .. and the fact is no matter where the data goes client
side, the data can still be pulled.

I can knock a delphi app which runs in the background pulling the session
id from the pages, no matter where it gets put (ram, hdd, url) just by
intercepting the communication in the [ever so secure] windows layer.

Security in this matter should be taken with a pinch of salt. Some methods
are more flexable (available to more people), some methods take more work
to get the data... but neither is really more secure as the data is still
stored in (effectivly) plain text and is easily locatable.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Dan Hardiker]

> +
> + Therefore, when dealing with sensative information, there should +
> always be additional methods to decide whether it is a valid +
> session. Sessions are not reliable as a secure +
> authentication mechanism.
> +

So if Im to write an online web-based banking system (either in Java/JSP,
PHP, ASP - whatever)... what method would you suggest that IS secure?


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Dan Hardiker]

>> I absolutely agree with Stefan here. It is *not* PHP's job to secure
>> a connection. SSL does this.
>
> Like that's going to stop users from pasting url with SID in it to an
> email, which is what this thread is about.

There are 2 issues at play here, firstly is educating PHP site builders
that using HTTPS would enable a secure method of communication to stop
packet sniffing and stream caching.

Secondly, is educating the PHP users to the cause and effect cycle (the
issues) with using things like session's, their client-side storage
methods etc.

HTTPS should be used where nessesary yes - but we currently have no
alternative to sessions ... not a good, http-universally usable one.

If we can come up with a universal alternative that can be used - then
lets go for it ... if not, were gonna just have to live with the best we
have.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Dan Hardiker]

>> So if Im to write an online web-based banking system (either in
>> Java/JSP,
>> PHP, ASP - whatever)... what method would you suggest that IS secure?
>
> As for the propagation of the session id, there is only one
> pseudo-secure
> method -- using HTTP basic authentication. On authenticated pages, the
> following code can be used to make the session id dependent on the
> authentication credentials passed on by the user. I'm quite happy with
> it on various sites.

However, HTTP basic authentication is passed the same as session cookies
(discussed earlier in this thread) - in the headers of the HTTP
communication. This can very easily be faked with something like cURL.

The only secure way I have found has been flash inside the web browser,
with a blowfish encryption handler. Then the flash app talks to the PHP
scripts over HTTPS communicating in XML and passing the session back and
forward there.

The only way around it is to log every single packet and use packet
reconstruction after putting it though a SSL handler and then parse the
TCP communication... but theres no way around that one.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Dan Hardiker]

> On the other hand, if you know the user's credentials, why bother to
> fake anything -- just log in to the system like anyone else!

Thats user security - only user training can do that.

> So... In a system where eavesdropping or man-in-the-middle attacks are
> not possible (ie. HTTP over SSL), HTTP Basic Authentication is secure.

As secure as any other method suggested [eg: cookies] yes - but no more or
less secure.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CVS Account Request: m_alnasri31

[Dan Hardiker]

> PHP is very Good.

and you require a PHP CVS account because ... heh

-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Parent _LINE_ Request

[Dan Hardiker]

What you are requesting is available in the new ZE2. Have a look at the
following URL for more information:

http://www.php.net/ZEND_CHANGES.txt

[what your after is the last item]

Im unsure of what version of PHP the new ZE2 and its propegated
functionality is expected in PHP, but PHP 5 would be a safe assumtion.

> xdebug looks nice but this is something so basic that having it as a
> base part of php would aid in development for everyone, including low
> level/newbie programmers. Not to mention that the instructions provided
> on there page are not possible for a very large portion of the php
> programmers out there, Ones without there own machine who do not have
> access to php.ini.
>
> Granted the module can possibly be loaded within the script however this
> level of troubleshooting should be a part of php.
>
> On Thu, 2002-08-15 at 05:22, Alan Knowles wrote:
>> have a look at xdebug, or similar which does backtraces
>>
>> I think PHP5 will do this as well..

-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] #18401 [Opn->Ana]: shuffle() broken (fwd)

[Dan Kalowsky]

Anyone able to confirm or deny the validity of this patch?


-- Forwarded message --
Date: 14 Aug 2002 07:04:50 -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: #18401 [Opn->Ana]: shuffle() broken

 ID:   18401
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Analyzed
 Bug Type: Arrays related
 Operating System: Redhat 7.3
 PHP Version:  4CVS-2002-08-12
 New Comment:

-   if (rnd_idx != cur_elem) {
-   temp = elems[cur_elem];
-   elems[cur_elem] = elems[rnd_idx];
+   RAND_RANGE(rnd_idx, 0, n_left, PHP_RAND_MAX);
+   if (rnd_idx != n_left) {
+   temp = elems[n_left];
+   elems[n_left] = elems[rnd_idx];
elems[rnd_idx] = temp;

Thanks for detailed report. This diff clearly show where to fix.
Swapping values requires 3 lines!!



Previous Comments:


[2002-08-12 03:10:28] [EMAIL PROTECTED]

I have just tried it with the latest CVS and I still get the same
results. Brad's changes were in a different section of the file.



[2002-08-11 02:30:52] [EMAIL PROTECTED]

I'm pretty Brad has been playing with this code.  Can you test again,
and report back with a new snapshot?



[2002-07-18 01:03:51] [EMAIL PROTECTED]

The shuffle() function in the CVS is (still) broken. It does not
correctly generate all possible combinations of the array. (I know this
function was recently updated, this test is with new version.)

Here is a diff to fix the problem:

--- array.c Thu Jul 18 00:50:54 2002
+++ array.new.c Thu Jul 18 00:49:35 2002
@@ -1441,7 +1441,7 @@
 {
Bucket **elems, *temp;
HashTable *hash;
-   int j, n_elems, cur_elem = 0, rnd_idx, n_left;
+   int j, n_elems, rnd_idx, n_left;

n_elems = zend_hash_num_elements(Z_ARRVAL_P(array));

@@ -1457,13 +1457,12 @@
elems[j++] = temp;
while (--n_left) {
rnd_idx = php_rand(TSRMLS_C);
-   RAND_RANGE(rnd_idx, cur_elem, n_left, PHP_RAND_MAX);
-   if (rnd_idx != cur_elem) {
-   temp = elems[cur_elem];
-   elems[cur_elem] = elems[rnd_idx];
+   RAND_RANGE(rnd_idx, 0, n_left, PHP_RAND_MAX);
+   if (rnd_idx != n_left) {
+   temp = elems[n_left];
+   elems[n_left] = elems[rnd_idx];
elems[rnd_idx] = temp;
}
-   cur_elem++;
}

HANDLE_BLOCK_INTERRUPTIONS();

Here is some PHP that will reproduce the problem. As you can see the
built-in shuffle() only generates 3 of the 6 possible combinations,
while the userland array_shuffle() correctly generates all 6 with equal
likelyhood.

 $v) {
print "$k: $v\n";
  }

}

test('shuffle');
test('array_shuffle');

?>





-- 
Edit this bug report at http://bugs.php.net/?id=18401&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Build warnings on OSX in sockets

[Dan Kalowsky]

Haven't noticed this before, so I'm guessing this isn't a good thing.

/Users/dank/Development/php4-cvs/ext/sockets/sockets.c: In function
`zif_socket_recvmsg':
/Users/dank/Development/php4-cvs/ext/sockets/sockets.c:1524: warning:
assignment from incompatible pointer type
/Users/dank/Development/php4-cvs/ext/sockets/sockets.c:1529: warning:
assignment from incompatible pointer type
/Users/dank/Development/php4-cvs/ext/sockets/sockets.c:1578: warning:
assignment from incompatible pointer type
/Users/dank/Development/php4-cvs/ext/sockets/sockets.c:1584: warning:
assignment from incompatible pointer type
/Users/dank/Development/php4-cvs/ext/sockets/sockets.c: In function
`zif_socket_sendmsg':
/Users/dank/Development/php4-cvs/ext/sockets/sockets.c:1670: warning:
assignment from incompatible pointer type
/Users/dank/Development/php4-cvs/ext/sockets/sockets.c:1698: warning:
assignment from incompatible pointer type
/Users/dank/Development/php4-cvs/ext/sockets/sockets.c: At top level:
/Users/dank/Development/php4-cvs/ext/sockets/sockets.c:115: warning:
`php_strerror_buf' defined but not used

>---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] php_error_docref bugs

[Dan Kalowsky]

Running the latest Windows CVS checkout, I get an interesting problem with
the php_error_docref output.

It seems to cut off the first letter of messages, ala:

etwork.php) [ Blah blah blah
blah.

Might be good to fix that.

>---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] ZE2 and PHP

[Dan Hardiker]

Hi,

As php user's requests are getting closer and closer to what ZE2 is
offering (eg: back tracing, private/protected classes, extra inheritance
functionality, etc) ...

1. When is ZE2 expected to be released (if its not already)
2. When is it expected to be available in a development (experimental) or
production release?

Any ideas?


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ZE2 and PHP

[Dan Hardiker]

>>2. When is it expected to be available in a development (experimental)
>> or production release?
>
> It already is - go to www.php.net, and search for 'alpha'.
> http://www.php.net/do_download.php?download_file=php-4.3.0-dev-zend2-alpha2.tar.gz

Forgive me for my ignorance... but does that mean PHP-4.3.0 release will
have a stable ZE2 version as well as the standard ZE1 one?


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Tru64, snprintf and bug #1298

[Dan Kalowsky]

Yes, that is correct, bug #1298 (it's existed for a LONG time).

The user is having some difficulty compiling the Zend libraries for 4.2.2.
Mainly it seems that snprintf is turning up as an unresolved symbol.
I asked him to grep through the /usr/include looking for it, and the
result was nothing.

Looking through the code I see PHP has it's own snprintf implementation,
and that should suffice.  Apparently zend_API.c though doesn't notice it.
His fix was to place <#include "php.h"> inside the file, and everything
worked fine.

Does anyone have any more insight into this that they might be able to
share?

>-------<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Tru64, snprintf and bug #1298

[Dan Kalowsky]

Well it's starting to sound like it might be necessary to do this.  While
nohn's compiler is working, it seems that at least one other Tru64 person
is having difficulty.

Looking at the influx of bugs as well, I'm wondering if Tru64 is going to
be more of a problem for the project as whole... or if it's just 64-bit
arch's in the end.

On Sat, 17 Aug 2002, Marcus [iso-8859-1] Börger wrote:

> First of all the internal replacement of snprintf fails if size is 1 or 0.
> Second it is not C99 complient and third we do not include it the
> right way. We would need to check if snprintf is available and if it is
> C99 complient and if not use the replacement.
>
> I had a lengthy discussion with the php group on that but i did
> not get any answer at last. This might be the case because my
> first worst assumptions were wrong for most systems.
>
> In fact i could commit detection code and corect replacement code
> but will do only when receiving a go from the group.
>
> regards
> marcus
>
> At 23:31 16.08.2002, Dan Kalowsky wrote:
> >Yes, that is correct, bug #1298 (it's existed for a LONG time).
> >
> >The user is having some difficulty compiling the Zend libraries for 4.2.2.
> >Mainly it seems that snprintf is turning up as an unresolved symbol.
> >I asked him to grep through the /usr/include looking for it, and the
> >result was nothing.
> >
> >Looking through the code I see PHP has it's own snprintf implementation,
> >and that should suffice.  Apparently zend_API.c though doesn't notice it.
> >His fix was to place <#include "php.h"> inside the file, and everything
> >worked fine.
> >
> >Does anyone have any more insight into this that they might be able to
> >share?
> >
> > >---<
> >Dan Kalowsky"A little less conversation,
> >http://www.deadmime.org/~dank   a little more action."
> >[EMAIL PROTECTED]   - "A Little Less Conversation",
> >[EMAIL PROTECTED]Elvis Presley
> >
> >
> >--
> >PHP Development Mailing List <http://www.php.net/>
> >To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>

>---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP apxs installs on AIX

[Dan Kalowsky]

Hello again list...

While scanning through some of the bugs tonight, I came across a real jem.

A large number of bugs are submitted dealing with the fact that PHP on AIX
machines does not install.  There is some minor hackery done to enable
this, and it's actually documented only through the bug system.

One user has actually made a patch against the configure script though,
and it looks legit enough.  I did run into a problem though, converting
the configure script changes back into ltmain.sh changes.  Can anyone more
familiar with the build system look at this patch and possibly rev-eng it
to our CVS?

The url to it is:
http://tclab.kaist.ac.kr/~cmlee/pub/php-4.2.2-20020730.patch

>-------<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 4.2.3

[Dan Kalowsky]

Hrm, well a lot of the fixes I've been doing have only gone to head
because the belief of no 4.2.3.

There are still a few outstanding bugs I'd like to see fixed before things
we RC.  Sfox and I (mostly her though) have been looking at the dbm_*
functionality on Windows.  We're questioning if it ever worked at all.

I can run through a list if there is a desire to see one.

On Sat, 17 Aug 2002, Zeev Suraski wrote:

> I'd like to raise the option of releasing 4.2.3 again.  I believe that it
> would be quite a while before 4.3.0 is out, and there are quite a few fixes
> in the 4.2 branch that should make the userbase as soon as possible,
> especially the Windows userbase.
> I think that releasing 4.2.3 can be done within approximately one week,
> with one RC, barring unexpected surprises.
> Opinions?
>
> Zeev
>
>
>

>-------<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 4.2.3

[Dan Kalowsky]

I have to disagree, a LOT of bug fixes have gone in.

Honest I can run through the list of things I think should be done, and a
list of things that I think should be back ported.  None of it is new
functionality, all of it is fixes to bugs.

And I still think the Tru64/AIX issues will need to be solved as well.

On Sat, 17 Aug 2002, Zeev Suraski wrote:

> I'd really like to avoid waiting this time, though (the enemy of good is
> better...).  Even if we release 4.2.3 as it is in the branch, without any
> further fixes, it's significantly better than 4.2.2.
>
> Translating this into action - my personal preference is to release the RC
> as early as tomorrow.
>
> Zeev
>
> At 16:20 17/08/2002, Dan Kalowsky wrote:
> >Hrm, well a lot of the fixes I've been doing have only gone to head
> >because the belief of no 4.2.3.
> >
> >There are still a few outstanding bugs I'd like to see fixed before things
> >we RC.  Sfox and I (mostly her though) have been looking at the dbm_*
> >functionality on Windows.  We're questioning if it ever worked at all.
> >
> >I can run through a list if there is a desire to see one.
> >
> >On Sat, 17 Aug 2002, Zeev Suraski wrote:
> >
> > > I'd like to raise the option of releasing 4.2.3 again.  I believe that it
> > > would be quite a while before 4.3.0 is out, and there are quite a few fixes
> > > in the 4.2 branch that should make the userbase as soon as possible,
> > > especially the Windows userbase.
> > > I think that releasing 4.2.3 can be done within approximately one week,
> > > with one RC, barring unexpected surprises.
> > > Opinions?
> > >
> > > Zeev
> > >
> > >
> > >
> >
> > >---<
> >Dan Kalowsky"A little less conversation,
> >http://www.deadmime.org/~dank   a little more action."
> >[EMAIL PROTECTED]   - "A Little Less Conversation",
> >[EMAIL PROTECTED]Elvis Presley
>

>---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 4.2.3

[Dan Kalowsky]

I disagree that it should go out as is, very strongly at that too.

Some fixes not in the 4.2 branches:

- ODBC no longer crashes on Windows upon unloading
- while not fully tested, ext/java now works for 1.4 JDK's
- various memory leak fixes provied by Ilia (pack being one of them)
- a few misc fixes for Win32 platforms
- nsapi build fix which allows it to build and reported run again
  (although I still think we need to decide if we can kill this support)
- numerous domxml bug fixes have been added as well.
- QTDOM fix to allow it to compile again and run again

This is one yet to be made, but:
- a potential fix to have 'make install' work on AIX machines again
  finally.

These are just bug fixes.  I don't want to see new functionality added to
PHP for a potential 4.2.3, but I do want to see a LOT of these bugs
squished.  There is a fix, why go and release another version of PHP with
known and non-fixed bugs in it?

It still doesn't seem to compile and work on 64-bit arch's.

But yet again, there are numerous reasons why we should move to release
PHP 4.3.  The biggest of which in my book is, it supports OSX!  While
possibly a minor issue to many of the users on this list, it's becoming a
more significant issue, especially with Jaguar/10.2 being released in a
few days.  There have been numerous fixes to all the code bases in an
effort to get support for OSX implemented into them (ext/java still being
a bastard).


On Sat, 17 Aug 2002, Zeev Suraski wrote:

> I think it makes good sense to release 4.2.3 as-is (after a short QA cycle,
> that will ensure we didn't introduce any new bugs).  If 4.2.3 becomes a
> larger project, with more pre-requisites, I don't see it happening ("if it
> will not be simple, it will simply not be").
> The last time around 4.2.3 died was exactly due to this issue.
>
> Zeev
>
> At 16:47 17/08/2002, Dan Kalowsky wrote:
> >I have to disagree, a LOT of bug fixes have gone in.
> >
> >Honest I can run through the list of things I think should be done, and a
> >list of things that I think should be back ported.  None of it is new
> >functionality, all of it is fixes to bugs.
> >
> >And I still think the Tru64/AIX issues will need to be solved as well.
> >
> >On Sat, 17 Aug 2002, Zeev Suraski wrote:
> >
> > > I'd really like to avoid waiting this time, though (the enemy of good is
> > > better...).  Even if we release 4.2.3 as it is in the branch, without any
> > > further fixes, it's significantly better than 4.2.2.
> > >
> > > Translating this into action - my personal preference is to release the RC
> > > as early as tomorrow.
> > >
> > > Zeev
> > >
> > > At 16:20 17/08/2002, Dan Kalowsky wrote:
> > > >Hrm, well a lot of the fixes I've been doing have only gone to head
> > > >because the belief of no 4.2.3.
> > > >
> > > >There are still a few outstanding bugs I'd like to see fixed before things
> > > >we RC.  Sfox and I (mostly her though) have been looking at the dbm_*
> > > >functionality on Windows.  We're questioning if it ever worked at all.
> > > >
> > > >I can run through a list if there is a desire to see one.
> > > >
> > > >On Sat, 17 Aug 2002, Zeev Suraski wrote:
> > > >
> > > > > I'd like to raise the option of releasing 4.2.3 again.  I believe
> > that it
> > > > > would be quite a while before 4.3.0 is out, and there are quite a
> > few fixes
> > > > > in the 4.2 branch that should make the userbase as soon as possible,
> > > > > especially the Windows userbase.
> > > > > I think that releasing 4.2.3 can be done within approximately one week,
> > > > > with one RC, barring unexpected surprises.
> > > > > Opinions?
> > > > >
> > > > > Zeev
> > > > >
> > > > >
> > > > >
> > > >
> > > > >---<
> > > >Dan Kalowsky"A little less conversation,
> > > >http://www.deadmime.org/~dank  a little more action."
> > > >[EMAIL PROTECTED]   - "A Little Less Conversation",
> > > >[EMAIL PROTECTED]Elvis Presley
> > >
> >
> > >---<
> >Dan Kalowsky"A little less conversation,
> >http://www.deadmime.org/~dank   a little more action."
> >[EMAIL PROTECTED]   - "A Little Less Conversation",
> >[EMAIL PROTECTED]Elvis Presley
>

>---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] 4.2.3

[Dan Kalowsky]

On Sat, 17 Aug 2002, Zeev Suraski wrote:

> PHP x.y.z has known bugs that are not fixed, for any given x, y and z,
> since forever, and until the of time.  Realize that, and decisions become
> much simpler.

Yes, but again many of these fixes were not applied to the 4_2 Branch
because we had been informed that it was dead, long live the 4_3 upcoming
branch.

That may have been my fault for not appling many of them anyways.

>-------<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RE: [PHP-QA] RE: [PHP-DEV] 4.2.3

[Dan Kalowsky]

Because we aren't always sure what the next version will be.  Witness the
4.0.6-4.0.7/4.1 release process.



On Sat, 17 Aug 2002, Liz wrote:

> > there should be 'fixed in the next bug-fix release' or 'fixed
> > in the next
> > semi-major release'.
>
> How about
>
> Will be fixed in version major.minor.buildrelease ?? ie tell them which
> version it will be fixed in, no confusion at all then
>
>
>

>---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] odbc_primarykeys return type

[Dan Kalowsky]

Hi Kevin

On Sun, 18 Aug 2002, Kevin Gordon wrote:

> The first two functions return "resource" and the second two functions
> return "int". Is there any difference?

In this case, not really.  I think I should probably update some of the
documentation it seems.

> Using a postgresql database odbc_tables works fine. But with
> odbc_primarykeys I can not find a result.

Either A) you've found a bug, or B) you're using it wrong.  I'm going to
guess B at this time as it does seem to work.  Although there is an open
bug about it not working for others.

>-------<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP apxs installs on AIX

[Dan Kalowsky]

On Sat, 17 Aug 2002, Jani Taskinen wrote:

> It's a bug in libtool. It would be best for everyone (not only PHP project)
> that it's fixed in it..

Good to have you back.  :)  Thanks, and will do.

>-------<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Dan Hardiker]

>> But the real issue here is about session hijacking.  Yes, of course
>> people can send whatever session id they want to PHP.  Since the
>> session id comes from the user we need to accept what is sent.
>
> This is what I consider unconceivable.
> Why ever should  tickets issued  by the user be accepted,  to what pro?
> Something clashes here with that 'very umpredictable dedicated device'.
> I'd prefer no acceptance of user provided id, if not where expressely
> configured.

There is a simple solution, make sure your the one generating the IDs, and
upon each "proper" session start (where no session id is passed in) set a
session "I started this session" variable. If a session ID has been passed
in, then check for that variable, if it exists - continue, if not then
show an error message.

Note: you will experiance the same problem if the session times out.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Dan Hardiker]

> look at the opcodes for:
>
> a(b(c()));
>
> function a() {}
> function b() {}
> function c() {}
>
> and tell me which function is called from which scope. unless
> you know something i dont youll see
> a()
> b()
> c()
>
> which is wrong as the correct call-order is
> c()
> b()
> a()

That makes sense to me, as in order to pass a value to a, it must execute
b to get the parameter, and before it can do that it needs to execute c in
order to pass the param to b ... so the it turns out c,b,a.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

[Dan Hardiker]

> Lack of momentum
> is the  main reason PHP releases are taking several weeks now.  It's not
> as if  people are testing it thoroughly for weeks and weeks...

I have a dev box I can test my installation setup on with dev releases of
PHP ... where do I sign up? (If needed)


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PECL compilation

[Dan Helfman]

Perhaps I just haven't looked hard enough, but I can't find any
information on how PECL software is supposed to be compiled (in CVS).
Most PECL packages just have a config.m4 and a Makefile.in, but no
configure.in, build.sh, etc. I'm adding a new PECL package and would
like it to play nicely with the rest of the repository. Any help would
be much appreciated.

-- 
Dan Helfman
Software Engineer, TrustCommerce
(626) 744-7700 x813
[EMAIL PROTECTED]
http://www.trustcommerce.com

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PECL compilation

[Dan Helfman]

Thanks.. I didn't realize the PEAR installer worked on PECL packages
currently.

On Mon, 2002-08-19 at 13:46, Tal Peer wrote:
> You could also use the latest version of the PEAR installer, of course.
> 
> -Tal
> 
>  Original Message 
> From: Rasmus Lerdorf <[EMAIL PROTECTED]>
> To: Dan Helfman <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] PECL compilation
> Date: Mon, 19 Aug 2002 13:01:20 -0700 (PDT)
> 
> > run phpize in the extension's dir
> > 
> > On 19 Aug 2002, Dan Helfman wrote:
> > 
> > > Perhaps I just haven't looked hard enough, but I can't find any
> > > information on how PECL software is supposed to be compiled (in CVS).
> > > Most PECL packages just have a config.m4 and a Makefile.in, but no
> > > configure.in, build.sh, etc. I'm adding a new PECL package and would
> > > like it to play nicely with the rest of the repository. Any help would
> > > be much appreciated.
> > >
> > > --
> > > Dan Helfman
> > > Software Engineer, TrustCommerce
> > > (626) 744-7700 x813
> > > [EMAIL PROTECTED]
> > > http://www.trustcommerce.com
> > >
> > > --
> > > PHP Development Mailing List <http://www.php.net/>
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > 
> > 
> > -- 
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
-- 
Dan Helfman
Software Engineer, TrustCommerce
(626) 744-7700 x813
[EMAIL PROTECTED]
http://www.trustcommerce.com

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Dan Hardiker]

>> Well, more worrisome would be if a bad guy tricks you into clicking on
>> a link or simply sends you an image in an email that makes a request
>> to my server with a valid-looking session id.  Then if you go to this
>> site (that
>
> I've debunked that scenario already a few times.  The net
> result is that this class of attacks is impossible to
> prevent.
>
> The assumption in your scenario and the following is this:
>
> The attacker has access to a script X which calls
> session_start().
>
> My scenario:
>
> 1.) Attacker A accesses X and stores the SID which PHP assigns to
> him.
>
> 2.) A crafts a link containing SID and sends it to victim V.
>
> 3.) A keeps SID alive by repeatedly accessing X using SID.
>
> 4.) V opens link and authenticates.
>
> 5.) A's script notices (4).  A can overtake V's session.

Ive extended the session handling so that upon session start, it takes a
snapshot of the browser string (and maybe a couple of other
javascript-retrieved variables about the user's os, eg: the resolution)
and build up as much of a picture of the client as possible.

Then store this with the session id, and each time its loaded, check that
the system hasnt changed. Ive found that (although all the data can be
faked) that the browser string alone causes alot of grief - especially as
IE's browser string is changed by many plugin programs.

Just a thought.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Dan Hardiker]

> On Tue, 20 Aug 2002, Andi Gutmans wrote:
>> I still think it shouldn't go in. This is the only feature in Engine 2
>> which might make non-OOP people convert. Once this isn't in Engine 2 we
>> don't have a carrot for them.

[..]

> I'm +1 for getting this backtrace thing in PHP asap. It's more
> useful for my work than any of that OOP stuff ZE2 has. And I'd
> rather have it now than wait indefinately for PHP 5 to be released.
>
> --Jani

If the code wont be committed to the main PHP 4.x download, can a patch be
provided for those of us gagging for backtracing in our php development.
The amount of time it would save me is phenomninal.

Today I found a bug in my 5 meg (accumulative) scripts, all of which use a
$mysql->query() method. The error shows up as being thrown in the query,
but I have no idea out of the tens of thousands of lines of code which
called it. A backtrace in this case would be like gold dust.

Could we not just release a patch to the people that want it (well, need
it!), and leave the "official implementation" until PHP5? That way the
carrot remains, but nothing is held back from the people who desperatly
want it.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Dan Hardiker]

> It is also very conceivable that a person would send a link to a java
> applet or any other kind of wrapper (PHP or other CGI actually would be
> able to establish the connection on the server side always sending the
> same user agent string and sending back the data from your site) to
> establish the session in which case this is rendered useless.

So because its not flawless, we shouldnt try to get as close to perfection
as we can?

I know its not water-tight by any stretch of the imagination, but the more
checking in there, the harder it is for hackers to get the foot in the
door and penetrate. The more abstract the system is (especially on a site
by site basis) the more work a cracker has to do to work out how a host is
authenticated.

At the end of the day, nothing from the client can be trusted - nothing.
So we are never gonna reach perfection when the client is involved in
relaying information.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Dan Hardiker]

[..]

>> >Besides whos to say that
>> >adding debug_backtrace now to 4.3 won't steer more people to php
>> instead of other envrionments.
>>
>> I'm willing to be the first person to say this if no one beats me to
>> it...  Such a featurelet steering people to choose one
>> technology/platform  over the other?
>
>  In one case ive heard someone didn't choose php becuase it doesn't
> support MI.
> Now ive heard this from a "not very smart programmer" but that was the
> decision. I know that thats absoulty obsurde but something like php
> doesn't support backtraces may or maynot lean someone twards php. I konw
> this isn't the majority but maybe a handfull.

Ive taken systems which I would have prefered to have done in PHP away
from PHP (in that case I moved to Java for the stack tracing - because the
code was used so much inside itself it was impossible to bug trace -
especialy when the code was evaling heh).

PHP is my forte and I would have prefered to do it with the language I
know best and love. However - purely based on not having a backtrace I had
to move.

NOTE: At the time I was unaware of the existance of anything that could be
plugged into PHP to do this... and this was 5 months ago. However,
regardless of time frame - fact is that I moved because of the lack of a
feature... one that is availiable to us, but were not putting in out of
politics.

[..]

>  Obvisouly we all have our own opnion I wanted to state mine not get in
> a big
> argument about this. I do see your point, as a zend2 advocate, and im
> sure you see mine too, as a php user who wants debug_backtrace. So what
> to do, do you just call the shots or do we have an offical vote?

If there is a vote, Im +1 on the idea of a backtrace into the earliest PHP
release possible.

-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Dan Hardiker]

>>  Obvisouly we all have our own opnion I wanted to state mine not get
>> in a big
>>argument about this. I do see your point, as a zend2 advocate, and im
>> sure you see mine too, as a php user who wants debug_backtrace. So what
>> to do, do you just call the shots or do we have an offical vote?
>
> I've never been keen on votes since we don't have any rules of voting
> anyway.  It's Thies's call, I'll live with either call.  I just hope
> that  if this feature finds itself in 4.x, this lengthy thread will at
> least  prevent other features from being backported.

I dont think anyone on this list, or in the PHP community is trying to
make ZE1 a clone of ZE2 via backporting. This is a pretty unique case
where a feature of ZE2 deserves backporting due to its immense benifits to
the active community.

If there was 1 feature, and 1 feature alone I could choose from ZE2 to
backport, this would be it. I can gaurentee it will make christmas come
early for many "top end" PHP developers coding the more advanced systems.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 4.3 and PHP 5

[Dan Kalowsky]

Adding to the ever expanding list...

On Wed, 21 Aug 2002, Sterling Hughes wrote:

> > Hi all,
> >
> > Following on from the recent debug_backtrace discussion, and the
> > discussion about just what we are releasing next and so on, I'd just
> > thought I would make a couple of comments about PHP 4.3 and about what
> > I think (IMHO) should be the goals of PHP 5.
> >
> > I'm currently reviewing the streams code, to make sure that the API is
> > good enough for a release: there are a couple of things that I want to
> > tidy up ready for PHP 4.3:
> >
> > o Add a "set-blocking-flag" method to the generic stream operations,
> >  So that non-blocking IO can be enabled on any stream that it makes
> >  sense to do so. (IIRC, there is a bug in the DB, or this deficiency
> >  was mentioned on the list).
> >
> > o Tidy up persistent streams support. (I need some help from someone
> > that
> >  really knows what they are doing here).  This is important, because
> >  I'm not sure that persistent sockets (pfsockopen) are actually working
> >  in HEAD ATM.
> >
> > o Implement a filter API, so that filters can be stacked over a stream.
> >  I've mentioned this before; it will be useful to stack things like
> >  base64, charset conversion, zlib/bzip compression and crypto over a
> >  stream - potentially multiple filters.  I don't think that this will
> >  take too long to implement (perhaps by the weekend).
> >
> > o Implement stat() and readdir() for ftp.  I think http will be "too
> > hard"
> >  to achieve in time for 4.3.
> >
> > PHP 5
> > -
> >
> > Zeev raised the issue of figuring out what we want to be in PHP 5.
> > Well, I can't think of (m)any fancy new features for PHP 5 that we
> > haven't already got in HEAD, but to get the ball rolling, this is my
> > take on how PHP 5 could/should look:
> >
> > Current HEAD, stabilized.  This includes things like the new build
> > system, streams, enhancements to post/file uploading, domxml and so on.
> > ZE2, feature complete.  (New OO, better rpc/com/java, try/catch,
> > delegation, etc. etc.)
> >
> > To me, that sounds really pretty good.  Yes, it's just HEAD with ZE2,
> > but I think it's almost what will be PHP 5.  A couple of additions that
> > would make it more attractive:
> >
> > o PEAR/PECL CA fully established.  I know that we are aiming to get
> > this off the ground for PHP 4.3, but I'm sure we can improve it for PHP
> > 5.
> >
> > o Bundle Brads php-soap extension, and "market" PHP 5 as being "Web
> > Service Enabled".
> >
>
>
> o Finish off Harald's RPC extension, which should provide "Seemless" web
> services.  Move Brad's extension into PEAR/PECL, for those people who need
> to use soap in a manly, yet sexy way.
>
> o We really need some people to look at PHP's XML support.  Yeah, currently,
> it kinda-sorta works, however, we can really do it better.  I suggest using
> the DOMXML extension as a base (so much work has been done already).  Test
> strongly, Add full LibXML support, standardize the API to DOM's api, and
> bundle libxml & libxslt with PHP version 5 (removing expat bundling).
>
> o See if we can get cURL bundled for PHPv5.
>
> o In that vein, get a proper standardized bundling scheme setup, that makes
> it easy to bundle/unbundle software with PHP.

 o Update ODBC to v 3.7 support.  The current v2 support just doesn't cut
it anymore with users wanting to use IMAGE, TEXT, NTEXT, and other various
large data field types, and unicode.  I started this, but my resource
books were ummm... acquired by another and never returned.

 o Decide if we are or are not going to support the iPlanet system.  If we
are, it needs to be drastically fixed, if we're not we need to drop it.
Really.  Look at the bug reports.

>---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 4.3 and PHP 5

[Dan Kalowsky]

On Wed, 21 Aug 2002, Shane Caraveo wrote:

> It should simply be marked EXPERIMENTAL, but not removed.  On the other
> hand, it doesn't have to be included in the distribution if it simply
> does not work correctly.

It's apparently been broken since 4.0.5.  I did a little bit of patching
it up so that it actually compiles and put these fixes into PHP_4_2_0 and
HEAD, but nothing is ensuring that it works with completely.

>-------<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 4.3 and PHP 5

[Dan Kalowsky]

On Wed, 21 Aug 2002, Pierre-Alain Joye wrote:

> Works well in 4.1.1 :
>
> on : SunOS argiope 5.8 Generic_108528-05 sun4u sparc SUNW,Ultra-250

You are the first to report back that I've seen/heard from stating it
works.  You're even on one of the two major difficulty platforms.

Now try using 4.2 ;)

>-------<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 4.2.3

[Dan Kalowsky]

Any of you who have done some 64bit fixes, may want to check the PHP_4_2_0
branch out and ensure that they are backported.  A number of commits went
on in CVS, and not all of them mention if they fix compile errors for
64bit platforms or only for 32bit (or even both).

Anyhow just look.

On Thu, 22 Aug 2002, Zeev Suraski wrote:

> As per Dan K, most of the important bug fixes were backported to the 4.2
> branch (thanks everyone!)
>
> I'll pack 4.2.3RC1 tomorrow morning, so if anybody has any last minute bug
> fixes to put in, now's the time!
>
> Zeev
>
>
>

>-------<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] developing with php

[Dan Hardiker]

> Why not use an additional heading
> PHP developers list - A list for developers using and programming with
> PHP direct above the heading of the other developers lists?
>
> marcus

This still isnt all that clear to me... what about putting

 "PHP developers list - A list for developing the PHP scripting language."

making it much clearer of the purpose.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Sablot / XSLT extension functional in 4.3.0-dev?

[Dan Hardiker]

Hi All,

Im trying here as a last resort as the PHP General list didnt provide much
help, and I suspect something to be wrong.

I am trying to compile Sablot XSLT support into PHP-4.3.0-dev (from CVS)
but Im getting no errors, no warnings, but no Sablot support. The
configure command Im using is displayed on the webpage:

 http://dipsy.dapond.net/phpinfo.html

Is it normal for a module to fail inclusion, but not cause any error
reporting?


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Sablot / XSLT stability (httpd segfault?)

[Dan Hardiker]

Hi all,

After finally getting Sablot to compile itself in (silly mistake), I find
that the following code causes the line in /var/log/messages:

  [..] /kernel: pid 15070 (httpd), uid 65534: exited on signal 11

repeated numerous times. The script Im running is as follows:

  $xslt = new stdClass;
  $xslt->processor = xslt_create();
  $xslt->xsl = implode("\n",file($xsl));
  echo "Begin Processing";
  $xslt->output = xslt_process($xslt->processor, $xslt->xsl, $xml, &$err);
  echo "Processed Successfully";
  xslt_free($xslt->processor);

The xslt_create command is executed fine, returning a Resource ID #5, the
$xslt->xsl contains a valid XSL document (correctly parsed by IE6), $xml
contains the XML document to transform (correctly parsed by IE6). The line
that is dying is the xslt_process line.

I have no clue how to debug this, Ive heard of doing a "backtrace" but am
unsure of how to do this. Im running FreeBSD v4.6 with PHP v4.3.0-dev
(from CVS) - a URL to info on how to provide more accurate bug information
would help (or a set of instructions).

Thanks.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/exif config.m4

[Dan Kalowsky]

I'll throw my -1 on adding anything to be enabled by default.  I've argued
this before, and I will continue to argue for less things to be enabled by
default.

On Thu, 29 Aug 2002, Jani Taskinen wrote:

> On Wed, 28 Aug 2002, Marcus Börger wrote:
>
> >>Having exif not enabled by default doesn't harm development at all. If
> >>people want exif, they can enable it just fine. Adding more 'bloat'
> >>(this has nothing to do with the usefulness) to the default compilation
> >>is not a good thing, for example we could have enabled sockets, sysvshm,
> >>sysvsem... too by default.
> >>
> >>Derick
> >
> >Of cause exif doesn't affect php development in any way! I meant here that
> >PECL development must not hurt php development.
>
> -1 for enabling any extensions by default..
> Especially this kind of extensions which are not really widely
> used..
>
> --Jani
>
>
>
>

>---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] MFH -R php4/pear/* files

[Dan Kalowsky]

On Thu, 29 Aug 2002, Martin Jansen wrote:

> The original plan was to only bundle the PEAR installer and all
> packages, which are required to make it work, with PHP 4.3.0. All
> other components should stay outside and must be installed via this
> installer.

I tend to believe we should stick to this thinking.  Once we start doing
otherwise, it will become rather difficult to change course without major
user opposition.

> Anyways, the release cycle for 4.3.0 has already gone pretty far, so I
> think that this decision is over to the release masters (Zeev,
> Derick?) and Stig.

At this point in the game 4.3 will have a lot of improvements.  I would
hope that as soon as 4.2.3 is out the door, 4.3.0 enters into the RC
process (even if it takes a month or two).

>-------<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring

[Dan Kalowsky]

On Sun, 1 Sep 2002, James Cox wrote:

> I vote to remove mbstring as a default module.

+1000

> And for those who say that i could just disable it -- well, the converse is
> true. Let us STOP burdening default builds with crap that is unlikely to be
> used.

Another voice of reason!  Welcome!

>-------<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Problem with http://php.net

[Dan Hardiker]

>> P.S.
>> Offtopic sorry
>
> funny things are allowed as off topic posts :)
>
> Derick

Such as Derick's cross dressing tendancies? heh :P [sorry, couldnt resist]


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring

[Dan Kalowsky]

On Mon, 2 Sep 2002, Yasuo Ohgaki wrote:

> If we should reduce number of modules built by default, 1st
> module should be MySQL. Removing MySQL does not cause any
> technical problems at all.

I'll agree to that as well.  +1 on removing --with-mysql as a default.
Although realize I'm also +1 on removing any default modules that are not
essential to PHP's running.

> Is --disable-something is too hard to get used to?

Yes it is.  Why?  Because PHP has so many options at this point, finding
which modules are automatically enabled isn't terribly easy.  More to the
point, it's a PITA to find out during the build you forgot to explicitly
disable a feature.

In general it is easier to enable a feature than to disable a feature
(witness Clippy).

>-------<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] pread solutions needed

[Dan Kalowsky]

Please read bug:

http://bugs.php.net/bug.php?id=15983

As it states, currently non-i386 Linux boxen are having difficulty with
the session functionality.  Mainly because of the pread/pwrite functions.
The check passes, and the HAVE_PREAD/HAVE_PWRITE flags are given.

One of the users has discovered that this is actually a bug in the glibc
implementations on non-i386 machines.  There is a message (linked in the
bug report) that states this has been fixed in CVS as of Tues, 30th July
2002.  So what does the official PHP stance become?  Do we want to put a
series of #defines around this code section to make sure Linux/non-i386
doesn't use this code?  Or do we just ignore it and wait for the new glibc
code to filter down?

>-------<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] pread solutions needed

[Dan Kalowsky]

On Tue, 3 Sep 2002, Zeev Suraski wrote:

> Why do we use pread in the first place?


I don't know.  It looks like we have options for both pread and non-pread
capable systems (ext/session/mod_files.c:270).

I personally don't see any specific reason to use the HAVE_PREAD version,
if we have something that works "universally".



> At 21:27 03/09/2002, Dan Kalowsky wrote:
> >Please read bug:
> >
> >http://bugs.php.net/bug.php?id=15983
> >
> >As it states, currently non-i386 Linux boxen are having difficulty with
> >the session functionality.  Mainly because of the pread/pwrite functions.
> >The check passes, and the HAVE_PREAD/HAVE_PWRITE flags are given.
> >
> >One of the users has discovered that this is actually a bug in the glibc
> >implementations on non-i386 machines.  There is a message (linked in the
> >bug report) that states this has been fixed in CVS as of Tues, 30th July
> >2002.  So what does the official PHP stance become?  Do we want to put a
> >series of #defines around this code section to make sure Linux/non-i386
> >doesn't use this code?  Or do we just ignore it and wait for the new glibc
> >code to filter down?
> >
> > >---<
> >Dan Kalowsky"A little less conversation,
> >http://www.deadmime.org/~dank   a little more action."
> >[EMAIL PROTECTED]   - "A Little Less Conversation",
> >[EMAIL PROTECTED]Elvis Presley
> >
> >
> >--
> >PHP Development Mailing List <http://www.php.net/>
> >To unsubscribe, visit: http://www.php.net/unsub.php
>

>---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ZendEngine2 availability

[Dan Hardiker]

> Sorry if this is out of place, but is there any estimates as to when the
> famous Z2 might be ready?

There is more (accurate) information in the archives of this list, but
from what I recall, the estimates were about 6 months off.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] A little help needed - get_filename() and get_linenum()

[Dan Hardiker]

Hi All,

Im looking at developing a couple of functions which could retrieve the
current line number, and filename where ever they are put. By file name, I
mean the actual file name, not the parent (eg: the file that included this
one)... very similar to what would be outputted in a syntax error or such.

A scenario where this would be useful would be in include files:



It would also be useful for custom debug functions which dump to log files.

What Im after is a bit of help of where to start, any areas of PHP which I
can canabalise for hints / tips on doing this, examples - or even
information if this has been tried and failed / succeeded before.

also - would anyone else find this sort of functionality helpful, or is it
just me?

Thanks for any help,


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: A little help needed - get_filename() and get_linenum()

[Dan Hardiker]

Appologies :) That was a quick fix! heh

Thanks for your help,

> Hello!
>
> You probably did not see magic constants __FILE__ and __LINE__ in PHP
> manual ?
>
> Check this: http://si.php.net/manual/en/language.constants.php
>
> Cheers,
> Dejan
>
> "Dan Hardiker" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> | Hi All,
> |
> | Im looking at developing a couple of functions which could retrieve
> the | current line number, and filename where ever they are put. By file
> name, I | mean the actual file name, not the parent (eg: the file that
> included this | one)... very similar to what would be outputted in a
> syntax error or such. |
> | A scenario where this would be useful would be in include files: |
> |  |   if ($_SERVER["SCRIPT_FILENAME"] == get_filename()) {
> | die("Dont talk to me!");
> | // or a header redirect, you get the jist
> |   }
> | ?>
>
>
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] __LINE__, __FILE__ and function()

[Dan Hardiker]

Hi all,

Sorry if this isn't an interesting feature for anyone else, but it would
prove to be very useful for me. In the following test case:

";
  }

  output();
  output();

?>

The variable $line is calculated once as the start of the script (with
$line always being "3") where as the desired effect would surely be for it
to be calculated each time the function is called, with the output being
"7" and "8" respectivly.

Im guessing this is a feature of whatever handles the building / assigning
of functions, but I really dont know the php / zend source well enough to
say.

How much work would one be looking at to alter this functionality?
Are there any reasons why this hasnt already been done?

Thanks again,


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Windows builds and ftp.c

[Dan Kalowsky]

Warnings in the Windows FTP builds, which may be of concern (or may not
be):

ftp.c(650) : warning C4018 : '!=' signed/unsigned mismatch
ftp.c(1565) : warning C4018 : '!=' signed/unsigned mismatch

>-------<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Windows builds and ftp.c

[Dan Kalowsky]

Is that the general consensus still?  It seems rather odd to support it,
but not care about it.  I don't see that patch doing anything evil though
in any case.

On Thu, 5 Sep 2002, Joseph Tate wrote:

> I believe that the consensus with warnings on the windows builds is that we
> don't care.  We're not going to cast where it isn't necessary.  So you might
> want to revert your last patch.
>
> Joseph
>
> > -Original Message-
> > From: Dan Kalowsky [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, September 05, 2002 5:21 PM
> > To: PHP Development Mailing list
> > Subject: [PHP-DEV] Windows builds and ftp.c
> >
> >
> > Warnings in the Windows FTP builds, which may be of concern (or may not
> > be):
> >
> > ftp.c(650) : warning C4018 : '!=' signed/unsigned mismatch
> > ftp.c(1565) : warning C4018 : '!=' signed/unsigned mismatch
> >
> > >---<
> > Dan Kalowsky"A little less conversation,
> > http://www.deadmime.org/~danka little more action."
> > [EMAIL PROTECTED]- "A Little Less Conversation",
> > [EMAIL PROTECTED]Elvis Presley
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>

>---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [BUG] bugs.php.net bugs

[Dan Kalowsky]

Yeah I've had this problem too since it's moved.  So far my answer has
been to reload the page, and it goes away.  Although I've made mention of
it to Derick and Jani.

On Fri, 6 Sep 2002, Devon O'Dell wrote:

> Hi All,
>
> I hope this is the right place to post this, I couldn't find a valid
> place to put this on bugs.php.net.  Please correct me if this isn't the
> right place.
>
> Browsing through the bug list, I sometimes get mysql errors when
> browsing searching for bugs using the input field at the top right.
>
> The errors are as follows:
>
> Warning: mysql_numrows(): 4 is not a valid MySQL result resource in
> /local/Web/sites/php-bugs-web/search.php on line 119
>
> and
>
> Warning: mysql_fetch_array(): 4 is not a valid MySQL result resource in
> /local/Web/sites/php-bugs-web/search.php on line 139
>
> I've recieved this twice, once searching for "FreeBSD" and once
> searching for "ming", however, it does not occur every time, and I've
> not been able to successfully reproduce it (it happens always on accident)
>
> Additionally (while I'm thinking about it), whenever I try to search the
> whole site on php.ca, I get an error stating:
>
>
> *There was an error executing this query.*
>
> Please try later.
>
> You can see this at
> http://www.php.ca/search.php?show=nosource&pattern=something_stupid
>
> Feel free to substitute anything for something_stupid (including valid
> php functions).
>
> Greetings,
>
> Devon O'Dell
>
>
>

>---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: #19286 [NEW]: header() Control Char Injection

[Dan Kalowsky]

On Sun, 8 Sep 2002, Stefan Esser wrote:

> PS: Is php-dev censored? Or why disappeared my mail about MD5/GPG signs of
> PHP 4.2.3... Is there some autofilter on "group says everytime: we do it the
> next time?"

Naw I saw it and you bug report on it.

>-------<
Dan Kalowsky"I'll walk a thousand miles just
http://www.deadmime.org/~dankto slip this skin."
[EMAIL PROTECTED]- "Streets of Philadelphia",
[EMAIL PROTECTED]Bruce Springstreen


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short tags thoughts

[Dan Hardiker]

> I'm really not enjoying the fact that short_tags is defaulted to on
> right now as I'm trying to make all my page work XHTML compliant.  This
> means that I have to put
>
> 
>
> in my pages.  This is also a pain when I'm working on pages for WAP
> devices.  I don't know if anybody else is experiencing this problem, but
>  I was wondering if there are any thoughts about making short_tags off
> by  default.

Turning short tags off would break alot of sites, especially when a "fast
echo" is used by nature. I would like to see the defaults in PHP remain
the way they are for the most part, perhaps change in 5.

It's easy to over-ride in php.ini (or perhaps one of the various default
ini files [other than php.ini-dist]), .htaccess. Any site relying on the
setting of register_globals, short_tags, or any other coding-style setting
would be bad (IMHO), without the use of .htaccess files, as you loose your
cross-installation platform base.

A repeat of the mass hysteria caused by [people not reading about] the
register_globals change isnt wanted by anyone, least of all by the people
who talk on php-general@ and various other PHP help mediums.

I'm -1 on this change.

> Additionally,  sense, and  off.  It seems like  Devon

-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] #18640: compilation with Oracle fails on Tru64

[Dan Kalowsky]

Commited.

On Mon, 9 Sep 2002, Michael Mauch wrote:

> Hi,
>
> <http://bugs.php.net/bug.php?id=18640> describes the problem that some
> Oracle versions (patch levels) on Tru64 seem to have some OCILob*
> functions in the libocijdbc8 library instead of in the usual libclntsh.
>
> This makes the PHP build fail with unresolved symbols.
>
> <http://bugs.php.net/bug.php?id=14193> also seems to be related.
>
> Although this seems to be all Oracle's fault, I suggest to link against
> libocijdbc8 if it is available.
>
> I tested the patch below with Oracle 8.1.7 and 9.0.1 on Tru64 5.1,
> Oracle 8.1.6 on Tru64 4.0f, Oracle 8.1.7 on Solaris 7, and with Oracle
> 8.1.6 on Linux/ix86. Only the Oracle 8.1.x on Tru64 needed the patch,
> but I wanted to make sure that the additional library does no harm to
> the others.
>
> The patch also applies cleanly against 4.2.3, and against the current
> CVS version (HEAD) if you use --ignore-whitespace (GNU patch).
>
> Can somebody please add this? If this is not the right way to send a
> patch, please tell me.
>
> Regards...
>  Michael
>
> --- php4-STABLE-200209050900/ext/oci8/config.m4.orig  Fri Nov 30 19:59:46 2001
> +++ php4-STABLE-200209050900/ext/oci8/config.m4   Fri Sep  6 16:23:01 2002
> @@ -68,6 +68,9 @@
>
>   8.1|9.0)
> PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD)
> +   if test -f $OCI8_DIR/lib/libocijdbc8.so ; then
> + PHP_ADD_LIBRARY(ocijdbc8, 1, OCI8_SHARED_LIBADD)
> +   fi
> PHP_ADD_LIBPATH($OCI8_DIR/lib, OCI8_SHARED_LIBADD)
>         AC_DEFINE(HAVE_OCI8_TEMP_LOB,1,[ ])
> ;;
>
>
>
>
>
>

>---<
Dan Kalowsky"I'll walk a thousand miles just
http://www.deadmime.org/~dankto slip this skin."
[EMAIL PROTECTED]- "Streets of Philadelphia",
[EMAIL PROTECTED]Bruce Springstreen


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] sockets extension

[Dan Kalowsky]

Because the user can see how active such functionality is by looking at
the CVS logs, and doing a search on php-dev conversations.

While the authors have decided to mark it experimental doesn't mean it
will ever not be experimental.

Not to continue a "flame war", but this is Open Source, and it is done on
free time.  Because you the user feels you'd like to use such
functionality it's not typically a concern for the developers.  Often
times this functionality is added to make their own lives easier, or to
try an experiment with something.  Take a look at the iD software policy:
it'll be ready when it's ready.  Thats all there is to it :)


On Mon, 9 Sep 2002, NAIK,ROSHAN (HP-Cupertino,ex1) wrote:

>
> >
> > Between 15 days and 15 months.
>
> Looking at the CVS its been 19 months since the EXPERMENTAL file was last
> modified for sockets.
>
> No offense intended but, sometimes people dont seem to like to be asked such
> "obvious" questions by users. I realize that people in open source are not
> working for money but this attitude may be a little extreme.
>
> The obvious meaning behind the question was "is this piece under active
> development?".
> Users like to know such things so that they can have reasonable expectations
> from what they are using or make alternate plans. And this list is the most
> reasonable place for asking something like that.
>
> Bundling functionality into the distribution and tagging them as
> experimental...its a way of giving end users hope to see something concrete
> sooner or later...so why flame over it when the user comes back asking  "how
> it is doing" ?
>
> --Roshan
>
>
>

>---<
Dan Kalowsky"I'll walk a thousand miles just
http://www.deadmime.org/~dankto slip this skin."
[EMAIL PROTECTED]- "Streets of Philadelphia",
[EMAIL PROTECTED]Bruce Springstreen


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RFC: ODBC and PHP

[Dan Kalowsky]

To Whom It May Concern,

I've been working for the last few months (delayed often, but mostly the
last few weeks) on what I've been tenatively calling ODBC2.  Basically
this is what I'd like to see PHP v 5 have as it's default ODBC system.

Some general notes about it:

- It will break BC.  I have tried to conform and keep things the same,
but I'm not making any promises to keep BC at this time.

- It will support ODBC v 3.0 and greater only.  With the needs of many DBs
to include larger typesets (like TEXT, NTEXT, IMAGE, etc) and UNICODE, I
see this as being a necessity.

Some implementation notes:

- So far my testing is being done using iODBC, unixODBC, and Windows ODBC
drivers.  I have no way of checking any of the others... help on this
front would be appriciated.

Some of the features already added to it:

- Ability to control the ODBC environment handles before and after a
  connection is created.
- Ability to specify a CURSOR for use in statements.
- More strongly enforced safe_mode restrictions.
- The ability to connect to data sources without being defined locally.
- A user can force the PHP system to create a new connection now.
- An attempt to make the ODBC API look more like the MySQL/PostgreSQL APIs
  feature setwise.
- An option for the user to turn on which can allow dynamic sizing of a
  result set text field (currently it's static).
- Use of the default_user, default_db, and default_passwd in the php.ini.
- Hopefully more detailed error messages.
- Native support for returning results from functions, and SQL based
  constructs (outside of SELECT statements).

If you have any specific functionality you would like to see, please send
it to me, and I will see what I can do about adding this in.

I would like to add this into the current PHP system, to allow users to
start playing with and testing as well.  Well probably just as soon as I
finish some more of the odbc2_exec/odbc2_execute() cleanups.  This code is
not optimized in any way, shape, or form.  It's not even believed to work
with a lot of systems.  Because of this, I would like to hear back
commentary back on any suggested recourse from those who've done this
already.

Hopefully this will prove to be a useful change, and people will be happy
:)  As always send your comments to me.

>-------<
Dan Kalowsky"I'll walk a thousand miles just
http://www.deadmime.org/~dankto slip this skin."
[EMAIL PROTECTED]- "Streets of Philadelphia",
[EMAIL PROTECTED]Bruce Springsteen


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CVS Account Request: dan

[Dan Hardiker]

General bug fixing / tracking (to get the herds of bugs out of the way) and 
php4/ext/session.

It was suggested that I get an account a while back, but never got around to it.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: ODBC and PHP

[Dan Kalowsky]

On Wed, 11 Sep 2002, Wez Furlong wrote:

> I know this probably isn't the kind of comment you want just now, but...
> If this is to support ODBC v3+, why not call the functions odbc3_xxx instead
> of odbc2_xxx?  I think this could help prevent some head-scratching a little
> later down the track.

Well technically it's to move PHP's ODBC support further along.  I've just
been calling it ODBC2 locally here to make life easier when I talk to
other people (as in v2 of the PHP ODBC lib).

What I'm thinking I'd really like to see is ODBC move to PECL or something
like that, to allow me to keep it in a different release schedule (as ODBC
standards don't change that rapidly).  But I've heard some complaints
against such ideas, so I haven't pushed it (yet).  Anyways naming
convention can be changed very easily.

>-------<
Dan Kalowsky"I'll walk a thousand miles just
http://www.deadmime.org/~dankto slip this skin."
[EMAIL PROTECTED]- "Streets of Philadelphia",
[EMAIL PROTECTED]Bruce Springstreen


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: ODBC and PHP

[Dan Kalowsky]

On Tue, 10 Sep 2002, Shane Caraveo wrote:

> Hmm, is there no way to make the functions work with both odbc versions?
>   Have an odbc_set_version(int) function that can set the version of
> odbc to use.  The default can be version 3.  This way, with the addition
> of a single function call, scripts can provide BC.

This is a tricky question really.  Theoretically, yes it should be
possible to allow this.  You may run into issues with some of the result
sets, but the connections should still be the same.  You couldn't really
do it with a function like odbc_set_version, as my understanding of ODBC
states you must declare which version type you are using at compile time.
If you have some documentation stating otherwise, I'd be interested in
reading it.

The reality is, I don't know.  All ODBC3 drivers should be able to utilize
the deprecated functionality just fine, but the mapping is an unknown
and dependent upon vendor implementation.  Going the other way, of course,
is not going to work.

But I don't see a reason to keep such BC at this point.  The problem with
the current system can be seen with bugs in the result sets.  The one
area specifically mentioned above.  Users are still going to ask "Why
doesn't my select work?" while using NTEXT or something non-compliant.
The CURSOR type cannot be changed with the current system.  This in itself
leads to a slower implementation, a (unnecessarily) larger memory
footprint, and in DB2 systems a memory leak.

Hey at least I haven't gone as drastic as I originally thought, and asked
to drop support specific for things like DB2, Solid, Empress, etc, and
only support multi-driver systems (unixODBC, i-ODBC, and Windows ODBC).  :)
Although I still think that would make the most sense and be the easiest
to support on our end of things.

>-------<
Dan Kalowsky"I'll walk a thousand miles just
http://www.deadmime.org/~dankto slip this skin."
[EMAIL PROTECTED]- "Streets of Philadelphia",
[EMAIL PROTECTED]Bruce Springsteen



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: ODBC and PHP

[Dan Kalowsky]

On Tue, 10 Sep 2002, Shane Caraveo wrote:

> Ok, then I would be for ODBC 3 for PHP 5 as the standard.  An ODBC 2
> extension can be shuttled out to PECL for those who may need it.  But
> for BC issues, there is still the nameing convention.  I would personaly
> prefer that the odbc functions stay odbc_*, rather than to start
> iterating through odbc2...odbc3 and so forth.  Don't know an easy
> solution right now.
> Shane

Shane, I agree that the naming convention should stay the same.  I'm only
calling it that now so I can test it and reference it with other people.
:)

>
> Dan Kalowsky wrote:
> > On Tue, 10 Sep 2002, Shane Caraveo wrote:
> >
> >
> >>Hmm, is there no way to make the functions work with both odbc versions?
> >>  Have an odbc_set_version(int) function that can set the version of
> >>odbc to use.  The default can be version 3.  This way, with the addition
> >>of a single function call, scripts can provide BC.
> >
> >
> > This is a tricky question really.  Theoretically, yes it should be
> > possible to allow this.  You may run into issues with some of the result
> > sets, but the connections should still be the same.  You couldn't really
> > do it with a function like odbc_set_version, as my understanding of ODBC
> > states you must declare which version type you are using at compile time.
> > If you have some documentation stating otherwise, I'd be interested in
> > reading it.
> >
> > The reality is, I don't know.  All ODBC3 drivers should be able to utilize
> > the deprecated functionality just fine, but the mapping is an unknown
> > and dependent upon vendor implementation.  Going the other way, of course,
> > is not going to work.
> >
> > But I don't see a reason to keep such BC at this point.  The problem with
> > the current system can be seen with bugs in the result sets.  The one
> > area specifically mentioned above.  Users are still going to ask "Why
> > doesn't my select work?" while using NTEXT or something non-compliant.
> > The CURSOR type cannot be changed with the current system.  This in itself
> > leads to a slower implementation, a (unnecessarily) larger memory
> > footprint, and in DB2 systems a memory leak.
> >
> > Hey at least I haven't gone as drastic as I originally thought, and asked
> > to drop support specific for things like DB2, Solid, Empress, etc, and
> > only support multi-driver systems (unixODBC, i-ODBC, and Windows ODBC).  :)
> > Although I still think that would make the most sense and be the easiest
> > to support on our end of things.
> >
> >
> >>---<
> >
> > Dan Kalowsky"I'll walk a thousand miles just
> > http://www.deadmime.org/~dankto slip this skin."
> > [EMAIL PROTECTED]- "Streets of Philadelphia",
> > [EMAIL PROTECTED]Bruce Springsteen
> >
> >
> >
>
>

>---<
Dan Kalowsky"I'll walk a thousand miles just
http://www.deadmime.org/~dankto slip this skin."
[EMAIL PROTECTED]- "Streets of Philadelphia",
[EMAIL PROTECTED]Bruce Springsteen


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] highlight_file modification

[Dan Hardiker]

[..]
> something I (and others) thought would be cool is line numbering
> for highlight_file (aka show_source).
[..]
> Devon

+1 from me

Line numbering on show_source output is always useful! Especially when in
a chat room your debugging someone elses code and you have to refer to
"that if statement halfway down the page" heh.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] highlight_file modification

[Dan Hardiker]

>> The other option is just making it work with line numbering
>> regardless. This won't break any scripts, just make them have line
>> numbers instead.
>
> This is not a good idea, many may find line-numbers useless in some
> cases/scripts...
> I agree that it would be an great idea to make it an optional parameter,
> and NOT in the ini file :)
>
> This applies in both highligt_file, show_source and highlight_string

I disagree entirely. In many cases, line-numbers are invalible to
assisting people / even reading source code on multiple pages. If the
attempt of showing the source and syntax highlighting it is to give a
read-only "in editor" feel, how many people work with line numbers
switched off now-a-days (but agreed, this is down to personal preference).

I believe the default should be its current behaviour (for backward
compatability, and to prevent unexpected change)... but I do think there
should be an ini option so that .phps files can have this functionality.

Real world example:

A user comes into one of my help channels and screams "my script aint
working, whats wrong". Instead of getting them flooding the screen with
irrelevant cut's n paste's or leaving myself open to accepting files from
people I dont trust (or even know), .phps files are the quickest, easiest
and most effective way of supporting a person in this sort of scenario. In
#php on irc.dal.net, we see this kind of problem hourly, if not more
regularly than that.

Having line numbers on a .phps file would enable us to support users MUCH
better just by asking them to rename the file from .php to .phps and give
us the URL. We then say "your missing a ; on line 52". Much easier than
trying to navigate them to the "if halfway down the screen".

If you can think of an alternative way to enable / disable the
modifications suggested other than using a php.ini entry...  ;)



Sorry guys, but this sort of functionalty enabled in the .phps would make
my life (and anyone else who works with PHP developers) alot easier - and
benifit many. Personally I cant think of a reason *not* to have the
numbers.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] highlight_file modification

[Dan Hardiker]

> The feature should be implemented in PHP, but not active by default. It
> should be controlled by php.ini and this value should be overwrited by
> the optional parameter in the functions.. how's that?

I think it should be switched on by default, if possible, because it is
only going to help support if the majority of installations (especially
hosters) switch it on. If its not switched on, its not going to help the
people in support channels because the feature wont be activated.

If anyone can give me some good reasons why having this extra
(unintrusive) feature on by default would be a problem to the majority (or
even 30%) of the PHP using population, then I might agree that it should
be defaulted to off.

Personally Im of the mind that, if it doesnt hinder you, it can only help.

> The only reason for even using php.ini for this, is because of phps

Agreed


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php