[PHP-DEV] Bug #10898 Updated: is_dir && filetype return wrong values

[yves]

ID: 10898
User Update by: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Filesystem function related
Operating system: Win ME & Win NT 4.0
PHP Version: 4.0.5
Description: is_dir &&  filetype return wrong values

Hello,

than the docs in my book are wrong, it says file instead of path. Sorry for wasting 
your time...

Previous Comments:
---

[2001-05-16 10:53:13] [EMAIL PROTECTED]
this is bogus. you have to either chdir() into the $parent or is_dir() the full path.

---

[2001-05-16 08:35:02] [EMAIL PROTECTED]
A little script that should echo alle filetypes of all files in any subdir of the 
parent provided. 
Now I use opendir to test wether the file is a dir, but this isn't a good solution, is 
it?

The is_dir() allways returns false
the filetype() allwyas returns dir




---

[2001-05-16 06:23:07] [EMAIL PROTECTED]
Please provide a short script so that we can reproduce it.

Derick

---

[2001-05-16 05:44:07] [EMAIL PROTECTED]
Hello,

I'm running php 4.0.5 on my win ME & Win NT 4.0 and I have experienced 2 functions 
returning the wrong values. I don't know if this bug is allready reported.

the is_dir() allways returns false except for "." && ".."
the filetype() allways returns dir

---


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


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

Re: [PHP-DEV] Re: [PHP-QA] PHP 4.0.6RC1 ready for testing

[Petr Cech]

On Wed, May 16, 2001 at 09:06:48PM -0400 , Mike Robinson wrote:
> 
> 
> > -Original Message-
> > From: Zak Greant [mailto:[EMAIL PROTECTED]]
> > Sent: May 15, 2001 3:27 PM
> > To: [EMAIL PROTECTED]; Andi Gutmans; [EMAIL PROTECTED]
> > Subject: [PHP-DEV] Re: [PHP-QA] PHP 4.0.6RC1 ready for testing
> > 
> > 
> > Andi wrote:
> > > I rolled 4.0.6RC1. It is ready for testing.
> > > http://www.php.net/~andi/php-4.0.6RC1.tar.gz
> > >
> > > Please everyone take sometime to make sure this is release worthy :)
> > 
> > Hurray! :)
> > 
> > Successful build on Mandrake 7.1
> > Basic scripts run w/o issues
> 
> The gd support in 4.0.6RC1 got a little broken.
> Building snapshot php4-200105060945 against a
> copy of gd-1.8.3 with gif support hacked in, php
> builds fine and phpinfo() shows:
> 
> GD Support enabled 
> GD Version 1.6.2 or higher 
> FreeType Support enabled 
> FreeType Linkage with TTF library 
> T1Lib Support enabled 
> GIF Support enabled 
> JPG Support enabled 
> PNG Support enabled 
> WBMP Support enabled

I've build php4 yesterday and it's OK. Note, that it's gd 1.8.3 without gif
support. it has the above without the gif.

Petr Cech
P.S. must remeber to upload
-- 
Debian GNU/Linux maintainer - www.debian.{org,cz}
   [EMAIL PROTECTED]

* Joy notes some people think "Unix" is a misspelling of "Unics" which is a 
misspelling of "Emacs" :)

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

Re: [PHP-DEV] issues about domxml in 4.0.6

[Sterling Hughes]

Christian Stocker wrote:

> On Yesterday, Colin Viebrock wrote:
> 
> 
>>>I've contacted Uwe, and if he doesn't object (or respond ;) within the
>>>next day or so, I'll revert the commit in the 4_0_6 branch (leaving head
>>>alone).
>>>
>>Whoa.
>>
>>Are you saying that 4.0.6 will revert to the domxml "syntax" that was in
>>4.0.4 and previous?  And that 4.0.5 will just have it's own "syntax"?
>>
> 
> no, i don't think, either, that this would be a good idea. but in 4.0.5
> the "old" and the "new" syntax worked (i'm not sure what's really old and
> what's new). so if i want to get the childrens of a root domNode
> i could write:
> 
> $children = domxml_children($root); (the old method ?)
> or
> $children = $root->children; (i assume the new one...)
> 


More accurately i believe:

$children = $root->children();
to
$children = $root->children;

I could be wrong though.


> in 4.0.5 both worked. in 4.0.6 only the second works, the first causes
> a segfault... and segfaults are very annoying for debugging php-code (and
> maybe some coders even don't know, where their error_log file is to look
> for segfaults...)
>


Well the commit I plan on reversing in the branch what happened during 
4.0.6-dev, I got permission from Uwe, so I'll go ahead and do that.

-Sterling


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

[PHP-DEV] CVS Account Request

[CVS Account Request]

Full name: one senn
Email: [EMAIL PROTECTED]
ID: 8866
Purpose: learn.

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

Re: [PHP-DEV] issues about domxml in 4.0.6

[Christian Stocker]

On Yesterday, Colin Viebrock wrote:

>
> > I've contacted Uwe, and if he doesn't object (or respond ;) within the
> > next day or so, I'll revert the commit in the 4_0_6 branch (leaving head
> > alone).
>
> Whoa.
>
> Are you saying that 4.0.6 will revert to the domxml "syntax" that was in
> 4.0.4 and previous?  And that 4.0.5 will just have it's own "syntax"?

no, i don't think, either, that this would be a good idea. but in 4.0.5
the "old" and the "new" syntax worked (i'm not sure what's really old and
what's new). so if i want to get the childrens of a root domNode
i could write:

$children = domxml_children($root); (the old method ?)
or
$children = $root->children; (i assume the new one...)

in 4.0.5 both worked. in 4.0.6 only the second works, the first causes
a segfault... and segfaults are very annoying for debugging php-code (and
maybe some coders even don't know, where their error_log file is to look
for segfaults...)

and if you compare the returned array $children from the above example in
4.0.5 and in 4.0.6 they are quite different, and that's much more annoying
for writing cross-version (what a word...) code.

If the this change stays in 4.0.6 please please at least update the
documentation and clearly state the difference between 4.0.5 and 4.0.6.

chregu


-- 
nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich
pho...+41  1 451 6021  www...http://phant.ch/chregu
mob...+41 76 561 8860  [EMAIL PROTECTED]


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

Re: [PHP-DEV] LDAP V3 Server Side Sorting

[Stig Venaas]

On Wed, May 16, 2001 at 08:52:52AM -0700, David Giffin wrote:
> 
> 
> If we are to follow the Netscape API then we should have a
> ldap_search_ext() function which we can pass the results of the
> ldap_create_sort_control(), other server side and client side controls.
> We can then incorporate "Virtual List View Control" and "Entry Change
> Notification Control" along with the rest of LDAP Version 3
> functionality.

Yes, I think it might be better to have separate functions for the
controls like I suggested in my last mail though. We then make sure to
pass the necessary controls to ldap_search_ext() in our internal C
function. Also in some cases people can set necessary controls with
the existing ldap_set_control() function.

This is easier for PHP users than having to first call
ldap_create_sort_control() etc. and call ldap_search_ext() with
results from those. They would also have to free the resources that
ldap_search_ext() will have to create. What I propose is that we
only keep the resources internally, and that they are freed in the
sort case by calling the set_server_sort.. function with an empty
attribute array. This is a matter of taste. I can try to explain
my thinking in more detail, but I don't have time for that until
next week.

Stig

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

[PHP-DEV] Bug #10918: $HTTP_POST_VARS incorrectly initialized.

[bruce]

From: [EMAIL PROTECTED]
Operating system: Linux 2.4.3
PHP version:  4.0.5
PHP Bug Type: Variables related
Bug description:  $HTTP_POST_VARS incorrectly initialized.

Array variables acquired via the POST method do not appear in the $HTTP_POST_VARS 
array unless magic_quotes_gpc is DISABLED.

For example, if one uses a checkbox array named thus:





an array variable called $fred will appear in the global namespace (assuming 
register_globals is ON). The same array variable should also appear as 
$HTTP_POST_VARS["fred"] (assuming track_vars is ON).

The BUG results in $HTTP_POST_VARS["fred'] appearing, but not as an array variable. 
That is, is_array($HTTP_POST_VARS["fred"]) returns FALSE. Further, the value of 
$HTTP_POST_VARS["fred"] is the string literal "Array" which curiously is the same 
string returned when an array variable is accessed in a scalar context.

If magic_quotes_qpc is DISABLED, this problem vanishes and the value of 
$HTTP_POST_VARS["fred"] is the anticipated array of values of selected checkboxes.

It looks to me like PHP4 is storing the result of a scalar access to the array 
variable $fred in $HTTP_POST_VARS["fred"] when magic_quotes_gpc is enabled. I think 
this qualifies as a bug.


-- 
Edit Bug report at: http://bugs.php.net/?id=10918&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 #10917: deal with the BLOB data

[dickzzm]

From: [EMAIL PROTECTED]
Operating system: AIX4.3
PHP version:  4.0.4
PHP Bug Type: Sybase (dblib) related
Bug description:  deal with the BLOB data

PHP has some functon to deal with BLOB data for Oracle,but
how can I deal with BLOB data for Sybase? Are there  some functions?
I tried with Sybase's function,but after that ,there are some error message like 
"Cannot add header information--headers already sent by ".How can I do now?


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



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

RE: [PHP-DEV] Latest commit -- depreciation of call_user_method()

[Andi Gutmans]

At 10:27 PM 5/16/2001 -0400, Sean R. Bright wrote:
> > -Original Message-
> > From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
>
>...
>
> > There has been lots of talk and I think there have also been
> > some good ideas.
> > The only problem I have had with these discussions up to now
> > is that people
> > here really forget that the average PHP coder is not a
> > php-dev guy who
> > wants everything to be perfect.
> > So we can maybe start making a plan for 4.1.x which would
> > address this
> > standardization but I would definitely urge to think of the
> > average PHP
> > user and give him an option which 95% of the time won't trash
> > his site :)
> >
> > Andi
>
>Its not really my place to throw in my $0.02 having only contributed very
>little thus far to the project, but reading this gave me a thought.  Why not
>create a utility program before compatibility breaking releases that runs
>through existing scripts and reports to the user/developer what types of
>changes need to be made in order for the script to work properly under a new
>version?  This way a user could download and build the utility, run it,
>receive a report of the deprecated/changed functions, determine the amount
>of effort that is going to be required to update his/her scripts and then
>make an decision as when/if to upgrade.  It could feed off of some sort of
>database on php.net so that we can update it with each new version without
>having the user download/build again.  It may sound like a silly idea, but
>there needs to be some sort of migration plan, and at least this way we will
>not be alienating the end-users.

I think these kind of utilities are in general a good idea. We created one 
for the PHP/FI 2 -> PHP 3 transition which helped people quite a bit.

Andi


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

RE: [PHP-DEV] Re: [PHP-QA] PHP 4.0.6RC1 ready for testing

[Andi Gutmans]

Can you try and revert those changes and see if it helps? Maybe you can 
find the cause of the problem?

Andi

At 10:11 PM 5/16/2001 -0400, Mike Robinson wrote:

> > Andi wrote:
> > > I rolled 4.0.6RC1. It is ready for testing.
> > > http://www.php.net/~andi/php-4.0.6RC1.tar.gz
> > >
> > > Please everyone take sometime to make sure this is release worthy :)
>
>
>Hmm.
>I can't get freetype2 support hooked up.
>It worked fine in a snapshot from about a week ago.
>(php4-200105060945)
>In that snapshot, png support was successful without having
>to specify --with-png-dir=/usr, thats no longer the case.
>This is with gd-1.8.3gif installed from source, and
>the stock freetype2 rpms on redhat-7.1.
>
>There were some changes about a week ago to
>php4/ext/gd/config.m4 involving freetype dir tests
>(amongst others).
>
>Regards
>Mike Robinson
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


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

Re: [PHP-DEV] sockets extension

[Andi Gutmans]

At 10:34 PM 5/16/2001 +0200, Daniel Beulshausen wrote:
>At 22:49 16.05.2001 +0300, Andi Gutmans wrote:
>>Daniel,
>>
>>Would it make sense to try to integrate the new php_streams into this 
>>extension?
>>It might give php_streams a push and I'm sure Wez would work with you 
>>fixing any remaining issues.
>>It would be a nice test bed.
>>What do you think?
>>
>>About backwards compatibility, without having read the code it sounds as 
>>if you're doing "the right thing" as opposed to the old module. Do any of 
>>the new function names overlap with the old ones? I'm not quite sure how 
>>we should tackle backwards compatibility here.
>
>forgot to answer that, no the new function names don't overlap, 
>thereprefixed i.e.
>socket -> socket_create
>fd_dealloc -> socket_fd_free
>create_listen_sock -> socket_create_listen

The names sound good. That's for sure :)

Andi


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

Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()

[Andi Gutmans]

At 08:31 PM 5/16/2001 -0400, Stig Sæther Bakken wrote:
>[Jani Taskinen <[EMAIL PROTECTED]>]
> > On Wed, 16 May 2001, Zeev Suraski wrote:
> >
> > >Also bare in mind that a very large percentage of the developers don't
> > >*want* to be forced to change their code, and consider it to be a
> >
> > Who's forcing anybody to update anyway?
> >
> > >misfeature in the language if it breaks downwards compatibility in between
> > >releases, regardless of whether they get a clear notification about it 
> or not.
> >
> > It seems like everybody just ignores my emails..oh well. So I can rant
> > again. >:-p
> >
> > Have you ever heard that you can also change that number in the middle?
> >   4.0.6
> > This one^
> >
> > It can be something else than an ellipse called zero..it can even be a
> > number 1!!! Whoa! Never thougth about that?!
> >
> > And maybe, just MAYBE then these people (who you seem to think of as
> > complete idiots) would READ the NEWS file? Or e.g. RELEASE_NOTES ?
> >
> > Or is that number in the middle reserved for something special? Something
> > the 'group' only know of and don't want to tell us lower class people?
> > Maybe the 'group' could take their thumbs out of their asses and
> > start DOING something? And maybe they could start listening to new ideas
> > for once and a while. Or is the 'group' nowadays only Zeev/Andi ?
> >
> > It would be really nice to hear from the other members of the 'group' also
> > as it really seems like the only ones speaking for it are Zeev/Andi..
> >
> > Or could someone please define the function of this mysterious 'group' ?
> > (And please, someone else than Zeev/Andi.. :)
>
>Hey Jani, you can attribute yourself as the PHP Whipping Boy now if
>you like.  I think you just got enough points. :-)
>
>I completely agree that we should start using the minor version.  It's
>like we're afraid to touch it because that would imply too big changes
>or something.  Seeing how huge our process between "micro" versions
>has become, it's just getting weirder.
>
>I think we should take a good look at the 4.1 TODO and split into a
>4.1 and 4.2 TODO, and have 4.1 out sooner, maybe even as the next
>release after 4.0.6.

I agree. I just think we should concentrate on something specific for 4.1. 
Otherwise, we're going to split up our efforts too much and 4.1 won't 
happen. I would go with the standardization stuff everyone has wanted and 
get it over with :) I'd like to do this without breaking everyone's sites 
though.

Andi


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

Re: [PHP-DEV] Seperating bugs out of here

[Andi Gutmans]

We've been there before and discussed it a long time. You can check the 
archives.
If you want a short summary: "Part of the burden of being on php-dev and 
part of the development of PHP is that you should see the bugs (be forced 
to see them) so that you will hopefully not forget about them and even fix 
a couple".

Andi

At 12:01 AM 5/17/2001 +0200, Jeroen wrote:
>Hi,
>
>Just an idea... what about getting those bug#43285432432 added notices to
>another (new) mailinglist?
>Just like the cvs's, they are not always interesting for everyone. I
>estimate the bug-traffic
>makes about 70% of this ML, IMO too much.
>php.bugs sounds great.
>
>Greetz,
>Jeroen
>NB: i'm not sure this isn't posted before, but searching for 'bug' or 'bugs'
>is hopeless ;)
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


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

[PHP-DEV] Bug #10916: (Feature Request) OS-independent path parsing

[mark]

From: [EMAIL PROTECTED]
Operating system: Linux 2.2.18
PHP version:  4.0.4pl1
PHP Bug Type: Feature/Change Request
Bug description:  (Feature Request) OS-independent path parsing

I've looked for something like this in the existing function suite but haven't found 
it...

Because Windoze and Linux (at least) use different characters to separate elements of 
a file path, I think a function that parses a path into an array of subdirectories, 
basename and extension would be useful.


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



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

RE: [PHP-DEV] Latest commit -- depreciation of call_user_method()

[Sean R. Bright]

> -Original Message-
> From: Andi Gutmans [mailto:[EMAIL PROTECTED]]

...

> There has been lots of talk and I think there have also been
> some good ideas.
> The only problem I have had with these discussions up to now
> is that people
> here really forget that the average PHP coder is not a
> php-dev guy who
> wants everything to be perfect.
> So we can maybe start making a plan for 4.1.x which would
> address this
> standardization but I would definitely urge to think of the
> average PHP
> user and give him an option which 95% of the time won't trash
> his site :)
>
> Andi

Its not really my place to throw in my $0.02 having only contributed very
little thus far to the project, but reading this gave me a thought.  Why not
create a utility program before compatibility breaking releases that runs
through existing scripts and reports to the user/developer what types of
changes need to be made in order for the script to work properly under a new
version?  This way a user could download and build the utility, run it,
receive a report of the deprecated/changed functions, determine the amount
of effort that is going to be required to update his/her scripts and then
make an decision as when/if to upgrade.  It could feed off of some sort of
database on php.net so that we can update it with each new version without
having the user download/build again.  It may sound like a silly idea, but
there needs to be some sort of migration plan, and at least this way we will
not be alienating the end-users.

Sean


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

RE: [PHP-DEV] Re: [PHP-QA] PHP 4.0.6RC1 ready for testing

[Mike Robinson]

> Andi wrote:
> > I rolled 4.0.6RC1. It is ready for testing.
> > http://www.php.net/~andi/php-4.0.6RC1.tar.gz
> >
> > Please everyone take sometime to make sure this is release worthy :)


Hmm.
I can't get freetype2 support hooked up.
It worked fine in a snapshot from about a week ago.
(php4-200105060945)
In that snapshot, png support was successful without having
to specify --with-png-dir=/usr, thats no longer the case.
This is with gd-1.8.3gif installed from source, and
the stock freetype2 rpms on redhat-7.1.

There were some changes about a week ago to
php4/ext/gd/config.m4 involving freetype dir tests
(amongst others).

Regards
Mike Robinson



-- 
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 #10913 Updated: hw_who() returns incorrect data & prints extraneous string (patch incl.)

[torben]

ID: 10913
Updated by: torben
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Hyperwave related
Operating system: 
PHP Version: 4.0 Latest CVS (2001-05-16)
Assigned To: 
Comments:

Just a minor change to the patch: s/#if 0/#ifdef HW_DEBUG/. :)

Previous Comments:
---

[2001-05-16 21:31:25] [EMAIL PROTECTED]
Just found this with hw_who(): the returned array skipped some attributes and printed 
what looked like
a debugging string when called. Basic upshot was that the array returned didn't have 
all of the actual
data returned from the Hyperwave server, and all values were associated with the wrong 
keys (except
for 'self').

This patch seems to fix it for me:

Index: hw.c
===
RCS file: /repository/php4/ext/hyperwave/hw.c,v
retrieving revision 1.81
diff -u -r1.81 hw.c
--- hw.c2001/04/30 12:53:55 1.81
+++ hw.c2001/05/17 01:20:09
@@ -1190,7 +1190,10 @@
 
ptr = object;
 
+#if 0
 php_printf("%sn", ptr);
+#endif
+
/* Skip first two lines, they just contain:
 Users in Database
 
@@ -1228,6 +1231,9 @@
add_assoc_long(user_arr, "self", 0);

ptr++;
+   while((*ptr != '

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

Re: [PHP-DEV] xslt problems

[Sterling Hughes]

Gavin Sherry wrote:

> Alex,
> 
> Sablot has some poor error handling at the moment. All ambiguous errors
> you can put down to Sablot. Try using the `sabcmd` from the command line
> in order to get better information on where and how your transformations
> are playing up.
> 
> Also, if you're unsure if it is a bug, best to mail the general php list
> before this one.
> 


Just a note, PHP 4.0.4pl1 has ambiguous errors.  Still you can use the 
xslt_set_error_handler() function to get all errors that occur (more 
descriptive than the sabcmd program).

-Sterling


> Gavin
> 
> On Wed, 16 May 2001, Alex Black wrote:
> 
> 
>>hi all,
>>
>>I'm running sablot
>>(--with-sablot=/usr/local/Sablot)
>>
>>and am getting very strange behavior surrounding xslt_process.
>>
>>sometimes, I get a processed page. then (with no change in any of the
>>files), I'll get an error: "Fatal error: msgtype: error in..."
>>
>>I did a little looking, and all I could find was some pissed-off looking bug
>>reports and a couple posts in various places.
>>
>>So question:
>>-is this a bug?
>>-if so, great, that's that, wonderful to have a fix, etc.
>>-if not, uh, what am I doing wrong such that I get random fatal
>>errors form sablot?
>>
>>
>>
>>any info much appreciated.
>>
>>xslt freaking rocks...
>>
>>_alex
>>
>>
>>
>>
> 
> 




-- 
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 #10915: function get_cfg_var() returns inaccurate result

[sprucely]

From: [EMAIL PROTECTED]
Operating system: Linux Mandrake 7.2
PHP version:  4.0.4
PHP Bug Type: Scripting Engine problem
Bug description:  function get_cfg_var() returns inaccurate result

get_cfg_var('magic_quotes_gpc') accurately returns the setting from php.ini. But when 
that setting is overridden in a .htaccess file it still returns the setting from 
php.ini instead of the new setting in .htaccess.


-- 
Edit Bug report at: http://bugs.php.net/?id=10915&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 #10914: --with-ccvs[=DIR] breaks configure if DIR not given (patch incl.)

[torben]

From: [EMAIL PROTECTED]
Operating system: Linux 2.2.14/Mandrake 7
PHP version:  4.0 Latest CVS (2001-05-16)
PHP Bug Type: Compile Failure
Bug description:  --with-ccvs[=DIR] breaks configure if DIR not given (patch incl.)

The CCVS config.m4 doesn't search for the CCVS installation if DIR isn't given to 
--with-ccvs[=DIR], like
other options; since there is a default install dir for CCVS it seemed reasonable to 
hack it to do the search.
The symptom is that if =DIR isn't given then a spurious "-L" ends up on the command 
line and the next test down
the configure script fails with an apparently unrelated error message: in my case, the 
cURL tests told me to add
--with-openssl; I have a feeling this might also fix Bug #8045 (ccvs breaking mcrypt 
configuration).

This patch is just more-or-less copied from some of the other config.m4s:

Index: config.m4
===
RCS file: /repository/php4/ext/ccvs/config.m4,v
retrieving revision 1.8
diff -u -r1.8 config.m4
--- config.m4   2001/05/12 11:08:47 1.8
+++ config.m4   2001/05/17 01:33:25
@@ -1,26 +1,29 @@
-dnl $Id: config.m4,v 1.8 2001/05/12 11:08:47 sas Exp $
+dnl $Id: config.m4,v 1.7 2001/03/27 20:34:22 sniper Exp $
 dnl config.m4 for PHP4 CCVS Extension
 
-AC_MSG_CHECKING(CCVS Support)
-AC_ARG_WITH(ccvs,
-[  --with-ccvs[=DIR]   Compile CCVS support into PHP4. Please specify your 
-  CCVS base install directory as DIR.],
-[
-  if test "$withval" != "no"; then
- CCVS_DIR="$withval"
-   test -f $withval/include/cv_api.h && CCVS_INCLUDE_DIR=$withval/include
-test -f $withval/lib/libccvs.a && CCVS_LIB_DIR=$withval/lib
+PHP_ARG_WITH(ccvs, for CCVS support,
+[  --with-ccvs[=DIR]   Include CCVS support])
 
-   if test -n "$CCVS_DIR"; then
-   AC_MSG_RESULT(yes)
-   PHP_EXTENSION(ccvs)
-   LIBS="$LIBS -L$CCVS_LIB_DIR"
-   PHP_ADD_LIBRARY_WITH_PATH(ccvs, $CCVS_LIB_DIR)
-   PHP_ADD_INCLUDE($CCVS_INCLUDE_DIR)
- else
-   AC_MSG_RESULT(no)
- fi
-   fi
-],[
-  AC_MSG_RESULT(no)
-])
+if test "$PHP_CCVS" != "no"; then
+  if test -r $PHP_CCVS/include/cv_api.h; then
+ CCVS_DIR=$PHP_CCVS
+  else 
+AC_MSG_CHECKING(for CCVS in default path)
+for i in /usr/local/ccvs /usr; do
+  if test -r $i/include/cv_api.h; then
+CCVS_DIR=$i
+AC_MSG_RESULT(found in $i)
+  fi
+done
+  fi
+
+  if test -z "$CCVS_DIR"; then
+AC_MSG_RESULT(not found)
+AC_MSG_ERROR(Please check your CCVS installation; cv_api.h should be in 
+/include/)
+  fi
+
+  PHP_ADD_INCLUDE($CCVS_DIR/include)
+  PHP_ADD_LIBRARY_WITH_PATH(ccvs, $CCVS_DIR/lib)
+
+  PHP_EXTENSION(ccvs)
+fi



-- 
Edit Bug report at: http://bugs.php.net/?id=10914&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] imap--ssl broken with cclient from 2001 dist

[ilya]

Looks like --with-imap-ssl is broken, imap2001 (latest c-client), does not
contain auth_ssl anymore, compilation of php --with-imap-ssl fails with:
/bin/sh /usr/tmp/php-4.0.5/libtool --silent --mode=compile gcc  -I.
-I/usr/tmp/php-4.0.5/ext/imap -I/usr/tmp/php-4.0.5/main -I/usr/tmp/php-4.0.5
-I/usr/local/include/apache -I/usr/tmp/php-4.0.5/Zend
-I/usr/local/include/freetype -I/usr/local/include/gd -I/usr/local/include
-I/usr/local/include/c-client/ -I/usr/local/include/mcal
-I/usr/local/include/mysql -I/usr/tmp/php-4.0.5/ext/xml/expat/xmltok
-I/usr/tmp/php-4.0.5/ext/xml/expat/xmlparse -I/usr/tmp/php-4.0.5/TSRM
-DHARD_SERVER_LIMIT=512 -DDOCUMENT_LOCATION="/usr/local/www/data/"
-DDEFAULT_PATH="/usr/local/bin:/bin:/usr/bin" -DACCEPT_FILTER_NAME="httpread
y"
-DMOD_SSL=208102 -DEAPI -DEAPI_MM -DUSE_EXPAT -DSUPPORT_UTF8 -DXML_BYTE_ORDE
R=12
-g -O2  -c php_imap.c
php_imap.c: In function `php_minit_imap':
php_imap.c:451: `auth_ssl' undeclared (first use in this function)
php_imap.c:451: (Each undeclared identifier is reported only once
php_imap.c:451: for each function it appears in.)
*** Error code 1

Stop in /usr/tmp/php-4.0.5/ext/imap.
*** Error code 1

Stop in /usr/tmp/php-4.0.5/ext/imap.

i have tried to remove that one line in php_main.c which references
auth_ssl, and it does compile after that, but apache fails to start:
apachectl configtest
Syntax error on line 177 of /usr/local/etc/apache/httpd.conf:
Cannot load /usr/local/libexec/apache/libphp4.so into server:
/usr/local/libexec/apache/libphp4.so: Undefined symbol "ssl_onceonlyinit"

i am not much of the programmer, so not sure how to debug futher.





-- 
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 #10913: hw_who() returns incorrect data & prints extraneous string (patch incl.)

[torben]

From: [EMAIL PROTECTED]
Operating system: Linux 2.2.14/Mandrake 7
PHP version:  4.0 Latest CVS (2001-05-16)
PHP Bug Type: Hyperwave related
Bug description:  hw_who() returns incorrect data & prints extraneous string (patch 
incl.)

Just found this with hw_who(): the returned array skipped some attributes and printed 
what looked like
a debugging string when called. Basic upshot was that the array returned didn't have 
all of the actual
data returned from the Hyperwave server, and all values were associated with the wrong 
keys (except
for 'self').

This patch seems to fix it for me:

Index: hw.c
===
RCS file: /repository/php4/ext/hyperwave/hw.c,v
retrieving revision 1.81
diff -u -r1.81 hw.c
--- hw.c2001/04/30 12:53:55 1.81
+++ hw.c2001/05/17 01:20:09
@@ -1190,7 +1190,10 @@
 
ptr = object;
 
+#if 0
 php_printf("%s\n", ptr);
+#endif
+
/* Skip first two lines, they just contain:
 Users in Database
 
@@ -1228,6 +1231,9 @@
add_assoc_long(user_arr, "self", 0);

ptr++;
+   while((*ptr != '\0') && (*ptr == ' '))
+   ptr++;
+
name = ptr;
while((*ptr != '\0') && (*ptr != ' '))
ptr++;
@@ -1235,6 +1241,9 @@
add_assoc_string(user_arr, "id", name, 1);
 
ptr++;
+   while((*ptr != '\0') && (*ptr == ' '))
+   ptr++;
+
name = ptr;
while((*ptr != '\0') && (*ptr != ' '))
ptr++;



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



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

Re: [PHP-DEV] xslt problems

[Gavin Sherry]

Alex,

Sablot has some poor error handling at the moment. All ambiguous errors
you can put down to Sablot. Try using the `sabcmd` from the command line
in order to get better information on where and how your transformations
are playing up.

Also, if you're unsure if it is a bug, best to mail the general php list
before this one.

Gavin

On Wed, 16 May 2001, Alex Black wrote:

> hi all,
> 
> I'm running sablot
> (--with-sablot=/usr/local/Sablot)
> 
> and am getting very strange behavior surrounding xslt_process.
> 
> sometimes, I get a processed page. then (with no change in any of the
> files), I'll get an error: "Fatal error: msgtype: error in..."
> 
> I did a little looking, and all I could find was some pissed-off looking bug
> reports and a couple posts in various places.
> 
> So question:
> -is this a bug?
> -if so, great, that's that, wonderful to have a fix, etc.
> -if not, uh, what am I doing wrong such that I get random fatal
> errors form sablot?
> 
> 
> 
> any info much appreciated.
> 
> xslt freaking rocks...
> 
> _alex
> 
> 
> 


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

RE: [PHP-DEV] Re: [PHP-QA] PHP 4.0.6RC1 ready for testing

[Mike Robinson]

> -Original Message-
> From: Zak Greant [mailto:[EMAIL PROTECTED]]
> Sent: May 15, 2001 3:27 PM
> To: [EMAIL PROTECTED]; Andi Gutmans; [EMAIL PROTECTED]
> Subject: [PHP-DEV] Re: [PHP-QA] PHP 4.0.6RC1 ready for testing
> 
> 
> Andi wrote:
> > I rolled 4.0.6RC1. It is ready for testing.
> > http://www.php.net/~andi/php-4.0.6RC1.tar.gz
> >
> > Please everyone take sometime to make sure this is release worthy :)
> 
> Hurray! :)
> 
> Successful build on Mandrake 7.1
> Basic scripts run w/o issues

The gd support in 4.0.6RC1 got a little broken.
Building snapshot php4-200105060945 against a
copy of gd-1.8.3 with gif support hacked in, php
builds fine and phpinfo() shows:

GD Support enabled 
GD Version 1.6.2 or higher 
FreeType Support enabled 
FreeType Linkage with TTF library 
T1Lib Support enabled 
GIF Support enabled 
JPG Support enabled 
PNG Support enabled 
WBMP Support enabled

RC1, phpinfo() shows:
GD Support enabled 
GD Version 1.6.2 or higher 
T1Lib Support enabled 
GIF Support enabled 
JPG Support enabled 
WBMP Support enabled

so somewhere along the line freetype and
png stuff got dropped. I'll investigate more
shortly.

Regards
Mike Robinson





-- 
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] xslt problems

[Alex Black]

hi all,

I'm running sablot
(--with-sablot=/usr/local/Sablot)

and am getting very strange behavior surrounding xslt_process.

sometimes, I get a processed page. then (with no change in any of the
files), I'll get an error: "Fatal error: msgtype: error in..."

I did a little looking, and all I could find was some pissed-off looking bug
reports and a couple posts in various places.

So question:
-is this a bug?
-if so, great, that's that, wonderful to have a fix, etc.
-if not, uh, what am I doing wrong such that I get random fatal
errors form sablot?



any info much appreciated.

xslt freaking rocks...

_alex


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

Re: [PHP-DEV] removing ereg functions

[Stig Sæther Bakken]

I have to say that I'm more in favor of removing --without-pcre-regex
than adding --disable-ereg, especially now that Apache is starting to
bundle PCRE.  And I don't think the "bloat" argument holds water, it
sounds to me like more of a warm-fuzzy-feeling issue than a real
performance/maintainability issue.

 - Stig

[Cynic <[EMAIL PROTECTED]>]
> yes, PCRE is part of Apache-2.0
> 
> On Wed, 16 May 2001 -0400, [EMAIL PROTECTED] wrote:
> 
> > Rasmus Lerdorf wrote:
> >
> > >>But, that all makes sense and tells me that it is not worth pursuing.
> > >>
> > >>Is the regex lib bundled with apache always as part of the core or just
> > >>included with certain modules?
> > >>
> > >
> > > It is part of the core.
> > >
> >
> >
> > As Apache 2.0, I believe PCRE is also a part of the Apache core?
> >
> > -Sterling
> >
> >
> >
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

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

Re: [PHP-DEV] removing ereg functions

[Stig Sæther Bakken]

["Brian Moon" <[EMAIL PROTECTED]>]
> No, sorry, I think you misunderstood my question.  I would just like to see
> a --disable-ereg option for configure.  I would never dream of removing ereg
> from PHP as a supported function set.  It would break Phorum and lots of
> stuff I have written.
> 
> I understand your reaction now Rasmus.  Sorry for the confusion.

If you write a regular expression implementation in PHP that we can
use as a fall-back in PEAR code if both preg and ereg are disabled,
I'll think about it.  In general I'm against new options simply
because of the interop nightmare we've spun ourselves into. :-P

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

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

Re: AW: AW: [PHP-DEV] arrays

[Stig Sæther Bakken]

[Zeev Suraski <[EMAIL PROTECTED]>]
> At 13:34 16/5/2001, Stig Sæther Bakken wrote:
> >Acknowledged.  But IMO the arrays will be either clearly continous or
> >clearly associative/non-continous in 99.2% of the cases (Zeev
> >statistics applied).
> 
> I never claim to be accurate, I usually say 99% :)

I don't either, my random generator just has a higher resolution. :-)

> >   I think it's fine to keep treating an array as
> >non-continous if there has ever been holes or string keys in it.
> 
> I actually think that arrays with both numeric and associative indices
> are quite common.  Lots of apps I've seen use them, as well as some of
> PHP's internal functions.

You're probably right.  But the question is really how often arrays
change between being continous and associative/mixed/non-continous?

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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 #10912 Updated: in --with-pspell=DIR DIR is ignored

[vlad]

ID: 10912
Updated by: vlad
Reported By: [EMAIL PROTECTED]
Old-Status: Assigned
Status: Closed
Bug Type: Pspell related
Operating system: 
PHP Version: 4.0.5
Assigned To: vlad
Comments:

ops... I meant to close it too...

Previous Comments:
---

[2001-05-16 20:39:08] [EMAIL PROTECTED]
Fixed in CVS

(plus fixed one more config.m4-related bug)


---

[2001-05-16 20:04:53] [EMAIL PROTECTED]
...and I think I know what the problem is. I wanted to
slightly rewrite the config.m4 file anyway - there are more
problems with it than just that... assigning...

---

[2001-05-16 19:10:53] [EMAIL PROTECTED]
when I configure PHP with 
configure --with-pspell=/opt/local/include

PHP still looks for pspell in /usr/local and ignores the path I specify


---



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


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

[PHP-DEV] Bug #10912 Updated: in --with-pspell=DIR DIR is ignored

[vlad]

ID: 10912
Updated by: vlad
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type: Pspell related
Operating system: 
PHP Version: 4.0.5
Assigned To: vlad
Comments:

Fixed in CVS

(plus fixed one more config.m4-related bug)


Previous Comments:
---

[2001-05-16 20:04:53] [EMAIL PROTECTED]
...and I think I know what the problem is. I wanted to
slightly rewrite the config.m4 file anyway - there are more
problems with it than just that... assigning...

---

[2001-05-16 19:10:53] [EMAIL PROTECTED]
when I configure PHP with 
configure --with-pspell=/opt/local/include

PHP still looks for pspell in /usr/local and ignores the path I specify


---



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


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

Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()

[Stig Sæther Bakken]

[Jani Taskinen <[EMAIL PROTECTED]>]
> On Wed, 16 May 2001, Zeev Suraski wrote:
> 
> >Also bare in mind that a very large percentage of the developers don't
> >*want* to be forced to change their code, and consider it to be a
> 
> Who's forcing anybody to update anyway?
> 
> >misfeature in the language if it breaks downwards compatibility in between
> >releases, regardless of whether they get a clear notification about it or not.
> 
> It seems like everybody just ignores my emails..oh well. So I can rant
> again. >:-p
> 
> Have you ever heard that you can also change that number in the middle?
>   4.0.6
> This one^
> 
> It can be something else than an ellipse called zero..it can even be a
> number 1!!! Whoa! Never thougth about that?!
> 
> And maybe, just MAYBE then these people (who you seem to think of as
> complete idiots) would READ the NEWS file? Or e.g. RELEASE_NOTES ?
> 
> Or is that number in the middle reserved for something special? Something
> the 'group' only know of and don't want to tell us lower class people?
> Maybe the 'group' could take their thumbs out of their asses and
> start DOING something? And maybe they could start listening to new ideas
> for once and a while. Or is the 'group' nowadays only Zeev/Andi ?
> 
> It would be really nice to hear from the other members of the 'group' also
> as it really seems like the only ones speaking for it are Zeev/Andi..
> 
> Or could someone please define the function of this mysterious 'group' ?
> (And please, someone else than Zeev/Andi.. :)

Hey Jani, you can attribute yourself as the PHP Whipping Boy now if
you like.  I think you just got enough points. :-)

I completely agree that we should start using the minor version.  It's
like we're afraid to touch it because that would imply too big changes
or something.  Seeing how huge our process between "micro" versions
has become, it's just getting weirder.

I think we should take a good look at the 4.1 TODO and split into a
4.1 and 4.2 TODO, and have 4.1 out sooner, maybe even as the next
release after 4.0.6.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

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

Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()

[Stig Sæther Bakken]

[Zeev Suraski <[EMAIL PROTECTED]>]
> One comment;  Why? :)
> 
> We've been in that discussion before.  In my opinion, we should
> probably rethink our whole deprecation approach.
> Yes, I know that people don't like the burden of maintaining downwards
> compatibility.  I sure as hell don't.  But PHP's huge popularity boost
> put the development team in a position where it has *a lot* of
> responsibility;  Doing the wrong thing will reflect badly on PHP and
> its acceptance as a stable solution (not segfault wise, but
> development wise).
> 
> On the other hand, I really don't like the bloat either.
> 
> So, what should be done?  In my opinion, the approach of adding
> E_NOTICE notifications to functions doesn't cut it;  It won't
> significantly improve the situation.  I think we should go in a
> different path (or an 'extended' path) - IMHO, the best approach would
> be adding some sort of a 'LEAN_AND_MEAN' mode to PHP's build.   When
> built in this mode, bloat code will be #define'd away, or displayed as
> 'deprecated' in a similar manner to the way warn_not_available works.
> That gives everyone almost everything -
> people who care about the bloat (like me) will build it in
> LEAN_AND_MEAN mode, hosting companies or legacy sites, who care most
> about having their code go on working with minimum hassle - won't mind
> the added bloat.  If kept closely documented, people who care enough
> about the bloat will be able to go through the checklist, make sure
> their sites are compatible with it, and turn this mode on.
> 
> The only drawback I see to this approach is that the code itself
> remains and 'bloats' the various files.  We can probably overcome this
> problem by separating legacy code to separate files.

I second this.  Although we do have some minor bloat :) here and
there, I don't think we should go out of our way to break people's
scripts.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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 #10912 Updated: in --with-pspell=DIR DIR is ignored

[vlad]

ID: 10912
Updated by: vlad
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Assigned
Bug Type: Pspell related
Operating system: 
PHP Version: 4.0.5
Assigned To: vlad
Comments:

...and I think I know what the problem is. I wanted to
slightly rewrite the config.m4 file anyway - there are more
problems with it than just that... assigning...

Previous Comments:
---

[2001-05-16 19:10:53] [EMAIL PROTECTED]
when I configure PHP with 
configure --with-pspell=/opt/local/include

PHP still looks for pspell in /usr/local and ignores the path I specify


---



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


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

Re: [PHP-DEV] sockets extension

[Wez Furlong]

I don't appear to have seen/received the rest of this thread,
so please pardon any mistakes in advance...

On 2001-05-16 20:49:30, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> Would it make sense to try to integrate the new php_streams into this 
> extension?
> It might give php_streams a push and I'm sure Wez would work with you 
> fixing any remaining issues.
> It would be a nice test bed.
> What do you think?

I'm not sure that the sockets extension would benefit from php_streams as
much as php_streams would benefit from the sockets extension, if you see
what I mean.

I would like to see it using php_streams, as that would result in PHP being
much more flexible for the person coding in PHP; they needn't worry about
the type of the file handle they pass to any function.

To integrate php_streams properly, ext/sockets should converge with fsock.c
and use the same underlying sockets implemented as php_streams (it's not
too much work).

I think it's a good idea to get it done.

--Wez.


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

[PHP-DEV] Bug #10912: in --with-pspell=DIR DIR is ignored

[vksgeneric]

From: [EMAIL PROTECTED]
Operating system: Linux Redhat 6.2
PHP version:  4.0.5
PHP Bug Type: Pspell related
Bug description:  in --with-pspell=DIR DIR is ignored

when I configure PHP with 
configure --with-pspell=/opt/local/include

PHP still looks for pspell in /usr/local and ignores the path I specify



-- 
Edit Bug report at: http://bugs.php.net/?id=10912&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 #5332 Updated: ODBC Connect Fails for Sybase SQLanywhere DB

[kalowsky]

ID: 5332
Updated by: kalowsky
Reported By: [EMAIL PROTECTED]
Old-Status: Analyzed
Status: Feedback
Bug Type: ODBC related
Operating system: 
PHP Version: 4.0 Release Candidate 2
Assigned To: 
Comments:

The SQL error you are receiving is "Server rejected access"
I'm wondering if your odbc_connect only needs "wald" instead
of "waldserver - wald"



Previous Comments:
---

[2001-03-26 16:22:39] [EMAIL PROTECTED]
Yes, this is still happening.  I have loaded PHP version 4.04 PL1.  I am trying to run 
the following simple script:

-



Neue Seite 2










The output I receive is:

Warning: SQL error: [Sybase][ODBC Driver]Unable to connect to database server: unable 
to start database engine, SQL state 08001 in SQLConnect in 
c:inetpubwwwrootodbctestdefault.php on line 11
Odbc connection variable: 
Warning: Supplied argument is not a valid ODBC-Link resource in 
c:inetpubwwwrootodbctestdefault.php on line 13

Warning: Supplied argument is not a valid ODBC-Link resource in 
c:inetpubwwwrootodbctestdefault.php on line 15

Warning: Supplied argument is not a valid ODBC-Link resource in 
c:inetpubwwwrootodbctestdefault.php on line 15
03.26.2001 22:50:23 Westeuropäische Normalzeit 

-
I have enabled the ODBC log.  However, the log shows absolutely nothing for this ODBC 
connection attempt via PHP.  I can connect via Excel and Borland DB explorer for 
example.  Here are excerpts from the odbc logs:

ODBC via Excel:

MSQRY32 5ac-850 ENTER SQLDriverConnectW 
HDBC00811910
HWND00020564
WCHAR * 0x1F7D8B70 [  -3] "** 0"
SWORD   -3 
WCHAR * 0x1F7D8B70 
SWORD8 
SWORD * 0x
UWORD1 

MSQRY32 5ac-850 EXIT  SQLDriverConnectW  with return code 0 (SQL_SUCCESS)
HDBC00811910
HWND00020564
WCHAR * 0x1F7D8B70 [  -3] "** 0"
SWORD   -3 
WCHAR * 0x1F7D8B70 
SWORD8 
SWORD * 0x
UWORD1 

MSQRY32 5ac-850 ENTER SQLGetInfoW 
HDBC00811910
UWORD2 
PTR 0x00811A40 
SWORD 2048 
SWORD * 0x0006EF96

MSQRY32 5ac-850 EXIT  SQLGetInfoW  with return code 0 (SQL_SUCCESS)
HDBC00811910
UWORD2 
PTR 0x00811A40 [  30] "wadlserv - wadl"
SWORD 2048 
SWORD * 0x0006EF96 (30)




ODBC from Borland DB Explorer:
dbexplor88c-850 EXIT  SQLDataSourcesW  with return code 0 (SQL_SUCCESS)
HENV02B314F0
UWORD1 
WCHAR * 0x02B31658 [  15] "wadlser"
SWORD   33 
SWORD * 0x0012EFAA (15)
WCHAR * 0x02B322E8 [  23] "Sybase SQL "
SWORD  257 
SWORD * 0x0012EFA8 (23)

dbexplor88c-850 ENTER SQLAllocConnect 
HENV02B314F0
HDBC *  013386EC

dbexplor88c-850 EXIT  SQLAllocConnect  with return code 0 (SQL_SUCCESS)
HENV02B314F0
HDBC *  0x013386EC ( 0x02b316b0)

dbexplor88c-850 ENTER SQLConnectW 
HDBC02B316B0
WCHAR * 0x02B317B8 [  -3] "wadlserv - wadl 0"
SWORD   -3 
WCHAR * 0x1F7D8B70 [  -3] "** 0"
SWORD   -3 
WCHAR * 0x1F7D8B70 [  -3] "** 0"
SWORD   -3 

dbexplor88c-850 EXIT  SQLConnectW  with return code 0 (SQL_SUCCESS)
HDBC02B316B0
WCHAR * 0x02B317B8 [  -3] "wadlserv - wadl 0"
SWORD   -3 
WCHAR * 0x1F7

[PHP-DEV] Bug #10911 Updated: Accessing null string as array in loop causes infinite spooling.

[sr2899]

ID: 10911
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating system: linux
PHP Version: 4.0.5
Description: Accessing null string as array in loop causes infinite spooling.

Whoops I accidentally selected latest CVS when I should've said 4.0.5

Previous Comments:
---

[2001-05-16 18:28:54] [EMAIL PROTECTED]
Accessing null string as array in loop causes infinite spooling.

The following code causes php to loop forever.  It appears a memory leak unsets the $i 
variable, although I'm not certain.  If allowed to run long enough, error logs appear, 
such as:
child pid 14467 exit signal Segmentation fault (11)
FATAL:  emalloc():  Unable to allocate 1313818981 bytes





Output is as follows

HTTP/1.1 200 OK
Date: Wed, 16 May 2001 22:20:07 GMT
Server: Apache/1.3.19 (Unix) mod_ssl/2.8.3 OpenSSL/0.9.6a
Connection: close
Content-Type: text/html


1..
2..
..
..
..
..


After that, it repeats forever...

---


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


-- 
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 #10911: Accessing null string as array in loop causes infinite spooling.

[sr2899]

From: [EMAIL PROTECTED]
Operating system: linux
PHP version:  4.0 Latest CVS (2001-05-16)
PHP Bug Type: Scripting Engine problem
Bug description:  Accessing null string as array in loop causes infinite spooling.

Accessing null string as array in loop causes infinite spooling.

The following code causes php to loop forever.  It appears a memory leak unsets the $i 
variable, although I'm not certain.  If allowed to run long enough, error logs appear, 
such as:
child pid 14467 exit signal Segmentation fault (11)
FATAL:  emalloc():  Unable to allocate 1313818981 bytes





Output is as follows

HTTP/1.1 200 OK
Date: Wed, 16 May 2001 22:20:07 GMT
Server: Apache/1.3.19 (Unix) mod_ssl/2.8.3 OpenSSL/0.9.6a
Connection: close
Content-Type: text/html


1..
2..
..
..
..
..


After that, it repeats forever...


-- 
Edit Bug report at: http://bugs.php.net/?id=10911&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] Seperating bugs out of here

[Jeroen]

Hi,

Just an idea... what about getting those bug#43285432432 added notices to
another (new) mailinglist?
Just like the cvs's, they are not always interesting for everyone. I
estimate the bug-traffic
makes about 70% of this ML, IMO too much.
php.bugs sounds great.

Greetz,
Jeroen
NB: i'm not sure this isn't posted before, but searching for 'bug' or 'bugs'
is hopeless ;)



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

Re: [PHP-DEV] Adding "charset" - patch for php_imap.c

[derick]

On Wed, 16 May 2001, Johan Ekenberg wrote:

> Attached is a suggested patch to make it possible to set the CHARSET
> parameter with imap_mail_compose(). Currently, all body parts with
> Content-Type = TYPETEXT get CHARSET=US-ASCII.

Where? I think you forgot to attach your attachment :)

Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-


-- 
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 #10908 Updated: Undeclared variables/URL declared variables

[derick]

ID: 10908
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Scripting Engine problem
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

It's not open, it was not a bug, so closing.

Previous Comments:
---

[2001-05-16 17:36:31] [EMAIL PROTECTED]
Submitter added:
"Oops!  in the code in the above bug report, i made a mistake:  Change   
if($id="view")  to   if($id=="view")  Thats how the original code I ran looked like. 
Sorry for the error, I was typing fast."

Your problem is simply that the error_level (as described by derick) is set higher 
than you are used to. Still, the code should probably read something like

if (isset($id) && ($id=="view"))


---

[2001-05-16 17:07:02] [EMAIL PROTECTED]
This is not a bug.

1. Use:

if ($id == "view")

= : assignment
== : comparison

2. You can change your errorlevel, which is causing these
   messages, see www.php.net/error_reporting

---

[2001-05-16 16:56:04] [EMAIL PROTECTED]
Ok, I ran this script on my Apache server with the new PHP 4.0.5 installed and it did 
not work...










When you first view the page, it says "You are not in view mode" and has a submit 
button that says "Change to View Mode". If you click to button it will give $id the 
value of "view", so when it reloads the page, it will display "You are in view mode".

This script works fine on my server with the earlier version of PHP, but not with 
4.0.5. The new version 4.0.5 returns an error the first time it loads an says that $id 
hasnt been defined. 

I dont know if they changed it on the new version because they thought it was a bug of 
the old versions(that didnt return errors for undeclared variables), but if thats the 
case, they certainly disabled simple scripts like this one that made things a hell of 
a lot easier for us programmers. Thats why I'm using the old version of PHP, and not 
PHP 4.0.5 on my Apache server.

---



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


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

[PHP-DEV] Correction: Adding "charset" - patch for php_imap.c

[Johan Ekenberg]

This time the patch is actually attached...

Attached is a suggested patch to make it possible to set the CHARSET parameter with 
imap_mail_compose(). Currently, all body parts with Content-Type = TYPETEXT get 
CHARSET=US-ASCII.

Usage:
   $body[1][type] = TYPETEXT;
   $body[1][charset] = "iso-8859-1";

Chuck, if there are no objections to the patch, can you commit it?

Best regards,
/Johan Ekenberg


--- php_imap.c.bak  Fri May  4 19:47:01 2001
+++ php_imap.c  Wed May 16 23:18:56 2001
@@ -3255,6 +3255,14 @@
convert_to_long_ex(pvalue);
bod->encoding = (short) Z_LVAL_PP(pvalue);
}
+   if (zend_hash_find(Z_ARRVAL_PP(data), "charset", sizeof("charset"), 
+(void **) &pvalue)== SUCCESS) {
+   convert_to_string_ex(pvalue);
+   tmp_param = mail_newbody_parameter();
+   tmp_param->value = cpystr(Z_STRVAL_PP(pvalue));
+   tmp_param->attribute = "CHARSET";
+   tmp_param->next = bod->parameter;
+   bod->parameter = tmp_param;
+   }
if (zend_hash_find(Z_ARRVAL_PP(data), "subtype", sizeof("subtype"), 
(void **) &pvalue)== SUCCESS) {
convert_to_string_ex(pvalue);
bod->subtype = cpystr(Z_STRVAL_PP(pvalue));
@@ -3332,6 +3340,14 @@
if (zend_hash_find(Z_ARRVAL_PP(data), "encoding", 
sizeof("encoding"), (void **) &pvalue)== SUCCESS) {
convert_to_long_ex(pvalue);
bod->encoding = (short) Z_LVAL_PP(pvalue);
+   }
+   if (zend_hash_find(Z_ARRVAL_PP(data), "charset", 
+sizeof("charset"), (void **) &pvalue)== SUCCESS) {
+   convert_to_string_ex(pvalue);
+   tmp_param = mail_newbody_parameter();
+   tmp_param->value = cpystr(Z_STRVAL_PP(pvalue));
+   tmp_param->attribute = "CHARSET";
+   tmp_param->next = bod->parameter;
+   bod->parameter = tmp_param;
}
if (zend_hash_find(Z_ARRVAL_PP(data), "subtype", 
sizeof("subtype"), (void **) &pvalue)== SUCCESS) {
convert_to_string_ex(pvalue);



-- 
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 #10908 Updated: Undeclared variables/URL declared variables

[lyric]

ID: 10908
Updated by: lyric
Reported By: [EMAIL PROTECTED]
Old-Status: Bogus
Status: Open
Bug Type: Scripting Engine problem
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

Submitter added:
"Oops!  in the code in the above bug report, i made a mistake:  Change   
if($id="view")  to   if($id=="view")  Thats how the original code I ran looked like. 
Sorry for the error, I was typing fast."

Your problem is simply that the error_level (as described by derick) is set higher 
than you are used to. Still, the code should probably read something like

if (isset($id) && ($id=="view"))


Previous Comments:
---

[2001-05-16 17:07:02] [EMAIL PROTECTED]
This is not a bug.

1. Use:

if ($id == "view")

= : assignment
== : comparison

2. You can change your errorlevel, which is causing these
   messages, see www.php.net/error_reporting

---

[2001-05-16 16:56:04] [EMAIL PROTECTED]
Ok, I ran this script on my Apache server with the new PHP 4.0.5 installed and it did 
not work...










When you first view the page, it says "You are not in view mode" and has a submit 
button that says "Change to View Mode". If you click to button it will give $id the 
value of "view", so when it reloads the page, it will display "You are in view mode".

This script works fine on my server with the earlier version of PHP, but not with 
4.0.5. The new version 4.0.5 returns an error the first time it loads an says that $id 
hasnt been defined. 

I dont know if they changed it on the new version because they thought it was a bug of 
the old versions(that didnt return errors for undeclared variables), but if thats the 
case, they certainly disabled simple scripts like this one that made things a hell of 
a lot easier for us programmers. Thats why I'm using the old version of PHP, and not 
PHP 4.0.5 on my Apache server.

---



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


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

[PHP-DEV] Adding "charset" - patch for php_imap.c

[Johan Ekenberg]

Attached is a suggested patch to make it possible to set the CHARSET parameter with 
imap_mail_compose(). Currently, all body parts with Content-Type = TYPETEXT get 
CHARSET=US-ASCII.

Usage:
   $body[1][type] = TYPETEXT;
   $body[1][charset] = "iso-8859-1";

Chuck, if there are no objections to the patch, can you commit it?

Best regards,
/Johan Ekenberg


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

[PHP-DEV] Bug #10910 Updated: var $foo = madness

[hholzgra]

ID: 10910
Updated by: hholzgra
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Feature/Change Request
Operating system: 
PHP Version: 4.0 Latest CVS (2001-05-16)
Assigned To: 
Comments:

no way, initializer values have to be constants

use a constructor to initialize instead

Previous Comments:
---

[2001-05-16 17:07:16] [EMAIL PROTECTED]
class foo {

  var $bar = "Some string";

  var $baz = new some_other_class_i_defined;

}



I would like for that to work, please.  ;)

---



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


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

[PHP-DEV] Bug #10909 Updated: Oops! Fix above bug I wrote

[derick]

ID: 10909
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Scripting Engine problem
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

Please do not open a bug report for the same 'bug' in the future. Just add your 
comments to the first one.

regards,
Derick

Previous Comments:
---

[2001-05-16 17:06:24] [EMAIL PROTECTED]
Oops!

in the code in the above bug report, i made a mistake:

Change 

if($id="view")

to 

if($id=="view")

Thats how the original code I ran looked like. Sorry for the error, I was typing fast.

---



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


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

[PHP-DEV] Bug #10910: var $foo = madness

[jjones]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0 Latest CVS (2001-05-16)
PHP Bug Type: Feature/Change Request
Bug description:  var $foo = madness

class foo {
  var $bar = "Some string";
  var $baz = new some_other_class_i_defined;
}

I would like for that to work, please.  ;)


-- 
Edit Bug report at: http://bugs.php.net/?id=10910&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 #10908 Updated: Undeclared variables/URL declared variables

[derick]

ID: 10908
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Scripting Engine problem
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

This is not a bug.

1. Use:

if ($id == "view")

= : assignment
== : comparison

2. You can change your errorlevel, which is causing these
   messages, see www.php.net/error_reporting

Previous Comments:
---

[2001-05-16 16:56:04] [EMAIL PROTECTED]
Ok, I ran this script on my Apache server with the new PHP 4.0.5 installed and it did 
not work...










When you first view the page, it says "You are not in view mode" and has a submit 
button that says "Change to View Mode". If you click to button it will give $id the 
value of "view", so when it reloads the page, it will display "You are in view mode".

This script works fine on my server with the earlier version of PHP, but not with 
4.0.5. The new version 4.0.5 returns an error the first time it loads an says that $id 
hasnt been defined. 

I dont know if they changed it on the new version because they thought it was a bug of 
the old versions(that didnt return errors for undeclared variables), but if thats the 
case, they certainly disabled simple scripts like this one that made things a hell of 
a lot easier for us programmers. Thats why I'm using the old version of PHP, and not 
PHP 4.0.5 on my Apache server.

---



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


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

[PHP-DEV] Bug #10909: Oops! Fix above bug I wrote

[jpmaster77]

From: [EMAIL PROTECTED]
Operating system: WinME
PHP version:  4.0.5
PHP Bug Type: Scripting Engine problem
Bug description:  Oops! Fix above bug I wrote

Oops!

in the code in the above bug report, i made a mistake:

Change 

if($id="view")

to 

if($id=="view")

Thats how the original code I ran looked like. Sorry for the error, I was typing fast.


-- 
Edit Bug report at: http://bugs.php.net/?id=10909&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 #10908: Undeclared variables/URL declared variables

[jpmaster77]

From: [EMAIL PROTECTED]
Operating system: WinME
PHP version:  4.0.5
PHP Bug Type: Scripting Engine problem
Bug description:  Undeclared variables/URL declared variables

Ok, I ran this script on my Apache server with the new PHP 4.0.5 installed and it did 
not work...










When you first view the page, it says "You are not in view mode" and has a submit 
button that says "Change to View Mode". If you click to button it will give $id the 
value of "view", so when it reloads the page, it will display "You are in view mode".

This script works fine on my server with the earlier version of PHP, but not with 
4.0.5. The new version 4.0.5 returns an error the first time it loads an says that $id 
hasnt been defined. 

I dont know if they changed it on the new version because they thought it was a bug of 
the old versions(that didnt return errors for undeclared variables), but if thats the 
case, they certainly disabled simple scripts like this one that made things a hell of 
a lot easier for us programmers. Thats why I'm using the old version of PHP, and not 
PHP 4.0.5 on my Apache server.


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



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

Re: [PHP-DEV] issues about domxml in 4.0.6

[Sterling Hughes]

Colin Viebrock wrote:

>>I've contacted Uwe, and if he doesn't object (or respond ;) within the
>>next day or so, I'll revert the commit in the 4_0_6 branch (leaving head
>>alone).
>>
> 
> Whoa.
> 
> Are you saying that 4.0.6 will revert to the domxml "syntax" that was in
> 4.0.4 and previous?  And that 4.0.5 will just have it's own "syntax"?
> 
> I've already updated all my scripts to the new syntax, assuming it was the
> way of the future.  Don't tell me we are back-pedalling now!
> 


Ok, maybe I won't ;)))

its odd though, the NEWS file seems to show that 4.0.6 is the release 
where the syntax changes, not 4.0.5, perhaps we're talking about two 
different commits (in 4.0.4 DOM-XML was also overhauled)?

Its just the new syntax seems to be quite buggy (leaks and crashes) and 
a large amount of people are getting surprised and annoyed by the new 
syntax as the documentation does not reflect it, and neither do any of 
the notes in the NEWS file.

-Sterling


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

Re: [PHP-DEV] sockets extension

[Daniel Beulshausen]

At 22:49 16.05.2001 +0300, Andi Gutmans wrote:
>Daniel,
>
>Would it make sense to try to integrate the new php_streams into this 
>extension?
>It might give php_streams a push and I'm sure Wez would work with you 
>fixing any remaining issues.
>It would be a nice test bed.
>What do you think?
>
>About backwards compatibility, without having read the code it sounds as 
>if you're doing "the right thing" as opposed to the old module. Do any of 
>the new function names overlap with the old ones? I'm not quite sure how 
>we should tackle backwards compatibility here.

forgot to answer that, no the new function names don't overlap, 
thereprefixed i.e.
socket -> socket_create
fd_dealloc -> socket_fd_free
create_listen_sock -> socket_create_listen
...

daniel

/*--
daniel beulshausen - [EMAIL PROTECTED]
using php on windows? http://www.php4win.de


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

Re: [PHP-DEV] issues about domxml in 4.0.6

[Colin Viebrock]

> I've contacted Uwe, and if he doesn't object (or respond ;) within the
> next day or so, I'll revert the commit in the 4_0_6 branch (leaving head
> alone).

Whoa.

Are you saying that 4.0.6 will revert to the domxml "syntax" that was in
4.0.4 and previous?  And that 4.0.5 will just have it's own "syntax"?

I've already updated all my scripts to the new syntax, assuming it was the
way of the future.  Don't tell me we are back-pedalling now!

- Colin


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

Re: [PHP-DEV] sockets extension

[Daniel Beulshausen]

At 04:01 16.05.2001 -0400, Sterling Hughes wrote:
>I've been meaning for a while to do this, so yes, that's perfectly ok.
>
>I don't quite understand "the return values of most functions had to be 
>changed because win32 has a completely different error handling".  Can you 
>elaborate a bit more.

WSAGetlastError() returns completly different errno's, thus i think it's 
not a good idea to use them as return values (and for the users to rely on 
them).

>Also, strerror() is to my knowledge, available on Win32 systems (check out 
>FormatMessage()).
>
>*ouch*
>
>I WILL NOT DO WINDOWS PROGRAMMING
>I WILL NOT DO WINDOWS PROGRAMMING
>...
>
>
>>as that together would already break old scripts i've also renamed the 
>>functions to (hopefully) go with the standards.
>
>
>The naming looks pretty good.  It seems like most people want this (I 
>don't, but, ah well.)

great.

daniel

/*--
daniel beulshausen - [EMAIL PROTECTED]
using php on windows? http://www.php4win.de


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

[PHP-DEV] register_globals doesn't seem to be working

[Shawn South]

I was wondering if any of the developers out there might have a handle on
this...

I've recently recompiled my apache 1.3.19 binary to include static php4.05
support (in addition to mod_perl 1.25) on my Solaris 2.7 server so that I
can run Squirrel Mail.  Unfortunately the system does not seem to be
registering the EGCPS as global variables, which Squirrel mail seems to
depend on.  I've checked and the variables DO exist in HTTP_*_VARS (ie:
HTTP_POST_VARS["login_username"] is populated properly but $login_username
is blank/null.)

I'm using the standard php.ini-dist file for my php.ini (which includes
register_globals as On by default).  I've tried switching it off, with no
effect, and including  the "php_flag register_globals on" directive in my
httpd.conf, also with no effect.

FYI, PHP was configured with the --with-gettext, --with-ldap,
and --with-apache directives.


I've search through the SquirrelMail and PHP archives and cannot find any
other mention of someone having this problem.  Given that I have zero
experience with both SquirrelMail and PHP, I can easily see how this could
be a bug located half-way between my keyboard and the back of my chair.
However I like to think I'm not a complete idiot and have followed the
simple install directions properly.  Would anyone care to prove me
wrong...please?

  Shawn South




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

Re: [PHP-DEV] sockets extension

[Daniel Beulshausen]

At 22:49 16.05.2001 +0300, Andi Gutmans wrote:
>Daniel,
>
>Would it make sense to try to integrate the new php_streams into this 
>extension?
>It might give php_streams a push and I'm sure Wez would work with you 
>fixing any remaining issues.
>It would be a nice test bed.
>What do you think?

that surely would be a great idea, just didn't had the time to look at them 
yet.
i'll do that tomorrow :)

>About backwards compatibility, without having read the code it sounds as 
>if you're doing "the right thing" as opposed to the old module. Do any of 
>the new function names overlap with the old ones? I'm not quite sure how 
>we should tackle backwards compatibility here.

i think the same, but i'm pretty sure that it'll break alot sockets scripts.

daniel

/*--
daniel beulshausen - [EMAIL PROTECTED]
using php on windows? http://www.php4win.de


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

Re: [PHP-DEV] sockets extension

[Sterling Hughes]

Daniel Beulshausen wrote:

> 
> 
> hi,
> 
> i've updated the sockets extension so that it's usable under win32 as 
> well, however it's incompatible to the "old extension" for some reasons 
> (thats why i want some feedback):
> sockets fd under win32 are usigned, the previous approach of returning 
> long's and check for < 0 wouldn't have worked, thus it's been converted 
> to use resources (which is also cleaner behaviour IMO).
> the return values of most functions had to be changed, because win32 has 
> an complete different error handling.
> 


I've been meaning for a while to do this, so yes, that's perfectly ok.

I don't quite understand "the return values of most functions had to be 
changed because win32 has a completely different error handling".  Can 
you elaborate a bit more.

Also, strerror() is to my knowledge, available on Win32 systems (check 
out FormatMessage()).

*ouch*

I WILL NOT DO WINDOWS PROGRAMMING
I WILL NOT DO WINDOWS PROGRAMMING
...


> as that together would already break old scripts i've also renamed the 
> functions to (hopefully) go with the standards.
> 


The naming looks pretty good.  It seems like most people want this (I 
don't, but, ah well.)


Nice Job!

-Sterling



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

Re: [PHP-DEV] sockets extension

[Andi Gutmans]

Daniel,

Would it make sense to try to integrate the new php_streams into this 
extension?
It might give php_streams a push and I'm sure Wez would work with you 
fixing any remaining issues.
It would be a nice test bed.
What do you think?

About backwards compatibility, without having read the code it sounds as if 
you're doing "the right thing" as opposed to the old module. Do any of the 
new function names overlap with the old ones? I'm not quite sure how we 
should tackle backwards compatibility here.

Andi

At 09:28 PM 5/16/2001 +0200, Daniel Beulshausen wrote:


>hi,
>
>i've updated the sockets extension so that it's usable under win32 as 
>well, however it's incompatible to the "old extension" for some reasons 
>(thats why i want some feedback):
>sockets fd under win32 are usigned, the previous approach of returning 
>long's and check for < 0 wouldn't have worked, thus it's been converted to 
>use resources (which is also cleaner behaviour IMO).
>the return values of most functions had to be changed, because win32 has 
>an complete different error handling.
>
>as that together would already break old scripts i've also renamed the 
>functions to (hopefully) go with the standards.
>
>daniel
>
>/*--
>daniel beulshausen - [EMAIL PROTECTED]
>using php on windows? http://www.php4win.de
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP 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] sockets extension

[Daniel Beulshausen]

hi,

i've updated the sockets extension so that it's usable under win32 as well, 
however it's incompatible to the "old extension" for some reasons (thats 
why i want some feedback):
sockets fd under win32 are usigned, the previous approach of returning 
long's and check for < 0 wouldn't have worked, thus it's been converted to 
use resources (which is also cleaner behaviour IMO).
the return values of most functions had to be changed, because win32 has an 
complete different error handling.

as that together would already break old scripts i've also renamed the 
functions to (hopefully) go with the standards.

daniel

/*--
daniel beulshausen - [EMAIL PROTECTED]
using php on windows? http://www.php4win.de
 sockets.tar.gz

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

RE: [PHP-DEV] removing ereg functions

[Richard Heyes]

> No, sorry, I think you misunderstood my question.  I would just 
> like to see
> a --disable-ereg option for configure.

Wouldn't the disable_functions ini directive be of use here?

-- 
Richard Heyes

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

Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()

[Andi Gutmans]

At 01:06 PM 5/16/2001 +0200, Jani Taskinen wrote:
>On Wed, 16 May 2001, Zeev Suraski wrote:
>
> >Also bare in mind that a very large percentage of the developers don't
> >*want* to be forced to change their code, and consider it to be a
>
>Who's forcing anybody to update anyway?
>
> >misfeature in the language if it breaks downwards compatibility in between
> >releases, regardless of whether they get a clear notification about it 
> or not.
>
>It seems like everybody just ignores my emails..oh well. So I can rant
>again. >:-p
>
>Have you ever heard that you can also change that number in the middle?
>   4.0.6
>This one^
>
>It can be something else than an ellipse called zero..it can even be a
>number 1!!! Whoa! Never thougth about that?!
>
>And maybe, just MAYBE then these people (who you seem to think of as
>complete idiots) would READ the NEWS file? Or e.g. RELEASE_NOTES ?
>
>Or is that number in the middle reserved for something special? Something
>the 'group' only know of and don't want to tell us lower class people?
>Maybe the 'group' could take their thumbs out of their asses and
>start DOING something? And maybe they could start listening to new ideas
>for once and a while. Or is the 'group' nowadays only Zeev/Andi ?
>
>It would be really nice to hear from the other members of the 'group' also
>as it really seems like the only ones speaking for it are Zeev/Andi..
>
>Or could someone please define the function of this mysterious 'group' ?
>(And please, someone else than Zeev/Andi.. :)

I hope you don't mind me replying :)
I agree with you that we can bump the second version number.
I think the biggest question is if we were to create a 4.1.x in order to 
make changes (not features necessarily) which we think are important for 
standardization of function names, install paths and so on then how do we 
do it.
There has been lots of talk and I think there have also been some good ideas.
The only problem I have had with these discussions up to now is that people 
here really forget that the average PHP coder is not a php-dev guy who 
wants everything to be perfect.
So we can maybe start making a plan for 4.1.x which would address this 
standardization but I would definitely urge to think of the average PHP 
user and give him an option which 95% of the time won't trash his site :)

Andi


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

Re: [PHP-DEV] removing ereg functions

[Cynic]

yes, PCRE is part of Apache-2.0

On Wed, 16 May 2001 -0400, [EMAIL PROTECTED] wrote:

> Rasmus Lerdorf wrote:
>
> >>But, that all makes sense and tells me that it is not worth pursuing.
> >>
> >>Is the regex lib bundled with apache always as part of the core or just
> >>included with certain modules?
> >>
> >
> > It is part of the core.
> >
>
>
> As Apache 2.0, I believe PCRE is also a part of the Apache core?
>
> -Sterling
>
>
>


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

[PHP-DEV] Re: Integer casts broken or...?

[Jeroen]

In some really rare cases, but who is purposely using
(int) "0x... " anyway, and trusting on 0x being NOT
recognised??? And in user-submitted data, this just
adds another feature to most apps :), without any
programming.

The feature that non-numeric characters after the number
are ignored is only the best-of-worse-things to do
if you don't want to possible return errors on
casting to int.

Greetz,
Jeroen

On Wed, 16 May 2001, Brian Moon wrote:

> Making (int) recognize Hex values is a bad idea to me.  It could
potentially
> break current code.
>
> Brian Moon
> --
> dealnews.com, Inc.
> Makers of dealnews & dealmac
> http://dealnews.com/ | http://dealmac.com/
>
> - Original Message -
> From: "Jeroen" <[EMAIL PROTECTED]>
> To: ""Jeroen"" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
> Sent: Wednesday, May 16, 2001 1:04 PM
> Subject: Re: [PHP-DEV] Integer casts broken or...?
>
>
> > > Brian Moon writes:
> > > > I know it would confuse me to have 0009 turned into an octal or hex
if
> I
> > > > type cast it to (int).  When I think of (int), I only think of their
> > > > ultimate decimal value.  Perhaps there needs to be a new type cast
> > ((hex)?
> > > > (oct)?) that will interpret variables in their hex or octal value.
I
> > know
> > > > it is still a long integer in value, but it is a different
> > representation of
> > > > that number.
> > >
> > > That's along the lines of what I was thinking--another cast (and
> > > perhaps an optional arg to intval()?) which would respect the
> > > base--maybe not separate (oct) or (hex)--or maybe so--or something
> > > like (intbase) which just respected the base (since octal and hex are
> > > the only ones strtol() claims to handle anyway). I admit that name is
> > > clumsy at best. :) As it stands is_numeric('0x24') returns true but
> > > intval('0x24') returns 0--which seems to conflict. Changing the
> > > existing cast would probably surprise a lot of people though :).
> >
> > A new cast is IMO no good idea. A cast is a way to enforce
> > converting to another TYPE, and that is not the case here.
> >
> > The default string -> int behaviour (is doesn't matter whether
> > implicit or explicit (resp. type-juggling and casting)) could
> > be improved to understand hex, but is definitely should NOT,
> > I repeat NOT understand octal numbers. Octal numbers
> > are obsolete (I've only seen them in chmod-like functions,
> > nowhere else.), and it would confuse a lot of people.
> > Mostly this function is called over user-supplied data,
> > and 90% of that users are still confused about why
> > the heck the internet uses forward-slashes, let alone
> > they know what octal means.
> > But it should be made possible of course, if you're certain
> > what you're doing.
> >
> > Summary:
> > - enhance string -> int conversion to understand hex.
> > - get an optional argument to intval as a possibility
> >   to make it understand octals.
> >
> > What WOULD be nice cast (i realise i'm now contradicting
> > myself) is (number)
> >   (number) $a
> > should be completely equivalent with
> >   0 + $a
> > that is, $a wil be converted to int if possible, but if it
> > is too large, or contains a fraction symbol (the dot)
> > or an exponent, it should be converted to float
> > instead.
> >
> >
> > Greetz,
> > Jeroen
> >
> >
> >
> >
> >
>
>

Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://www.A-Eskwadraat.nl/~jeroen




-- 
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 #10907 Updated: date() bug...

[rasmus]

ID: 10907
Updated by: rasmus
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Date/time related
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

Please read the documentation more closely.  The t modifier is the number of days in 
the month so 31 is indeed correct.

Previous Comments:
---

[2001-05-16 14:21:16] [EMAIL PROTECTED]
date() function does not work well

this code shown the date() function bug...



Result of above code is only "2001.05.31".

it's incorrect... correct result is "2001.5.17"

linux console command "date" work correctly...

===
My php Configure Line

./configure' '--with-apache=/usr/local/src/apache_1.3.19' 
'--with-sybase=/usr/local/freetds' '--enable-track-vars' '--disable-debug' 
'--enable-sysvsem' '--enable-sysvshm' '--enable-shmop'
===

---



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


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

Re: [PHP-DEV] removing ereg functions

[Sterling Hughes]

Rasmus Lerdorf wrote:

>>But, that all makes sense and tells me that it is not worth pursuing.
>>
>>Is the regex lib bundled with apache always as part of the core or just
>>included with certain modules?
>>
> 
> It is part of the core.
> 


As Apache 2.0, I believe PCRE is also a part of the Apache core?

-Sterling


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

[PHP-DEV] Bug #10907: date() bug...

[skysign]

From: [EMAIL PROTECTED]
Operating system: Redhat 7.0 kernel 2.2.16
PHP version:  4.0.5
PHP Bug Type: Date/time related
Bug description:  date() bug...

date() function does not work well

this code shown the date() function bug...



Result of above code is only "2001.05.31".

it's incorrect... correct result is "2001.5.17"

linux console command "date" work correctly...

===
My php Configure Line

./configure' '--with-apache=/usr/local/src/apache_1.3.19' 
'--with-sybase=/usr/local/freetds' '--enable-track-vars' '--disable-debug' 
'--enable-sysvsem' '--enable-sysvshm' '--enable-shmop'
===


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



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

Re: [PHP-DEV] removing ereg functions

[Rasmus Lerdorf]

> But, that all makes sense and tells me that it is not worth pursuing.
>
> Is the regex lib bundled with apache always as part of the core or just
> included with certain modules?

It is part of the core.

-Rasmus


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

Re: [PHP-DEV] removing ereg functions

[Brian Moon]

But, that all makes sense and tells me that it is not worth pursuing.

Is the regex lib bundled with apache always as part of the core or just
included with certain modules?

Brian Moon
--
dealnews.com, Inc.
Makers of dealnews & dealmac
http://dealnews.com/ | http://dealmac.com/

- Original Message -
From: "Rasmus Lerdorf" <[EMAIL PROTECTED]>
To: "Brian Moon" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, May 16, 2001 11:33 AM
Subject: Re: [PHP-DEV] removing ereg functions


> > No, sorry, I think you misunderstood my question.  I would just like to
see
> > a --disable-ereg option for configure.  I would never dream of removing
ereg
> > from PHP as a supported function set.  It would break Phorum and lots of
> > stuff I have written.
>
> I just don't see the point in this.  There are other functions like
> split() that rely on the ereg code, and since removing the code isn't
> actually going to save you anything as the library is non-optional in
> Apache, removing the hooks from PHP makes no sense.  I don't think
> disabling functions in PHP is a good way to enforce coding conventions.
>
> -Rasmus
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>
>



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

Re: [PHP-DEV] Integer casts broken or...?

[Jeroen]

> Brian Moon writes:
> > I know it would confuse me to have 0009 turned into an octal or hex if I
> > type cast it to (int).  When I think of (int), I only think of their
> > ultimate decimal value.  Perhaps there needs to be a new type cast
((hex)?
> > (oct)?) that will interpret variables in their hex or octal value.  I
know
> > it is still a long integer in value, but it is a different
representation of
> > that number.
>
> That's along the lines of what I was thinking--another cast (and
> perhaps an optional arg to intval()?) which would respect the
> base--maybe not separate (oct) or (hex)--or maybe so--or something
> like (intbase) which just respected the base (since octal and hex are
> the only ones strtol() claims to handle anyway). I admit that name is
> clumsy at best. :) As it stands is_numeric('0x24') returns true but
> intval('0x24') returns 0--which seems to conflict. Changing the
> existing cast would probably surprise a lot of people though :).

A new cast is IMO no good idea. A cast is a way to enforce
converting to another TYPE, and that is not the case here.

The default string -> int behaviour (is doesn't matter whether
implicit or explicit (resp. type-juggling and casting)) could
be improved to understand hex, but is definitely should NOT,
I repeat NOT understand octal numbers. Octal numbers
are obsolete (I've only seen them in chmod-like functions,
nowhere else.), and it would confuse a lot of people.
Mostly this function is called over user-supplied data,
and 90% of that users are still confused about why
the heck the internet uses forward-slashes, let alone
they know what octal means.
But it should be made possible of course, if you're certain
what you're doing.

Summary:
- enhance string -> int conversion to understand hex.
- get an optional argument to intval as a possibility
  to make it understand octals.

What WOULD be nice cast (i realise i'm now contradicting
myself) is (number)
  (number) $a
should be completely equivalent with
  0 + $a
that is, $a wil be converted to int if possible, but if it
is too large, or contains a fraction symbol (the dot)
or an exponent, it should be converted to float
instead.


Greetz,
Jeroen



-- 
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 #10906: mod_ssl and php oci8 interaction problem

[dawson_j]

From: [EMAIL PROTECTED]
Operating system: RedHat Linux 7.1
PHP version:  4.0.5
PHP Bug Type: OCI8 related
Bug description:  mod_ssl and php oci8 interaction problem 

When building apache, ssl and php4 with oci8 support statically, and compiling 
everything myself, things are great.
However,

When trying  to use RedHat's built in Apache server and mod_ssl, on both RedHat 
version 7.0 and 7.1,
The following events happen.

Scenario 1:
Using Apache without the mod_ssl rpm installed.
Build php 4.0.5 using apxs with-oci8

This works.

Scenario 2:
Using apache with the mod_ssl rpm installed.
build php4.0.5 using apxs without-oci8
This works.

Scenario 3.
Using apache with mod_ssl rpm installed,
build php4.0.5 using apxs with-oci8

httpd dies silently, no error message.

This method is also reproducable by loading the RedHat 7.1 SRPM for php version 
4.0.4pl1.
modify the spec file to include --with-oci8.
rebuild the rpm and install.

I have seen this particular problem in mailing lists, but not specifically described 
in detail. By trying all of 
these different combinations, I believe that something with the oci8 support is 
conflicting with mod_ssl.

Is this a problem of a missing -DEAPI flag?

I tried modifying the make file for it, but that didn't work either.




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



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

Re: [PHP-DEV] issues about domxml in 4.0.6

[Sterling Hughes]

Andrei Zmievski wrote:

> On Wed, 16 May 2001, Christian Stocker wrote:
> 
>>Hello
>>
>>As mentioned in bug #9896 the api for domxml seems to has changed a
>>lot...
>>it's now almost impossible to write code with domxml which works in 4.0.5
>>and 4.0.6.
>>
>>for example  $root->children() returns a completely different Array
>>(tagname instead of name and so on...).
>>
>>Does this make sense for a minor-update?
>>
>>And all the domxml function still just produce a segfault on 4.0.6. if
>>this is not supported anymore, fine ($root->children() instead of
>>domxml_children($root) works also in 4.0.5), but i'd prefer a fatal error
>>instead of a segfault :)
>>
>>Maybe I have to live with all these api-changes and as soon as all our
>>servers have 4.0.6, it won't be a problem for me. But I think i'm not the
>>only one which disturbs that a little bit.
>>
> 
> I fixed a few memory leaks I found in that extension, but my feeling
> is that there are still lots of them and also many bugs lurking in
> there. I don't know where Uwe is or what he plans to do with the
> extension..
> 


I've contacted Uwe, and if he doesn't object (or respond ;) within the 
next day or so, I'll revert the commit in the 4_0_6 branch (leaving head 
alone).

-Sterling


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

Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()

[Sterling Hughes]

Zeev Suraski wrote:

> At 01:40 15/5/2001, Sterling Hughes wrote:
> 
>> Sure, yeah.  But as a note, other big projects with huge user bases 
>> break compatibility as well, Perl, Apache, Python, to name three.
> 
> 
> It doesn't mean it's a good idea.


You no use logic on me!!! ;)


> 
>> And in its own way, C, is constantly breaking compat, the amount of 
>> times I've had to upgrade programs i've written, because a library 
>> changes is countless...
> 
> 
> Well, C's been pretty darned stable along the years, since it was 
> ANSI'fied.  C++ was a moving target.  I don't recall having to make any 
> significant changes in PHP's fairly-large codebase (as well as other 
> codebases I was working on along the years) due to standard changes, 
> except for, perhaps, the inline issues.  I definitely wouldn't consider 
> this to be a precedence for making downwards incompatible changes.
> 


I'm talking about "library changes", such as a change of syntax in the 
expat library or the libxml library that made you change your code, its 
not the core of C itself, but rather the libraries surrounding it that 
do change.


>>> On the other hand, I really don't like the bloat either.
>>> So, what should be done?  In my opinion, the approach of adding 
>>> E_NOTICE notifications to functions doesn't cut it;  It won't 
>>> significantly improve the situation.  I think we should go in a 
>>> different path (or an 'extended' path) - IMHO, the best approach 
>>> would be adding some sort of a 'LEAN_AND_MEAN' mode to PHP's build.   
>>> When built in this mode, bloat code will be #define'd away, or 
>>> displayed as 'deprecated' in a similar manner to the way 
>>> warn_not_available works.  That gives everyone almost everything - 
>>> people who care about the bloat (like me) will build it in 
>>> LEAN_AND_MEAN mode, hosting companies or legacy sites, who care most 
>>> about having their code go on working with minimum hassle - won't 
>>> mind the added bloat.  If kept closely documented, people who care 
>>> enough about the bloat will be able to go through the checklist, make 
>>> sure their sites are compatible with it, and turn this mode on.
>>
>>
>> well, you can't have your cake and eat it too.
> 
> 
> No need to get into metaphores - I'm suggesting a very specific 
> solution.  What's the cake and who's eating it, I don't know :)
> 


Aww. Don't ruin all my fun. ;)

The basic idea is this.  Sometimes in order to make the language 
better/less bloated/easier to use.  You need to break compatibility. 
The saying "you can't have your cake and eat it too" means simply that 
you can't have it both ways.


>> (did I say this before wh

en talking about backwards compat, 
>> AHH, hey Zeev, is PHP an OO language? ;)
> 
> 
> I'm not sure how it's related to downwards compatibility...
> 


see above.


>> Well, what I intended to do was mark it with an E_NOTICE for this 
>> release and if no one complained with my latest commit, redo the 
>> call_user_method*() documentation as well as a big ass news entry.
>>
>> Next release, bump up the level to E_WARNING, and add a nice sized 
>> NEWS entry about that.
>>
>> Finally, third release, say buh-bye to good old call_user_method, and 
>> replace it with a new function, warn_depreciated.
> 
> 
> Bare in mind that many people don't upgrade on every release.  I'd argue 
> even that most people don't, and only upgrade every 2 or 3 releases, 
> that is, if they upgrade at all.  So for them, this entire process will 
> be a single and swift blow in the face, despite your efforts.
> Also bare in mind that a very large percentage of the developers don't 
> *want* to be forced to change their code, and consider it to be a 
> misfeature in the language if it breaks downwards compatibility in 
> between releases, regardless of whether they get a clear notification 
> about it or not.
> 
>> However, you have a very good point, ISP's will be pissed if we 
>> drastically change the syntax.
> 
> 
> They're pissed even if we slightly change the syntax, too, as a matter 
> of fact.  It's the small downwards compatibility breaks that make them 
> say "the hell with it, I'm not upgrading".
> 


yeah, I was unclear, I meant that, any compatibility breaking change == 
drastic change ;)


>> And your solution seems good, I'd just do the reverse (semantically 
>> speaking), so instead, what I think we should do is have a 
>> --enable-backwards-compat mode.  This mode would be for ISP's and 
>> people who need the bug fixes, etc. in new PHP releases, but don't 
>> want to upgrade their scripts.
>>
>> So, when deprecating a feature, the following is employed:
>>
>> minor release 1:  non backwards compat mode
>>php_error(E_WARNING, "DEPRECATED FEATURE BUM!");
>>
>> minor release 2:
>>now the function warn_deprecated replaces the deprecated function 
>> in non backwards compat mode, backwards compat mode is the only place 
>> the function is no longer present.  The function code i

Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()

[Sterling Hughes]

Harald Radi wrote:

>>new way:
>>call_user_func(array(&$obj, "method"), "method", "args", "go", "here");
>>
> ---^
> isn't 'pass by reference' deprecated too ?
> 


yes, so?  the above is not pass by reference, your passing an array to 
the function, not a reference to an array.

-sterling


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

Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()

[Harald Radi]

> new way:
> call_user_func(array(&$obj, "method"), "method", "args", "go", "here");
---^
isn't 'pass by reference' deprecated too ?

harald.

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

Re: [PHP-DEV] removing ereg functions

[Rasmus Lerdorf]

> wouldn't it be in at least the best interest to have split and other functions to 
>use preg instead of ereg?
> this might add some bloat to code, but it might be an interesting default speedup.

No, because POSIX and Perl-style regular expressions are not compatible.
That's why we have a preg_split() function.

> by all means, keep ereg.  unless you can get ereg to act just like preg, you can't 
>get rid of it.

And vice versa.  The two libs are not compatible.

-Rasmus


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

Re: [PHP-DEV] removing ereg functions

[spencer 'sporty' portee]

wouldn't it be in at least the best interest to have split and other functions to use 
preg instead of ereg?
this might add some bloat to code, but it might be an interesting default speedup. 

by all means, keep ereg.  unless you can get ereg to act just like preg, you can't get 
rid of it.



On Wed, May 16, 2001 at 09:33:48AM -0700, Rasmus Lerdorf wrote:
> > No, sorry, I think you misunderstood my question.  I would just like to see
> > a --disable-ereg option for configure.  I would never dream of removing ereg
> > from PHP as a supported function set.  It would break Phorum and lots of
> > stuff I have written.
> 
> I just don't see the point in this.  There are other functions like
> split() that rely on the ereg code, and since removing the code isn't
> actually going to save you anything as the library is non-optional in
> Apache, removing the hooks from PHP makes no sense.  I don't think
> disabling functions in PHP is a good way to enforce coding conventions.
> 
> -Rasmus
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 

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

Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()

[Rasmus Lerdorf]

> >Also bare in mind that a very large percentage of the developers don't
> >*want* to be forced to change their code, and consider it to be a
>
> Who's forcing anybody to update anyway?
>
> >misfeature in the language if it breaks downwards compatibility in between
> >releases, regardless of whether they get a clear notification about it or not.
>
> It seems like everybody just ignores my emails..oh well. So I can rant
> again. >:-p
>
> Have you ever heard that you can also change that number in the middle?
>   4.0.6
> This one^
>
> It can be something else than an ellipse called zero..it can even be a
> number 1!!! Whoa! Never thougth about that?!

Sure, but a version number if quite arbitrary and the way we have always
done this is to consider the second digit for large changes.  The fact
that we haven't had a .1 yet is not really relevant.  I don't see why you
are making such a big deal out of a version number.

> Or is that number in the middle reserved for something special? Something
> the 'group' only know of and don't want to tell us lower class people?
> Maybe the 'group' could take their thumbs out of their asses and
> start DOING something? And maybe they could start listening to new ideas
> for once and a while. Or is the 'group' nowadays only Zeev/Andi ?
>
> It would be really nice to hear from the other members of the 'group' also
> as it really seems like the only ones speaking for it are Zeev/Andi..
>
> Or could someone please define the function of this mysterious 'group' ?
> (And please, someone else than Zeev/Andi.. :)

[EMAIL PROTECTED] is just for administrative purposes.  Licensing issues and
such.  The main day-to-day thing done by [EMAIL PROTECTED] is sys-admin stuff
like keeping all the *.php.net machines and services working, managing cvs
accounts, etc.  Lots of grunt work.  All relevant development discussion
is done on php-dev.  Occasionally we will discuss development stuff
internally, but that is more because we know each other well and want to
bounce ideas off of each other before we make idiots of ourselves on
php-dev.

It is not some elite high-and-mighty group that make arbitrary decisions.
It is simply a small group of core PHP people who have been involved with
PHP development for a long time.

-Rasmus


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

Re: [PHP-DEV] removing ereg functions

[Vlad Krupin]

Next thing you know is that we have --disable-(your favorite function 
here) for half the functions in php. That's a bad precedent, IMHO.
Vlad

Brian Moon wrote:

> No, sorry, I think you misunderstood my question.  I would just like to see
> a --disable-ereg option for configure.  I would never dream of removing ereg
> from PHP as a supported function set.  It would break Phorum and lots of
> stuff I have written.
> 
> I understand your reaction now Rasmus.  Sorry for the confusion.
> 
> Brian Moon
> --
> dealnews.com, Inc.
> Makers of dealnews & dealmac
> http://dealnews.com/ | http://dealmac.com/
> 
> - Original Message -
> From: "Zeev Suraski" <[EMAIL PROTECTED]>
> To: "Brian Moon" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Wednesday, May 16, 2001 3:17 AM
> Subject: Re: [PHP-DEV] removing ereg functions
> 
> 
>> At 08:50 16/5/2001, Brian Moon wrote:
>> 
>>> Is it possible to remove the ereg functions?  We have a strict policy to
>>> only use preg as they are more reliable and faster.  So, I am not to
>> 
> happy
> 
>>> that PHP is bloated with these ereg functions.
>>> 
>>> Any thoughts?
>> 
>> Wow, it's like a plague out there. :)
>> 
>> No way.  ereg() has got to be used by millions of code lines around the
>> world.  I don't see it being removed in this millennium.  These functions
>> can fit nicely into the lean-and-mean approach.
>> 
>> Zeev
>> 
>> 
>> 



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

Re: [PHP-DEV] removing ereg functions

[Brian Moon]

I guess it just seems a little odd too me that PCRE is optional and POSIX is
not.  I know the history and all.

Brian Moon
--
dealnews.com, Inc.
Makers of dealnews & dealmac
http://dealnews.com/ | http://dealmac.com/

- Original Message -
From: "Rasmus Lerdorf" <[EMAIL PROTECTED]>
To: "Brian Moon" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, May 16, 2001 11:33 AM
Subject: Re: [PHP-DEV] removing ereg functions


> > No, sorry, I think you misunderstood my question.  I would just like to
see
> > a --disable-ereg option for configure.  I would never dream of removing
ereg
> > from PHP as a supported function set.  It would break Phorum and lots of
> > stuff I have written.
>
> I just don't see the point in this.  There are other functions like
> split() that rely on the ereg code, and since removing the code isn't
> actually going to save you anything as the library is non-optional in
> Apache, removing the hooks from PHP makes no sense.  I don't think
> disabling functions in PHP is a good way to enforce coding conventions.
>
> -Rasmus
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>
>


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

Re: [PHP-DEV] removing ereg functions

[Rasmus Lerdorf]

> No, sorry, I think you misunderstood my question.  I would just like to see
> a --disable-ereg option for configure.  I would never dream of removing ereg
> from PHP as a supported function set.  It would break Phorum and lots of
> stuff I have written.

I just don't see the point in this.  There are other functions like
split() that rely on the ereg code, and since removing the code isn't
actually going to save you anything as the library is non-optional in
Apache, removing the hooks from PHP makes no sense.  I don't think
disabling functions in PHP is a good way to enforce coding conventions.

-Rasmus


-- 
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 #10905: ImageGif (ImagePNG) output uncompressed

[pumuckel]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0.5
PHP Bug Type: Output Control
Bug description:  ImageGif (ImagePNG) output uncompressed

Using the compression ob_gzhandler all HTML Pages get compressed well. But dynamic 
generated Images don't get compressed.

Header of the output says, it is compressed, but the data following the header isn't. 
So those images can't be displayed (by at least netscape)

Thanks for the patch, ;-)

 mike

PS: Don't tell me that it isn't useful to gzip images, but if you have switched 
compression to 'enabled' in your php.ini file and you are creating images on the fly, 
you'll need it to handle this case correctly.


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



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

Re: [PHP-DEV] removing ereg functions

[Brian Moon]

The problem is not the PHP C code.  It is the regex library.

Brian Moon
--
dealnews.com, Inc.
Makers of dealnews & dealmac
http://dealnews.com/ | http://dealmac.com/


- Original Message -
From: "John Lim" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 16, 2001 10:51 AM
Subject: Re: [PHP-DEV] removing ereg functions


> In my mind the problem that Brian raised is that ereg is slow.
> The solution is not to ban eregi but to fix it by performance tuning
> the C code.
>
> Just my 2c worth.
>
> John Lim
>
> Rasmus Lerdorf <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > > That is why I am asking.  Is there a core reason that the ereg
functions
> > > have to be there?  I could extend this to other functions as well of
> course.
> > > But this set in particular I have wondered about.
> >
> > 1) There was no PCRE library when I first added regex support to PHP.
> >Henry Spencer's regex library, although not my initial choice, was
> >chosen because that is what came bundled with Apache.
> >
> > 2) The ereg_* functions implement the Posix 1003.2 extended regular
> >expression standard.  The same regular expressions found in the
> >Unix command line utils like grep, egrep and fgrep.  The preg_*
> >functions support the perverted Perl-style regular expressions.
> >
> > 3) Removing the ereg_* functions would cause a backward compatibility
> >nightmare.  Thousands, if not hundreds of thousands of scripts out
> >there would have to be converted.
> >
> > 4) If you are using Apache you already have the library linked in
anyway.
> >Removing PHP support wouldn't save you any "bloat".  Not that this
> >"bloat" is at all significant on any modern OS with shared pages.
> >
> > -Rasmus
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>
>


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

Re: [PHP-DEV] LDAP V3 Server Side Sorting

[David Giffin]

If we are to follow the Netscape API then we should have a
ldap_search_ext() function which we can pass the results of the
ldap_create_sort_control(), other server side and client side controls.
We can then incorporate "Virtual List View Control" and "Entry Change
Notification Control" along with the rest of LDAP Version 3
functionality.

David


On Wed, 16 May 2001, Stig Venaas wrote:

> On Tue, May 15, 2001 at 06:17:11PM -0700, David Giffin wrote:
> > 
> > Hello,
> > 
> > I added in a function to provide server side sorting on searches. This is
> > a LDAP version 3 specific function, and uses the Netscape API so I have
> > ifdef'ed the new function. It adds a "sortstr" attriubte to the 
> > ldap_search() function that already exists in php. There might be a better
> > way to incorporate the code into php, but here is my first attempt.
> > 
> > proto int ldap_sort_search(int link, string base_dn, string filter
> > [, array attrs [, string sortstr [, int attrsonly [, int sizelimit
> > [, int timelimit [, int deref])
> 
> First of all, in order to be backwards compatible, the argument must be
> added to the end. I'm a bit worried that the search function is
> getting rather complicated.
> 
> Sorting could be done using ldap_set_option() which we already got, the
> problem is that the argument has a complicated structure. It's BER
> encoded sequence of sequence. ldap_set_option() could perhaps be made
> to take array a value and do BER encoding etc. but that's complicated.
> 
> The solution I prefer I think, is to mirror the Netscape API and do
> something like
> ldap_create_sort_control(ldap, sortkeylist, 1, &sortctrl);
> 
> How about
> 
> proto int ldap_server_sort(int link, array attrs, int
> reverse)
> 
> All subsequent searches should then use this. We could turn it off if
> it's called with empty attrs array. When it is on, searches should then
> include this control, like you did.
> 
> Maybe my solution sounds ugly, it is more complicated to implement.
> I'm just starting to get concerned with all the arguments to ldap_search()
> and I think to have it close to the C API if possible. And if you are to
> have backwards compatibility, adding it as final argument to ldap_search()
> means that users always must supply all the other optional arguments.
> 
> Stig
> 


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

Re: [PHP-DEV] removing ereg functions

[John Lim]

In my mind the problem that Brian raised is that ereg is slow.
The solution is not to ban eregi but to fix it by performance tuning
the C code.

Just my 2c worth.

John Lim

Rasmus Lerdorf <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > That is why I am asking.  Is there a core reason that the ereg functions
> > have to be there?  I could extend this to other functions as well of
course.
> > But this set in particular I have wondered about.
>
> 1) There was no PCRE library when I first added regex support to PHP.
>Henry Spencer's regex library, although not my initial choice, was
>chosen because that is what came bundled with Apache.
>
> 2) The ereg_* functions implement the Posix 1003.2 extended regular
>expression standard.  The same regular expressions found in the
>Unix command line utils like grep, egrep and fgrep.  The preg_*
>functions support the perverted Perl-style regular expressions.
>
> 3) Removing the ereg_* functions would cause a backward compatibility
>nightmare.  Thousands, if not hundreds of thousands of scripts out
>there would have to be converted.
>
> 4) If you are using Apache you already have the library linked in anyway.
>Removing PHP support wouldn't save you any "bloat".  Not that this
>"bloat" is at all significant on any modern OS with shared pages.
>
> -Rasmus
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>



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

[PHP-DEV] Bug #10904 Updated: php.exe accesses unreadable memory and crashes

[pax]

ID: 10904
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating system: WINNT SP4
PHP Version: 4.0.5
Description: php.exe accesses unreadable memory and crashes

This script reproduces the bug on my machine:

";
   print "";
   print "   bug";
   print "";
   print "";
   for ($i=0; $i<1000; $i++) {
  print "hello" ;
   }
   print "";
   print "";
?>

Change 1000 to 333 and the bug disappears,
Change 1000 to 2 and the bug disappears.


Previous Comments:
---

[2001-05-16 11:02:35] [EMAIL PROTECTED]
WINNT SP4, APACHE 1.3.14, PHP 4.0.4 and 4.0.5

I cannot make a gdb backtrace, but I can give you the following:

1) It is an access violation -- the instruction at 0x0dsd5973 referenced 0x.  
the memory could not be read.

2) It always occurs near the end of a script and is not related to what HTML happens 
to be generated.  Most scripts do not show the error at all, but when one does only 
changing the size of the output (either very small or very large) will suppress it.  

3) After clearing the error (by clicking OK on the error message on the server), the 
full HTML is always produced correctly.  However, until OK is clicked, the client is 
left waiting for the last 1K or so of output).  

4) It is defintely related to the size of the output.  Scripts that make output 
smaller then 1K never show the error.  Larger scripts may or may not show the error, 
but when they do, the error can always be removed by making the script generate a very 
large output (~100K). I just repeated the same content x times. Once x is large 
enough, the bug goes away.

5) On my system, calling phpinfo causes it --  -- but only on the 
second and subsequent calls after rebooting the server.  Just starting and stopping 
Apache does not allow the first good call to succeed--the server must be rebooted.

6) changing imlicit_flush, output_buffering, and memory_limit in php.ini do not fix 
it, but might(???) alter the size of output that exhibts the problem.  flush() in the 
code does not fix it.

7) I theorize it is related to some final cleanup or garbage collection code.  

8) I first saw it in 4.0.4 and upgraded to 4.0.5 hoping to see it go away.  It did 
not, but again the size of output that shows the error might(???) have changed. One 
point about the upgrade, I could not copy msvcrt.dll to the system root because it was 
always locked by the OS, even after closing all closable services.  My msvcrt.dll is 
dated three days earlier than the one distributed with PHP 4.0.4 and 4.0.5.  There 
appears to be no way to change it.

--This bug could easily exist under another OS, but be invisible (and harmless) if the 
OS does not generate an error message for the address violation.  

Hope this is helpful.  Feel free to contact me.

Steve 



---


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


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

Re: [PHP-DEV] removing ereg functions

[Zeev Suraski]

Aha, ok :)  That makes much more sense indeed.


At 17:52 16/5/2001, Brian Moon wrote:
>No, sorry, I think you misunderstood my question.  I would just like to see
>a --disable-ereg option for configure.  I would never dream of removing ereg
>from PHP as a supported function set.  It would break Phorum and lots of
>stuff I have written.
>
>I understand your reaction now Rasmus.  Sorry for the confusion.
>
>Brian Moon
>--
>dealnews.com, Inc.
>Makers of dealnews & dealmac
>http://dealnews.com/ | http://dealmac.com/
>
>- Original Message -
>From: "Zeev Suraski" <[EMAIL PROTECTED]>
>To: "Brian Moon" <[EMAIL PROTECTED]>
>Cc: <[EMAIL PROTECTED]>
>Sent: Wednesday, May 16, 2001 3:17 AM
>Subject: Re: [PHP-DEV] removing ereg functions
>
>
> > At 08:50 16/5/2001, Brian Moon wrote:
> > >Is it possible to remove the ereg functions?  We have a strict policy to
> > >only use preg as they are more reliable and faster.  So, I am not to
>happy
> > >that PHP is bloated with these ereg functions.
> > >
> > >Any thoughts?
> >
> > Wow, it's like a plague out there. :)
> >
> > No way.  ereg() has got to be used by millions of code lines around the
> > world.  I don't see it being removed in this millennium.  These functions
> > can fit nicely into the lean-and-mean approach.
> >
> > Zeev
> >
> >
> >

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


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

[PHP-DEV] Bug #10904: php.exe accesses unreadable memory and crashes

[pax]

From: [EMAIL PROTECTED]
Operating system: WINNT SP4
PHP version:  4.0.5
PHP Bug Type: Reproducible crash
Bug description:  php.exe accesses unreadable memory and crashes

WINNT SP4, APACHE 1.3.14, PHP 4.0.4 and 4.0.5

I cannot make a gdb backtrace, but I can give you the following:

1) It is an access violation -- the instruction at 0x0dsd5973 referenced 0x.  
the memory could not be read.

2) It always occurs near the end of a script and is not related to what HTML happens 
to be generated.  Most scripts do not show the error at all, but when one does only 
changing the size of the output (either very small or very large) will suppress it.  

3) After clearing the error (by clicking OK on the error message on the server), the 
full HTML is always produced correctly.  However, until OK is clicked, the client is 
left waiting for the last 1K or so of output).  

4) It is defintely related to the size of the output.  Scripts that make output 
smaller then 1K never show the error.  Larger scripts may or may not show the error, 
but when they do, the error can always be removed by making the script generate a very 
large output (~100K). I just repeated the same content x times. Once x is large 
enough, the bug goes away.

5) On my system, calling phpinfo causes it --  -- but only on the 
second and subsequent calls after rebooting the server.  Just starting and stopping 
Apache does not allow the first good call to succeed--the server must be rebooted.

6) changing imlicit_flush, output_buffering, and memory_limit in php.ini do not fix 
it, but might(???) alter the size of output that exhibts the problem.  flush() in the 
code does not fix it.

7) I theorize it is related to some final cleanup or garbage collection code.  

8) I first saw it in 4.0.4 and upgraded to 4.0.5 hoping to see it go away.  It did 
not, but again the size of output that shows the error might(???) have changed. One 
point about the upgrade, I could not copy msvcrt.dll to the system root because it was 
always locked by the OS, even after closing all closable services.  My msvcrt.dll is 
dated three days earlier than the one distributed with PHP 4.0.4 and 4.0.5.  There 
appears to be no way to change it.

--This bug could easily exist under another OS, but be invisible (and harmless) if the 
OS does not generate an error message for the address violation.  

Hope this is helpful.  Feel free to contact me.

Steve 




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



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

Re: [PHP-DEV] removing ereg functions

[Brian Moon]

No, sorry, I think you misunderstood my question.  I would just like to see
a --disable-ereg option for configure.  I would never dream of removing ereg
from PHP as a supported function set.  It would break Phorum and lots of
stuff I have written.

I understand your reaction now Rasmus.  Sorry for the confusion.

Brian Moon
--
dealnews.com, Inc.
Makers of dealnews & dealmac
http://dealnews.com/ | http://dealmac.com/

- Original Message -
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Brian Moon" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, May 16, 2001 3:17 AM
Subject: Re: [PHP-DEV] removing ereg functions


> At 08:50 16/5/2001, Brian Moon wrote:
> >Is it possible to remove the ereg functions?  We have a strict policy to
> >only use preg as they are more reliable and faster.  So, I am not to
happy
> >that PHP is bloated with these ereg functions.
> >
> >Any thoughts?
>
> Wow, it's like a plague out there. :)
>
> No way.  ereg() has got to be used by millions of code lines around the
> world.  I don't see it being removed in this millennium.  These functions
> can fit nicely into the lean-and-mean approach.
>
> Zeev
>
>
>


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

[PHP-DEV] Bug #10878 Updated: Compile problem with IMAP support

[sean . truman]

ID: 10878
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: IMAP related
Operating system: sparc-sun-solaris2.7
PHP Version: 4.0.5
Description: Compile problem with IMAP support

--with-imap=../imap-2001 (Same thing)
--with-imap=/usr/include (Same thing)

Previous Comments:
---

[2001-05-16 10:20:42] [EMAIL PROTECTED]
cp c-client.a /usr/lib/libc-client.a
cp rfc822.h /usr/include
cp linkage.h /usr/include
cp mail.h /usr/include


---

[2001-05-16 09:31:27] [EMAIL PROTECTED]
Sorry no I have tried it with --with-imap I am running the most recent version 
ftp://ftp.cac.washington.edu/imap/imap.tar.Z

---

[2001-05-16 00:17:48] [EMAIL PROTECTED]
Is there really a path 'y' in your system? 
What version of c-client you have?
And where is it located? and the header files?

--Jani



---

[2001-05-15 10:14:45] [EMAIL PROTECTED]
configure line is:
./configure --with-mysql=/usr  
--with-imap=y  
--with-apache=../apache_1.3.19 
--enable-track-vars
--enable-register-globals  
--enable-trans-sid  


make[2]: Entering directory `/usr/local/src/php-4.0.5/main'
 
gcc  -I. -I/usr/local/src/php-4.0.5/main -I/usr/local/src/php-4.0.5/main 
-I/usr/local/src/php-4.0.5 -I/usr/local/src/apache_1.3.19/s
rc/include -I/usr/local/src/apache_1.3.19/src/os/unix -I/usr/local/src/php-4.0.5/Zend 
-I/usr/include/mysql -I/usr/local/src/php-4.0.
5/ext/xml/expat/xmltok -I/usr/local/src/php-4.0.5/ext/xml/expat/xmlparse 
-I/usr/local/src/php-4.0.5/TSRM  -D_POSIX_PTHREAD_SEMANTICS
 -DSUPPORT_UTF8 -DXML_BYTE_ORDER=21 -g -O2  -c main.c && touch main.lo 
 
gcc  -I. -I/usr/local/src/php-4.0.5/main -I/usr/local/src/php-4.0.5/main 
-I/usr/local/src/php-4.0.5 -I/usr/local/src/apache_1.3.19/s
rc/include -I/usr/local/src/apache_1.3.19/src/os/unix -I/usr/local/src/php-4.0.5/Zend 
-I/usr/include/mysql -I/usr/local/src/php-4.0.
5/ext/xml/expat/xmltok -I/usr/local/src/php-4.0.5/ext/xml/expat/xmlparse 
-I/usr/local/src/php-4.0.5/TSRM  -D_POSIX_PTHREAD_SEMANTICS
 -DSUPPORT_UTF8 -DXML_BYTE_ORDER=21 -g -O2  -c internal_functions.c && touch 
internal_functions.lo  
In file included from internal_functions.c:32: 
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:50: parse error before `MAILSTREAM'   
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:50: warning: no semicolon at end of 
struct or union
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:58: parse error before `}'
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:58: warning: data definition has no type 
or storage class  
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:61: parse error before `SIZEDTEXT'
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:61: warning: no semicolon at end of 
struct or union
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:65: parse error before `}'
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:65: warning: data definition has no type 
or storage class  
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:68: parse error before `SIZEDTEXT'
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:68: warning: no semicolon at end of 
struct or union
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:70: conflicting types for `next'  
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:64: previous declaration of `next'
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:71: parse error before `}'
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:71: warning: data definition has no type 
or storage class  
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:156: parse error before `STRINGLIST'  
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:156: warning: no semicolon at end of 
struct or union   
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:157: warning: data definition has no type 
or storage class

[PHP-DEV] Bug #10898 Updated: is_dir && filetype return wrong values

[cynic]

ID: 10898
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Filesystem function related
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

this is bogus. you have to either chdir() into the $parent or is_dir() the full path.

Previous Comments:
---

[2001-05-16 08:35:02] [EMAIL PROTECTED]
A little script that should echo alle filetypes of all files in any subdir of the 
parent provided. 
Now I use opendir to test wether the file is a dir, but this isn't a good solution, is 
it?

The is_dir() allways returns false
the filetype() allwyas returns dir




---

[2001-05-16 06:23:07] [EMAIL PROTECTED]
Please provide a short script so that we can reproduce it.

Derick

---

[2001-05-16 05:44:07] [EMAIL PROTECTED]
Hello,

I'm running php 4.0.5 on my win ME & Win NT 4.0 and I have experienced 2 functions 
returning the wrong values. I don't know if this bug is allready reported.

the is_dir() allways returns false except for "." && ".."
the filetype() allways returns dir

---



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


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

Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()

[Cynic]

Hi Andrei.

Yes, that's how it should be, but not how it is. At least I've been
observing PHP 4.0.x evolve dramatically with compat breakage included.

At 08:34 16.5. 2001 -0500, Andrei Zmievski wrote:
>As far as your question about the version numbers, the middle digit gets
>bumped up when we plan some changes that will break backwards
>compatibility and implement features in the core language. So, yes, it
>is something special, it's not for bug fixes or extension changes.
>
>-Andrei



[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
 - Book of Installation chapt 3 sec 7 


-- 
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 #10902 Updated: Possible security hole via external modification of session vars

[cynic]

ID: 10902
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: *Session related
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

this could only happen with a misconfigured PHP - you would have to set it to register 
globals AND extract GET/POST data AFTER session data.

proper configuration is an admin reponsibility.

Previous Comments:
---

[2001-05-16 10:19:23] [EMAIL PROTECTED]
Not really a bug, just an issue.

---

[2001-05-16 10:17:14] [EMAIL PROTECTED]
This is kind of similar to the old file upload problem, where you could set variables 
in a POST.

In some cases (depends on the way the code is written), if a site stores login status 
(eg. user name, etc) in session variables after an authorisation check, it is possible 
to pass values as the same-named session vars, and therefore actually bypass the 
authorisation step getting access to restricted areas.


---



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


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

[PHP-DEV] Bug #8672 Updated: Crash when returning a variable from function as argument

[bf]

ID: 8672
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: Variables related
Operating system: Redhat Linux 6.2
PHP Version: 4.0.4
Description: Crash when returning a variable from function as argument

I can't reproduce this with 4.0.5. Seems to be fixed ;)


Previous Comments:
---

[2001-05-16 01:02:47] [EMAIL PROTECTED]
Does this happen with PHP 4.0.5 or not?

--Jani


---

[2001-04-28 14:45:15] [EMAIL PROTECTED]
Can you try to reprocude this when php 4.0.5 will be released next week? 

---

[2001-01-12 05:30:39] [EMAIL PROTECTED]
I had code like this:
$user = new eZUser( $session->variable("AuthenticatedUser" ) );

And I noticed now that this creates a segfault in php.

The workaround is changing the code to:

$val = $session->variable( "AuthenticatedUser" );
$user = new eZUser( $val );


The code worked with php-4.0.3pl1 and has worked with 
4.0.4, but it's reproduceable and I think it's a PHP bug.

The eZSession::variable() function returns a string value.

I've tested it with 4.0.4pl1 and the bug is still there.

---


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


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

Re: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] PHP 4.0.6RC1 ready for testing

[Daniel Beulshausen]

At 14:19 16.05.2001 +0200, Petr Cech wrote:
>On Wed, May 16, 2001 at 12:44:39PM +0200 , Hellekin O. Wolf wrote:
> >*** I just downloaded it and got some warning about a missing MSVCR70.dll :
> > it seems to me that previous discussions elsewhere stated
> > quite new, like a .NET thing... Sounds like libtool-1.4 on Debian to me =8\

people not having .Net installed would experience some problems when trying 
to use extensions that are relying upon openssl like the curl or openssl 
extension.
http://www.php4win.de/openssl-0.9.6a.zip includes updated libaries that 
fixes that issue (can be used for 4.0.5 as well)

daniel

/*--
daniel beulshausen - [EMAIL PROTECTED]
using php on windows? http://www.php4win.de


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

[PHP-DEV] Bug #7821 Updated: Unresolved symbol with GD

[mad]

ID: 7821
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: *Configuration Issues
Operating system: HP-UX 10.20
PHP Version: php4-200105160045
Description: Unresolved symbol with GD

Okay, with the build php4-200105160045, I've this config message error :

...
checking for the location of libjpeg... yes
checking for jpeg_read_header in -ljpeg... yes
checking for the location of libpng... yes
checking for png_info_init in -lpng... yes
./configure[6]: no:  not found.
checking for the location of libXpm... yes
checking for XpmFreeXpmImage in -lXpm... no
configure: error: libXpm.(a|so) or libX11.(a|so) not found!

In config.log : 

...
configure:18240: checking for the location of libXpm
configure:18288: checking for XpmFreeXpmImage in -lXpm
configure:18309: gcc -o conftest -O2  -DHPUX10 -DMOD_SSL=208101 -DUSE_HSREGEX -DEAPI 
-DUSE_EXPAT  -L/PKl01h01/soft/web/lib -L/PKl01h01/soft/web/lib -L/PKl01h01/so
ft/web/src/php/lib -L/PKl01h01/soft/web/src/php/lib conftest.c -lXpm
  -L/PKl01h01/soft/web/lib -lX11
 -lpng -lz -ljpeg -lcrypt -lm  1>&5
/usr/ccs/bin/ld: Can't find library for -lX11
collect2: ld returned 1 exit status
configure: failed program was:
#line 18298 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply.  */
char XpmFreeXpmImage();

int main() {
XpmFreeXpmImage()
; return 0; }

Any idea ?
Thx :)
JC

Previous Comments:
---

[2001-05-16 01:06:00] [EMAIL PROTECTED]
What does it say in config.log about this ?
In the end of it.

And could you please try with latest snapshot from
http://snaps.php.net/ as the configure script for
GD has gone through a face lift.

--Jani


---

[2001-05-15 15:02:31] [EMAIL PROTECTED]
Hellow,

Here's the feedback : 

When I add --with-xpm-dir=..., the configure program failed : 

...
checking for libjpeg (needed by gd-1.8+)... yes
checking for jpeg_read_header in -ljpeg... yes
checking for libXpm (needed by gd-1.8+)... yes
checking for XpmFreeXpmImage in -lXpm... no
no
checking whether to include GD support... yes (static)
checking for gdImageString16 in -lgd... no
checking for gdImagePaletteCopy in -lgd... no
checking for gdImageColorClosestHWB in -lgd... no
checking for compress in -lz... no
checking for png_info_init in -lpng... no
checking for gdImageColorResolve in -lgd... no
checking for gdImageCreateFromPng in -lgd... no
checking for gdImageCreateFromGif in -lgd... no
checking for gdImageWBMP in -lgd... no
checking for gdImageCreateFromJpeg in -lgd... no
checking for gdImageCreateFromXpm in -lgd... no
checking whether to include FreeType 1.x support... yes
checking for T1lib support... no
checking whether to include GNU gettext support... no
checking for gmp support... no
checking for Hyperwave support... no
checking for ICAP support... no
checking for iconv support... no
checking for Kerberos support in IMAP... no
checking for SSL support in IMAP... no
checking for IMAP support... no
checking for Informix support... no
checking for Ingres II support... no
checking for InterBase support... no
checking for ircg support... no
checking for Java support... no
checking whether to include LDAP support... no
checking for MCAL support... no
checking for mcrypt support... no
checking for mhash support... no
checking whether to include ming support... no
checking for mnoGoSearch support... no
checking for mSQL support... no
checking for Muscat support... no
checking for MySQL support... no
checking for Oracle-OCI8 support... no
checking for Adabas support... no
checking for SAP DB support... no
checking for Solid support... no
checking for IBM DB2 support... no
checking for Empress support... no
checking for Velocis support... no
checking for a custom ODBC support... no
checking for iODBC support... no
checking for Easysoft ODBC-ODBC Bridge support... no
checking for unixODBC support... no
checking for OpenLink ODBC support... no
checking for DBMaker support... no
checking for Oracle-ORACLE support... no
checking for Ovrimos SQL Server support... no
checking whether to include PCRE support... yes
checking for memmove... (cached) yes
checking whether to include PDFlib support... yes
checking for libz needed by pdflib 3.x... already zlib support
checking for jpeg_read_header in -ljpeg... (cached) yes
checking for png_create_info_struct in -lpng... no
no
checking for TIFFOpen in -ltiff... no
no
checking for PDF_show_boxed in -lpdf... no
configure: error: pdflib extension requires pdflib 3.x.

I'll become crazy :p

An idea ?
Thx :)


---

[2001-04

[PHP-DEV] Bug #10903: Output buffering crashs PHP when mail function is invoked

[carlos . a . viana]

From: [EMAIL PROTECTED]
Operating system: Win98
PHP version:  4.0.5
PHP Bug Type: Output Control
Bug description:  Output buffering crashs PHP when mail function is invoked

This will crash PHP:

ob_start("ob_gzhandler");
echo "something";
mail (.);

but this will not:

ob_start("ob_gzhandler");
echo "something";
ob_end_flush();
mail (.);

Note: I don't have any mail server installed. The mail function should report an 
error, but PHP crashes instead.


-- 
Edit Bug report at: http://bugs.php.net/?id=10903&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 #10878 Updated: Compile problem with IMAP support

[sean . truman]

ID: 10878
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: IMAP related
Operating system: sparc-sun-solaris2.7
PHP Version: 4.0.5
Description: Compile problem with IMAP support

cp c-client.a /usr/lib/libc-client.a
cp rfc822.h /usr/include
cp linkage.h /usr/include
cp mail.h /usr/include


Previous Comments:
---

[2001-05-16 09:31:27] [EMAIL PROTECTED]
Sorry no I have tried it with --with-imap I am running the most recent version 
ftp://ftp.cac.washington.edu/imap/imap.tar.Z

---

[2001-05-16 00:17:48] [EMAIL PROTECTED]
Is there really a path 'y' in your system? 
What version of c-client you have?
And where is it located? and the header files?

--Jani



---

[2001-05-15 10:14:45] [EMAIL PROTECTED]
configure line is:
./configure --with-mysql=/usr  
--with-imap=y  
--with-apache=../apache_1.3.19 
--enable-track-vars
--enable-register-globals  
--enable-trans-sid  


make[2]: Entering directory `/usr/local/src/php-4.0.5/main'
 
gcc  -I. -I/usr/local/src/php-4.0.5/main -I/usr/local/src/php-4.0.5/main 
-I/usr/local/src/php-4.0.5 -I/usr/local/src/apache_1.3.19/s
rc/include -I/usr/local/src/apache_1.3.19/src/os/unix -I/usr/local/src/php-4.0.5/Zend 
-I/usr/include/mysql -I/usr/local/src/php-4.0.
5/ext/xml/expat/xmltok -I/usr/local/src/php-4.0.5/ext/xml/expat/xmlparse 
-I/usr/local/src/php-4.0.5/TSRM  -D_POSIX_PTHREAD_SEMANTICS
 -DSUPPORT_UTF8 -DXML_BYTE_ORDER=21 -g -O2  -c main.c && touch main.lo 
 
gcc  -I. -I/usr/local/src/php-4.0.5/main -I/usr/local/src/php-4.0.5/main 
-I/usr/local/src/php-4.0.5 -I/usr/local/src/apache_1.3.19/s
rc/include -I/usr/local/src/apache_1.3.19/src/os/unix -I/usr/local/src/php-4.0.5/Zend 
-I/usr/include/mysql -I/usr/local/src/php-4.0.
5/ext/xml/expat/xmltok -I/usr/local/src/php-4.0.5/ext/xml/expat/xmlparse 
-I/usr/local/src/php-4.0.5/TSRM  -D_POSIX_PTHREAD_SEMANTICS
 -DSUPPORT_UTF8 -DXML_BYTE_ORDER=21 -g -O2  -c internal_functions.c && touch 
internal_functions.lo  
In file included from internal_functions.c:32: 
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:50: parse error before `MAILSTREAM'   
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:50: warning: no semicolon at end of 
struct or union
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:58: parse error before `}'
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:58: warning: data definition has no type 
or storage class  
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:61: parse error before `SIZEDTEXT'
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:61: warning: no semicolon at end of 
struct or union
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:65: parse error before `}'
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:65: warning: data definition has no type 
or storage class  
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:68: parse error before `SIZEDTEXT'
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:68: warning: no semicolon at end of 
struct or union
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:70: conflicting types for `next'  
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:64: previous declaration of `next'
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:71: parse error before `}'
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:71: warning: data definition has no type 
or storage class  
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:156: parse error before `STRINGLIST'  
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:156: warning: no semicolon at end of 
struct or union   
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:157: warning: data definition has no type 
or storage class 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:158: parse error before `*'   
 
/usr/local/src/php-4.0.5/ext/imap/php_imap.h:158: war

[PHP-DEV] Bug #10902 Updated: Possible security hole via external modification of session vars

[luci]

ID: 10902
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: *Session related
Operating system: Linux
PHP Version: 4.0.5
Description: Possible security hole via external modification of session vars

Not really a bug, just an issue.

Previous Comments:
---

[2001-05-16 10:17:14] [EMAIL PROTECTED]
This is kind of similar to the old file upload problem, where you could set variables 
in a POST.

In some cases (depends on the way the code is written), if a site stores login status 
(eg. user name, etc) in session variables after an authorisation check, it is possible 
to pass values as the same-named session vars, and therefore actually bypass the 
authorisation step getting access to restricted areas.


---


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


-- 
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 #10902: Possible security hole via external modification of session vars

[luci]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0.5
PHP Bug Type: *Session related
Bug description:  Possible security hole via external modification of session vars

This is kind of similar to the old file upload problem, where you could set variables 
in a POST.

In some cases (depends on the way the code is written), if a site stores login status 
(eg. user name, etc) in session variables after an authorisation check, it is possible 
to pass values as the same-named session vars, and therefore actually bypass the 
authorisation step getting access to restricted areas.



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



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

Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()

[Zeev Suraski]

At 14:06 16/5/2001, Jani Taskinen wrote:
>On Wed, 16 May 2001, Zeev Suraski wrote:
>
> >Also bare in mind that a very large percentage of the developers don't
> >*want* to be forced to change their code, and consider it to be a
>
>Who's forcing anybody to update anyway?

We are, by not supporting old versions (i.e., no bug fixes, no security 
updates, no nothing).

> >misfeature in the language if it breaks downwards compatibility in between
> >releases, regardless of whether they get a clear notification about it 
> or not.
>
>It seems like everybody just ignores my emails..oh well. So I can rant
>again. >:-p

I don't ignore your Email;  I answered you.

>Have you ever heard that you can also change that number in the middle?
>   4.0.6
>This one^
>
>It can be something else than an ellipse called zero..it can even be a
>number 1!!! Whoa! Never thougth about that?!

So what?  ISPs and many companies won't be bothered even if you change the 
ellipse to the number of the beast.  So what.  It breaks compatibility.

>And maybe, just MAYBE then these people (who you seem to think of as
>complete idiots) would READ the NEWS file? Or e.g. RELEASE_NOTES ?

It has nothing to do with their level of stupidity, or even 
ignorance.  They can be Einsteins, but breaking downwards compatibility 
means we're giving them work to do, work that they don't want to do, and 
shouldn't be forced to do.


>Or is that number in the middle reserved for something special? Something
>the 'group' only know of and don't want to tell us lower class people?
>Maybe the 'group' could take their thumbs out of their asses and
>start DOING something? And maybe they could start listening to new ideas
>for once and a while. Or is the 'group' nowadays only Zeev/Andi ?
>
>It would be really nice to hear from the other members of the 'group' also
>as it really seems like the only ones speaking for it are Zeev/Andi..
>
>Or could someone please define the function of this mysterious 'group' ?
>(And please, someone else than Zeev/Andi.. :)

I'll let that topic slide for now.  We'll get around to it soon.  At any 
rate, other than your mood, the issue of the group has nothing to do with 
this issue.

Zeev


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