Re: [PHP-DEV] php_gettext.dll

[Edin Kadribasic]

On Tuesday, Mar 11, 2003, at 03:35 Europe/Copenhagen, Nathan 
Fredrickson wrote:

Hi,
Is the CVS source out of date for gettext extension?  The distributed
php_gettext.dll dynamically loads libintl-1.dll.   The php_gettext.dll 
I
built from the CVS source is linked to gnu_gettext.lib.

How can I build a php_gettext.dll that works like the one in the win32
binary distribution?  (dynamiclly loads libintl.dll)
It could be that I compiled libintl differently. You can find all 
libraries and includes for the snapshot/release building machine at:

http://ftp.proventum.net/pub/php/win32/misc/dev/php_build/(include|lib)/

Edin

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

Re: [PHP-DEV] php_xslt: xslt_set_encoding

[Edin Kadribasic]

You can download latest stable snapshot from snaps.php.net or wait for 4.3.2
release.

Edin

- Original Message -
From: "Michel Sahyoun" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Thursday, March 06, 2003 1:02 AM
Subject: [PHP-DEV] php_xslt: xslt_set_encoding


> I have downloaded the 4.3.1 windows binaries zip package and it doesn't
seem
> to have xslt_set_encoding() enabled.
>
> Can anyone confirm this? And short of getting the sources and recompiling
> PHP, is there another binary distribution that would have
> xslt_set_encoding() enabled?
>
> Thanks,
>
> Michel
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


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

Re: [PHP-DEV] php_pgsql.dll problem

[Edin Kadribasic]

php_pgsql.dll does not depend on external libpq.dll (its built in 
statically). Your problem is most probably in the local install, ie. a 
stale php4ts.dll somewhere.

Edin


On Mon, 3 Mar 2003, Peter Kmet wrote:

> Hello,
> 
> i'm trying to use php with postgres on win32 i have found some problems
> with php 4.3.1 (same for php 4.3.0) and php_pgsql.dll.
> 
> When i try to load php_pgsql.dll extension in php.ini i get error notice
> 
> PHP Warning:  Unknown(): Unable to load dynamic library
> 'C:\Program Files\php\extensions\php_pgsql.dll' - The specified
> procedure could not be found.
> 
> file php_pgsql.dll exists. I have found on internet that this problem can
> be caused by missing libpq.dll from postgres distribution so i downloaded
> postgresql-7.3.1 and compiled with VC5.0 interface libpq and copied
> libpq.dll and libpq.lib and copied it to winnt/system32 folder (i tried php
> dll extensions dir as well) but i still have same warning and pg_*
> functions are not avilable.
> 
> Your help is very appreciated
> 
> Peter Kmet
> 
> 
> --
> 
> 
> 
> 
> 


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

Re: [PHP-DEV] Re: INI defaults for CLI

[Edin Kadribasic]

Hi Marcus,

This patch looks fine to me, but I have the same reservations as you in 
that I'm not sure if we really need to modify the current behavior.

IIRC it was Markus who objected to the way CLI overrode some default 
ini settings in a way that php.ini entries were ignored. You could 
still change them with -d command line switch.

I'm sort of +0.5 for applying this patch if no other objections 
surface. If it gets applied we're probably best of commenting out 
relevant php.ini-dist and php.ini-recommended entries and noting in the 
commend what are defaults.

Edin



On Monday, Mar 3, 2003, at 11:40 Europe/Copenhagen, Marcus Börger wrote:

At 02:45 03.03.2003, [EMAIL PROTECTED] wrote:
Nothing attached...


Try again...
<20030303-1.diff.txt>
--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] disable_classes

[Edin Kadribasic]

On Sunday, Mar 2, 2003, at 23:42 Europe/Copenhagen, Harald Radi wrote:

i reclassified http://bugs.php.net/bug.php?id=22481 to a feature 
request for
adding disable_classes . if there are no objections i'm going to 
implement it
that way.
+1

It is actually necessary to have such an ini option as I suppose we'll 
have more extensions exposing their functionality in an OO way.

Edin

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

Re: [PHP-DEV] new Date extenstion

[Edin Kadribasic]

On Mon, 17 Feb 2003, Pierre-Alain Joye wrote:

> On Mon, 17 Feb 2003 15:40:08 +0100
> Hartmut Holzgraefe <[EMAIL PROTECTED]> wrote:
> 
> 
> > ext/calendar has support for all this ... it even knows about the
> > "french revolution calendar" ;)
> 
> rofl :)
> 
> Well, I'm talking about a good and usefull date/time extension. I do not
> say calendar is not good, but it does not cover what we need for a good,
> crossplatform date/time modules :)

Well, isn't it better/easier to "fix" ext/calendar and add missing 
functionality than to introduce a whole new extension? Having two 
extensions doing essentialy the same thing would IMHO be very confusing.

Edin



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

Re: [PHP-DEV] new Date extenstion

[Edin Kadribasic]

On Mon, 17 Feb 2003, Pierre-Alain Joye wrote:

> On Mon, 17 Feb 2003 12:58:21 +0100
> "Edin Kadribasic" <[EMAIL PROTECTED]> wrote:
> 
> > Does the extension take into acount calendar changes like:
> > 
> > $ cal 9 1752
> >September 1752
> > Su Mo Tu We Th Fr Sa
> >1  2 14 15 16
> > 17 18 19 20 21 22 23
> > 24 25 26 27 28 29 30
> 
> oops, wrong shortcut :)
> 
> Actually no, date corrections will be part of the date functions as soon
> as the locale part is done. The changes of calendar was not the same in
> each country, not in the same time, and even not in the same country (I
> like scottland, switzerland or others proud people ;-), there are
> ambiguous common days offset, some use it, some not.
> 
> That is one of the things we should discuss, and document our choice as
> well.
> 
> What do you think ?

It would probably be easier to take one cutoff point like the unix cal 
command. From its manpage:

  The Gregorian Reformation is assumed to have occurred in 1752 on the 3rd
  of September.  By this time, most countries had recognized the reforma-
  tion (although a few did not recognize it until the early 1900's.) Ten
  days following that date were eliminated by the reformation, so the cal-
  endar for that month is a bit unusual.

Edin



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

Re: [PHP-DEV] new Date extenstion

[Edin Kadribasic]

Does the extension take into acount calendar changes like:

$ cal 9 1752
   September 1752
Su Mo Tu We Th Fr Sa
   1  2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

Edin

- Original Message -
From: "Pierre-Alain Joye" <[EMAIL PROTECTED]>
To: "phpdev" <[EMAIL PROTECTED]>
Sent: Sunday, February 16, 2003 4:38 PM
Subject: [PHP-DEV] new Date extenstion


> Hello,
>
> I made a new extension to work with dates, you may find
infos&sources
> here:
> Docs: http://www.pearfr.org/php_date/docs/
> Sources: http://www.pearfr.org/php_date/sources/
>
> This is a alpha release, a first shot. I still have to create a
full set
> of tests script.
>
> The idea is to provide a fullfeatured date/time standart extension
with
> php5.
>
> A non documented function is get_isoweek() which returns the ISO
week
> number. But the weeknumber is a thing we have to discuss, because
there
> are tons of way to represent it. Actually the week #1 is the week
where
> fit 4th of january.
>
> For all date_new_xxx functions, an optionnal arg can be set to
define
> the 1st day week, default is monday.
>
> Todo:
> - strftime()
> - add/clean warnings (overflow, invalid dates,...)
> - add times functions
>   This part is real pain if we want to DST times, localtime and so
on.
>
> - add time_span datatype, which represents a time interval in
days,
>   hours, seconds, and related functions
>
> - add a true crossplatform localisations, which does not depend of
the
>   target platform. That will make our life easier to provide date
>   localisations in any cases.
>
> Usefull but not really needed:
> - add additionnals functions for specials days and official
hollydays
>
> any comments, ideas, feedback ?
>
> pierre
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


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

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

[Edin Kadribasic]

On Thu, 13 Feb 2003, Sebastian Bergmann wrote:

> Edin Kadribasic wrote:
> > edink   Thu Feb 13 12:15:22 2003 EDT
> >
> >   Modified files:
> > /php4/ext/mysqlimysqli_api.c
> >   Log:
> >   Use my_ulonglong instead of unsigned long long to make msvc++ happy.
> 
>   Did you somehow manage to build MySQL 4.1 on Windows? If so, how? If
>   not, how are you building ext/mysqli since it requires libmysql 4.1?

I have indeed. Lots of tweaking of project files, but I'm able to compile 
and load php_mysqli.dll extension and to make it show up in phpinfo(). I 
didn't test it beyond that.

The compiled lib and header files are available at: 
http://snaps.php.net/~edink/libmysql-4.1.zip and the compiled extension 
is at http://snaps.php.net/~edink/php_mysqli.dll.

Please note that I exported only symbols needed for ext/mysqli at this 
point so I might need to recompile it if the extension gets extended and 
starts using some more of the mysqli API.

Edin



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

RE: [PHP-DEV] Weird PHP5 APXS libtools errors

[Edin Kadribasic]

On Thu, 13 Feb 2003, John Coggeshall wrote:

> >>upgrade your libtool to 1.4.3, it is required now.
> 
> [user@localhost php5]# ./buildconf
> using default Zend directory
> buildconf: checking installation...
> buildconf: autoconf version 2.13 (ok)
> buildconf: automake version 1.4-p5 (ok)
> buildconf: libtool version 1.4.3 (ok)
> 
> And just to be sure..
> 
> [user@localhost php5]# libtool --version
> ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54)
> 
> Any other thoughts? If there's anything else you need to know, 
> let me know.

Does a snapshot from snaps.php.net compile without running ./buildconf?

Edin



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

[PHP-DEV] Re: New CLI switches (was [PHP-DEV] Using CLI as a shell)

[Edin Kadribasic]

On Tuesday 04 February 2003 20:25, Marcus Börger wrote:
[snip]
> >That is a bit too much text for 'php -h'. It should be moved to the
> >online manual. Adding a man page would be great too.
>
> I wrote already i will do so...but haven't yet the time.

Could you please then remove the explanation from the php -h output?

[snip]
> Yes it is the same result. I never said you cannot do it otherwise.
> The reason i implemented the switches is that it makes thinks easier.
> And sometimes making things easier for users is better than knowing
> as a developer that there is a solution.

After having played a bit with the new switches I begun to see the idea. I 
actually kind of like the ease of use that they give for providing search & 
replace sort of capability and using extensive array of PHP string functions.

For example its quite easy to strip tags from an html file/output:

php -d html_errors=1 -i | php -R 'echo strip_tags($argn)."\n";'

So provided that you remove large (and imho confusing) output on the bottom of 
-h I'm +1 on keeping these changes.

Edin

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

[PHP-DEV] New CLI switches (was [PHP-DEV] Using CLI as a shell)

[Edin Kadribasic]

>First simply use "php -h" but i am also thinking about adding a man
>page.

That is a bit too much text for 'php -h'. It should be moved to the
online manual. Adding a man page would be great too.

[snip]
>find . -name '*.c' -o -name '*.h' | php -B '$l=0;' -R
>'$f=count(file($argn)); echo "$argn($n)\n";$l+=$f;' -E 'echo
"Files: $argi,
>Lines: $l\n";'

This appears to be equivelant of:

find . -name '*.c' -o -name '*.h' | php -r 'while (!feof(STDIN)) {
$q=count(file($n=trim(fgets(STDIN; echo "$n($q)\n"; $l+=$q;
$f++; } echo "Files $f, Lines: $l\n";'

Am I correct in this assumption? If yes, could please try to point
out what are the advantages of -B -R -E and -F over using just -r?

Edin


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

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

[Edin Kadribasic]

> I don't even see the speed difference as an issue as much as (A)
> simplicity for the user who hasn't figured out regex yet, (B) consistency
> (we have 'i' versions of most other string functions, why not this one?)

+1 for the reasons stated above.

Edin



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

[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_execute_API.c

[Edin Kadribasic]

> EK>> That makes PEAR installer coredump with the following core:
>
> Doesn't happen to me. What were the arguments?

You need to remove $PREFIX/lib/php to reproduce on my RedHat 7.3
box.

./configure --enable-debug && make && make install-pear

Edin


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

[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_execute_API.c

[Edin Kadribasic]

That makes PEAR installer coredump with the following core:

Core was generated by `/data/src/php5/sapi/cli/php -n -dsafe_mode 0
/data/src/php5/pear/install-pear.php'.

#0  0x08142d78 in _efree (ptr=0x400b396c,
__zend_filename=0x81a89e0
"/data/src/php5/Zend/zend_execute_API.c",
__zend_lineno=332,
__zend_orig_filename=0x81a95e0
"/data/src/php5/Zend/zend_variables.c",
__zend_orig_lineno=44) at /data/src/php5/Zend/zend_alloc.c:242
242 REMOVE_POINTER_FROM_LIST(p);
(gdb) bt
#0  0x08142d78 in _efree (ptr=0x400b396c,
__zend_filename=0x81a89e0
"/data/src/php5/Zend/zend_execute_API.c",
__zend_lineno=332,
__zend_orig_filename=0x81a95e0
"/data/src/php5/Zend/zend_variables.c",
__zend_orig_lineno=44) at /data/src/php5/Zend/zend_alloc.c:242
#1  0x08154de0 in _zval_dtor (zvalue=0x400b39a8,
__zend_filename=0x81a89e0
"/data/src/php5/Zend/zend_execute_API.c",
__zend_lineno=332) at /data/src/php5/Zend/zend_variables.c:44
#2  0x0814c1f8 in _zval_ptr_dtor (zval_ptr=0x400b39f8,
__zend_filename=0x81a95e0
"/data/src/php5/Zend/zend_variables.c",
__zend_lineno=164) at /data/src/php5/Zend/zend_execute_API.c:332
#3  0x08155077 in _zval_ptr_dtor_wrapper (zval_ptr=0x400b39f8)
at /data/src/php5/Zend/zend_variables.c:164
#4  0x0815c18d in zend_hash_destroy (ht=0x400b33d4)
at /data/src/php5/Zend/zend_hash.c:541
#5  0x0814ecef in destroy_zend_class (pce=0x81efa84)
at /data/src/php5/Zend/zend_opcode.c:120
#6  0x0815c18d in zend_hash_destroy (ht=0x81c0984)
at /data/src/php5/Zend/zend_hash.c:541
#7  0x0815613a in zend_shutdown () at /data/src/php5/Zend/zend.c:674
#8  0x081229eb in php_module_shutdown () at
/data/src/php5/main/main.c:1346
#9  0x08172b97 in main (argc=7, argv=0xb9c4)
at /data/src/php5/sapi/cli/php_cli.c:813
#10 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6

Edin
- Original Message -
From: "Stanislav Malyshev" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 29, 2003 3:33 PM
Subject: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_execute_API.c


> stas Wed Jan 29 09:33:18 2003 EDT
>
>   Modified files:
> /ZendEngine2 zend_execute_API.c
>   Log:
>   Fix object destructors:
>   zend_objects_store_call_destructors is not used anymore, we rely
on
>   symbol tables cleaners to destroy all objects.
>
>
> Index: ZendEngine2/zend_execute_API.c
> diff -u ZendEngine2/zend_execute_API.c:1.189
ZendEngine2/zend_execute_API.c:1.190
> --- ZendEngine2/zend_execute_API.c:1.189 Thu Jan 23 00:15:42 2003
> +++ ZendEngine2/zend_execute_API.c Wed Jan 29 09:33:18 2003
> @@ -189,15 +189,23 @@
>  void shutdown_executor(TSRMLS_D)
>  {
>   zend_try {
> - zend_objects_store_call_destructors(&EG(objects_store)
TSRMLS_CC);
> -
>   zend_ptr_stack_destroy(&EG(arg_types_stack));
> -
> - while (EG(symtable_cache_ptr)>=EG(symtable_cache)) {
> +
> +/* Removed because this can not be safely done, e.g. in this
situation:
> +   Object 1 creates object 2
> +   Object 3 holds reference to object 2.
> +   Now when 1 and 2 are destroyed, 3 can still access 2 in its
destructor, with
> +   very problematic results */
> +/* zend_objects_store_call_destructors(&EG(objects_store)
TSRMLS_CC); */
> +
> +/* Moved after symbol table cleaners, because  some of the
cleaners can call
> +   destructors, which would use EG(symtable_cache_ptr) and thus
leave leaks */
> +/* while (EG(symtable_cache_ptr)>=EG(symtable_cache)) {
>   zend_hash_destroy(*EG(symtable_cache_ptr));
>   efree(*EG(symtable_cache_ptr));
>   EG(symtable_cache_ptr)--;
>   }
> +*/
>   zend_llist_apply(&zend_extensions, (llist_apply_func_t)
zend_extension_deactivator TSRMLS_CC);
>
>   zend_hash_destroy(&EG(symbol_table));
> @@ -217,6 +225,12 @@
>   } else {
>   zend_hash_reverse_apply(EG(function_table), (apply_func_t)
is_not_internal_function TSRMLS_CC);
>   zend_hash_reverse_apply(EG(class_table), (apply_func_t)
is_not_internal_class TSRMLS_CC);
> + }
> +
> + while (EG(symtable_cache_ptr)>=EG(symtable_cache)) {
> + zend_hash_destroy(*EG(symtable_cache_ptr));
> + efree(*EG(symtable_cache_ptr));
> + EG(symtable_cache_ptr)--;
>   }
>   } zend_end_try();
>
>
>
>
> --
> Zend Engine CVS Mailing List (http://cvs.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


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

[PHP-DEV] Another segfault running pear installer

[Edin Kadribasic]

$ gdb sapi/cli/php
GNU gdb Red Hat Linux (5.1.90CVS-5)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(gdb) r  -n -dsafe_mode=0 /data/src/php5/pear/install-pear.php
/data/src/php5/pear/package-*.xml
Starting program: /data/src/php5/sapi/cli/php -n -dsafe_mode=0
/data/src/php5/pear/install-pear.php
/data/src/php5/pear/package-*.xml

Warning: Invalid argument supplied for foreach() in
/data/src/php5/pear/PEAR/Registry.php on line 489
/data/src/php5/pear/PEAR/Registry.php(489) : Warning - Invalid
argument supplied for foreach()

Warning: Cannot use a scalar value as an array in
/data/src/php5/pear/PEAR/Installer.php on line 682
/data/src/php5/pear/PEAR/Installer.php(682) : Warning - Cannot use a
scalar value as an array

Warning: Invalid argument supplied for foreach() in
/data/src/php5/pear/PEAR/Installer.php on line 682
/data/src/php5/pear/PEAR/Installer.php(682) : Warning - Invalid
argument supplied for foreach()

Program received signal SIGSEGV, Segmentation fault.
0x080817b9 in compile_branch (optionsptr=0x402be350, brackets=0x0,
codeptr=0x1,
ptrptr=0x0, errorptr=0x10, firstcharptr=0x402b19fc,
reqcharptr=0x402c73bc,
bcptr=0x1, cd=0x402b1ce4) at
/data/src/php5/ext/pcre/pcrelib/pcre.c:2708
2708previous[1] = length;
(gdb) bt
#0  0x080817b9 in compile_branch (optionsptr=0x402be350,
brackets=0x0, codeptr=0x1,
ptrptr=0x0, errorptr=0x10, firstcharptr=0x402b19fc,
reqcharptr=0x402c73bc,
bcptr=0x1, cd=0x402b1ce4) at
/data/src/php5/ext/pcre/pcrelib/pcre.c:2708
#1  0x0816c0fc in zend_do_fcall_common_helper
(execute_data=0xbfffb0b0,
op_array=0x402d5ac4) at /data/src/php5/Zend/zend_execute.c:2630
#2  0x0816c43c in zend_do_fcall_by_name_handler
(execute_data=0xbfffb0b0,
op_array=0x402d5ac4) at /data/src/php5/Zend/zend_execute.c:2694
#3  0x081677e2 in execute (op_array=0x402d5ac4)
at /data/src/php5/Zend/zend_execute.c:1217
#4  0x0816c0fc in zend_do_fcall_common_helper
(execute_data=0xbfffd630,
op_array=0x400af464) at /data/src/php5/Zend/zend_execute.c:2630
#5  0x0816c43c in zend_do_fcall_by_name_handler
(execute_data=0xbfffd630,
op_array=0x400af464) at /data/src/php5/Zend/zend_execute.c:2694
#6  0x081677e2 in execute (op_array=0x400af464)
at /data/src/php5/Zend/zend_execute.c:1217
#7  0x081569f6 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /data/src/php5/Zend/zend.c:996
#8  0x08123479 in php_execute_script (primary_file=0xb960)
at /data/src/php5/main/main.c:1691
#9  0x081727bc in main (argc=7, argv=0xba04)
at /data/src/php5/sapi/cli/php_cli.c:753
#10 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6


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

Re: [PHP-DEV] Memory allocation problems

[Edin Kadribasic]

> > I have a script that allocates a lot of memory (huge associative
arrays).
> > The problem is that this scripts bails out with fatal error (emalloc
> > unable to allocate 44 bytes) when I hit the limit of physical ram in the
> > machine. Swap never gets used. The machine has 1 GB of ram and 2 GB of
> > swap space.
> >
> > Has anyone seen something like this before? Are there any limitations in
> > the PHP memory allocation code that would prevent it from being able to
> > use more memory.
>
> Are you sure you are hitting the exact physical memory limit?  What is
> your "ulimit -d" (data segment size limit)?

I have checked all the limits and the problem wasn't there.

It turns out that PHP + glibc-2.1.3 (RedHat 6.2 standard) + Kernel 2.2.22 is
a bad combination when allocating large number of small memory chunks.
Installing glibc-2.2.5 (scarry stuff to have to go through) solved the
problem for me.

Now building PHP with an alternative glibc on the system is not something I
would recommend for light entertainment :)

Anyway thanks to all who offered advice and have helped me track down and
resolve this issue.

Edin



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

Re: [PHP-DEV] sapi/embed ?

[Edin Kadribasic]

On Fri, 17 Jan 2003, Brian Moon wrote:

> I just noticed sapi/embed.  Where can I find out more about what this is?  I
> am hoping it is a sapi that will create a generic library that can be used
> from any C application.  Is this true?

Yes it is true. Writing some documentation on how to do it is my TODO 
list. If you need it right away I can send you some example code.

Edin



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

Re: [PHP-DEV] Memory allocation problems

[Edin Kadribasic]

> >I have a script that allocates a lot of memory (huge associative
arrays).
> >The problem is that this scripts bails out with fatal error
(emalloc
> >unable to allocate 44 bytes) when I hit the limit of physical ram
in the
> >machine. Swap never gets used. The machine has 1 GB of ram and 2
GB of
> >swap space.
>
>
> I suppose you use some windows machine. I remember that all
application have
> only 1GB of RAM for their own until you have a windows server
version and that
> has an appropriate HAL and is configured to have more than 1gig.

Nope it's a RedHat Linux box. Just to make sure I've tried another
one, and there as well program quit after hitting the limit of
physical ram.

I also tried writing small C test program to verify that I wasn't
reaching some ulimit or kernel limitations, but it had no problems
mallocing 1.2 GB on the same box.

Edin


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

[PHP-DEV] Memory allocation problems

[Edin Kadribasic]

I have a script that allocates a lot of memory (huge associative arrays). 
The problem is that this scripts bails out with fatal error (emalloc 
unable to allocate 44 bytes) when I hit the limit of physical ram in the 
machine. Swap never gets used. The machine has 1 GB of ram and 2 GB of 
swap space.

Has anyone seen something like this before? Are there any limitations in 
the PHP memory allocation code that would prevent it from being able to 
use more memory.

Edin



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

Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)

[Edin Kadribasic]

> Maybe I misunderstood when Edin said that there will be no new release
> for some time due to the move on PHP 5.

Yes, you misunderstood what I said which was that there is not going to be a
release from the HEAD branch for some time to come -- until PHP 5 is
released.

As a matter of fact I think it would be good idea to go for 4.3.1 in
February because number of bugfixes in PHP_4_3 branch is already significant
and since no major new features have been added there the QA process
shouldn't take that long either.

Edin



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

Re: [PHP-DEV] Re: [PEAR-DEV] Re: Thank's for the announce about PEAR and a little precision

[Edin Kadribasic]

Pear is not included in Win32 distribution of php-4.3.0. The pear
installer is broken on windows and since there is no easy way to
install PEAR without it it was not bundled with the distro.

You could try to install pear on windows from the command line. Go
into the directory where you have installed php (c:\php4 is
recommended if you want to use PEAR in its current state) and type:

cli\php -n -r "include ('http://go-pear.org/');"

This might work, and then again it might be broken :)

Edin

- Original Message -
From: "Dirkjan Ochtman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, January 13, 2003 3:48 PM
Subject: [PHP-DEV] Re: [PEAR-DEV] Re: Thank's for the announce about
PEAR and a little precision


> I guess the mirror I'm using didn't update...
>
> I'll try the main site now.
>
> Regards,
>
> Dirkjan
>
> "Pierre-Alain Joye" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > On Mon, 13 Jan 2003 15:14:55 +0100
> > "Dirkjan Ochtman" <[EMAIL PROTECTED]> wrote:
> >
> > > Hello,
> > >
> > > I'm running PHP (4.3.0) on Windows, and I haven't seen
*anything*
> > > relating to PEAR in my (.zip) binary distribution. Am I just
looking
> > > in the wrong place?
> >
> > Early release of binary php 4.3.0 for win32 did not contain
PEAR, please
> > try to download it again, you may find pear inside.
> >
> > hth
> >
> > pierre
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


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

Re: [PHP-DEV] Apache2Filter SAPI segfaults

[Edin Kadribasic]

What bison version are you using. I saw similar segfaults with 1.875.
Downgrading to 1.75 or even to 1.28 fixes it for me.

Edin

- Original Message -
From: "Sebastian Bergmann" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, January 12, 2003 10:07 AM
Subject: Re: [PHP-DEV] Apache2Filter SAPI segfaults


> Sebastian Bergmann wrote:
> > [...]
>
>   I get a segfault with the same backtrace for Apache 1.3.
>
> --
>   Sebastian Bergmann
>   http://sebastian-bergmann.de/ http://phpOpenTracker.de/
>
>   Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


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

Re: [PHP-DEV] What headers/libs does Win32 Snaps build use?

[Edin Kadribasic]

Yes, Steph is right, the set of libraries used on the snaps machine is ~70MB
(uncompressed) and I don't think it's practical to update win32build.zip to
include them all. And this 70 MB does not include files needed for building
ext/infromix, ext/interbase and sapi/pi3web.

Edin

- Original Message -
From: "Steph" <[EMAIL PROTECTED]>
To: "Christoph Grottolo" <[EMAIL PROTECTED]>; "Michael Sisolak"
<[EMAIL PROTECTED]>
Cc: "PHP DEV" <[EMAIL PROTECTED]>
Sent: Tuesday, January 07, 2003 8:44 PM
Subject: Re: [PHP-DEV] What headers/libs does Win32 Snaps build use?


> There are a lot of them - that's likely to be the biggest issue.  Nearly
> 20 megs of libraries (and this from some months ago).
>
> This is really Edin's territory...
>
> - Original Message -
> From: "Christoph Grottolo" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, January 07, 2003 7:31 PM
> Subject: Re: [PHP-DEV] What headers/libs does Win32 Snaps build use?
>
>
> > > Basically what I'm talking about is updating win32build.zip so that
> it
> > > has all the current libraries that are really used to do a PHP build
> > > on Win32.  Is there a practical or licensing reason why that
> couldn't
> > > be done?  Would it be a lot more work than just packaging up a few
> > > directories on the snaps machine?
> > >
> > > Michael Sisolak
> >
> > +1 on this - if my vote counts
> >
> > Christoph
> >
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


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

[PHP-DEV] Re: Building a HTTP server using PHP -> PHP and Windows question (please don't delete)

[Edin Kadribasic]

Very impressive work!

As for writing to the php-cgi.exe I suggest you look into proc_open()
function in PHP 4.3.0 (http://www.php.net/manual/en/function.proc-open.php).

Edin

- Original Message -
From: "Dominik Wittenbeck" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 07, 2003 10:28 PM
Subject: Building a HTTP server using PHP -> PHP and Windows question
(please don't delete)


Hi,

I am not trying to spam you guys, I just don't know where else to turn to to
get help. Maybe you know somebody to help me on the following Win2K/PHP
problem.

Task: I am trying to implement the CGI interface on a PHP based webserver I
have built using the new CLI, that comes with PHP 4.3.0. So far I have no
problems with the server sending and recieving data as well as static
document. However I am experiencing difficulties, trying to implement the
CGI interface.

In order stabalize the server I have the server process PHP files via the
php.exe (the CGI not the CLI one that comes with the 4.3.0). I use

shell_exec("php\php-cgi.exe -c php\php.ini PathToPhpScript.php");

to call the binary and have a custom script processed. Before this I set
environmental variables using putenv(). All this works fine. I get my html
output, the headers and stuff and send it back to the browser.

I am however experiencing problems, when trying to get the php-cgi.exe to
read POST data, that supposedly has to be submitted via the "standard input"
if no other mechanism is available. Now unlike GET, which basically comes
from the QUERY_STRING env-var, I appearently cannot "abuse" another env-var
such as HTTP_RAW_POST_DATA for POST payload. Trying to pipe information
either directly or via a file like

shell_exec("type fileWithPostData | php\php-cgi.exe -c php\php.ini
PathToPhpScript.php");

or

shell_exec("echo postData | php\php-cgi.exe -c php\php.ini
PathToPhpScript.php");

doesn't work. How do I get the php-cgi.exe to understand and process my POST
data? There has to be a way, as other webserver have to use the same
interface. I just cannot figure out how. As this is the last step to
complete the implementation of the CGI on my server, I desperately need
help!

I am currently using a bugfix that populates the HTTP_RAW_POST_DATA var and
append a PHP script before each script to be processed, that analyses the
variables from it and fills it into $_POST... which still does not help me
with uploaded files :-( ... I know, this workaround sucks pretty bad too!

If you are interested in the source:
http://developaz.no-ip.com/index.php?action=download(9)

Thanks very much in advance!
Dominik Wittenbeck

System Architect

Developaz Network
  Holderbaum Str. 31
  67549 Worms

  Telefon:06241/209474
  Mobil:   0179/7710426
  E-Mail: [EMAIL PROTECTED]
  URL:http://www.developaz.com



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

Re: [PHP-DEV] ZE2 dev snaps

[Edin Kadribasic]

If you checkout "php4-ze2" all this will be done automagically for
you by the CVS server.

Edin

- Original Message -
From: "Christian Stocker" <[EMAIL PROTECTED]>
To: "Stephan Seidt" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, January 07, 2003 10:00 AM
Subject: Re: [PHP-DEV] ZE2 dev snaps


> On Mon, 6 Jan 2003, Stephan Seidt wrote:
>
> > At least ./buildconf with --ZendEngine2 did never work for me.
;)
> > I also did cvs co ZendEngine2 in php4 cvstree root.
>
> Did you rename ZendEngine2 to Zend? (Or make a symbolic link,
after
> renaming the old Zend directory to something else)
>
> chregu
>
> >
> > Mark J. Hershenson wrote:
> > > Hi all,
> > >
> > > I know there are "Win32+ZE2 Package" snapshots on
snaps.php.net, but I don't
> > > believe I've read why there isn't a ZE2 source code snapshot
for everyone
> > > else. Checking out the source with CVS may not be the world's
most difficult
> > > practice, but automating that process likely isn't either. ;)
> > >
> > > Is there a timeline for this, or is this being intentionally
kept off the
> > > radar?
> > >
> > > --  mjh
> > >
> > >
> >
> >
> >
>
> --
> nam...christian stockeradr...pflanzschulstr. 31, ch-8004
zurich
> pho...+41 43 317 9984  www...http://phant.ch/chregu
> mob...+41 76 561 8860  [EMAIL PROTECTED]
> wor...+41  1 240 5670  gpg...0x5CE1DECB
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


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

Re: [PHP-DEV] Re: [PHP-WIN] PHP 4.3.0 no gif support?

[Edin Kadribasic]

Hello,

Read-only GIF support has now been enabled in the windows version of the
bundled GDLIB. Fixed version of php_gd2.dll compatible with PHP 4.3.0 will
be available from http://snaps.php.net/win32/php4-win32-STABLE-latest.zip in
approx. 8 hours.

Edin

- Original Message -
From: "Brian Weil" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, January 05, 2003 6:31 PM
Subject: [PHP-DEV] Re: [PHP-WIN] PHP 4.3.0 no gif support?


> So...
>
> WIll gif support ever be available on win32? Can a patched gd.dll be found
> somewhere with readonly gif support or will we have to re-install php when
> the binary is updated? I've been (patiently) waiting for this since GD1.6.
>
> Thanks,
> Brian
>
> "Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > Hrm..  Whoever built the Windows binary didn't define HAVE_GD_GIF_READ I
> > guess.  Or perhaps it should go into main/config.w32.h.in assuming we
are
> > always going to build the windows binary against the bundled gd library.
> >
> > -Rasmus
> >
> > On Fri, 3 Jan 2003, Zac Barton wrote:
> >
> > > hi all, i thought php 4.3 was ment to have read-only access to gif
> images?
> > >
> > >
> > > all i get via phpinfo(); is:
> > >
> > > GD Support  enabled
> > > GD Version  bundled (2.0 compatible)
> > > FreeType Support  enabled
> > > FreeType Linkage  with freetype
> > > JPG Support  enabled
> > > PNG Support  enabled
> > > WBMP Support  enabled
> > >
> > > wheres the gif read support?
> > >
> > > php 4.3 d/loaded via www.php.net so its the correct version.. what am
i
> > > missing?
> > >
> > > does gif read support mean i can load a gif image then output it as a
> PNG?
> > >
> > > many thanks in advance
> > >
> > > zac barton
> > >
> > > --
> > > PHP Windows Mailing List (http://www.php.net/)
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


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

Re: [PHP-DEV] branch compile problem - win32

[Edin Kadribasic]

> Maybe this is know but on snaps there is an error :
> Next STABLE Win32 snapshot in: Win32 build failed. Consult compile.log for
> failure reason.
> Cvs build is ok.

It should be fixed now (or on the next stable build to be precise).

Edin



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

Re: [PHP-DEV] Re: [PHP-CVS] Merging into PHP_4_3

[Edin Kadribasic]

> There is one for 4.4 (possibly to be renamed 5), but I don't see a 4.3.X
> section.

Oh, that is in HEAD. We usually add all the branch changes into the brach
version of the NEWS and merge them into HEAD once a new release has been
made from the branch.

Edin



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

Re: [PHP-DEV] Re: [PHP-CVS] Merging into PHP_4_3

[Edin Kadribasic]

> Could you please add a section for the branch (4.3.1?) in the news file.

Isn't it already there?

Edin



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

Re: [PHP-DEV] Re: PHP 4.3.0 released

[Edin Kadribasic]

On Saturday 28 December 2002 00:16, Andi Gutmans wrote:
> I think you're right. I also see some weird language :)

It was a mistake commit by one of the translators. It was corrected and the 
page will be shown in English again in a few hours (documentation build takes 
a lng time).

Edin


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

Re: [PHP-DEV] Win32 binaries, CLI and PEAR

[Edin Kadribasic]

CLI was missing in the win32 distro by mistake. I have just updated the bin,
but the problem is that the webserver at www.php.net still spits out the old
binary. Since the file has correctly been rsynced I have to assume that this
has to do with squid caching. Could someone from [EMAIL PROTECTED] have a
look?

Edin

- Original Message -
From: "Pierre-Alain Joye" <[EMAIL PROTECTED]>
To: "phpdev" <[EMAIL PROTECTED]>
Cc: "peardev" <[EMAIL PROTECTED]>
Sent: Friday, December 27, 2002 8:14 PM
Subject: [PHP-DEV] Win32 binaries, CLI and PEAR


> Hello,
>
> While checking the win32 binaries, I did not find any CLI, neither PEAR
> files.
>
> Any reason ?
>
> pierre
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


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

Re: [PHP-DEV] Re: #21139 [Ctl]: zlib.output_compression + windows failure

[Edin Kadribasic]

On Thursday 26 December 2002 21:14, Frank M. Kromann wrote:

> I think this is a good idea too, but on my system zlib.dll is required to
> run php.exe. If this is the case with the official build we might have a
> support issue. This could be a local problem with the way I compile the
> Zlib library ?

Yes, you probably chose "Win32 dynamic link library" over "Win32 static 
library" when compiling zlib. Let me know if you want me to send you the libs 
I use on the snapshot/relese build machine.

Edin

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

Re: [PHP-DEV] Re: #21139 [Ctl]: zlib.output_compression + windows failure

[Edin Kadribasic]

On Tuesday 24 December 2002 04:51, Moriyoshi Koizumi wrote:
> "Edin Kadribasic" <[EMAIL PROTECTED]> wrote:
> > > Isn't the solution as "simple" as changing the #ifdef to include
> > > COMPILE_DL_ZLIB in the checks, or is this another situation where the
> > > zlib extension should be compiled into the distribution itself?
> > >
> > > Is there a problem with doing that in the win32 build Edin?
> > > (it seems that the unix build will also have the same problems if zlib
> > > is built as a shared extension - there was even a bug report today
> > > about related issues).
> >
> > One of the solutions for the windows build is to compile zlib module into
> > php4ts.dll statically. In that way all the problems go away and its a
> > nice module to have built-in anyway. I have a patch ready and a test
> > build of php4ts.dll at http://snaps.php.net/~edink/php4ts.dll-zlib.zip
>
> I've checked your test build, and it works fine as for Apache-1.3.27.
> But it still fails with Apache2... this seems another apache2filter
> problem.
>
> Anyway this solution sounds like a quickest and most reasonable way.

Any objections to making zlib built-in extension on windows?

Edin

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

Re: [PHP-DEV] Re: #21139 [Ctl]: zlib.output_compression + windows failure

[Edin Kadribasic]

> Isn't the solution as "simple" as changing the #ifdef to include
> COMPILE_DL_ZLIB in the checks, or is this another situation where the
> zlib extension should be compiled into the distribution itself?
>
> Is there a problem with doing that in the win32 build Edin?
> (it seems that the unix build will also have the same problems if zlib
> is built as a shared extension - there was even a bug report today about
> related issues).

One of the solutions for the windows build is to compile zlib module into
php4ts.dll statically. In that way all the problems go away and its a nice
module to have built-in anyway. I have a patch ready and a test build of
php4ts.dll at http://snaps.php.net/~edink/php4ts.dll-zlib.zip

Edin

P.S. Make sure to remove extension=php_zlib.dll from your php.ini


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

Re: [PHP-DEV] RC4 + windows

[Edin Kadribasic]

On Sunday 22 December 2002 00:51, Marcus Börger wrote:
> Hi,
>
> i can no longer load mhash and domxml dll's under windows RC4.
>
> marcus

Rememberd to copy .dlls from dlls folder to a folder in PATH like 
c:\winnt\system32?

Edin


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

Re: [PHP-DEV] Re: ground rules

[Edin Kadribasic]

I have changed bundled php.ini-dist and php.ini-recommended to reflect these
changes. Thanks for compilinng the list.

Edin

- Original Message -
From: "Christoph Grottolo" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, December 21, 2002 10:40 PM
Subject: [PHP-DEV] Re: ground rules


> Hi
>
> Andrei Zmievski wrote:
> > Everyone,
> >
> > I have just released 4.3.0RC4. Despite the quote in my signature, I am
> > determined to keep this one the very last final RC of the interminable
> > 4.3.0 development cycle. Towards that end, I will closely monitor the
> > CVS commits and revert any that do not satisfactorily explain what
> > critical or showstopper bug they are fixing.
>
> There are inconsistencies in php.ini on windows:
>
> The following extensions are listed in the [extensions] part of php.ini,
but
> are not dlivered with the distribution:
> - ctype (now built in)
> - cybercash (?)
> - dotnet (build failure since months)
> - ingres (build failure since months)
> - tokenizer (now built in)
>
> The following extensions are part of the distribution but not listed in
> php.ini
> - gd2
> - mime_magic
> - msql
> - xmlrpc
> - zip
>
> Maybe you can correct this before 4.3.0. At least the missing GD2 is bad.
>
> Christoph
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


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

Re: [PHP-DEV] RC4: ground rules

[Edin Kadribasic]

> Should I commit a small fix to the Windows projects to avoid having the
> CGI and CLI produce php.exe to the same directory ?

Andrei I think that we should include this small change in 4.3.0. It cannot
possibly affect anything in the negative way and I will make sure that the
files are correctly placed in the distribution.

Edin



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

Re: [PHP-DEV] CGI and CLI (compromise proposal)

[Edin Kadribasic]

Just testing the patch... will be commiting shortly.

Thanks anyway,

Edin
- Original Message - 
From: "Frank M. Kromann" <[EMAIL PROTECTED]>
To: "Edin Kadribasic" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Andrei Zmievski" <[EMAIL PROTECTED]>
Sent: Thursday, December 19, 2002 6:44 PM
Subject: Re: [PHP-DEV] CGI and CLI (compromise proposal)


> Edin,
> 
> Are you doing the changes on Win32 also _ If not I'll make the changes.
> 
> - Frank
> 
> > 
> > Here is the patch against PHP_4_3 that implements the Unix side of 
> > changes.
> > 
> > Edin
> > 
> > 
> > On Thu, 19 Dec 2002, Andrei Zmievski wrote:
> > 
> > > This gets my complete support. Let's go ahead with the changes.
> > > 
> > > On Thu, 19 Dec 2002, Edin Kadribasic wrote:
> > > > After having consulted with Andrei, Derick and others on irc here
> is
> > > > a proposal for a compromise:
> > > > 
> > > > On Unix:
> > > > 
> > > > 1. Both cgi and cli are built as 'php' in their respective sapi
> > > > directories (pretty much as it is today except that cgi gets
> renamed
> > > > back from php-cgi to just php).
> > > > 2. Make install will *not* install cli if cgi build was selected
> > > > (only cgi gets installed).
> > > > 3. A new install target 'install-cli' is introduced so that make
> > > > install-cli will overwrite whatever is in $(PREFIX)/bin/php.
> > > > 
> > > > On Windows:
> > > > 
> > > > 1. php.exe in the root of distribution is php cgi sapi.
> > > > 2. New cli directory is included with php.exe (cli) in it.
> > > > 
> > > > If this is an acceptable compromise I volunteer to do the changes
> > > > required.
> > > 
> > > -Andrei  
> http://www.gravitonic.com/
> > > * The great thing about standards is that there are so many to choose
> from. *
> > > 
> > > 
> > 
> 
> 
> 
> 
> 


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

Re: [PHP-DEV] CGI and CLI (compromise proposal)

[Edin Kadribasic]

Here is the patch against PHP_4_3 that implements the Unix side of 
changes.

Edin


On Thu, 19 Dec 2002, Andrei Zmievski wrote:

> This gets my complete support. Let's go ahead with the changes.
> 
> On Thu, 19 Dec 2002, Edin Kadribasic wrote:
> > After having consulted with Andrei, Derick and others on irc here is
> > a proposal for a compromise:
> > 
> > On Unix:
> > 
> > 1. Both cgi and cli are built as 'php' in their respective sapi
> > directories (pretty much as it is today except that cgi gets renamed
> > back from php-cgi to just php).
> > 2. Make install will *not* install cli if cgi build was selected
> > (only cgi gets installed).
> > 3. A new install target 'install-cli' is introduced so that make
> > install-cli will overwrite whatever is in $(PREFIX)/bin/php.
> > 
> > On Windows:
> > 
> > 1. php.exe in the root of distribution is php cgi sapi.
> > 2. New cli directory is included with php.exe (cli) in it.
> > 
> > If this is an acceptable compromise I volunteer to do the changes
> > required.
> 
> -Andrei   http://www.gravitonic.com/
> * The great thing about standards is that there are so many to choose from. *
> 
> 

Index: configure.in
===
RCS file: /repository/php4/configure.in,v
retrieving revision 1.396.2.15
diff -u -3 -p -r1.396.2.15 configure.in
--- configure.in13 Dec 2002 13:34:37 -  1.396.2.15
+++ configure.in19 Dec 2002 16:45:38 -
@@ -1081,7 +1081,11 @@ INLINE_CFLAGS="$INLINE_CFLAGS $standard_
 CXXFLAGS="$CXXFLAGS $standard_libtool_flag"
 
 all_targets='$(OVERALL_TARGET) $(PHP_MODULES) $(PHP_CLI_TARGET)'
-install_targets="install-sapi install-modules $PHP_INSTALL_CLI_TARGET $install_pear"
+install_targets="install-sapi install-modules $install_pear"
+if test "$PHP_SAPI" != "cgi"; then
+  install_targets="$PHP_INSTALL_CLI_TARGET $install_targets"
+fi
+
 PHP_SUBST(all_targets)
 PHP_SUBST(install_targets)
 
Index: sapi/cgi/config9.m4
===
RCS file: /repository/php4/sapi/cgi/config9.m4,v
retrieving revision 1.1.2.2
diff -u -3 -p -r1.1.2.2 config9.m4
--- sapi/cgi/config9.m4 9 Dec 2002 17:25:01 -   1.1.2.2
+++ sapi/cgi/config9.m4 19 Dec 2002 16:45:38 -
@@ -88,10 +88,10 @@ if test "$PHP_SAPI" = "default"; then
 PHP_ADD_MAKEFILE_FRAGMENT($abs_srcdir/sapi/cgi/Makefile.frag)
 case $host_alias in
   *cygwin* )
-SAPI_CGI_PATH=sapi/cgi/php-cgi.exe
+SAPI_CGI_PATH=sapi/cgi/php.exe
 ;;
   * )
-SAPI_CGI_PATH=sapi/cgi/php-cgi
+SAPI_CGI_PATH=sapi/cgi/php
 ;;
 esac
 PHP_SUBST(SAPI_CGI_PATH)
@@ -147,7 +147,7 @@ if test "$PHP_SAPI" = "default"; then
 AC_DEFINE_UNQUOTED(PHP_FCGI_STATIC, $PHP_FCGI_STATIC, [ ])
 AC_MSG_RESULT($PHP_ENABLE_FASTCGI)
 
-INSTALL_IT="\$(INSTALL) -m 0755 \$(SAPI_CGI_PATH) 
\$(INSTALL_ROOT)\$(bindir)/php-cgi"
+INSTALL_IT="\$(INSTALL) -m 0755 \$(SAPI_CGI_PATH) \$(INSTALL_ROOT)\$(bindir)/php"
 PHP_SELECT_SAPI(cgi, program, $PHP_FCGI_FILES cgi_main.c getopt.c, 
-I$PHP_FCGI_INCLUDE,'$(SAPI_CGI_PATH)')
 
 case $host_alias in

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

[PHP-DEV] CGI and CLI (compromise proposal)

[Edin Kadribasic]

After having consulted with Andrei, Derick and others on irc here is
a proposal for a compromise:

On Unix:

1. Both cgi and cli are built as 'php' in their respective sapi
directories (pretty much as it is today except that cgi gets renamed
back from php-cgi to just php).
2. Make install will *not* install cli if cgi build was selected
(only cgi gets installed).
3. A new install target 'install-cli' is introduced so that make
install-cli will overwrite whatever is in $(PREFIX)/bin/php.

On Windows:

1. php.exe in the root of distribution is php cgi sapi.
2. New cli directory is included with php.exe (cli) in it.

If this is an acceptable compromise I volunteer to do the changes
required.

Edin


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

Re: [PHP-DEV] -+ [01]

[Edin Kadribasic]

On Thu, 19 Dec 2002, Zeev Suraski wrote:

> I disagree.  For instance, if I helped writing the combined module, and 
> someone separated it without thoroughly making sure that everyone is ok 
> with this separation, I believe it's upto him to be responsible to merge it 
> back in.  What you suggest is that PHP will really be f(t), as people's 
> resources change with time.  I do not agree.

I don't know if you're referring to cgi/cli separation, but in case you 
are let me just remind you that no one objected at the time. You were 
strongly in favor as well iirc.

Edin



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

Re: [PHP-DEV] CGI and CLI

[Edin Kadribasic]

On Wed, 18 Dec 2002, Shane Caraveo wrote:

> Edin Kadribasic wrote:

[snip]

> > I really don't understand why insist on cgi being installed on "make
> > install" to ${PREFIX}/bin? The solution outlined by Andrei and Derick is
> > much better IMHO because it will alert users of the issue and because
> > installing a cgi into a webserver requires manual action anyway.
> 
> It's realy very logical.  It leaves the default installation the way 
> most people will expect it to behave, which is as it has been for years 
> now.  Having the options allow people to modify that behaviour to the 
> way they want it to work.  It's very flexable for all interests.

This seems to be matter of personal opinion.

I happen to belive that having cli in /usr/bin/php is a real improvement 
over having cgi there. For command line scripts cli is 
(nearly) a drop-in replacement for cgi. I am not aware of webserver 
installs that use cgi in that location.

My great wish was to have the same freedom perl programmers have in 
distributing scripts with #!/usr/bin/perl shebang line. Scripts that you 
could nearly count on being executable on the target host. And scripts 
that would always work, no matter from which context they were called.

Edin




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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /sapi/cli php_cli.c

[Edin Kadribasic]

> >Sorry, I'm still unsure if my patch is the correct one, as I said in the
> >first mail. As far as I've looked into it, the streams seem to be
> >destructed and freed twice, once in deactivation and once in shutdown.
> >If you think my patch is bogus, feel free to revert it unless I can give
> >more reasonable explanation.

I comitted tha patch and I'll revert it. Just to clarify one thing:
constanst throuout PHP should be created as CONST_PERSISTENT?

Edin


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

[PHP-DEV] Re: [PHP-QA] PHP_AUTH_USER

[Edin Kadribasic]

I had discussed the issue with Rasmus and Jani some time ago and the
concensus reached was only to disable PHP_AUTH_USER when safe mode is
active. Nobody got around to do anything about it though. Is this still an
acceptable solution?

Edin
- Original Message -
From: "Phil Driscoll" <[EMAIL PROTECTED]>
To: "PHP QA" <[EMAIL PROTECTED]>
Sent: Wednesday, December 18, 2002 11:14 PM
Subject: [PHP-QA] PHP_AUTH_USER


I thought I'd better draw attention to the issues described at
http://bugs.php.net/20441

I'm sure that the changes made to PHP in this respect are correct, but there
is a BC issue which might affect lots of users, if my experience is typical.

Cheers
--
Phil Driscoll

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





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

Re: [PHP-DEV] CGI and CLI

[Edin Kadribasic]

> Andrei Zmievski wrote:
> > On Wed, 18 Dec 2002, Andi Gutmans wrote:
> >
> >>I doubt this will happen fast enough. We should just release the way we
> >>released 4.2.x, which as far as I know was php for CGI and php-cli for
CLI
> >>or am I a bit behind things? :)
> >
> >
> > Derick and I hashed it out on IRC and we have a proposal:
> >
> > We should keep 4.2.x behavior with some modifications. CLI and CGI
> > should always be built unless disabled, and the executables should go
> > into sapi/cli/php and sapi/cgi/php, respectively. In addition, 'install'
> > target should be modified to detect whether the user is trying to
> > install either one of these SAPIs, output a warning message regarding
> > the potential naming problem, and stop. Let the user install CLI and CGI
> > manually, basically.
> >
> > I really hope we can come to an agreement on this.
>
> I can agree to, and live with, this to some extent.  The changes I would
> want on this would be...
>
> * On win32, cli remains php-cli.exe.  Windows users can rename the
> executable if they feel it's necessary.

I think that this is acceptable to everyone since in this way week keep
status quo to 4.2.x releases.

> * On other platforms, the cgi *is* installed by 'make install' by
> default.  To install cli something like, 'make install-cli', or
> 'configure --install-cli=[DIR] --install-cgi=[DIR]' can be used (the
> second option would be more usefull for installing both, using both
> without [DIR] on one results in a configure error).  A note regarding
> what was installed and where should be added to the output resulting
> from an install.

I really don't understand why insist on cgi being installed on "make
install" to ${PREFIX}/bin? The solution outlined by Andrei and Derick is
much better IMHO because it will alert users of the issue and because
installing a cgi into a webserver requires manual action anyway.

> * Binaries are combined into a single binary in a later release.  I'd be
> happy to do this in January.

-1 for reasons i stated in my reply to Andrei.

> * Documentation is added in regards to this issue.
>
> Shane

Edin


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

Re: [PHP-DEV] CGI and CLI

[Edin Kadribasic]

> The merging of CLI and CGI will still happen, but in 4.3.1.

I was not under the impression that this decision has been reached. In fact
there were several people strongly opposed to the idea and I'm one of them.

I have several reasons one of them being that having an interpreter which
radically changes behavior depending on environmental variables is a bad
idea IMHO. In practice this would mean that one would be unable to run php
command line scripts from within webserver environment, through system()
call from other cgi/php scripts etc.

Edin




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

Re: [PHP-DEV] mbstring/exif/win32

[Edin Kadribasic]

> Both 4.3 and Head still have a problem with mbstring not being
default
> under win32. Exif module can be compiled but not loaded because it
> uses a function from mbstring. Exif tests for HAVE_MBSTRING and
> COMPILE_DL_MBSTRING. The question is why HAVE_MBSTRING is
> defined but COMPILE_DL_MBSTRING is undefined.

I cannot see where HAVE_MBSTRING could be defined on win32. Several
places use this line to check for its presence:

#if HAVE_MBSTRING && !defined(COMPILE_DL_MBSTRING)

This works fine for say main/rfc1867.c. Does it work for you?

Edin


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

Re: [PHP-DEV] distributing windows binaries (dll's) of PECL's

[Edin Kadribasic]

> > We already bundle several pecl extensions in the win32 distro
> > (printer, iisfunc, etc.) I could add radius to the list.
> that would be great!
>
> But how can I provide upgrades of the PECL?
> then the user has to wait until a new php-version is released.

That is a larger question. I'm afraid that there are no satisfactory
aswers to it yet. PECL infrastructure is still pretty much
non-existent. But you're welcome to help defining and implementing
it :)

Edin


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

Re: [PHP-DEV] distributing windows binaries (dll's) of PECL's

[Edin Kadribasic]

Hi,

We already bundle several pecl extensions in the win32 distro
(printer, iisfunc, etc.) I could add radius to the list.

Edin

- Original Message -
From: "Michael Bretterklieber" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, December 13, 2002 12:29 PM
Subject: [PHP-DEV] distributing windows binaries (dll's) of PECL's


> Hi,
>
> I would like to distribute also binaries of my (our) radius PECL
for
> windows, because Windows users usualy don't have visualstudio to
compile
> the PECL.
>
> I would like to make a bin subdirectory and then for each
php-version
> also a subdirectory:
> PECL/radius/bin
> PECL/radius/bin/php4.2.3/php_radius.dll
>
> My question is this allowed?
>
> Are there any other ideas howto distribute binaries of PECL's?
>
> bye,
>
> --
> --- --
> Michael Bretterklieber- [EMAIL PROTECTED]
> JAWA Management Software GmbH - http://www.jawa.at
> Liebenauer Hauptstr. 200-- privat 
> A-8041 GRAZ GSM: ++43-(0)676-93 96 698
> Tel: ++43-(0)316-403274-12  E-mail:   [EMAIL PROTECTED]
> Fax: ++43-(0)316-403274-10  http://www.inode.at/mbretter
> --- --
> "...the number of UNIX installations has grown to 10, with more
> expected..." - Dennis Ritchie and Ken Thompson, June 1972
>
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


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

[PHP-DEV] BC issues in cgi

[Edin Kadribasic]

Since version 1.197 of the cgi_main.c, cgi sapi will identify itself as
"cgi-fcgi" when compiled with fast cgi support (default on windows). This
breaks some PHP scripts and some C code, like PHP's dl() function. IMHO this
should be reverted to the old behavior regardless of the presence of fcgi
code.

Edin


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

Re: [PHP-DEV] Critical Bug #20887

[Edin Kadribasic]

No because it was preciselly because of cgi that CWD wasn't removed
from the php.ini search path. Have a look at the following thread:

http://www.zend.com/lists/php-dev/200202/msg01325.html

Edin

- Original Message -
From: "Moriyoshi Koizumi" <[EMAIL PROTECTED]>
To: "Edin Kadribasic" <[EMAIL PROTECTED]>
Cc: "Derick Rethans" <[EMAIL PROTECTED]>; "Jani Taskinen"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, December 12, 2002 12:44 PM
Subject: Re: [PHP-DEV] Critical Bug #20887


> > At the time CLI was introduced I argued to remove . from php.ini
> > search path, but that was not accepted because some people
> > apparently use this feature for having different configurations
for
> > different virtual hosts.
> >
> > Therefore . was removed only from CLI's php.ini search path.
>
> This feature looks somewhat evil since it enables users to bypass
the safe
> mode restrictions enforced by the administrator, or am I missing
> something?
>
> Anyway, the following patch should make sense for #20887?
>
> Moriyoshi
>
> Index: main/php_ini.c
>
===
> RCS file: /repository/php4/main/php_ini.c,v
> retrieving revision 1.106
> diff -u -r1.106 php_ini.c
> --- main/php_ini.c  12 Nov 2002 20:56:47 -  1.106
> +++ main/php_ini.c  12 Dec 2002 11:22:17 -
> @@ -272,7 +272,8 @@
>
> /* Add cwd */
>  #ifdef INI_CHECK_CWD
> -   if (strcmp(sapi_module.name, "cli")!=0) {
> +   if (strcmp(sapi_module.name, "cgi")==0
> +   || strcmp(sapi_module.name,
"cgi-fcgi")==0) {
> if (*php_ini_search_path) {
> strcat(php_ini_search_path,
paths_separator);
> }
>
>


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

Re: [PHP-DEV] Critical Bug #20887

[Edin Kadribasic]

> You are right. I verified Apache changes the cwd to / unless it's
been
> launched in single process mode.
>
> And I found results could be different by cases, using DSO or
using CGI
> executable. When you run your script with CGI executable and
php.ini is
> also present in that directory, the PHP binary tries to read that
one as
> mod_cgi tries to chdir to where the script is put.
> I'm not sure, but this appears to imply some security issues?

At the time CLI was introduced I argued to remove . from php.ini
search path, but that was not accepted because some people
apparently use this feature for having different configurations for
different virtual hosts.

Therefore . was removed only from CLI's php.ini search path.

Edin


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

Re: [PHP-DEV] php.exe - php-cgi.exe

[Edin Kadribasic]

> So i am -1 on renaming CLI
> And +1 on keeing CGI as php-cgi and CLI as php
> 
> marcus

Just for the record: my vote is the same.

Edin


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

Re: [PHP-DEV] php.exe - php-cgi.exe

[Edin Kadribasic]

> [snip]
>
> Look, IMHO, it all boils down to the same simple points:
> - No drawbacks to naming the PHP CLI as something different than
PHP (well,
> unless you count the gut feeling of people who 'feel make install
should
> install CLI in ${PREFIX}/bin/php', without really being able to
say why).
> - Considerable drawbacks to changing the PHP CGI name.  You may
argue that
> the confusion this would cause is not as bad as I may think, but
you cannot
> argue that it won't cause confusion.  I'm a fairly competent user,
and it
> still took me a few minutes to understand what was going on and
> why.  Suffice to say I came across less competent users.

The big drawback for me is the BC issue of changing all the command
line scripts that contain #!/usr/bin/php in them. I still see no
sense in putting a CGI binary there. Configuring a web server for
running CGI involves manual copy of the PHP binary anyway.

> >P.S. I wish people were following this list more closely so that
we don't
> >have to discuss same issues over and over again.
>
> Unfortunately this is not an option for all of us at any given
time.
> I, for one, do wish that the developers here employed a more
user-oriented
> approach and less 'this should be changed cause it'll be
cool/neat/Right'
> approach.  This would do a lot of good for PHP.

I don't claim to hold a monopoly on what is a user-oriented
approach. I'd sure like to think that the changes implemented are
for the good of the user. Not because they're "cool/neat/Right".

I agree that most of development done in PHP is geared towards the
web. That's what I do for living as well. But in the past 3 years
and about a dozen or so rather large PHP solutions later, I see that
the command line scripting mustn't be neglected either. Why write
backend processes in language other than PHP? Once we have developed
all the classes/libraries for the web solution it is obvious that
the easiest way to implemet the rest of the system is to re-use
those in command line (often run from cron) PHP scripts. And from
what I hear from other development houses, my experiences are far
from unique.

Edin


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

Re: [PHP-DEV] Placebo for bug #20539

[Edin Kadribasic]

Hi,

Your patch seems to resolve the issue. I've applied it.

Thanks,

Edin

- Original Message -
From: "Moriyoshi Koizumi" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, December 11, 2002 5:56 AM
Subject: [PHP-DEV] Placebo for bug #20539


> Hi,
>
> Attached is a patch against the PHP_4_3 branch which appears to
fix the
> bug #20539, while I haven't expected for this to be a cure at all.
I guess  destruction order of constants and resources have something
to do with
> this issue.
>
> Moriyoshi
>






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


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

Re: [PHP-DEV] php.exe - php-cgi.exe

[Edin Kadribasic]

On Tue, 10 Dec 2002, Zeev Suraski wrote:

> I think that's a bit like inventing problems and then trying to fix them.
> Let's keep it down to things we can determine relatively easily:
> 
> - Nothing bad will happen if we name the new CLI with whatever kind of name 
> - php-cli, phpsh, whatever
> - There WILL be some level of confusion if we rename the CGI binary
> 
> If we use this KISS approach, why the heck are we even considering this rename?

The CGI sapi was first renamed to php-cgi on Feb 28, and the change was 
temporarily reverted for the 4.2.x release because CLI sapi was 
considered experimental.

The reason for the name change was discussed on php-dev back then and it 
had to do with the fact that most people felt that "make install" should 
install CLI in ${PREFIX}/bin/php. The goal was to make the php interpreter 
installed on as many machines as possible. And for the reasons of keeping 
BC CLI sapi was named php so that existing scripts that have 
#!/usr/bin/php shebang line would not have to be modified. For the same 
reason CLI silently ignores some command line options (like -q and -C).

The next logical questions was what to do with the CGI sapi. It made very 
little sense to "make install" it under the same name in some different 
folder, so a decision was reached to rename it to php-cgi. "make install" 
and cgi make very little sense anyway since the installer has no way of 
knowing what's the correct location for the binary. Configuring a server 
for execution of php as a cgi requires manual configuration anyway. 

Windows file rename merely mirrored that of the unix build.

I'm still of the oppinion that we should leave things as they are in PHP 
4.3.0-dev for the reasons stated.

Edin

P.S. I wish people were following this list more closely so that we don't 
have to discuss same issues over and over again.


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

Re: [PHP-DEV] Java Extension Build Method

[Edin Kadribasic]

Under the heading "Build java module with -ljava" you mention that there
were crashing problems because libjava.so was linked agains pthread and
apache wasn't. This is not uncommon problem for other libraries such as
oci8. You can link apache with pthread which will prevent the segfaults. See
oci8 manual page for instructions.

Edin

- Original Message -
From: "Tony J. White" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 05, 2002 7:35 PM
Subject: [PHP-DEV] Java Extension Build Method


>
> The /ext/java module is an odd duck compared to other php extentions in
that
> it uses DL_LOAD() to load libjava instead of being linked and that it is
> always built as a module (.so) instead of being built static into php.
>
> I've spent some time over the past couple weeks investigating why this is
> done and experimenting with different build methods.  Although, i haven't
> come up with any breakthroughs in makeing the java extension build any
> other way, I've compiled some notes on the subject:
>
> http://tjw.org/php_java/build_notes.php
>
> I think I have a pretty good handle on why things are the way they are,
but
> am I missing something?
>
> -Tony
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


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

Re: [PHP-DEV] fgetcsv problems was: register_shutdown_function => register_offline_function

[Edin Kadribasic]

> Well, this goes back to my original problem with fgetcsv then.  I can not
> find another application that will accept a CSV file that will allow
> mutliline quoted fields.  They stop at the newline regardless.

Now that's not true. Excel and other spreadsheet programs happily accept
them. They also create multi-line quoted fields when exporting data that has
newlines in them. And having PHP parse those correctly is one of the few
ways getting data out of those apps.

Edin



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

Re: [PHP-DEV] Re: Multiple MSSQL Crashes in 4.3.0RC2

[Edin Kadribasic]

> On Tue, 3 Dec 2002, Michael Sisolak wrote:
>
> > Frank Kromann has investigated these issues and has made fixes
in the
> > CVS version of ext/mssql.
>
> Are these fixes merged into the branch?

Just did that.

Edin


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

Re: [PHP-DEV] Patch for bug #20539

[Edin Kadribasic]

Forget the patch, its not working well. The problem is that with
session autostart SID constant gets defined in rinit and gets
destroyed twice.

Edin

- Original Message -
From: "Edin Kadribasic" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, November 28, 2002 2:11 PM
Subject: [PHP-DEV] Patch for bug #20539


> Hi Sascha,
>
> The attached patch fixes a crash in CLI when php.ini contains:
>
> session.auto_start=1
> magic_quotes_gpc=1
>
> Could you please review it?
>
> Edin
>
>






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


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

[PHP-DEV] Patch for bug #20539

[Edin Kadribasic]

Hi Sascha,

The attached patch fixes a crash in CLI when php.ini contains:

session.auto_start=1
magic_quotes_gpc=1

Could you please review it?

Edin


Index: session.c
===
RCS file: /repository/php4/ext/session/session.c,v
retrieving revision 1.336.2.1
diff -u -3 -p -r1.336.2.1 session.c
--- session.c   20 Nov 2002 17:49:57 -  1.336.2.1
+++ session.c   28 Nov 2002 13:06:46 -
@@ -1031,7 +1031,8 @@ PHPAPI void php_session_start(TSRMLS_D)
smart_str_appendc(&var, '=');
smart_str_appends(&var, PS(id));
smart_str_0(&var);
-   REGISTER_STRINGL_CONSTANT("SID", var.c, var.len, 0);
+   REGISTER_STRINGL_CONSTANT("SID", var.c, var.len, CONST_PERSISTENT | 
+CONST_CS); 
+   smart_str_free(&var);
} else {
REGISTER_STRINGL_CONSTANT("SID", empty_string, 0, 0);
}

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

[PHP-DEV] Re: [PHP-QA] 4.30rc1 on Win32(2k) w/ Apache 1.3.27

[Edin Kadribasic]

> Daily stable build, php4-win32-STABLE-200211261730.zip, seems to work
> fine. Even looks like some other annoying bugs have finally been fixed.
> thanks for the quick response. Seeing a rc fail like that is kinda scary!

Thanks for testing it. Timing of the RC1 was a bit unfortinate for the
windows apache users, but the most important thing is that the problem is
fixed :)

Edin



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

Re: [PHP-DEV] Redirect on Error (not localisation)

[Edin Kadribasic]

> On November 26, 2002 03:09 pm, John Coggeshall wrote:
> > Unless told otherwise, I'm already planning on making a few changes and
> > committing.

-1 

Edin



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

[PHP-DEV] Re: [PHP-QA] 4.30rc1 on Win32(2k) w/ Apache 1.3.27

[Edin Kadribasic]

Could you plase try the latest snapshot from snaps.php.net and report back
on the result?

Edin

- Original Message -
From: "Lucas Nealan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 26, 2002 11:42 PM
Subject: [PHP-QA] 4.30rc1 on Win32(2k) w/ Apache 1.3.27


> Daily build 10-10-2002 of 4.30-dev was working for the most part fine
> for me. I've upgraded to rc1 and get the following error trying to
> execute a simple phpinfo() script named info.php:
>
> ***
> Warning: Unknown(/u\sr\local\www\v2\info.php): failed to create
> stream: No such file or directory in Unknown on line 0
> **
>
> My apache docroot is /usr/local/www/v2 which is working fine for
> non-php apache requests. I've rolled back to my 10-10-2002 cvs binary
> and it executes just fine. The questions seems to be where is the \
> coming from after the /u\sr/ for the path to the php script?
>
> -screen
> http://brainkrash.com/
>
> --
> PHP Quality Assurance Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


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

Re: [PHP-DEV] Re: #20638 [Opn->Fbk]: Apache cannot start

[Edin Kadribasic]

On Tue, 26 Nov 2002, Jan Maska wrote:

> I'm experiencing the same problem.
> 
> OS: Windows XP
> Apache 1.3.27 for Windows
> MySQL 3.23.53-win
> PHP 4.2.3 for Windows (php-4.2.3-Win32.zip)
> 
> After I successfully installed Apache and MySQL, I tried to install PHP as
> module.
> Following the instructions of install.txt I got this result:
> Cannot load [path]/psp/sapi/php4apache.dll into server: module not found.
> 
> The problem lies somewhere within the line 'LoadModule php4_module
> c:/[path]' - but if I look into the .dll the module is there..
> 
> Regards, Jan 'Mac' Maska
> 
> P.S. No 'RTFMs', please.. this error was generated using your installation
> notes. M.

The exact same setup works for me, so you probably missed something. 
Probably the part about putting php4ts.dll and the rest of files in the 
dlls folder into some directory in path (c:\windows\system32 for example).

Edin



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

Re: [PHP-DEV] Error Codes, Langs, etc

[Edin Kadribasic]

On Tue, 26 Nov 2002, Sascha Schumann wrote:

> > This is not FUD. He brought up the issue of M$ practises. And I didn't
> > hear you answer the question about why is "parse error" more difficult to
> > understand than "register_shutdown_function"?
> 
> You need to learn a bit about writing good compilers.  It is
> easy to write a compiler; it is hard to write a compiler with
> good diagnostic output.

You missed my point: you cannot write PHP code without using English. 
Function names, reserved words, etc. are all in English. So does this mean 
that non-English speaking people are unable to write PHP code? Of course 
not. With a good manual this is perfectly possible. IMHO error messages 
are no different.

Edin
 



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

Re: [PHP-DEV] Error Codes, Langs, etc

[Edin Kadribasic]

On Tue, 26 Nov 2002, Sascha Schumann wrote:

> > Billy tried localizing programming languages as well. Remember Excel
> > 95? It ended up in complete disaster and was removed in the next
> > office version.
> 
> The language won't chance. Stop the FUD.

This is not FUD. He brought up the issue of M$ practises. And I didn't 
hear you answer the question about why is "parse error" more difficult to 
understand than "register_shutdown_function"?

Edin


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

Re: [PHP-DEV] [PATCH] Redirect on Error

[Edin Kadribasic]

On Tue, 26 Nov 2002, Maxim Maletsky wrote:
> I rather propose. And, it seems to interest many on the list.

Don't forget that there seem to be many who strongly opose your 
suggestion.

Edin



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

Re: [PHP-DEV] Error Codes, Langs, etc

[Edin Kadribasic]

> >  I've seen a big poster in my local Fullbright foundation
represantive.
> > It says something like : "One of every four people on the earth
knows some
> > English".
>
> Why does Billy localize M$ windows then? And, most importantly,
what
> would he sell without doing it? Remember, his users know basic IT
english
> too.

Billy tried localizing programming languages as well. Remember Excel
95? It ended up in complete disaster and was removed in the next
office version.

Edin


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

Re: [PHP-DEV] [PATCH] Redirect on Error

[Edin Kadribasic]

> And, most importantly, what the hell doi I care of losing 0.12
secs
> for a Fatal Error dysplay?

I don't like the whole idea of having localized error messages.
People have to use English when programming PHP anyway, and nobody
is insane enough (yet) to suggest to translate function names. I
don't think "Parse error" is any more difficult to understand than
register_shutdown_function(). People use manual for understanding
things like this.

And I do care about unnecessary performance loss. But most of all I
care about maintenance nightmare that this localization would put us
in. If some of the pro-localization ever bother to read the php-bugs
you would know that even a simple matter of using the correct .ini
or .dll file can be too much for your target audience. Adding some
CDB file to it is not going to help. The other side is maintaining
the translation in the PHP code itself. This is just too large a
task for the current team.

I think it would be far more useful that some energy is spent on
keeping PHP manual up to date so say our Italian users would have
some clue about streams once PHP 4.3.0 hits the street.

Edin


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

Re: [PHP-DEV] Oracle < 8.1.7

[Edin Kadribasic]

No go. OCIServerRelease seems not to be supported in Oracle 8.0:

ext/oci8/oci8.o: In function `zif_ociserverrelease':
ext/oci8/oci8.c:4551: undefined reference to `OCIServerRelease'

Edin

- Original Message -
From: "Maxim Maletsky" <[EMAIL PROTECTED]>
To: "Edin Kadribasic" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, November 26, 2002 12:46 AM
Subject: Re: [PHP-DEV] Oracle < 8.1.7


>
> ok.
>
> here is the patch as txt. It applies to the latest CVS of the file. But,
> in any case - there is only that very function that is not documented
> anywhere, and I wonder whether it works.
>
> to test it, just run this:
>
> 
> $conn = OCILogon('user', 'pass', 'listener');
> echo "\nServer version: " . OCIServerVersion($conn);
> echo "\nServer release: " . OCIServerRelease($conn);
>
> /*
>  you should expect something like that. Important part is the last line -
release code
>
> Server version: Oracle9i Enterprise Edition Release 9.0.1.1.0 - Production
> With the Partitioning option
> JServer Release 9.0.1.0.0 - Production
> Server release: 150999296
>
> */
> ?>
>
>
> let me know.
>
> ---
> Maxim Maletsky
> [EMAIL PROTECTED]
>
>
> On Tue, 26 Nov 2002 00:18:17 +0100 "Edin Kadribasic" <[EMAIL PROTECTED]>
wrote:
>
> > > That sounds very good. What version is your oracle client?
> >
> > The client is on the same Linux box, so the version is still 8.0.5.
> >
> > Edin
> >
> >
>


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

Re: [PHP-DEV] Oracle < 8.1.7

[Edin Kadribasic]

> That sounds very good. What version is your oracle client?

The client is on the same Linux box, so the version is still 8.0.5.

Edin



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

Re: [PHP-DEV] Oracle < 8.1.7

[Edin Kadribasic]

> Does anyone have an access to any lower versions of Oracle Servers and
> Oracle Clients to compile and test from CVS? Especially Client. If so,
> please let me know.

I've got access to Oracle 8.0.5 on Linux.

Edin



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

Re: [PHP-DEV] [PATCH 4.3.0] Win32 CoInitalize/CoUninitialize Call Move

[Edin Kadribasic]

+1

Anything that impoves stability of isapi at this point is more than welcome.
Hopefully bugs.php.net quickfix "isapi instability" will not have to be used
as often :)

Edin

- Original Message -
From: "Michael Sisolak" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 25, 2002 7:32 PM
Subject: [PHP-DEV] [PATCH 4.3.0] Win32 CoInitalize/CoUninitialize Call Move


> While stess testing the recent threading fixes under the ISAPI module I
> was seeing a lot of instability in IIS after the testing finished.
> While the PHP pages would continue to load, no ASP pages would anymore.
>  I have tracked this down to the placement of the Win32 CoInitialize()
> and CoUninitialize() calls.  In the current 4.3.0 release candidate
> CoInitialize() and CoUninitialize() are only called once per thread
> (from the basic_globals_ctor/_dtor in basic_functions.c).  According to
> Microsoft, however, at
> http://msdn.microsoft.com/library/en-us/iisref/html/psdk/asp/devs0hm5.asp:
>
> "COM initialization, from CoInitialize or CoInitializeEx, affects the
> thread in which it's called. For this reason, you cannot initialize COM
> unless you uninitialize it before returning from your callback
> function. [ . . .] CoInitialize and CoUninitialize need to be called in
> order. If one is called twice in a row, by different ISAPIs on the same
> thread, your users may see error 270."
>
> This is exactly the error I am seeing: if I load an ASP page in a
> thread that has processed PHP pages I get the 270 error (reported as
> "Error -2147417842 (0x8001010e)").  I moved the CoInitilize call to
> PHP_RINIT_FUNCTION(basic) and CoUninitialize to
> PHP_RSHUTDOWN_FUNCTION(basic) and reran my stress testing.  After
> 100,000 PHP page loads IIS now remains stable and able to process both
> ASP and PHP pages.
>
> I ran this by Zeev and he suggested that some kind of just-in-time COM
> initialization, but I'm not going to have the time to get to this full
> solution until later.  In the meantime for 4.3.0 I request that the
> attached patch is applied that moves the CoInitialize or CoInitializeEx
> calls to be per-request.  This is the last little fix that all the
> multi-threading bug fixing to make the ISAPI rock solid in 4.3.0
> requires.  I've done a lot of testing and feel very confident about
> including this patch.
>
> Michael Sisolak
> [EMAIL PROTECTED]
>
>
> __
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com






> --- basic_functions.c.orig Fri Nov 08 10:49:32 2002
> +++ basic_functions.c Mon Nov 25 13:25:09 2002
> @@ -959,10 +959,6 @@
>   memset(&BG(url_adapt_state), 0, sizeof(BG(url_adapt_state)));
>   memset(&BG(url_adapt_state_ex), 0, sizeof(BG(url_adapt_state_ex)));
>
> -#ifdef PHP_WIN32
> - CoInitialize(NULL);
> -#endif
> -
>   BG(incomplete_class) = php_create_incomplete_class(TSRMLS_C);
>  }
>
> @@ -973,9 +969,6 @@
>   if (BG(sm_allowed_env_vars)) {
>   free(BG(sm_allowed_env_vars));
>   }
> -#ifdef PHP_WIN32
> - CoUninitialize();
> -#endif
>  }
>
>
> @@ -1102,6 +1095,10 @@
>
>  PHP_RINIT_FUNCTION(basic)
>  {
> +#ifdef PHP_WIN32
> + CoInitialize(NULL);
> +#endif
> +
>   memset(BG(strtok_table), 0, 256);
>   BG(strtok_string) = NULL;
>   BG(strtok_zval) = NULL;
> @@ -1182,6 +1179,10 @@
>   if (BG(mmap_file)) {
>   munmap(BG(mmap_file), BG(mmap_len));
>   }
> +#endif
> +
> +#ifdef PHP_WIN32
> + CoUninitialize();
>  #endif
>
>   return SUCCESS;
>
>






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


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

Re: [PHP-DEV] Fix for bug 19207 (change of cgi behaviour in PHP 4.3.0)

[Edin Kadribasic]

On Friday 22 November 2002 04:18, Jani Taskinen wrote:
> I can't remember that discussion..but why do we need
> yet another ini option? If the current behaviour is incorrect,
> and you can fix it..why do you even ask here? :)

FYI:
http://www.phpbuilder.com/mail/php-developer-list/2002092/0238.php
http://bugs.php.net/bug.php?id=19207

Edin

P.S. I don't like adding ini setting either, but I see no other way of solving 
the issue.

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

[PHP-DEV] Fix for bug 19207 (change of cgi behaviour in PHP 4.3.0)

[Edin Kadribasic]

Attached is a patch that fixes bug #19207 in accordance with previous 
discussion on php-dev. It add cgi.rfc2616_headers ini option which is by 
default set to off and mimics current 4.3.0 behaviour. If its set to on the 
HTTP status line is sent in accordance to RFC2616 which was default  for PHP 
4.2.3 and earlier.

Any objections to commiting this fix?

Edin
diff -u -3 -p -r1.190.2.2 cgi_main.c
--- cgi_main.c  15 Nov 2002 00:33:18 -  1.190.2.2
+++ cgi_main.c  22 Nov 2002 00:12:20 -
@@ -241,8 +241,23 @@ static int sapi_cgi_send_headers(sapi_he
int len;
sapi_header_struct *h;
zend_llist_position pos;
-
-   len = sprintf(buf, "Status: %d\r\n", SG(sapi_headers).http_response_code);
+   long rfc2616_headers = 0;
+
+   /* Check wheater to send RFC2616 style headers compatible with
+* PHP versions 4.2.3 and earlier compatible with web servers
+* such as IIS. Default is informal CGI RFC header compatible
+* with Apache.
+*/
+   if (cfg_get_long("cgi.rfc2616_headers", &rfc2616_headers) == FAILURE) {
+rfc2616_headers = 0;
+   }
+
+   if (rfc2616_headers && SG(sapi_headers).http_status_line) {
+   len = sprintf(buf, "%s\r\n", SG(sapi_headers).http_status_line);
+   } else {
+   len = sprintf(buf, "Status: %d\r\n", 
+SG(sapi_headers).http_response_code);
+   }
+
PHPWRITE_H(buf, len);

if (SG(sapi_headers).send_default_content_type) {


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

Re: [PHP-DEV] error handling

[Edin Kadribasic]

On Thursday 21 November 2002 08:04, Derick Rethans wrote:
> I still think that an included file just should fail hard and I just
> dont like this kind of obfucsication.

I agree with this 100%. It is IMHO a complete waste of time trying to handle 
parse errors gracefully. Most "solutions" proposed in this thread are either 
server specific or would have an impact on normal php operation (would 
require output buffering, etc.).

Edin


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

Re: [PHP-DEV] GD segfault in 4.3.0RC1

[Edin Kadribasic]

On Mon, 18 Nov 2002, Derick Rethans wrote:

> On Mon, 18 Nov 2002, Marcus Börger wrote:
> 
> > Brian could you create a short test for the segfault? It would help us
> > finding out the problems.
> 
> For now I think it's very wise to remove all the e*() memory functions 
> from the branch, it's not strictly needed and we need to be very careful 
> not to emalloc data that should be preserved accross requests. That's 
> why I've a patch read to remove the e*() stuff for the branch so that we 
> have a lot of time for the 4.4/5.0 version to check all these things 
> out.

+1

I think it's the safest thing to do ATM.

Edin



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

[PHP-DEV] Apache hooks link problem

[Edin Kadribasic]

I'm trying to make project files to make apache_hooks available on
windows. However, I cannot get it to link properly. I'm getting
'php_request_startup_for_hook' undefined symbol error.

Edin


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

Re: [PHP-DEV] error handling

[Edin Kadribasic]

On Mon, 18 Nov 2002, John Bradford wrote:

> On a similar note, I posted a patch a few days ago which was intended
> for development environments - it makes error messages appear in a
> clear 'window' in the middle of the browser window, so that you don't
> have to hunt around in the output of the program to find it.  I've
> attached it again, in case you're insterested.

You were also told that this functionality can be achieved with 
error_prepend_string and error_append_string ini settings, so there is no 
real need for additional functionality.

Edin



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

Re: [PHP-DEV] Re: #20461 [Opn->Bgs]: Unable to access $PHP_AUTH_USERor $PHP_AUTH_PW

[Edin Kadribasic]

On Sun, 17 Nov 2002, Rasmus Lerdorf wrote:

> > > But why do you assume that the documentation was right and the code was
> > > wrong and not the other way around?
> >
> > Because it was working like documented before. (When the documentation
> > was written). Anyway, not sure what to do with this one...
> 
> I don't have the energy to do a cvs check, but I remember adding this
> restriction years ago (php2 days) and then removing it (by commenting out
> the check) ages ago as well. I'm not sure PHP4 ever had this check turned
> on (the commented out check was ported to php4), so the documentation has
> not reflected reality in a very long time.

I agree that this change is going to break a lot of code. Some of it is my 
own :)

I suggest that we always populate $PHP_AUTH_USER since that one has no 
security consequences and the information is awailable elsewhere 
($_SERVER['REMOTE_USER']). $PHP_AUTH_PW should be set when there are no 
safe_mode/open_basedir restrctions in effects.

Would this solution be satisfactory to everyone?

Edin



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

[PHP-DEV] Re: #20441 [Opn->Bgs]: PHP_AUTH_USER isn't set

[Edin Kadribasic]

Well actually you could. From the beginning of time up to 4.3.0. I
expect to see a lot of bug reports similar to this one.

Edin

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, November 15, 2002 10:10 AM
Subject: #20441 [Opn->Bgs]: PHP_AUTH_USER isn't set


> ID:   20441
>  Updated by:   [EMAIL PROTECTED]
>  Reported By:  [EMAIL PROTECTED]
> -Status:   Open
> +Status:   Bogus
>  Bug Type: Apache related
>  Operating System: Redhat Linux 7.1 kernel 2.4.2-2
>  PHP Version:  4.3.0-pre2
>  New Comment:
>
> You need to decide if you are using an external auth mechanism or
http
> auth from php.  You can't do both.
>
>
> Previous Comments:
> --
--
>
> [2002-11-15 02:58:24] [EMAIL PROTECTED]
>
> I've upgraded PHP 4.2.3 to the beta 4.3.0-pre2 and I've set
register
> globals on in php.ini.
>
> My Apache version is 1.3.24.
> PHP configure:
> ./configure --with-apxs=/usr/local/apache/bin/apxs
> --with-mysql=/usr/local/mysql --enable-ftp --with-openssl
>
> The script is using this .htaccess-file
>
> AuthType Basic
> AuthName 'Urenregistratie'
> AuthUserFile /htpasswd/urenreg
> require valid-user
>
> I am sure that Apache is setting the PHP_AUTH_USER because the
> following script gives the correct output:
>
> // begin dirty hack
> $headers = apache_request_headers();
> foreach ($headers as $header => $value) {
> if ($header == "Authorization")
> {
>$value = str_replace(" ", "", $value);
>$value = str_replace("Basic", "", $value);
>$userArray = explode(":", base64_decode($value));
> $PHP_AUTH_USER = $userArray[0];
> }
> }
> echo $PHP_AUTH_USER;
> // end dirty hack
>
> If I echo $PHP_AUTH_USER or $_SERVER["PHP_AUTH_USER"] above this
script
> I am getting a empty result.
>
> Note: the script was functioning 100% properly with php 4.2.3
>
>
>
>
> --
--
>
>
> --
> Edit this bug report at http://bugs.php.net/?id=20441&edit=1
>
>
>


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

Re: [PHP-DEV] Re: php4 / configure.in /main php_version.h

[Edin Kadribasic]

>   I would love to see that happen. But in this "special" case it's
not
>   just a number. Maybe we should create a new CVS module, php5, to
which
>   we copy php4/* and let "cvs co php5" automatically checkout TSRM
and
>   ZendEngine2 (as Zend, of course).

You can do that without copying the repository. Currently the cvs
alias for checking out ZE2 is php4-ze2 but I guess that can be
changed to php5.

Edin


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

Re: [PHP-DEV] snaps.php.net

[Edin Kadribasic]

Unfortunatelly we don't save the logs for each win32 build. Only for
the latest one. It sort of make sense since there are situations
where we need compile log even if the build failed.

Edin

- Original Message -
From: "Marcus Börger" <[EMAIL PROTECTED]>
To: "Edin Kadribasic" <[EMAIL PROTECTED]>
Cc: "PHP developer list" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, November 14, 2002 11:43 AM
Subject: Re: [PHP-DEV] snaps.php.net


> Nice :-)
>
> Could we have the log files to each build (download) as an extra
link?
>
> marcus
>
> At 02:09 14.11.2002, Edin Kadribasic wrote:
> >Because of the creation of PHP_4_3 branch snaps.php.net was
updated so that
> >STABLE snapshots are made off that branch.
> >
> >Thanks to Ilia Alshanetsky we have a new pretty face on the snaps
which can
> >be seen at http://snaps.php.net/snaps.php
> >
> >My plan is to make this default look of the snaps.php.net in the
next couple
> >of days.
> >
> >Edin
> >
> >
> >
> >--
> >PHP Development Mailing List <http://www.php.net/>
> >To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


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

[PHP-DEV] snaps.php.net

[Edin Kadribasic]

Because of the creation of PHP_4_3 branch snaps.php.net was updated so that
STABLE snapshots are made off that branch.

Thanks to Ilia Alshanetsky we have a new pretty face on the snaps which can
be seen at http://snaps.php.net/snaps.php

My plan is to make this default look of the snaps.php.net in the next couple
of days.

Edin



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

Re: [PHP-DEV] build fails on bison: update

[Edin Kadribasic]

I hate to say it, but it works fine here (tm). Using bison 1.75 from cygwin.

Edin

- Original Message -
From: "Maxim Maletsky" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 14, 2002 12:54 AM
Subject: Re: [PHP-DEV] build fails on bison: update


>
> That does not happen, however, on PHP_4_3 tag.
>
> So just FYI.
>
> --
> Maxim Maletsky
> [EMAIL PROTECTED]
>
>
> On Thu, 14 Nov 2002 00:40:00 +0100 Maxim Maletsky <[EMAIL PROTECTED]> wrote:
>
> >
> > guys,
> >
> > current W32 build has failed on bison for me with the parse error:
> >
> >
> >
> > Configuration: TSRM - Win32
Release_TS
> > Compiling...
> > TSRM.c
> > tsrm_strtok_r.c
> > tsrm_virtual_cwd.c
> > tsrm_win32.c
> > Creating library...
> > Configuration: ZendTS - Win32
Release_TS
> > Performing Custom Build Step on ".\zend_language_scanner.l"
> > Compiling...
> > zend.c
> > zend_alloc.c
> > zend_API.c
> > zend_builtin_functions.c
> > zend_compile.c
> > Generating Code...
> > Compiling...
> > zend_constants.c
> > zend_dynamic_array.c
> > zend_execute.c
> > zend_execute_API.c
> > F:\CVS\PHP.NET\php4\Zend\zend_execute_API.c(366) : warning C4018: '==' :
signed/unsigned mismatch
> > zend_extensions.c
> > Generating Code...
> > Compiling...
> > zend_hash.c
> > zend_highlight.c
> > zend_indent.c
> > zend_ini.c
> > zend_ini_parser.c
> > Generating Code...
> > Compiling...
> > zend_ini_scanner.c
> > zend_language_parser.c
> > bison.simple(81) : error C2059: syntax error : '/'
> > bison.simple(83) : warning C4138: '*/' found outside of comment
> > bison.simple(189) : error C2449: found '{' at file scope (missing
function header?)
> > bison.simple(196) : error C2059: syntax error : '}'
> > bison.simple(248) : error C2449: found '{' at file scope (missing
function header?)
> > zend_language_parser.y(177) : error C2130: #line expected a string
containing the filename, found '&'
> > zend_language_parser.y(358) : error C2005: #line expected a line number,
found 'identifier'
> > bison.simple(760) : error C2059: syntax error : '}'
> > zend_language_scanner.c
> > zend_language_scanner.c(5726) : warning C4273: 'isatty' : inconsistent
dll linkage.  dllexport assumed.
> > zend_list.c
> > zend_llist.c
> > Generating Code...
> > Compiling...
> > zend_multibyte.c
> > zend_opcode.c
> > zend_operators.c
> > zend_ptr_stack.c
> > zend_qsort.c
> > Generating Code...
> > Compiling...
> > zend_sprintf.c
> > zend_stack.c
> > zend_variables.c
> > Generating Code...
> > Error executing cl.exe.
> >
> > php.exe - 7 error(s), 3 warning(s)
> >
> > --
> > Maxim Maletsky
> > [EMAIL PROTECTED]
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


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

Re: [PHP-DEV] php4apache on win32 regex problem?

[Edin Kadribasic]

..\..\regex needs to be included in the include path in php4apache.dsp.

Edin

- Original Message -
From: "Dave Viner" <[EMAIL PROTECTED]>
To: "Php-Dev@lists. php. net" <[EMAIL PROTECTED]>
Sent: Thursday, November 14, 2002 12:35 AM
Subject: RE: [PHP-DEV] php4apache on win32 regex problem?


> after struggling some more, i've discovered that for some reason, in my
> php4apache compilation, the value of REGEX is set to 0.  Therefore vc++ is
> trying to do:
>
> #if REGEX
> .. snip ..
> #elif REGEX == 0
> #include 
> #ifndef _REGEX_H_
> #define _REGEX_H_ 1
> #endif
> #endif
>
> i have updated my php cvs tree.  i realize that the standard snap build
> doesn't have this problem, but i can't see why I have this problem.  Can
> anyone offer advice on this?  Or is there a win32 buildmeister that I
could
> talk to off the list for help ?
>
> dave
>
> -Original Message-
> From: Dave Viner [mailto:dviner@;yahoo-inc.com]
> Sent: Tuesday, November 12, 2002 2:35 PM
> To: Php-Dev@lists. php. net
> Subject: [PHP-DEV] php4apache on win32 regex problem?
>
>
> has anyone seen this error on win32 php4apache?
>
> Configuration: php4apache - Win32
> Release_TS
> Compiling...
> mod_php4.c
> ..\..\main\php_regex.h(39) : fatal error C1083: Cannot open include file:
> 'regex.h': No such file or directory
> php_apache.c
> ..\..\main\php_regex.h(39) : fatal error C1083: Cannot open include file:
> 'regex.h': No such file or directory
> sapi_apache.c
> ..\..\main\php_regex.h(39) : fatal error C1083: Cannot open include file:
> 'regex.h': No such file or directory
> Error executing cl.exe.
>
> is there some cygwin package that I need to install in order to obtain the
> regex.h header file ?
>
> thanks
> dave
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


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

Re: [PHP-DEV] Windows build and mbstrig

[Edin Kadribasic]

> It seems the changes to make mbstring no longer a default
> module were a little bit unsophisticated ...
>
> mbstring is not included in default build but HAVE_MBSTING
> is defined. Therefor exif does not compile any longer. And there
> are problems in mbstring itself. See:
http://snaps.php.net/win32/compile.log

I've disabled it properly now.

> Also there is aproblem with the time display in the win32 directory
> of the snaps server.

You should look at the file name. Time stamp there is in UTC timezone
(MMDDHHmm).

Edin



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

Re: [PHP-DEV] DBA and Win

[Edin Kadribasic]

Dba on windows now builds with db3, cdb, cdb_make and flatfile
support. I didn't test it beyond building and loading. phpinfo shows
that those handlers are active.

I should probably run some test, but I don't know which?

Edin


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

Re: [PHP-DEV] mbstring and 4.3.0

[Edin Kadribasic]

> For me it was the wide stream of bugreports coming in; can't speak
for
> the others though.

If the stream of bug reports was the criteria the whole of PHP
should be considered highly experimental :)

Edin


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

[PHP-DEV] w32api extesion

[Edin Kadribasic]

On Tuesday 12 November 2002 15:31, James Moore wrote:
> jmooreTue Nov 12 09:31:35 2002 EDT
>
>   Added files:
> /php4/ext/w32api  w32api_function_definition_parser.y
>   w32api_function_definition_scanner.l
>   w32api_type_definition_parser.y
>   w32api_type_definition_scanner.l

This does not compile on the snapshot machine. Please have a look at 
http://snaps.php.net/win32/compile.log for details. Could it be it's because 
I'm using very recent bison version (1.75)?

Edin


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

Re: [PHP-DEV] DBA and Win

[Edin Kadribasic]

On Tuesday 12 November 2002 13:36, Marcus Börger wrote:
> Could someone with windows please add bundled flatfile
> and cdb support for ext/dba to the windows build?

Could you tell me which files need to be compiled and and which defines to be 
set?

Edin


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

Re: [PHP-DEV] cvs: php4 /ext/standard flock_compat.c

[Edin Kadribasic]

>   correct the last patch: make flock() a function again when it is
missing
>   #function name should be flock and not php_flock of cause

Nice. Now both PHP and ext/dba build correctly.

Edin


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

Re: [PHP-DEV] PHP Snaps

[Edin Kadribasic]

On Tuesday 12 November 2002 07:41, Derick Rethans wrote:
> On Tue, 12 Nov 2002, Edin Kadribasic wrote:
> > Any objections to changing timestamp timezone on source snaps to UTC?
> > Windows snapshots are already using it.
>
> Would be nice to have...

Ok. From now on snapshot filename should contain timestamp with UTC timezone.

Edin


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

Re: [PHP-DEV] bison error [was: PHP 4.3.0]

[Edin Kadribasic]

On Tuesday 12 November 2002 01:25, Dave Viner wrote:
> i got the 1.75 from cygwin, so you should be able to find it.

Yup. Windows snapshot and release build machine has an updated version of 
cygwin installed. That version contains bison 1.75.

Edin


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

Re: [PHP-DEV] bison error [was: PHP 4.3.0]

[Edin Kadribasic]

On Tuesday 12 November 2002 01:11, Dave Viner wrote:
> is anyone out there building php source from cvs using win32 ?  if so, what
> version of bison are you using ? and can you try using 1.75 ?

Windows build machine is using GNU bison 1.34. I'll try to see if cygwin has 
1.75 package, if not i'll downgrade to 1.28.

Edin


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

Re: [PHP-DEV] cvs: php4 /ext/standard flock_compat.c flock_compat.h

[Edin Kadribasic]

On Tuesday 12 November 2002 00:40, Marcus Boerger wrote:
> helly Mon Nov 11 18:40:33 2002 EDT
>
>   Modified files:
> /php4/ext/standardflock_compat.c flock_compat.h
>   Log:
>   make flock() a function again when it is missing

>  #ifndef HAVE_FLOCK
> -/* defines flock as php_flock */
> +PHPAPI int php_flock(int fd, int operation)
> +{
> + return php_flock(fd, operation);
> +}
>  #endif /* !defined(HAVE_FLOCK) */

Erm, this doesn't look right and gives the following compile error:

Compiling...   
  
file.c 
  
flock_compat.c 
  
c:\php4build\php4-new\ext\standard\flock_compat.c(125) : error C2084: function 
'int __cdecl php_flock(int ,in
t )' already has a body
  
mod_files.c
  
Error executing cl.exe.
  
   
  
php-cgi.exe - 1 error(s), 0 warning(s)

Edin

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

[PHP-DEV] PHP Snaps

[Edin Kadribasic]

Any objections to changing timestamp timezone on source snaps to UTC? Windows 
snapshots are already using it.

Edin


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

Re: [PHP-DEV] Openssl / DBA extensions broken on windows

[Edin Kadribasic]

On Monday 11 November 2002 21:43, Marcus Börger wrote:
> At 14:03 11.11.2002, Edin Kadribasic wrote:
> >Could the maintainers have a look? Details available at
> >http://snaps.php.net/win32/compile.log
>
> Thanks for notifying :-)
> DBA fixed now - now next step in development...
> Hope this doesn't break win build again...

Now the whole win32 build is broken :)

I get the following link error: 

basic_functions.obj : error LNK2001: unresolved external symbol _zif_flock 
  
..\Release_TS\php4ts.dll : fatal error LNK1120: 1 unresolved externals

Edin

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