[PHP-DEV] Re: PHP Startup Error In Apache

[J Smith]

Looks like a problem with your php.ini file. There should be some lines in
there that read something like

extension=xslt.so
extension=xmlrpc.so
extension=xml.so

There should also be a line that reads

extension_dir="/some/path"

Make sure the path in extension_dir actually leads to the extension library
files. If it doesn't, change it. If those files don't exist, remove their
"extension=" entries.

This sort of question belongs in php.general, not php.dev. 

J


Ray Hunter wrote:

> 
> Has anyone seen these startup errors before?
> 
> These are from my apache error_log file when i start up apache:
> 
> PHP Warning:  Unknown(): Unable to load dynamic library
>
'/usr/local/php-4.3.0/lib/php/extensions/no-debug-non-zts-20020429/xslt.so'
> -
> /usr/local/php-4.3.0/lib/php/extensions/no-debug-non-zts-20020429/xslt.so:
> cannot open shared object file: No such file or directory in Unknown on
> line 0
> 
> PHP Warning:  Unknown(): Unable to load dynamic library
>
'/usr/local/php-4.3.0/lib/php/extensions/no-debug-non-zts-20020429/xmlrpc.so'
> -
>
/usr/local/php-4.3.0/lib/php/extensions/no-debug-non-zts-20020429/xmlrpc.so:
> cannot open shared object file: No such file or directory in Unknown on
> line 0
> 
> PHP Warning:  Unknown(): Unable to load dynamic library
> '/usr/local/php-4.3.0/lib/php/extensions/no-debug-non-zts-20020429/xml.so'
> -
> /usr/local/php-4.3.0/lib/php/extensions/no-debug-non-zts-20020429/xml.so:
> cannot open shared object file: No such file or directory in Unknown on
> line 0
> 
> PHP:4.3.0 - 4.3.1
> Apache: 1.3.27
> Mandrake:   9.0
> 
> 
> How can i fix these warnings?
> 
> 
> Thanks,
> 
> Ray


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

[PHP-DEV] Re: Segmentation violation

[J Smith]

How about providing a short example script that reproduces the segfault?
Posting a backtrace is all well and good, but it's not very useful if
nobody can see what initiated it.

J


Matt wrote:

> Hi, i've never posted to this newsgroup b4 so pls don't shoot me down if
> this is not protocol. But I've been trying to debug a seg fault trying
> varying options from various postings with little success. After
> generating a stacktrace I'm not sure really what to do next to find the
> problem. If anyone can help me, given the trace below that'd be fantastic.
> 
> thanks,
> 
> Matt - [EMAIL PROTECTED]
> 



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

[PHP-DEV] Re: Fix for bug #22386

[J Smith]

Er, wrong patch. Proper one is attached.

J 

I wrote:

> 
> The browscap extension is trying to load stuff into the object_store
> before it gets initialized, so this'll fix it. Entries from the
> browscap.ini file are now stored in straight hashes rather than objects,
> but the return value is still an object.
> 

> 
> J
Index: browscap.c
===
RCS file: /repository/php4/ext/standard/browscap.c,v
retrieving revision 1.68
diff -u -r1.68 browscap.c
--- browscap.c	24 Jan 2003 16:29:40 -	1.68
+++ browscap.c	11 Mar 2003 17:52:14 -
@@ -34,11 +34,11 @@
 
 static void browscap_entry_dtor(zval *pvalue)
 {
-	if (Z_TYPE_P(pvalue) == IS_OBJECT) {
+	if (Z_TYPE_P(pvalue) == IS_ARRAY) {
 		TSRMLS_FETCH();
 
-		zend_hash_destroy(Z_OBJPROP_P(pvalue));
-		free(Z_OBJPROP_P(pvalue));
+		zend_hash_destroy(Z_ARRVAL_P(pvalue));
+		free(Z_ARRVAL_P(pvalue));
 	}
 }
 
@@ -61,8 +61,9 @@
 	}
 
 	t = (char *) malloc(Z_STRLEN_P(pattern)*2 + 1);
+	t[0] = '^';
 	
-	for (i=0, j=0; ivalue.ht = section_properties;
+zend_hash_update(&browser_hash, Z_STRVAL_P(arg1), Z_STRLEN_P(arg1)+1, (void *) ¤t_section, sizeof(zval *), NULL);
 
 Z_STRVAL_P(processed) = Z_STRVAL_P(arg1);
 Z_STRLEN_P(processed) = Z_STRLEN_P(arg1);
 Z_TYPE_P(processed) = IS_STRING;
+Z_STRVAL_P(unprocessed) = Z_STRVAL_P(arg1);
+Z_STRLEN_P(unprocessed) = Z_STRLEN_P(arg1);
+Z_TYPE_P(unprocessed) = IS_STRING;
+Z_STRVAL_P(unprocessed) = zend_strndup(Z_STRVAL_P(unprocessed), Z_STRLEN_P(unprocessed));
+
 convert_browscap_pattern(processed);
-zend_hash_update(section_properties, "browser_name_pattern", sizeof("browser_name_pattern"), (void *) &processed, sizeof(zval *), NULL);
+zend_hash_update(section_properties, "browser_name_regex", sizeof("browser_name_regex"), (void *) &processed, sizeof(zval *), NULL);
+zend_hash_update(section_properties, "browser_name_pattern", sizeof("browser_name_pattern"), (void *) &unprocessed, sizeof(zval *), NULL);
 			}
 			break;
 	}
@@ -154,6 +164,7 @@
 
 	if (browscap) {
 		zend_file_handle fh;
+		memset(&fh, 0, sizeof(fh));
 
 		if (zend_hash_init(&browser_hash, 0, NULL, (dtor_func_t) browscap_entry_dtor, 1)==FAILURE) {
 			return FAILURE;
@@ -197,7 +208,11 @@
 	if (*found_browser_entry) { /* already found */
 		return 0;
 	}
-	if(zend_hash_find(Z_OBJPROP_PP(browser), "browser_name_pattern", sizeof("browser_name_pattern"), (void **) &browser_name) == FAILURE) {
+	if (zend_hash_find(Z_ARRVAL_PP(browser), "browser_name_regex", sizeof("browser_name_regex"), (void **) &browser_name) == FAILURE) {
+		return 0;
+	}
+
+	if (Z_STRVAL_PP(browser_name)[0] != '^') {
 		return 0;
 	}
 	if (regcomp(&r, Z_STRVAL_PP(browser_name), REG_NOSUB)!=0) {
@@ -215,35 +230,35 @@
Get information about the capabilities of a browser */
 PHP_FUNCTION(get_browser)
 {
-	zval **agent_name, **agent;
+	zval **agent_name = NULL, **agent, **retarr;
 	zval *found_browser_entry, *tmp_copy;
 	char *lookup_browser_name;
+	zend_bool return_array = 0;
 
 	if (!INI_STR("browscap")) {
 		php_error_docref(NULL TSRMLS_CC, E_WARNING, "browscap ini directive not set.");
 		RETURN_FALSE;
 	}
-	
-	switch(ZEND_NUM_ARGS()) {
-		case 0:
-			if (!PG(http_globals)[TRACK_VARS_SERVER]
-|| zend_hash_find(PG(http_globals)[TRACK_VARS_SERVER]->value.ht, "HTTP_USER_AGENT", sizeof("HTTP_USER_AGENT"), (void **) &agent_name)==FAILURE) {
-php_error_docref(NULL TSRMLS_CC, E_WARNING, "HTTP_USER_AGENT variable is not set, cannot determine user agent name");
-RETURN_FALSE;
-			}
-			break;
-		case 1:
-			if (zend_get_parameters_ex(1, &agent_name)==FAILURE) {
-RETURN_FALSE;
-			}
-			break;
-		default:
-			WRONG_PARAM_COUNT;
-			break;
+
+	if (ZEND_NUM_ARGS() > 2 || zend_get_parameters_ex(ZEND_NUM_ARGS(), &agent_name, &retarr) == FAILURE) {
+		ZEND_WRONG_PARAM_COUNT();
 	}
 	
+	if (agent_name == NULL) {
+		if (!PG(http_globals)[TRACK_VARS_SERVER]
+			|| zend_hash_find(PG(http_globals)[TRACK_VARS_SERVER]->value.ht, "HTTP_USER_AGENT", sizeof("HTTP_USER_AGENT"), (void **) &agent_name)==FAILURE) {
+			php_error_docref(NULL TSRMLS_CC, E_WARNING, "HTTP_USER_AGENT variable is not set, cannot determine user agent name");
+			RETURN_FALSE;
+		}
+	}
+
 	convert_to_string_ex(agent_name);
 
+	if (ZEND_NUM_ARGS() == 2) {
+		convert_to_boolean_ex(retarr);
+		return_array = Z_LVAL_PP(retarr);
+	}
+
 	if (zend_hash_find(&browser_hash, Z_STRVAL_PP(agent_name), Z_STRLEN_PP(agent_name)+1, (void **) &agent)==FAILURE) {
 		lookup_browser_name = Z_STRVAL_PP(agent_name);
 		found_browser_entry = NULL;
@@ -255,17 +270,27 @@
 			RETURN_FALSE;
 		}
 	}
-	
-	object_init(return_value);
-	zend_hash_copy(Z_OBJPROP_P(return_value), Z_OBJPROP_PP(agent), (copy_ctor_func_t) zval_add_ref, (void *) &tmp_copy, sizeof(zval *));
-	
-	while (zend_hash_find(Z_OBJPROP_PP(agent), "parent", sizeof("parent"), (void **) &agent_name)==SUCCESS) {
 
+	if (return_array) {
+		array_init(return_value);
+		zend_hash_cop

[PHP-DEV] Fix for bug #22386

[J Smith]

The browscap extension is trying to load stuff into the object_store before
it gets initialized, so this'll fix it. Entries from the browscap.ini file
are now stored in straight hashes rather than objects, but the return value
is still an object. 

Additionally, this patch adds an optional parameter (a bool) that determines
whether the return value should be an object or an array. Object is the
default for BC.

This doesn't seem entirely, 100% BC, as I'm getting results now that are
slightly different from <= 4.3.x. However, the matches seem a bit better
after doing a few tests. For instance, the browser_name_pattern string no
longer escapes peroids and such, and it seems slightly more accurate. (In
older versions, my platform was reported as "unix"; now it's reporting
"linux", which is more precise.)

I figured I had better post the patch for comments before committing since
there is that ever-so-slight difference in browser_name_pattern and the
platform being reported.

Attached is the patch and a couple of tests so you can see the difference.
If there's no objections, I'll commit later on this week. This doesn't
really need to be merged into PHP_4, as it doesn't have the segfault bug.

J

browscap.tar.gz
Description: GNU Zip compressed data
-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: fun with autoconf on Tru64

[J Smith]

I have had similar problems, using autoconf 2.5x seems to work. (I use 2.54,
specifically.)

J


Dave Hill wrote:

> Hi all,
> I am having fun with [EMAIL PROTECTED]@#$ autoconf. In the past I always used
> the configure in the RC tarball without (much) problem. As I am trying
> to be a good little commiter, I am trying to build my potential changes
> out of cvs and am starting with buildconf.
> 
> I have installed:
> gawk-3.1.1
> m4-1.4o
> bison-1.875
> flex-2.5.27
> autoconf-2.13
> automake-1.5
> libtool-1.4.3
> 
> I get warnings/errors during buildconf, and then syntax errors in the
> ./configure after.
> 
> Any suggestions ?
> 
> # ./buildconf
> using default Zend directory
> buildconf: checking installation...
> buildconf: autoconf version 2.13 (ok)
> buildconf: automake version 1.5 (ok)
> buildconf: libtool version 1.4.3 (ok)
> rebuilding configure
> configure.in:564: AC_TRY_COMPILE was called before AC_AIX
> configure.in:564: AC_TRY_RUN was called before AC_AIX
> configure.in:564: AC_TRY_COMPILE was called before AC_AIX
> configure.in:564: AC_TRY_RUN was called before AC_AIX
> autoconf: Undefined macros:
> ***BUG in Autoconf--please report*** AC_ACVERSION
> ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
> ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
> ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
> ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
> ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
> ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
> ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
> ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
> rebuilding acconfig.h
> rebuilding main/php_config.h.in
> configure.in:564: AC_TRY_COMPILE was called before AC_AIX
> configure.in:564: AC_TRY_RUN was called before AC_AIX
> configure.in:564: AC_TRY_COMPILE was called before AC_AIX
> configure.in:564: AC_TRY_RUN was called before AC_AIX


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

Re: [PHP-DEV] Re: modules in c++

[J Smith]

Actually, try this instead of PHP_ADD_LIBRARY(stdc++) and see if that
works...

PHP_ADD_LIBRARY(stdc++, 1, BIAC_SHARED_LIBADD)

J


Michel M. Dos Santos wrote:

> 
> Yes.
> 
> My config.m4:
> 
> 
> PHP_ARG_ENABLE(biac, for biac support,[ --enable-biacEnable biac
> support])
> 
> if test "$PHP_BIAC" != "no" ; then
>  PHP_ADD_LIBRARY(stdc++)
>  PHP_EXTENSION(biac,$ext_shared)
>  PHP_REQUIRE_CXX()
> fi
> 
> Michel M. dos Santos
> 
> 
> 


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

Re: [PHP-DEV] Re: modules in c++

[J Smith]

Looks like you need to link to the standard C++ library. Try putting this in
your config.m4 file:

PHP_ADD_LIBRARY(stdc++)

And run phpize, configure and make again. That should make gcc link with
stdc++. 

J


Michel M. Dos Santos wrote:

> 
> 
> J,
> 
> First, thanks by your article. My original e first problem is :
> 
> PHP Warning:  Unable to load dynamic library
> '/usr/lib/php4/20010901/biac.so' - /usr/lib/php4/20010901/biac.so:
> undefined symbol: endl__FR7ostream in Unknown on line 0
> 
> The use of cout (in this case) result it. I try with std::cout or using
> namespace std but not resolve. Linking with g++ the error dont occur.
> 
> What is wrong ?
> 
> Thanks a lot,
> 
> Michel M. dos Santos
> 
> 
> 


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

[PHP-DEV] Re: modules in c++

[J Smith]

That should still work fine, though, shouldn't it? I mean, the .so spit out
should be working properly. I just tested this with a C++ extension and
while gcc was used by libtool for the linking, the extension works fine.

If you really want the C++ compiler to do the linking, you can open up
libtool file that's generated and edit the line that reads "CC=gcc" to say
"CC=g++". I'm not sure if there's a better way to do this. At least, I
haven't found one yet. If you find something that works a bit better, let
me know and I'll update the article.

J


Michel M. Dos Santos wrote:

> 
> 
> Hi,
> 
> I've been trying use C++ within a PHP extension with help by document in
> http://www.tutorbuddy.com/software/phpcpp/phpcpp/.
> The instructions works fine but I have problems with linking objects. The
> script libtool links objects with gcc and not with g++ and  the moment of
> creation of the dinamic library .so gcc is used and not g++.
> 
> See:
> 
> /bin/sh /root/biac_php/teste/libtool --mode=link gcc  -I.
>  ^^^
> -I/root/biac_php/teste/ -I/root/biac_php/teste/main -I/root/biac_php/teste
> -I/usr/include/php4 -I/usr/include/php4/main -I/usr/include/php4/Zend
> -I/usr/include/php4/TSRM  -DHAVE_CONFIG_H -g -O2   -o teste.la
> -avoid-version
> -module -rpath /root/biac_php/teste/modules   teste.lo
> 
> gcc -shared  teste.lo   -Wl,-soname -Wl,teste.so -o .libs/teste.so
> ^^^
> 
> Thanks,
> 
> Michel M. dos Santos


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

Re: [PHP-DEV] $GLOBALS broken?

[J Smith]

Just noticed register_long_arrays. Turning it on fixes problems with
$_SERVER and $_ENV, but $GLOBALS still acts weird.

J


Shane Caraveo wrote:

> It's a patch to ze2 that was done over the weekend, there is a new ini
> setting that if you turn it on will fix the problem, just cannot
> remember what it was right now...
> Shane
> 
> Sebastian Bergmann wrote:
>>   Notice: Undefined variable: GLOBALS in E:\test.php on line 7
>> 
>> 1 > 2 function foo() {
>> 3   $GLOBALS['foo'] = 'bar';
>> 4 }
>> 5
>> 6 function bar() {
>> 7   echo $GLOBALS['foo'];
>> 8 }
>> 9
>>10 foo();
>>11 bar();
>>12 ?>
>>


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

[PHP-DEV] Re: $GLOBALS broken?

[J Smith]

Using 'global $GLOBALS' works, though. 

On a related note, $GLOBALS and superglobals in general are acting a bit
weird recently. I just cvs updated and rebuilt HEAD and this modified
version of your script shows some oddness:



Output on my machine:

barArray
(
[GLOBALS] => Array
 *RECURSION*
[_POST] => Array
(
)

[_GET] => Array
(
)

[_COOKIE] => Array
(
)

[_FILES] => Array
(
)

[foo] => bar
)

$_SERVER isn't getting into GLOBALS and isn't populated at all. My
variables_order says "GPCS", but doing a var_dump($_SERVER) raises an
E_NOTICE and gives me NULL.

J


Sebastian Bergmann wrote:

>   Notice: Undefined variable: GLOBALS in E:\test.php on line 7
> 
> 1  2 function foo() {
> 3   $GLOBALS['foo'] = 'bar';
> 4 }
> 5
> 6 function bar() {
> 7   echo $GLOBALS['foo'];
> 8 }
> 9
>10 foo();
>11 bar();
>12 ?>
> 


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

[PHP-DEV] Re: Writing a php extension

[J Smith]

www.zend.com/apidoc

J

Mincu Alexandru wrote:

> I want to write a php module an I was wondering where I could find some
> docs about this ..
> 
> tks,


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

Re: Re[2]: [PHP-DEV] Weak references in PHP

[J Smith]

ZE2 == Zend Engine 2, which will be replacing the current Zend Engine in PHP
5. Amoung other things, one of it's main features is a more roboust OOP
framework, which includes class destructors.

J


Konstantin Knizhnik wrote:

> Hello George,
> 
> Friday, February 28, 2003, 5:46:18 PM, you wrote:
> 
>>> Can anybody tell me if such features are available in PHP (I failed to
>>> find
>>> them myself).
> 
> GS> Look at __destruct method for classes in ZE2.  They wopn't tell you
> the GS> reference count, but the do get called when the ref count goes to
> 0.
> 
> 
> Sorry, I am dummy in PHP world:( Can you explain more precisely what
> is ZE2 and where should I look for __destruct method.
> I didn't find any reference to such method neither in PHP manual
> neither in PHP sources i have downloaded.
> 


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

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

[J Smith]

Yep. Yesterday, through the form on the docs page. 

J


Andi Gutmans wrote:

> Have you submitted a CVS account request?
> 
> At 09:41 PM 2/27/2003 +, J Smith wrote:
>>A few weeks ago, I kind of volunteered to maintain testing scripts for ZE2
>>on the ZE2 mailing list. (See the thread beginning at
>>http://www.zend.com/lists/engine2/200302/msg3.html )
>>
>>Just to make good on my volunteering, I guess I'll be needing a CVS
>>account. I suppose I'd need access to php(4|5)/tests. I have a bunch of
>>tests ready to go, and will be adding more as features get added, tweaked,
>>etc. within ZE2.
>>
>>As for experience, I've submitted various patches to the project over the
>>past year or so and written a few extensions that will eventually make it
>>to PECL. I've also offered the use of a Solaris server to the group for
>>debugging Solaris SPARC issues and can do some debugging on it myself if
>>there's a need for it.
>>
>>J, aka darkpanda
>>
>>--
>>PHP Development Mailing List <http://www.php.net/>
>>To unsubscribe, visit: http://www.php.net/unsub.php


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

[PHP-DEV] Re: using VC++ to compile PHP extensions

[J Smith]

To add to that, I wrote up a short article yesterday that pretty much said
the same thing, although it had a more UNIX-y focus. See

http://www.tutorbuddy.com/software/phpcpp/phpcpp/

J


Dave Viner wrote:

> Hi,
> I've just completed some local php extensions using VC++.  Here are some
> notes that might help others when creating php extensions using VC++.
> 



> 
> dave


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

[PHP-DEV] CVS Account Request: jay

[J Smith]

A few weeks ago, I kind of volunteered to maintain testing scripts for ZE2 on the ZE2 
mailing list. (See the thread beginning at 
http://www.zend.com/lists/engine2/200302/msg3.html )

Just to make good on my volunteering, I guess I'll be needing a CVS account. I suppose 
I'd need access to php(4|5)/tests. I have a bunch of tests ready to go, and will be 
adding more as features get added, tweaked, etc. within ZE2.

As for experience, I've submitted various patches to the project over the past year or 
so and written a few extensions that will eventually make it to PECL. I've also 
offered the use of a Solaris server to the group for debugging Solaris SPARC issues 
and can do some debugging on it myself if there's a need for it.

J, aka darkpanda

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

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

[J Smith]

A lesson I learned yesterday after wondering why the hell the thing wouldn't
compile for the past three or four days... php5 works fine, though, like
you say.

J


Magnus N wrote:

> On Tue, 25 Feb 2003 14:45:26 -0500
> J Smith <[EMAIL PROTECTED]> wrote:
> 
>> I get missing
>> symbols like ZEND_INI_PARSER_POP_ENTRY and such, which should be defined
>> in zend_ini.h.) Checking out php5 seemed to correct this.
> 
> That is because php5 is HEAD. I have no idea what php4 is, except
> not-working. So you should checkout php5, not php4.
> 
> / Magnus


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

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

[J Smith]

I think that HEAD is getting slightly screwed up recently, as a couple of
recent cvs updates have got me some code from 4.3.x, or at least it looks
that way. (Specifically, Zend isn't coming down right, and I get missing
symbols like ZEND_INI_PARSER_POP_ENTRY and such, which should be defined in
zend_ini.h.) Checking out php5 seemed to correct this.

J


Sebastian Bergmann wrote:

> Stig Bakken wrote:
>> +#ifdef ZEND_ENGINE_2
> 
>   Why the #ifdef? Isn't HEAD supposed to be PHP 5 / ZE2 only?
> 


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

[PHP-DEV] Re: PHP extensions and C++

[J Smith]

Are you compiling both the PHP extension and the library with the same
compiler and linker settings, i.e. both of them need to have multithreaded
DLL settings, etc. It might also be a case of #including the same file
multiple times and getting the symbols defined multiple times accidently.

There is also an option in the linker to force linking even if there are
symbols defined multiple times. I believe the first found instance of the
symbol will be used and the others ignored. MSFT says this can cause
unexpected results, which is probably true, but I've had to do it a few
times and haven't noticed anything weird happening.

J


Dave Viner wrote:

> Hi,
> I'm trying to write a simple PHP extension that will wrap a C++ class.  I
> have a test C++ program which exercises the class and works properly.  I
> am trying to make the PHP extension code work, but I keep running into
> this error in VC++:
> 
> DataStore.lib(FileSystemDataStore.obj) : error LNK2005: "void __cdecl
> operator delete(void *,void *)" (??3@YAXPAX0@Z) already defined in
> DataStore.obj
> 
> This occurs only if I instantiate an object of my class (named
> FileSystemDataStore).
> #if 1
> FileSystemDataStore *fsds = new FileSystemDataStore(fs_args);
> #endif
> Including this code causes the linkage error, and #if 0 this block will
> compile and link fine.  I suspect the php glue code since my C++ test
> program compiles and links fine against the same .lib.
> 
> Has anyone seen this error or have a suggestion for how to fix it?
> 
> Thanks
> dave
> 
> P.S - I'm not sure if this is the correct list to post this question on,
> so please let me know if I should repost it elsewhere.


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

Re: [PHP-DEV] Re: Configure-System on Solaris

[J Smith]

Jani Taskinen wrote:

> On Tue, 4 Feb 2003, J Smith wrote:
> 
> /usr/xpg4/bin/sed
> 
> It should be part of standard install too..
> 
> --Jani

I hate Solaris. There's four seds on my system now: /usr/local/bin/sed,
/usr/bin/sed, /usr/ucb/sed and /bin/sed.

Yeah, xpg4 sed seems to work fine. xpg4 grep is working, too, which takes
care of that -E problem.

So, after some testing, the bottom line seems to be...

/usr/local/bin/sed (GNU): works
/usr/xpg4/bin (Sun POSIX stuff): works
/usr/ucb (SunOS BSD-compatible): dies
/bin/sed (Solaris): dies

J

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

Re: [PHP-DEV] Re: Configure-System on Solaris

[J Smith]

Jani Taskinen wrote:

> 
> There should be another version of 'sed' in Solaris which can handle
> the long lines though. No idea why they have 2 versions.
> 
> --Jani

Never knew that. Is that part of a standard install, or is it bundled in
some kind of patch, or does it have a different name or something? 

J

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

Re: [PHP-DEV] Re: Configure-System on Solaris

[J Smith]

Zeev Suraski wrote:

> I don't think we can rely on GNU grep being installed though...
> 

Well, we pretty much need to rely on GNU sed being installed on Solaris, so
why not grep, too? The sed problem comes up when doing the final linking
when building. You usually end up with a collosal libtool line, which makes
Sun's sed explode, as it can only handle about 4000 characters. (You'll end
up with sed reporting that the "output line [is] too long".

I haven't fully investigated what Sun tools will bork a build, but Sun's sed
definitely does, and probably a majority of the time. 

J

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

[PHP-DEV] Re: Configure-System on Solaris

[J Smith]

GNU grep should work. Just make sure /usr/local/bin comes before /bin in
your $PATH.

J


Sebastian Nohn wrote:

> Latest CVS (PHP5-dev) on Solaris:
> 
> Configuring TSRM
> checking for stdarg.h... (cached) yes
> grep: illegal option -- E
> Usage: grep -hblcnsviw pattern file . . .
> 
> Regards, Sebastian Nohn


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

[PHP-DEV] Re: Can't build xslt/sablot

[J Smith]

What's doing the linking? Is it linking to lstdc++?

J


Sebastian Bergmann wrote:

> /usr/local/lib/libsablot.so: undefined reference to `operator
> new[](unsigned)' /usr/local/lib/libsablot.so: undefined reference to
> `vtable for __cxxabiv1::__si_class_type_info'
> /usr/local/lib/libsablot.so: undefined reference to `operator
> delete(void*)' /usr/local/lib/libsablot.so: undefined reference to
> `__gxx_personality_v0' /usr/local/lib/libsablot.so: undefined reference to
> `__cxa_pure_virtual' /usr/local/lib/libsablot.so: undefined reference to
> `vtable for __cxxabiv1::__class_type_info'
> /usr/local/lib/libsablot.so: undefined reference to `operator
> delete[](void*)' /usr/local/lib/libsablot.so: undefined reference to
> `vtable for __cxxabiv1::__vmi_class_type_info'
> /usr/local/lib/libsablot.so: undefined reference to `operator
> new(unsigned)' collect2: ld returned 1 exit status
> make: *** [sapi/cgi/php] Error 1
> 


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

[PHP-DEV] Re: Mandatory File Locking in PHP?

[J Smith]

Try the direct I/O extension, specifically dio_fcntl(). Just make sure the
filesystem you're using the locks on was mounted with "-o mand", and the
locks will be mandatory by default.

J


Ananth Kesari wrote:

> Hi,
> 
> From the PHP manual I find that the flock() function does a advisory
> file locking. Is there a way to do mandatory file locking where we do
> strict locking? That is once a file is locked, no other process or
> thread is allowed to edit the file untill the lock owner is done with
> his job and he has removed the lock.
> 
> Thanks,
> Ananth.


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

[PHP-DEV] Re: [Fwd: 4.3.0 w/ Sablotron version check problem]

[J Smith]

Just saw this in the weekly php.dev summary on Zend.com.

Sablotron is working fine for me.

>From phpinfo():

XSLT - support enabled 
Backend - Sablotron 
Sablotron Version - 0.97 
Sablotron Information - Cflags: -g -O2 Libs: -L/usr/local/lib -lexpat 
Prefix: /usr/local

Details: 

linux (kernel 2.4.19)
Apache 1.3.27
expat 1.95.4
Sablotron 0.97
GCC 3.2.1
PHP 4.3.0
Configure line:  './configure' '--with-apache=../../apache/apache_1.3.27/' 
'--with-pgsql' '--with-regex=php' '--enable-sockets' '--without-mysql' 
'--disable-debug' '--enable-xslt' '--with-xslt-sablot' '--disable-cli' 
'--with-gd' '--with-zlib' '--with-freetype-dir'

This machine is a gentoo linux box, but I also have a RH linux 7.3 box 
running with nearly identical software, the only major difference being 
gcc. Apache, Sablotron and PHP were all compiled from source on both 
machines. The configure line for the RH box is...

 './configure' '--with-apache=../../apache/apache_1.3.27' '--with-pgsql' 
'--with-regex=php' '--enable-sockets' '--enable-porter' '--enable-stem' 
'--without-pear' '--without-mysql' '--disable-debug' '--enable-xslt' 
'--with-xslt-sablot' '--with-iconv' '--with-gd' '--with-jpeg-dir=/usr' 
'--with-png-dir=/usr' '--with-zlib-dir=/usr' '--with-freetype-dir=/usr' 
'--disable-cli' '--with-cryptopp'

--with-cryptopp, --enable-stem and --enable-porter are home-grown extensions 
that shouldn't affect Sablotron.

I had no problems with the configure script on either machine. I ran 
buildconf before configuring, so the configure script as shipped in the 
tarball might be the problem. I can check if need be.

J


Sterling Hughes wrote:

> -Forwarded Message-
> 
>> From: Lars Consume <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]
>> Cc: Luke Murphy <[EMAIL PROTECTED]>
>> Subject: 4.3.0 w/ Sablotron version check problem
>> Date: 08 Jan 2003 15:23:07 -0500
>> 
>> Dear Mr. Hughes,
>> 
>> Since 4.3.0 is a recent release, and because I haven't been able to
>> find any similar information on the Web or in any of the large PHP
>> forums, I am writing to you to notify you of a problem I'm having when
>> running the ./configure command against php 4.3.0 with the Sablotron
>> extensions. Namely, the configure script reports that I need Sablotron
>> v 0.96 or higher, when in fact I have just installed Sablotron v 0.97.
>> I have run ldconfig, and have checked the sablot-config file to make
>> sure there isn't a typo in there--sure enough it says "0.97". I'm
>> wondering if there's a bug in the configure information or in one of
>> the checks.
>> 
>> Here's my command line:
>> ./configure --with-apxs=/usr/local/apache/bin/apxs --prefix=/usr/local
>> --disable-short-tags --with-config-file-path=/etc
>> --with-calendar=shared --with-curl=/usr/local --enable-exif
>> --enable-ftp --with-gd --with-jpeg-dir=/usr/local --enable-magic-quotes
>> --with-mcrypt=/usr/local --with-mhash=/usr/local --with-ming=/usr/local
>> --with-mysql --with-openssl --with-pear --with-pgsql
>> --with-png-dir=/usr/local --enable-sockets --with-t1lib=/usr/local
>> --enable-track-vars --enable-trans-sid --with-ttf --enable-wddx
>> --with-xml --enable-xslt --with-xslt-sablot --with_sablot_js
>> --with-zlib --with-zlib-dir=/usr/local
>> 
>> And here's my error output during config:
>> checking for XSLT Sablotron backend... yes
>> checking for libexpat dir for Sablotron XSL support... yes
>> checking for iconv dir for Sablotron XSL support... yes
>> checking for JavaScript for Sablotron XSL support... yes
>> checking for Sablotron libraries in the default path... found in
>> /usr/local
>> checking for sablot-config... found
>> checking for Sablotron version... configure: error: Sablotron version
>> 0.96 or greater required.
>> 
>> The Machine is Red Hat Linux v 2.4.7-10
>> 
>> Please feel free to forward this e-mail to anyone who might be a more
>> appropriate recipient.
>> 
>> Thank you for your time.
>> 
>> Kristofer Widholm


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

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

[J Smith]

You can still use constructors that have the same name as the class, at 
least for the time being. Just tested it with 4.4.0-dev HEAD and ZE2. If 
you have both a method with the same name as the class and a method called 
__construct(), the method with the class name will be used as the 
constructor and __construct() won't be used at all.

J


Brian Moon wrote:

> From what I understand, all OO code will have to be modified for PHP5.
> Constructors for example and no longer named the same as the class name.
> That alone means every class must be changed.  I don't recall anyone
> saying it would be BC either, but I could be wrong.
> 
> Brian Moon
> -
> dealnews.com
> -
> phorum.org
> 


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

[PHP-DEV] Re: encryption functions

[J Smith]

Not to plug my own wares or anything, but you might want to look at 
cryptopp-php, which works on both UNIX and Windows. See

http://www.tutorbuddy.com/software/

It works fine on both platforms and is compatible both ways -- ciphertext 
created on one platform can be decrypted on another and vice versa et 
cetera ad nauseum.

It's a somewhat bulky extension, but you can pare it down by disabling the 
cipher algorithms and only use the ones you need. DES, SKIPJACK, Blowfish, 
they're all supported. 30 or so block cipher and stream cipher algorithms 
are supported, so there should be something there that's suitable. 

The current version, 0.0.10 is somewhat unstable as it hasn't gone through 
much testing. Version 0.0.8 is pretty stable. A new version, 0.0.11, might 
get out before New Year's that has a couple of new functions to control 
your source of random number generation (like choosing between a blocking 
and non-blocking RNG on UNIX). It's pretty much done now, I just need to 
get some time to test it on Windows.

Might be worth looking at to see if it suits your needs. I haven't submitted 
it to PECL and probably won't for the forseeable future. Again, it works on 
both UNIX and Windows, so it might be what you're looking for.

J


Michael Bretterklieber wrote:

> Hi,
> 
> I'm trying to provide samples for authenticating using MS-CHAP and my
> Radius PECL.
> 
> I need DES for generating the data., but it seems that des is only
> available via mcrypt-extension, but mcrypt only compiles under unix or
> am i wrong?
> 
> Its nearly useless to provide a sample for MS-CHAP only for unix,
> because MS-CHAP is often used with Windoze.
> 
> What should I do? I can add DES to my radius-PECL, but isn't it better
> to have an extension wich provides basic encryption functions for
> windows AND unix?
> 
> any suggestions?
> 
> bye,


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

Re: [PHP-DEV] [PATCH] New changes to ext_skel for C++

[J Smith]

As others have pointed out, it is, but I think it would be better to simply 
have the code there in the generated C++ source and not at all in the C 
source. It would lead to less confusion imho.

I guess it should kind of be assumed that if someone is going the distance 
to actually create an extension to PHP, they're probably going to know what 
__cplusplus, extern "C" and all that stuff means, but on the other hand, 
I've seen (and received) some pretty ridiculous questions on that sort of 
stuff dealing with PHP extensions directly.

J


Stig S. Bakken wrote:

> Isn't __cplusplus defined for all C++ compilers?
> 
> #ifdef __cplusplus
> extern "C" {
> #endif
> 
> #ifdef __cplusplus
> }
> #endif
> 
> This is pretty common in library header files at least.
> 
>  - Stig
> 


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

Re: [PHP-DEV] [PATCH] New changes to ext_skel for C++

[J Smith]

I seem to remember having problems the last time I tried that. With gcc, you 
get relocation errors, missing symbols, all sorts of craziness. (I just 
checked with an extension compiled as a shared objected -- without extern 
c-ing php.h, I got an undefined symbol on zend_register_list_destructors.) 

On Windows, I'm not even sure if VC++ would compile, but it's been a while 
since I checked. I'm pretty sure it had kittens over the non-extern-c-ed 
stuff.

Fixing the API functions in php.h would definitely be the way to go, but I 
wasn't sure if I should go there, as I haven't had any problems yet with 
wrapping the whole thing up in extern C's. 

J


Zeev Suraski wrote:

> Why do we need an extern c before php.h?  The relevant API functions in
> php.h should be extern "c"d in my opinion, wrapping php.h up in extern "c"
> is not very clean.
> 
> Zeev
> 


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

Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++

[J Smith]

Or it could just not be there at all? 

What the big deal here? It's four extra lines in ext_skel to get rid of it. 

Besides, you can comment the hell out of it, write six pages of 
documentation surrounded in /* */ if you want, you know there will be 
people asking why there's C++ code in their C code. If my vision of the 
future is in any way accurate, at least, which it may very well not be.

J


George Schlossnagle wrote:

> J Smith wrote:
> 
>>That's what I was thinking. The new patch updates skeleton.c a bit and
>>fixes ext_skel to either add extern "C" stuff to skeleton.c or get rid of
>>it. I think it would be simpler for extension first-timers to not worry
>>about what __cplusplus means, or why extern "C" is there in the first
>>place, etc.
>>
> 
> It could always be (horror of horrors) comemented in the code.
> 


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

Re: [PHP-DEV] [PATCH] New changes to ext_skel for C++

[J Smith]

For the second instance where extern "C" is used, that would be possible, 
but in the first instance, BEGIN/END_EXTERN_C() aren't defined yet, as 
they're in zend.h. The compiler would totally barf.

I had used BEGIN/END_EXTERN_C() in the first patch I sent out, but decided 
to use one or the other in this one for the sake of consistency.

J


Zeev Suraski wrote:

> Why not just use BEGIN_EXTERN_C() and END_EXTERN_C()?
> 
> Zeev
> 


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

[PHP-DEV] [PATCH] New changes to ext_skel for C++

[J Smith]

Taking a few comments into consideration, here's a new patch for adding C++ 
code-generating abilities to ext_skel. The new patch doesn't use a separate 
skeleton.cpp file. Instead, it adds some lines like 

/* __begin_extern_c__ */
/* __end_extern_c__ */

to skeleton.c and lets ext_skel either replace them with the proper C++ 
stuff or get rid of it altogether. I didn't want to make the extname.c 
output any more complicated with #ifdef __cplusplus preprocessor nonsense, 
'cause having extension first-timers asking why there's C++ stuff in their 
C file would suck.

Another slight change to skeleton.c just gets rid of the string named 
"string" and replaces it with "str". This is just to get rid of any 
conflict that might come up if someone #includes the C++ string library in 
their extension, so they don't need to worry about C-string named "string" 
being confused with the C++ data type "string".

Comments?

J


Index: ext_skel
===
RCS file: /repository/php4/ext/ext_skel,v
retrieving revision 1.44
diff -u -3 -p -r1.44 ext_skel
--- ext_skel	18 Nov 2002 15:55:07 -	1.44
+++ ext_skel	2 Dec 2002 15:08:10 -
@@ -7,7 +7,7 @@ givup() {
 
 usage() {
 echo "$0 --extname=module [--proto=file] [--stubs=file] [--xml[=file]]"
-echo "   [--skel=dir] [--full-xml] [--no-help]"
+echo "   [--skel=dir] [--full-xml] [--no-help] [--cpp]"
 echo ""
 echo "  --extname=module   module is the name of your extension"
 echo "  --proto=file   file contains prototypes of functions to create"
@@ -18,6 +18,7 @@ echo "  --full-xml generate xml 
 echo " (not yet implemented)"
 echo "  --no-help  don't try to be nice and create comments in the code"
 echo " and helper functions to test if the module compiled"
+echo "  --cpp  create a C++ extension"
 exit 1
 }
 
@@ -58,6 +59,9 @@ while test $# -gt 0; do
 --skel=?*)
 	skel_dir=$optarg
 	;;
+--cpp)
+cpp="yes"
+;;
 *)
 	usage
 	;;
@@ -94,7 +98,7 @@ if test -z "$stubs"; then
 fi
 
 if test -n "$proto"; then
-  cat $proto | awk -v extname=$extname -v stubs=$stubs -v stubfile=$stubfile -v xml=$xml -v full_xml=$full_xml -v i_know_what_to_do_shut_up_i_dont_need_your_help_mode=$no_help -f $skel_dir/create_stubs
+  cat $proto | awk -v extname=$extname -v stubs=$stubs -v stubfile=$stubfile -v xml=$xml -v full_xml=$full_xml -v i_know_what_to_do_shut_up_i_dont_need_your_help_mode=$no_help -v cpp=$cpp -f $skel_dir/create_stubs
 fi
 
 if test -z "$stubs"; then
@@ -165,11 +169,16 @@ if test "\$PHP_$EXTNAME" != "no"; then
   dnl ])
   dnl
   dnl PHP_SUBST(${EXTNAME}_SHARED_LIBADD)
+eof
 
-  PHP_NEW_EXTENSION($extname, $extname.c, \$ext_shared)
+if test "$cpp" = "yes"; then
+  echo "  PHP_REQUIRE_CXX()" >>config.m4
+  echo "  PHP_NEW_EXTENSION($extname, $extname.cpp, \$ext_shared)" >>config.m4
+else
+  echo "  PHP_NEW_EXTENSION($extname, $extname.c, \$ext_shared)" >>config.m4
 fi
-eof
 
+echo "fi" >>config.m4
 
 $ECHO_N " .cvsignore$ECHO_C"
 cat >.cvsignore <.cvsignore < sedscript
 echo "s/EXTNAME/$EXTNAME/g"  >> sedscript
+
+if test "$cpp" = "yes"; then
+echo "s/\/\* __begin_extern_c__ \*\//extern \"C\" {/" >> sedscript
+echo "s/\/\* __end_extern_c__ \*\//}/" >> sedscript 
+else
+echo "s/\/\* __begin_extern_c__ \*\///" >> sedscript
+echo "s/\/\* __end_extern_c__ \*\///" >> sedscript
+fi
+
 echo '/__function_entries_here__/r function_entries'  >> sedscript
 echo '/__function_stubs_here__/r function_stubs'  >> sedscript
 echo '/__header_here__/r ../../header'  >> sedscript
@@ -189,6 +211,7 @@ echo '/__function_entries_here__/D'  >> 
 echo '/__function_stubs_here__/D'  >> sedscript
 echo '/__header_here__/D'  >> sedscript
 echo '/__footer_here__/D'  >> sedscript
+
 if [ ! -z "$no_help" ]; then
 echo "/confirm_$extname_compiled/D" >> sedscript
 echo '/Remove the following/,/^\*\//D' >> sedscript
@@ -197,7 +220,11 @@ if [ ! -z "$no_help" ]; then
 echo '/^[[:space:]]*\/\*/,/^[[:space:]]*\*\//D' >> sedscript
 fi
 
-sed -f sedscript < $skel_dir/skeleton.c > $extname.c
+if test "$cpp" = "yes"; then
+sed -f sedscript < $skel_dir/skeleton.c > $extname.cpp
+else
+sed -f sedscript < $skel_dir/skeleton.c > $extname.c
+fi
 
 
 $ECHO_N " php_$extname.h$ECHO_C"
@@ -273,7 +300,15 @@ To use your new extension, you will have
 4.  $ ./configure --[with|enable]-$extname
 5.  $ make
 6.  $ ./php -f ext/$extname/$extname.php
-7.  $ vi ext/$extname/$extname.c
+eof
+
+  if test "$cpp" = "yes"; then
+  echo "7.  $ vi ext/$extname/$extname.cpp"
+  else
+  echo "7.  $ vi ext/$extname/$extname.c"
+  fi
+
+  cat <
-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++

[J Smith]

That's what I was thinking. The new patch updates skeleton.c a bit and fixes 
ext_skel to either add extern "C" stuff to skeleton.c or get rid of it. I 
think it would be simpler for extension first-timers to not worry about 
what __cplusplus means, or why extern "C" is there in the first place, etc. 

J


Sterling Hughes wrote:

>> Is there any reason the ifdef __cplusplus doesn't work?  There shouldn't
>> be any need for extra processing or config options.
>>
> 
> well, i think c++ code might confuse people just starting out writing a C
> extension...
> 
> -Sterling
> 


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

Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++

[J Smith]

How about adding something like this to skeleton.c:

/* __begin_extern_c__ */
/* __end_extern_c__ */

And having the sed script in ext_skel replace them with the proper extern 
"C" stuff? That way there's no need for skeleton.cpp and just a few changes 
need to be made in skeleton.c.

J


Sascha Schumann wrote:

> On Fri, 29 Nov 2002, J Smith wrote:
> 
>>
>> Attached is a patch to ext_skel that adds an optional argument (--cpp)
>> that will create a PHP extension in C++ rather than C. Also attached is
>> skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few
>> modifications for using C++. I could've just made some changes to
>> skeleton.c and done some sed work in the ext_skel script, but I think
>> it's clearer to have them separated into two files.
> 
> I'm reluctant to duplicate the contents of the .c file for
> maintenance reason.  Cannot you just put the C++ specific
> code into a
> 
> /* Remove this part, if this is not a C++ extension */
> #ifdef __cplusplus
> 
> #endif
> 
> section?
> 
> - Sascha


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

Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++

[J Smith]

Is this a problem with VS.net or something? I've never done that with any of 
my C++ extensions and they've all worked fine on VC++ 6.

If it is a problem, though, I'll make the changes.

J

Shane Caraveo wrote:

> J Smith wrote:
>> Attached is a patch to ext_skel that adds an optional argument (--cpp)
>> that will create a PHP extension in C++ rather than C. Also attached is
>> skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few
>> modifications for using C++. I could've just made some changes to
>> skeleton.c and done some sed work in the ext_skel script, but I think
>> it's clearer to have them separated into two files.
>> 
>> The ext_skel patch is based on the current HEAD.
>> 
>> Comments?
>> 
>> J
> 
> skeleton.h also needs to be dealt with.  If you do not, visual studio
> will export symbols as c++ symbols and the extension will not work.
> Simple solution is to have
> 
> #ifdef __cplusplus
> extern "C" {
> #endif
> 
> at the top of skeleton.h, and close it at the bottom.
> 
> Shane


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

[PHP-DEV] [PATCH] Changes to ext_skel for C++

[J Smith]

Attached is a patch to ext_skel that adds an optional argument (--cpp) that 
will create a PHP extension in C++ rather than C. Also attached is 
skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few 
modifications for using C++. I could've just made some changes to 
skeleton.c and done some sed work in the ext_skel script, but I think it's 
clearer to have them separated into two files. 

The ext_skel patch is based on the current HEAD.

Comments?

J
Index: ext_skel
===
RCS file: /repository/php4/ext/ext_skel,v
retrieving revision 1.44
diff -u -3 -p -r1.44 ext_skel
--- ext_skel	18 Nov 2002 15:55:07 -	1.44
+++ ext_skel	29 Nov 2002 18:20:40 -
@@ -7,7 +7,7 @@ givup() {
 
 usage() {
 echo "$0 --extname=module [--proto=file] [--stubs=file] [--xml[=file]]"
-echo "   [--skel=dir] [--full-xml] [--no-help]"
+echo "   [--skel=dir] [--full-xml] [--no-help] [--cpp]"
 echo ""
 echo "  --extname=module   module is the name of your extension"
 echo "  --proto=file   file contains prototypes of functions to create"
@@ -18,6 +18,7 @@ echo "  --full-xml generate xml 
 echo " (not yet implemented)"
 echo "  --no-help  don't try to be nice and create comments in the code"
 echo " and helper functions to test if the module compiled"
+echo "  --cpp  create a C++ extension"
 exit 1
 }
 
@@ -58,6 +59,9 @@ while test $# -gt 0; do
 --skel=?*)
 	skel_dir=$optarg
 	;;
+--cpp)
+cpp="yes"
+;;
 *)
 	usage
 	;;
@@ -94,7 +98,7 @@ if test -z "$stubs"; then
 fi
 
 if test -n "$proto"; then
-  cat $proto | awk -v extname=$extname -v stubs=$stubs -v stubfile=$stubfile -v xml=$xml -v full_xml=$full_xml -v i_know_what_to_do_shut_up_i_dont_need_your_help_mode=$no_help -f $skel_dir/create_stubs
+  cat $proto | awk -v extname=$extname -v stubs=$stubs -v stubfile=$stubfile -v xml=$xml -v full_xml=$full_xml -v i_know_what_to_do_shut_up_i_dont_need_your_help_mode=$no_help -v cpp=$cpp -f $skel_dir/create_stubs
 fi
 
 if test -z "$stubs"; then
@@ -165,11 +169,16 @@ if test "\$PHP_$EXTNAME" != "no"; then
   dnl ])
   dnl
   dnl PHP_SUBST(${EXTNAME}_SHARED_LIBADD)
+eof
 
-  PHP_NEW_EXTENSION($extname, $extname.c, \$ext_shared)
+if test "$cpp" = "yes"; then
+  echo "  PHP_REQUIRE_CXX()" >>config.m4
+  echo "  PHP_NEW_EXTENSION($extname, $extname.cpp, \$ext_shared)" >>config.m4
+else
+  echo "  PHP_NEW_EXTENSION($extname, $extname.c, \$ext_shared)" >>config.m4
 fi
-eof
 
+echo "fi" >>config.m4
 
 $ECHO_N " .cvsignore$ECHO_C"
 cat >.cvsignore <.cvsignore < sedscript
 echo "s/EXTNAME/$EXTNAME/g"  >> sedscript
 echo '/__function_entries_here__/r function_entries'  >> sedscript
@@ -189,6 +202,7 @@ echo '/__function_entries_here__/D'  >> 
 echo '/__function_stubs_here__/D'  >> sedscript
 echo '/__header_here__/D'  >> sedscript
 echo '/__footer_here__/D'  >> sedscript
+
 if [ ! -z "$no_help" ]; then
 echo "/confirm_$extname_compiled/D" >> sedscript
 echo '/Remove the following/,/^\*\//D' >> sedscript
@@ -197,7 +211,11 @@ if [ ! -z "$no_help" ]; then
 echo '/^[[:space:]]*\/\*/,/^[[:space:]]*\*\//D' >> sedscript
 fi
 
-sed -f sedscript < $skel_dir/skeleton.c > $extname.c
+if test "$cpp" = "yes"; then
+sed -f sedscript < $skel_dir/skeleton.cpp > $extname.cpp
+else
+sed -f sedscript < $skel_dir/skeleton.c > $extname.c
+fi
 
 
 $ECHO_N " php_$extname.h$ECHO_C"
@@ -273,7 +291,15 @@ To use your new extension, you will have
 4.  $ ./configure --[with|enable]-$extname
 5.  $ make
 6.  $ ./php -f ext/$extname/$extname.php
-7.  $ vi ext/$extname/$extname.c
+eof
+
+  if test "$cpp" = "yes"; then
+  echo "7.  $ vi ext/$extname/$extname.cpp"
+  else
+  echo "7.  $ vi ext/$extname/$extname.c"
+  fi
+
+  cat <
/* __header_here__ */

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

extern "C" {
#include "php.h"
#include "php_ini.h"
#include "ext/standard/info.h"
}

#include "php_extname.h"

// C++ header...

#include 

using namespace std;

/* If you declare any globals in php_extname.h uncomment this:
ZEND_DECLARE_MODULE_GLOBALS(extname)
*/

/* True global resources - no need for thread safety here */
static int le_extname;

/* {{{ extname_functions[]
 *
 * Every user visible function must have an entry in extname_functions[].
 */
function_entry extname_functions[] = {
	PHP_FE(confirm_extname_compiled,	NULL)		/* For testing, remove later. */
	/* __function_entries_here__ */
	{NULL, NULL, NULL}	/* Must be the last line in extname_functions[] */
};
/* }}} */

/* {{{ extname_module_entry
 */
zend_module_entry extname_module_entry = {
#if ZEND_MODULE_API_NO >= 20010901
	STANDARD_MODULE_HEADER,
#endif
	"extname",
	extname_functions,
	PHP_MINIT(extname),
	PHP_MSHUTDOWN(extname),
	PHP_RINIT(extname),		/* Replace with NULL if there's nothing to do at request start */
	PHP_RSHUTDOWN(extname),	/* Replace with NULL if there's nothing to do at request end */
	PHP_MI

Re: [PHP-DEV] C++ extensions and ext_skel

[J Smith]

The only modified file is ext_skel. There's also the addition of a file in 
ext/skeleton -- skeleton.cpp to go along with skeleton.c. I suppose I could 
get rid of the .cpp file, make a few changes to skeleton.c and have 
ext_skel make the proper modifications when it's replacing "extname", 
"EXTNAME" and whatnot. The changes to config.m4 and Makefile.in are done in 
ext_skel.

J


Sascha Schumann wrote:

> On Thu, 28 Nov 2002, J Smith wrote:
> 
>>
>> A couple of times a month, I get questions about from people looking to
>> use C++ with PHP. Apparently, a lot of people end up reading some post I
>> made to php.dev or something a year or so ago about C++, and although it
>> worked at the time, the procedure I describe has become stale.
>>
>> I messed around a bit with ext_skel and ext/skeleton today and added an
>> option to ext_skel (--cpp) that creates a basic C++ extension rather than
>> the standard C extension. The C++ extension is pretty much the same as
>> the standard C extension, with the exception of some extern "C" linkage,
>> modifications to config.m4 and Makefile.in and a small C++ class thrown
>> in for fun.
> 
> Cannot those be unified?
> 
> - Sascha

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

[PHP-DEV] test

[J Smith]

test, please ignore

J

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

RE: [PHP-DEV] C++ extensions and ext_skel

[J Smith]

The door has always been open, as it has always been possible. For instance, 
the qtdom extension has some C++ components, as does the dotnet extension. 
This just sort of facilitates the, uh, moving through said door. 

If you're using ANSI/ISO-compliant (or mostly compliant) C and C++ 
compilers, like the gcc suite or MSVC++, there shouldn't be any problems. 
(Famous last words, I know.) 

I get at least two emails a week about this sort of thing, so clearly there 
is interest. It seems that everyone who emails me is looking to do it on 
either a personal basis or for some proprietary extension, so it's not like 
PHP itself would suddenly become "polluted" with C++.

J



John Coggeshall wrote:

> 
> AFAIK, PHP is designed to function on any standard ANSI-compatible C
> compiler (as a goal). Unless this has changed, I don't know if opening
> the door for C++ development is the best of ideas (IMHO)
> 
> John
> 
> 


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

[PHP-DEV] C++ extensions and ext_skel

[J Smith]

A couple of times a month, I get questions about from people looking to use 
C++ with PHP. Apparently, a lot of people end up reading some post I made 
to php.dev or something a year or so ago about C++, and although it worked 
at the time, the procedure I describe has become stale.

I messed around a bit with ext_skel and ext/skeleton today and added an 
option to ext_skel (--cpp) that creates a basic C++ extension rather than 
the standard C extension. The C++ extension is pretty much the same as the 
standard C extension, with the exception of some extern "C" linkage, 
modifications to config.m4 and Makefile.in and a small C++ class thrown in 
for fun.

Would this be worth adding to PHP proper? I have patches available for 
4.2.3, but if it's worthy, I can whip it up for 4.3 or whatever. It'll save 
me some email bandwidth if it could be used.

J

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

[PHP-DEV] PHP crypto extension news

[J Smith]

Since I just finished a pretty major source overhaul of the cryptopp-php 
extension, I figured I should make a little announcement, as this is 
oh-so-exciting news.

Recently, Wei Dai released Crypto++ 5.0, which was pretty much a complete 
re-write of the public domain Crypto++ cryptography suite. In turn, I 
updated the cryptopp-php extension, hopefully for the better.

The changes to this version, 0.0.9, are numerous, but the highlights are...

- new padding schemes on block ciphers. In previous versions of 
cryptopp-php, you didn't get to choose your padding scheme -- you were 
stuck with whatever the default was for the block cipher mode. Now you can 
pick from PKCS#5, zeroes, one and zeroes or no padding at all. New 
functions to control this new ability were added: cryptopp_set_padding(), 
cryptopp_get_padding() and cryptopp_get_padding_name().

- keyed hash message authentication code algorithms were added. Basically, a 
HMAC is just a hash that uses a secret key. New HMAC algorithms include 
MD5-HMAC, RIPEMD-160-HMAC, etc. New functions to set HMAC keys were thusly 
added: cryptopp_set_hmac_key(), *get_hmac_key(), *set_hmac_key_length() and 
*get_hmac_key_length().

- a modified ARC4 algorithm was added.

- the MD4 hash algorithm was added, although it should only be used when you 
really, really need it, such as for compatbility with other programs, as it 
is known to be cryptographically weak.

- changes in the Crypto++ library itself have forced me to remove the 
Sapphire stream cipher and hash algorithms, but since I doubt they were 
used much, that shouldn't be much of a problem.

- everything is for the most part backwardly and forwardly compatible with 
previous versions of cryptopp-php, with exceptions being noted in the 
manual. The only real differences you need to worry about are the block 
cipher padding schemes you're using and the SKIPJACK changes and SAFER-* 
changes.

As always, cryptopp-php works on most UNIX-like systems as well as Microsoft 
Windows systems, and has been tested with Linux (kernel 2.4.18 and 2.4.9), 
Solaris 8 (SPARC) and Windows 2000 Professional. Source code and Windows 
DLLs are available under a BSD-like license at

http://www.tutorbuddy.com/software/

This version should be considered somewhat unstable, so if you're worried 
about that, use version 0.0.8. There are a few known bugs in Crypto++ 5.0 
that have been fixed in CVS -- they shouldn't affect cryptopp-php in any 
way, but there may be bugs in my code that haven't been weeded out yet, as 
this version hasn't been tested and is a near-total re-write from 0.0.8.

Any bugs reports or comments would be appreciated.

J

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

[PHP-DEV] Re: ADVANCED PHP (SOCKETS) MULTIPLEXING SERVER

[J Smith]

Questions like this should be posted to php.general, not php.dev -- php.dev 
is for developing PHP itself; php.general is for developing WITH PHP.

That aside, attached is a simple example of setting up a multiplexer with 
socket_select(). The example creates a [very] small chat server -- just
start up the server and try connecting with telnet to localhost on port 
1 with a couple of terminals. You should be able to send messages from 
terminal to terminal.

Note that the example doesn't do a lot of error checking, and is pretty 
hacked together and not too pretty. But it's a decent example.

J



Gustavo Almeida wrote:

> Dear php-dev,
> 
>  Hi, I'm here again with another doubt. Now, I know that I have to
>  use  socket_select() before the socket_accept(), but what I can't
>  understand  is  how to "store" or handle many clients yet, my app
>  has  a  lot  of  socket_write()  and socket_read() functions, and
>  intaction  with  DB  (Postgres),  I  guess am I a little confuse,
>  anybody help?
> 






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

[PHP-DEV] Re: [PHP] mcrypt

[J Smith]

If all you need is some generic encryption that doesn't require mcrypt, you 
might want to take a look at a crypto extension I wrote called 
cryptopp-php. It does everything that the mcrypt extension does and might 
be a touch easier to use as far as syntax and such goes. (Plus, it works on 
Windows if you're into that sort of thing.) It's fairly stable at the 
moment, and doesn't have the memory allocation problems.

See http://www.tutorbuddy.com/software/, and 
http://www.tutorbuddy.com/software/cryptopp/ for the manual.

(I hate the shameless plugging, but the more people who use my extension the 
easier it is for me to debug...)

J


Purushotham Komaravolu wrote:

> Hi,
>  Thanks for the prompt answer. But I am still getting the same error.
> 
> /
> original: meet at secret place
> encrypted: d40d72f1b224b9bf86a7dbc52402c1d02a5cf90adb9050f0
> 
> Warning: mcrypt_generic_init: Memory allocation error in
> 
/mount/marsellus/gwolfe/puruclient/staging/vhosts/partnersdev.sec.yaga.com/h
> tml/time/cancelsubscription/new.php on line 29
> 
> Warning: mdecrypt_generic(): 2 is not a valid MCrypt resource in
> 
/mount/marsellus/gwolfe/puruclient/staging/vhosts/partnersdev.sec.yaga.com/h
> tml/time/cancelsubscription/new.php on line 30
> 
> Warning: mcrypt_generic_end(): 2 is not a valid MCrypt resource in
> 
/mount/marsellus/gwolfe/puruclient/staging/vhosts/partnersdev.sec.yaga.com/h
> tml/time/cancelsubscription/new.php on line 31
> decrypted:
> 
> 
> ///
> 
> 
> Regards,
> 
> Purushotham Komaravolu
> Software Engineer
> Yaga, Inc. - "advanced payment services"
> Direct: 415-901-7343
> Fax: 415-901-1586
> http://www.yaga.com
> 
> 
> 
> - Original Message -
> From: "Tech Support" <[EMAIL PROTECTED]>
> To: "Purushotham Komaravolu" <[EMAIL PROTECTED]>
> Sent: Tuesday, July 30, 2002 11:34 AM
> Subject: Re: [PHP] mcrypt
> 
> 
>> Rather than tease you with hints I'll give you some working code ;-)
>>
>> Documentation for practical usage of mcrypt is weak. I agree.
>>
>> > // crypto.inc
>> $key = "secret key crap";
>>
>> function hex2bin($data)
>> {
>> $len = strlen($data);
>> return pack("H" . $len, $data);
>> }
>>
>> function encrypt($string, $key)
>> {
>>  // version 2.4.x of lib mcrypt
>>  $td = mcrypt_module_open (MCRYPT_TripleDES, "", MCRYPT_MODE_ECB,
>>  ""); $iv = mcrypt_create_iv (mcrypt_enc_get_iv_size ($td),
>>  MCRYPT_RAND); mcrypt_generic_init ($td, $key, $iv);
>>  $crypted = mcrypt_generic ($td, $string);
>>  mcrypt_generic_end ($td);
>>  return bin2hex($crypted);
>> }
>>
>> function decrypt($string, $key)
>> {
>>  //version 2.4.x of lib mcrypt
>>  $string = hex2bin($string);
>>  $td = mcrypt_module_open (MCRYPT_TripleDES, "", MCRYPT_MODE_ECB,
>>  ""); $iv = mcrypt_create_iv (mcrypt_enc_get_iv_size ($td),
>>  MCRYPT_RAND); mcrypt_generic_init ($td, $key, $iv);
>>  $decrypted = mdecrypt_generic ($td, $string);
>>  mcrypt_generic_end ($td);
>>  return trim($decrypted);
>> }
>> ?>
>>
>>
>> usage:
>> > include ("path/to/crypto.inc");
>> $secret = "meet at secret place";
>> $encrypted = encrypt($secret, $key);
>> print "original: " . $secret . "";
>> print "encrypted: " . $encrypted . "";
>> $decrypted = decrypt($encrypted, $key);
>> print "decrypted: " . $decrypted . "";
>> ?>
>>
>> Note: if you are encrypting really secret crap like credit card numbers
>> or something of that nature then NEVER include the key anywhere in your
>> code. Make a form where you have to type it in or something in order to
>> display the results.
>>
>>
>> Jim Grill
>> Support
>> Web-1 Hosting
>> http://www.web-1hosting.net
>> - Original Message -
>> From: "Purushotham Komaravolu" <[EMAIL PROTECTED]>
>> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
>> Sent: Tuesday, July 30, 2002 12:52 PM
>> Subject: [PHP] mcrypt
>>
>>
>> Hello,
>>   I am getting some odd errors trying to get an encrypt/decrypt
>> process to
>>   work. Looking at the manual examples and some other literature, I
> have
>> tried
>>   the two approaches listed below. For each, I get a sometimes-works,
>>   sometimes fails result. The manual entry has a string of user notes
>> with
>>   problem like mine, but I still have problems.
>>
>>
>>
>>   Server API Apache
>>
>>
>>
>>   mcrypt
>> mcrypt support enabled
>> version 2.4.x
>> Supported ciphers twofish rijndael-128 rijndael-192
> rijndael-256
>>   saferplus rc2 xtea serpent safer-sk64 safer-sk128 cast-256 loki97
> gost
>>   threeway cast-128 des tripledes enigma arcfour panama wake
>> Supported modes ofb cfb nofb cbc ecb stream
>>
>>
>>   --]
>>
>>
>>
>>   The first attempt used the following code:
>>
>>
>>   -->
>>   >   $key = "this is a secret key";
>>   $input = "Let us meet at 9 o'clock at the secret place.";
>>
>>

[PHP-DEV] PHP and sed blowing up builds

[J Smith]

The current CVS is having trouble compiling on Solaris platforms (Solaris 
8/SPARC for me) and from what I can tell, the problem is thanks to Sun's 
sed.

While the Solaris shell itself can handle an insane number of command line 
argument characters, the default Solaris sed truncates it's input down to 
4,000 characters. This causes problems when it comes time to link 
everything together during the final stages of the make, as the command 
libtool receives can become quite long:

/bin/ksh libtool --silent --mode=link gcc -export-dynamic -DPHP_ATOM_INC 
-I/setup/php/php4/include -I/setup/php/php4/main -I/setup/php/php4 
-I/setup/php/php4/Zend -I/setup/php/php4/ext/xml/expat  
-D_POSIX_PTHREAD_SEMANTICS -I/setup/php/php4/TSRM -g -O2  -L/usr/ucblib  -R 
/usr/ucblib ext/ctype/ctype.lo ext/mbstring/mbfilter_ja.lo 
ext/mbstring/mbfilter_cn.lo ext/mbstring/mbfilter_tw.lo 
ext/mbstring/mbfilter_kr.lo ext/mbstring/mbfilter_ru.lo 
ext/mbstring/mbfilter.lo ext/mbstring/mbstring.lo... (more, more, more) 
main/internal_functions.lo -lcrypt -lresolv -lresolv -lresolv -lm -ldl 
-lsocket -lsocket -lcrypt -ldl -o php
Output line too long.
Output line too long.
Output line too long.
gcc: ext/stan: No such file or directory
make: *** [php] Error 1
#

Sun's sed can't handle the input, but GNU sed can. After installing GNU sed 
and messing around with $PATH so GNU sed would be found before Sun's sed, 
the build works as expected. The above error was produced doing a plain, 
argument-less configure on Solaris 8 (SPARC) using autoconf 2.53 and a CVS 
checkout from Friday. It can also be reproduced if you configure with 
enough extensions -- anything that'll get the linking line above longer 
than 4000 characters.

The problem may exist on other platforms, such as IRIX, where sed apparently 
has an input limit of just over 8,000 characters or so.

Determining the best sed to use is a pain in the arse, as they're all a 
little different, but I'm thinking GNU sed should be a requirement on UNIX 
systems, since you're going to have to be using gcc anyways. There were 
apparently plans to put a macro in autoconf that would determine the best 
sed to use (prefering GNU sed above the others), but it appears it was 
dropped because of the distinct differences in seds from platform to 
platform. The macro is here:

http://mail.gnu.org/pipermail/autoconf-patches/2002-January/008138.html

Would it be overly difficult to perform this check during configure and use 
GNU sed over any system seds? (I have only a passing familiarity with the 
PHP build system, having mucked around in config.m4 a bit, but never really 
doing much with it beyond that.)

J

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

[PHP-DEV] Re: Introducing EXCPLICIT

[J Smith]

I wouldn't take my opinion as law, as I'm not part of the core PHP Group or 
anything, so I don't speak for anyone but myself. All I'm saying is that I 
seem to remember this issue being brought up before, and the result was 
that PHP is not a strong typed language, and probably won't become one any 
time soon.

A couple of weeks ago the discussion kind of stirred up again with the idea 
of "string types". 

You can sort of do your own data type checks now using is_int(), is_array(), 
etc., which although falls short of true strong typing, is better than 
nothing.

If you want to move to C#, super. Use the tool that fits the job. But I hope 
to hell you aren't doing it just 'cause I sent you a reply on a newsgroup 
that you didn't like. Personally, I wouldn't mind a slightly stronger typed 
PHP (at least for function arguments) as long as BC and portability were 
maintained and it was totally optional.

J


Ilker Cetinkaya wrote:

> thank you for your reply,
> 
> i'll change to c# as soon as i've finished my current projects.
> 
> regards,
> ilker
> 


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

[PHP-DEV] Re: Introducing EXCPLICIT

[J Smith]

I seem to remember strong typing being brought up before, and I also seem to 
remember it being shot down.

The consensus seemed to be if you want a strongly-typed language, use Java. 
Or C. Or C++. Or something other than PHP that has strong data typing.

Have things changed since then?

J


Ilker Cetinkaya wrote:

> i'd like to discuss with you a growing problem regarding php applications.
> 
> i see the features taken into account for ze2 have been made regarding the
> needs of advanced php developers who design complete applications with php
> instead of just dumping out some dynamic content.
> 
> php is ease of use because you don't have to care about important language
> needs like types.
> that makes following code possible
> 
> $a = "hello u ";
> $b = 2;
> echo $a.$b;
> 
> imho that is a good feature for coding simple things fast "from brain to
> keys".
> however in a more complicated and larger context, as in frameworks and
> libraries for example,
> this leads the coder to produce more code to get the things bugfree.
> 
> consider a function inserting a row into a table with id and name:
> 
> function ins($id, $name) {
> if (is_numeric($id) && is_string($name)) {
> // do insert
> return true;
> }
> return false;
> }
> 
> through loose typing a value of $id = "1 " (note whitespace) is possible
> and insert would fail.
> no problem, extending condition to is_numeric(trim($id)) does it.
> anyways, a value of $name=444 causes failing this condition too, although
> it should be dyncasted into a string.
> 
> instead consider this:
> 
> bool function ins(int $id, string name) {
> //do insert
> return true;
> }
> 
> and everything is right.
> 
> what i want to point out is the loose vs. strong type issue - certainly
> discussed prior this post.
> 
> i'd like to propose the introduction of an explicit command for ze2 to
> resolve this issue.
> as known of vb for example, explicit forces coder to explicitly declare
> variables.
> this would require to be "explicit" as a language directive or option.
> 
> example:
> 
> #!php --explicit (or something similar, perhaps a php.ini entry)
> 
> mixed $mixed = "hello";
> string $str = "string";
> int $num = 5;
> bool $ok = false;
> array $ar;
> float $rate;
> 
> bool function ins(int $id, string $name);
> 
> class test {
> private bool $done; //private
> var string $name; //public;
> private object $o;
> 
> string print() {
> return $name;
> }
> }
> 
> object $o = new test();
> echo $o->print();
> 
> 
> i don't have any clue about implications regarding parsing and handling
> such explicit behaviour,
> especially considering type juggling, but juggling could be disabled when
> explicit is turned on.
> 
> is there a chance to realize this ? and moreover, is this a desired,
> planned feature ?
> i'd welcome this
> 
> just my 2c;
> 
> ilker


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

RE: [PHP-DEV] Re: Client socket

[J Smith]

I'm no apache expert when it comes to hacking the source or anything, but it 
appears that ap_rwrite() and ap_write() might do what you're looking for. 
They look something like this:

int ap_rwrite(const void *buf, int nbyte, request_rec *r);

And apparently they let you write directly to the request. Or something like 
that. 

J



Vinod Panicker wrote:

> Makes sense.  Dunno why it didn't occur to me before - the '3' says it
> all.
> 
> I need the actual socket - which when written to will send data to the
> client.  Is it there in the request_rec structure?
> 
> Or can I get it some other way?
> 
> Tx,
> Vinod.
> 
> ---
> Vinod Panicker <[EMAIL PROTECTED]>
> Sr. Software Designer
> Geodesic Information Systems Ltd.
> 
> 
> 
> -Original Message-
> From: J Smith [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 29, 2002 8:13 PM
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] Re: Client socket
> 
> 
> 
> Since apache is multi-processed rather than multi-threaded, I'd imagine
> that
> you're getting the same socket file descriptor since each new connection
> 
> means a new fork of httpd, resulting in three file descriptors by the
> time
> you get to what you're doing.
> 
> Are you trying to get ahold of the socket/port number itself? Or connect
> to
> the actual socket?
> 
> J
> 
> 


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

[PHP-DEV] Re: Client socket

[J Smith]

Since apache is multi-processed rather than multi-threaded, I'd imagine that 
you're getting the same socket file descriptor since each new connection 
means a new fork of httpd, resulting in three file descriptors by the time 
you get to what you're doing.

Are you trying to get ahold of the socket/port number itself? Or connect to 
the actual socket? 

J


Vinod Panicker wrote:

> Hi,
> 
> Continuing with the problem that I've been having...
> 
> I made changes to the php_apache.c file and added a new php function of
> my own, which is supposed to return the client socket when called from a
> php script.  Here is the code for the function -
> 
> ---
> 
> /* {{{ proto int apache_client_socket()
>Get the client socket */
> PHP_FUNCTION(apache_client_socket)
> {
> RETURN_LONG(((request_rec
> *)SG(server_context))->connection->client->fd);
> }
> 
> ---
> 
> I recompiled php and made a module out of it.  Worked perfectly.  Now, I
> wrote a php script with the following code -
> 
> ---
>  echo apache_client_socket();
> ?>
> ---
> 
> This script I call from the browser, and everytime it displays a '3'.  I
> even called it from different browser windows, still the same.
> 
> That cant be alright since if the fd is 3 as shown in one browser
> window, it has to be something different in the other window since the
> browser defaults to a keep-alive connection, and the fd's have to be
> different.
> 
> I'll would tell you why I need the socket, but I've described it so many
> times that I'm gonna die :(  I'll forward you a mail if you are really
> interested.
> 
> Tx,
> Vinod.
> 
> ---
> Vinod Panicker <[EMAIL PROTECTED]>
> Sr. Software Designer
> Geodesic Information Systems Ltd.


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

[PHP-DEV] Re: OS X Support

[J Smith]

If you're looking for general cryptography that doesn't absolutely require 
mcrypt (like you just want to use Blowfish or Rijndael or some cipher 
algorithm that mcrypt provides), then I'll shamelessly plug a cryptography 
extension I've been working on that uses Crypto++ instead of mcrypt. It 
provides pretty much all of the functionality of the mcrypt extension, and 
in many cases is compatible with it.

Note that I'm only shamelessly plugging the extension because I'm interested 
in seeing if it works on OSX, not because I think it's the bomb or 
anything. I've got it working on Solaris 8, linux and Win2000, so I'm just 
curious how OSX would handle it. (We have a running copy of OSX at work, 
but I'm not allowed to play with it yet...)

Anyways, if you're still interested despite my shameful advertising, head to 

http://www.tutorbuddy.com/software/

And check out the cryptopp extension.

J


Mitch Vincent wrote:

> What's the current status of OS X support? I understand that 4.3 will be
> the first release to "officially" support OS X but how much of the work is
> complete in current CVS?
> 
> I grabbed the latest yesterday and compiled it -- still had my issues
> creating files and directories (Where I would get permission denied errors
> even though the perms were 777 and the entire directory was owned by the
> webserver user/group).. I ran into this problem using Smarty and evidently
> a lot of people have had it with 4.2.. I also couldn¹t get mcrypt to work
> in 4.3-dev -- "unable to open encryption module" for everything I tried
> (this worked fine in 4.2). I have libmcrypt 2.5.0 installed, which appears
> to be the latest available...
> 
> I would roll back to 4.1 but I can't get it to compile on this box and the
> only OSX build I've found doesn't have working mcrypt support and I kind
> of have to have it :-)
> 
> Thanks to all!!!
> 
> -Mitch


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

Re: [PHP-DEV] Extension news: cryptopp

[J Smith]

I can definitely look into it, although I can't guarantee any results yet, 
as we're about to go back into heavy development of a new app at work 
(which uses the extension), but hopefully I'll get some free time to put 
towards it. I'll let you know how things are in two weeks or so; I should 
have a bit of a clue by then as to how things are going to be with the new 
app.

J


[EMAIL PROTECTED] wrote:

> Hello,
> 
> I read some of the documentation, and noticed that this API seems to be
> very usable for an abstraction to multiple encryption libraries. It even
> looks a lot like the API I had in mind for the revamped mcrypt extension.
> 
> Would you be interested in figuring the best way to do it, so that we have
> a nice crypto API for PHP 5?
> 
> regards,
> Derick
> 


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

[PHP-DEV] Extension news: cryptopp

[J Smith]

Just thought I'd give an update about the current status of the Crypto++ 
extension for PHP I've been working on the past month or two, called simply 
cryptopp.

The extension is coming along rather nicely and is stablizing towards a 
solid release. I'd still consider the current releases of beta quality and 
not to be trusted with 100% confidence, although I have not had a problem 
yet. (As more users try out the extension, I'll get a better idea of how 
well it's working, but I need feedback, which sadly has been slow-coming.)

The good stuff:

- Works on a bunch of platforms, including both UNIX platforms (Solaris 8 
and linux tested; others should work if gcc/g++ work) and Windows platforms 
(Windows 2000 with VC++ 6 tested). Hopefully this will be of use to Windows 
PHP users, as I don't believe the win32 port of the libmcrypt libraries are 
being maintained anymore.

- The extension implements 32 cryptographic ciphers (27 block ciphers, 5 
stream ciphers), 14 cryptographic hashes and two checksum hashes. (CRC32 is 
included for completeness, even though there is already a CRC32 function in 
PHP.) 

- There is some compatibility with the mcrypt and mhash extensions. I 
haven't tested everything, but there are at least a few algorithms common 
to each that can produce compatible ciphertext.

- There's a set of C bindings to the extension that you can use in other 
extensions. I guess. I had originally used the C bindings in the extension 
itself until I wised up. I left them there for others to use if they really 
want to. (The extension is written in C++, so the C bindings were 
originally to make using the C++ classes from PHP's C code easier.)


The bad:

- produces a big-ass executable when statically linked with PHP. My current 
Apache executable went from 3.3 MB or so to 5.3 MB after enabling the 
extension. VC++ 6 produces a DLL of 430 KB or so. This is 'cause unlike 
mcrypt and mhash there's no dynamic loading of ciphers or hashes. (Yet -- I 
may work on this later.)

- there's no way to pick and choose which ciphers or hashes you'd like to 
compile in with the extension -- it's all or nothing. I'm also planning on 
working on this later.


The latest version of the extension is 0.0.5. There were a few changes from 
the original version, 0.0.1, which are listed in the docs. To play around 
with the extension, head to http://www.tutorbuddy.com/software/. (Mirrored 
at http://209.202.82.229/software/.)

J


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

[PHP-DEV] Re: news.php.net shows unterminated string

[J Smith]

[root@corduroy php-4.2.1RC1]# lynx -head -dump http://news.php.net
HTTP/1.1 200 OK
Date: Wed, 01 May 2002 14:37:45 GMT
Server: Apache/1.3.20 (Unix) PHP/4.2.0RC2
X-Powered-By: PHP/4.2.0RC2
Connection: close
Content-Type: text/html; charset=iso-8859-1

J


Derick Rethans wrote:

> Hello,
> 
> while browsing http://news.php.net/group.php?group=php.general I saw the
> following error:
> 
> Warning: String is not zero-terminated (Úèfî ) (source:
> zend_execute_API.c:583) in /usr/local/www/news.php.net/common.inc(80) :
> regexp code on line 0
> 
> Warning: String is not zero-terminated (Úèfî ) (source:
> zend_execute_API.c:274) in /usr/local/www/news.php.net/common.inc on line
> 80
> 
> 
> Which version of PHP is running on this machine? I'll see if I can fix
> this error then.
> 
> 
> regards,
> Derick


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

RE: [PHP-DEV] Build problem on Solaris 8

[J Smith]

I don't think so. I tried a couple of weeks ago with Solaris 8, and autoconf 
2.53 broke the build. 2.13 worked fine; anything greater seems to die.

J


David Knox wrote:

> Thanks,
> Will autoconf 2.13 or greater work? I already have 2.53.
> 
> --dk
> 


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

Re: [PHP-DEV] sockets

[J Smith]

One way to find which socket has died, if any, is to loop through each 
socket in the three sets (read/write/exceptions) and do a select() on each 
one to see if you can read with a timeout of 0. (The bad one being the one 
where select() returns -1, I think.)

J


Steve Meyers wrote:

> There's only one thing it's missing -- the equivalent of
> socket_get_status(), which is not part of the extension, despite the name.
> If I set my socket to nonblocking, the only way to tell if it has died is
> to try to write to it, which isn't always a desirable thing to do :)
> 
> Unless there's another way that I just don't understand.
> 


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

Re: [PHP-DEV] sockets

[J Smith]

You can kind of simulate multithreading with the sockets extension by using 
socket_select(). Technically, the result is multiplexing and not 
multithreading, but in the end, it works quite nicely -- you can handle 
multiple incoming/outgoing connections without the need for forking or 
multiple threads. 

Handling multiple sockets is definitely do-able in PHP, and it's relatively 
easy to set up. There should be an example I wrote somewhere in the 
archives.

J


Dan Hardiker wrote:

> The only feature which would be useful towards this module is threading.
> If PHP were able to thread it could handle multiple incoming sockets and
> neglegate the need for IPC between child processes (where PCNTL has been
> used) as it could all be handled by a common parent with shared (not
> copied) variables.
> 
> Just my 2p's worth
> 


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

Re: [PHP-DEV]

[J Smith]

Just read that myself at w3c.org. I hate the format of their 
recommendations, god. It takes forever for me to find anything specific in 
their specs.

J


[EMAIL PROTECTED] wrote:

> From: http://www.w3.org/TR/2000/REC-xml-20001006#sec-pi
> 
> [16]  PI   ::='' Char*)))? '?>'
> [17]  PITarget ::=Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))
> 
>  [3]  S::=(#x20 | #x9 | #xD | #xA)+
>  [2]  Char ::=#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] |
>  [[#x1-#x10FFFF]
> 
> Meaning that between  everytning is allowed but '?>'.
> 
> Derick
> 
> On Fri, 26 Apr 2002, J Smith wrote:
> 
>> Are you positive about that? I would have assumed so, too, but it passes
>> both the Sablotron and Xerces XML processors without so much as a
>> warning.
>> 
>> J


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

Re: [PHP-DEV]

[J Smith]

I hear that. Not that reading specs and standards isn't fun...

J



Rasmus Lerdorf wrote:

>> I'm pretty sure it is. It parses fine according to Xerces, at any rate.
>> At first, I was thinking the greater than comparison would cause
>> problems, as  elements like seeing the test written as "foo >
>> bar", but when you have the symbol inside of a processing instruction,
>> it's fine.
> 
> Are you sure?  I know that this is a common thing for XML parsers to
> allow, but I think going strictly by the spec it is not valid.  I could be
> wrong though, my XML spec-reading patience has long since worn off.
> 
> -Rasmus


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

Re: [PHP-DEV]

[J Smith]

Are you positive about that? I would have assumed so, too, but it passes 
both the Sablotron and Xerces XML processors without so much as a warning. 

J


Rasmus Lerdorf wrote:

>>  $bar)
>> ...
>> ?>
>>
>> Is this valid XML?
> 
> No, this is technically invalid XML.  You would have to write it as:
> 
>
> But sheez... That's just way too ugly, you can work around it and there
> are other examples out there of people breaking this rule. Doing  a much more flagrant violation in my opinion.
> 
> -Rasmus


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

Re: [PHP-DEV]

[J Smith]

This might not matter too much now, but conforming to XML standards might 
matter eventually.

Let's say in a year or two, somebody decides to write a PHP module for an 
XML/XSL processor. (Something like XSP using Apache's Cocoon.) Basically, 
these processors take in some XML, look for processing instructions, create 
some output based on what they find, pass the output through an XSL 
transformation and spit out some other format, like HTML. If PHP doesn't 
work well with XML, this is going to be a mess. (I seem to remember hearing 
about such a module for Cocoon, which they call producers. It would be kind 
of cool to have a PHP procuder, which I'd prefer over the standard Cocoon 
producer, Java.)

J

p.s. and OT -- it would be pretty cool if the XSLT extension for PHP was 
able to process the XML/XSL before it passed it off to the actual XSLT 
processor, i.e. look through the XML or XSL for PHP processing instructions 
encased in   and actually evaluate them before the 
transformation. That might be something cool to look into. (I use the XSLT 
extension quite a bit, and this would definitely be useful. For now, I 
eval() the XML/XSL and buffer it before sending it to the XSLT processor.)



Gabriel Ricard wrote:

> Why are short tags ( and <% %>) such a bad thing?
> 
> Why does the PHP formatting (tags) matter in terms of SGML & XML?
> 
> 
> Not that it matters, but personally I prefer to use the short tags  and ?> because it's less code for me to write, it fits nicely into my
> HTML, and I find  don't really care for  behind it and agree with the consistency argument for it.
> 
> - Gabriel


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

Re: [PHP-DEV]

[J Smith]

I'm pretty sure it is. It parses fine according to Xerces, at any rate. At 
first, I was thinking the greater than comparison would cause problems, as 
 elements like seeing the test written as "foo > bar", but when 
you have the symbol inside of a processing instruction, it's fine. 

J



Zeev Suraski wrote:

> At 21:07 26/04/2002, Sterling Hughes wrote:
>>The whole point of the >XML documents.  When short tags are disabled, commands such as <% echo
>>'HELLO'; %> don't work.  If you allow  syntax, it is not valid
>>XML, which negates the point of having  
> He was wrong about the 2nd example, but I'm pretty sure about his first:
> 
>  $bar)
> ...
> ?>
> 
> Is this valid XML?
> 
> 
> [I'm not taking sides on whether  
> Zeev


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

Re: [PHP-DEV] sockets

[J Smith]

I've been using it since the first API revision and it's been working fine 
for me. (Up to and including the latest API revision.) As far as I'm 
concerned, it's getting pretty close to losing the experimental tag. 
(Perhaps by PHP 4.3.x or so, barring any glarring problems that I've not 
encountered.)

J


Markus Fischer wrote:

> Hi,
> 
> Simple when enough people have tested it and it reaches the
> consensus that it's mature enough for being called stable
> (api doesn't change anymore, more testers, you name it).
> 
> - Markus
> 
> On Thu, Apr 25, 2002 at 07:46:30PM +0200, Michael Virnstein wrote :
>> Hi,
>> 
>> as i could read in the manual, the socket functions are completely
>> experimental.
>> When do you think the API gets final and won't change
>> anymore. Any comments on this are welcome.
>> 
>> Michael
>> 


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

Re: [PHP-DEV] Inline optimization

[J Smith]

I've also seen gcc go beserk and start taking up over 150 MB of memory on a 
pretty simple compile 'cause it got confused and take forever to compile. 
Last time I saw this happen, I waited a half-hour to see if it would 
eventually compile. Meanwhile, the memory usage was pegged at 99% or so. 
Eventually I just killed the process. With -O2, the same file took 10 
seconds to compile.

J


Aaron Bannert wrote:

> On Fri, Apr 19, 2002 at 03:50:16PM +0200, Sebastian Bergmann wrote:
>> Yasuo Ohgaki wrote:
>> > Any objection for changing -O2 -> -O3 when
>> > --enable-inline-optimization is used? (when GCC is used)
>> 
>>   What happened to the plan of making --enable-inline-optimization the
>>   default?
> 
> Is making these kinds of optimizations by default such a good idea? I've
> seen many a broken gcc install produce incorrect binaries with the larger
> -O optimizations turned on (unfortunately).
> 
> -aaron


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

Re: [PHP-DEV] Re: php extensions on windows

[J Smith]

Get somebody with enough karma to update it I guess. But I'd recommend 
opening up one of the VC++ projects from the source and checking the 
settings out, 'cause I might have forgotten something there.

J


Brent R. Matzelle wrote:
> 
> This information would be a terrific addition to the PHP
> documentation.  How might we get it added?
> 
> Brent
> 


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

[PHP-DEV] Re: php extensions on windows

[J Smith]

I've been working on this sort of thing for the past few weeks as I've been 
trying to make sure all of the PHP extensions I've written work on UNIX 
systems as well as Windows systems.

I think you can compile using gcc and cygwin, but I believe the recommended 
way is with Visual C++ 6, as the official binaries are done with VC++. (I 
think, I don't use PHP in Windows except to test portability.)

Anyways, here's what I do as far as settings. This is for a thread-safe 
release extension. I'm assuming you have a bit of experience working with 
VC++ and the PHP source, and that you're able to compile PHP in the first 
place.

0. Start a new project in VC++ and add your extension's files. 

1. In the Configurations dialog, add two configurations: Release_TS and 
Debug_TS. Release_TS should copy the settings from Release and Debug_TS 
should obviously copy from Debug. You can Remove Release and Debug and 
close the dialog. The next set of steps is for the Release_TS 
configuration. If you can figure that out, you should be able to get 
Debug_TS working fine.

2. Open up Project->Settings. On the C/C++ tab, General Category, added the 
following preprocessor definitions: ZEND_DEBUG=0, 
COMPILE_DL_YOUR_EXTENSION_NAME, ZTS=1, ZEND_WIN32, PHP_WIN32. 
YOUR_EXTENSION_NAME is the name you'll find in the sources generated by 
ext_skel.

3. In the Code Generation Category, change Use run-time Library to 
"Multithreaded DLL". 

4. In the Preprocessor Category, add the following "Additional include 
directories": ..\.., ..\..\main, ..\..\Zend, ..\..\TSRM, ..\..\bindlib_w32. 

5. On the Link tab in the General Category, change the Output file name to
..\..\Release_TS/php_yourextension.dll.

6. On that same tab, same category, add php4ts.lib to Object/library 
modules. 

7. In the Input Category, add the following to Additional library path: 
..\..\Release_TS.

That should be it. Close dialog and set the active configuration to 
Release_TS and (hopefully) build the DLL.

If you're using other libraries and such, make sure you compile them using 
the multithreaded DLL runtime library like you did with your extension. I 
found that out the hard way trying to get my cryptopp extension working on 
Windows.

Check out some of the VC++ project files included with the PHP source when 
you're stuck and try to replicate the settings they use in your own 
project. It takes a while to get used to building extensions with VC++ 
'cause that sort of thing is so poorly documented in the Windows world, but 
once you get it once you should be fine.

J


Igal Raizman wrote:

> Hello,
> 
> Can someone point me in the directions of a tutorial or perhaps some info
> on making PHP extensions on a Windows system ?
> 
> not on how to code them, but rather on how to compile them on a windows
> system.
> 
> Thanks,


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

Re: [PHP-DEV] Please forward to the list, I'm not a member anymore... (fwd)

[J Smith]

I don't know if it's so much a violation of the GPL as it is a clash with 
PHP's license, which is basically BSD-like. The whole point of the PHP 
license is that you can basically use PHP without restriction, commercial 
or otherwise. The GPL doesn't allow that.

But I'm just guessing here. It feels kind of like when OpenBSD removed it's 
ipf code because it wasn't under an OpenBSD-ish license.

J


Stefan Esser wrote:

> Morning,
> 
>> > It is GPL
>>
>> Then we can't use it with PHP...
> 
> sorry, but I do not see your point. How can optional support for a GPL
> library in PHP violate the GPL?
> 
> Stefan Esser


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

Re: [PHP-DEV] C++ Class Wrapping

[J Smith]

Of course. Use extern "C" style bindings and such.

J


Ken Egervari wrote:

> Can you use C++ however?  I'm very interested in writing/using a standard
> w3c binding for DOM XML
> 


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

[PHP-DEV] Crypto++ extension alpha release

[J Smith]

I've finally gotten the Crypto++ extension I've been working on up to the 
point where I think a release is warranted. At least, an alpha release.

The Crypto++ extension provides a number of cryptographic algorithms, 
including some 27 block cipher algorithms and 13 hash algorithms. At this 
point, you can pretty easily encrypt and decrypt text using a variety of 
block cipher modes along with a bunch of other options, as well as hash and 
validate hashed text.

I'm considering this alpha-quality right now, as I'm the only one who's 
tested it, and I'd like some others to start looking at it and telling me 
what they think. It's coded mostly in C++ with some C to talk to PHP. It's 
not an overly complex extension, but it works pretty well. Out of 360-some 
tests (taken from the Crypto++ validation suite), only 8 fail, and I 
already know why. (Not sure if I'm going to bother fixing it, though.)

Anyways, to try out the extension, head to http://209.202.82.229/software. 
To view the extension's manual, head to 
http://209.202.82.229/software/cryptopp/. To download the extension 
directly, try 
http://209.202.82.229/software/download.php/cryptopp-php-0.0.1.tar.gz. 

So far, I've only tested the extension on Linux (2.4.9 kernel using gcc/g++ 
2.96 and on Solaris 8 using gcc/g++ 2.95). It should work on Windows, but I 
haven't tested it yet. (If anybody gets it working on win32, please let me 
know.)

J

p.s. Derick -- what's the word on that abstracted crypto API you mentioned a 
while back? I'm still interested.

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

Re: [PHP-DEV] CLI & max_execution_time

[J Smith]

You're right about the -q thing, I didn't notice it the first time. (I kind 
of just run -q now without thinking about it.)

It's not a big thing to do the separate compiles, so it's no worry. Just a 
little annoyance, but I'll live. 

This isn't a big issue or anything, sort of a nice-to-have. But if I'm in 
the minority for wanting this, that's fine, I'll live.

J


Edin Kadribasic wrote:

> 
> Are you sure you were testing it with CLI? Header hiding (-q) has been in
> there since the first check-in back in Jan 6.
> 
> If you have sufficiently different setups, there is no way but to
> configure and compile PHP twice. Building of CLI creates no big overhead
> (just two c files and one extra link step).
> 
> Yes, there was a discussion about separating php.ini file for cli
> (php-cli.ini). At the end most people said that their configurations were
> sufficiently similar and that the content of those two files would be
> mostly the same. Derick promised to implement some sort of 
> mechanism, but I guess he was busy with other things.
> 
> Edin


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

Re: [PHP-DEV] CLI & max_execution_time

[J Smith]

I'd kind of agree with this. I use both the apache SAPI module and the CLI 
side by side in a single system (the web server does it's thing, and the 
CLI powers the search engine, which the web server can use on a per-request 
basis and ties the two together with XML/XSLT). One of the problems I had 
when playing around with PHP-4.2.0dev (I believe, it might have been 
4.3dev) was that the CLI was built by default, yet I use very different set 
ups for the apache module and the CLI module. There are a lot of extensions 
that aren't shared between the two, and it basically meant compiling the 
CLI twice -- once when I built the apache module and again to get the CLI 
executable I needed. 

I'd also like to see that automatic "-q" header hiding and, as has been 
discussed before, a separation of the web server's php.ini file and the 
CLI's, as I always have trouble with the two. (For instance, in the apache 
module, I always have output buffering set to something liek 4K, but on the 
CLI, I don't want output buffering at all. Little things like that.)

My opinion, for all it's worth.

J


Markus Fischer wrote:
> 
> Actually, I think that would be a good idea to remove it. Do
> not release something which is not completely well thought
> and finished. People have lived without CLI for a while; they
> can wait. But don't create another/new headache with some
> broken system to which we have to be backwards compatible :/
> 
> - Markus
> 



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

Re: [PHP-DEV] Crypto++ extension happenings

[J Smith]

Doesn't sound like a bad idea. It's a bit more grand than what I had in 
mind for the Crypto++ extension, but I'd be willing to work on it. The main 
thing for me right now is that the Crypto++ extension is being done for 
work, and isn't entirely a hobby-type of thing. (Although I'm glad I work 
for a company that lets me combine the two, as we need a crypto library for 
PHP and I'm glad to be writing one that other people will be able to use.)

Because it's for work, I'm still going to have to work towards getting the 
Crypto++ library working in some general sense, but if this API you're 
thinking of can be used with it, I'm all for it. Let me know what you're 
thinking and we'll see what happens.

J


[EMAIL PROTECTED] wrote:

> Hello,
> 
> I'm currently designing a new 'encryption' extension which should be able
> to have different backend encryption libaries like mcrypt and crypto++.
> however this extension will be developped with an OO approach and for ZE2.
> Th eidea is only in my mind at this moment, but I'm sure we can get a API
> defined which supports both of these libraries. What do you think of this?
> 
> Derick
> 


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

[PHP-DEV] Crypto++ extension happenings

[J Smith]

As I reluctantly mentioned a few weeks ago, I'm working on a PHP crypto 
extension that uses Crypto++, a C++ library that provides implementations 
for a bunch of crypto and hash algorithms. I was reluctant to bring it up 
because I didn't know if I was going to finish it at all, and I didn't want 
to get anybody's hopes up. The rationale behind the extension was partially 
because we need a crypto library at work that we can use on win32 platforms 
for a Windows Media Services plugin and one that PHP can use to create 
ciphertext compatible with the aforementioned plugin. Unfortunately, 
libmcrypt now requires cygwin on win32, and that sort of depedency would be 
hellish for a WMS plugin. Crypto++ works fine on Windows using VC++, and 
also works fine on UNIX systems using g++. Thus, a crypto extension for PHP 
that works on both major platforms.

Well, things have come along a bit further, and although the extension is 
still quite a way from being complete, it's getting there. The basic 
structure of the extension goes something like this:

- there's a base class in C++ that a template inherits from that provides 
the basic members and methods needed to encrypt and decrypt messages, along 
with all of the usual methods that allow you to set the IV for a crypto 
algorithm, the secret key, key length, mode (CBC, ECB, etc.), and 
plaintext. The base class is pure abstract virtual, as is the template that 
encapsulates it. (The template may seem a bit unnecessary, but it's used to 
set things like the block size for ciphers with variable block sizes and 
such. The base class it derives from makes things easier when dealing with 
C++'s templates, which allows it to compile on several compilers, like g++ 
and VC++, which all seem to disagree on how to use templates.)

- from there, there are a bunch of classes that provide interfaces to the 
various crypto algorithms, like Blowfish, 3-Way, Rijnadael, etc. So far, 
I've only implemented those three algorithms, but others will be done 
eventually, like the various CAST ciphers, RC5, etc. So far I've only 
worked with block ciphers -- I haven't started anything with the stream 
ciphers, like ARC4, WAKE, etc. All of the more popular block cipher modes 
are working, like OFB, CFB, several CBC padding modes, etc.

- on the hash side, there's a base hash class, from which various other 
classes derive that provide interfaces to the hash algorithms. So far, MD5, 
MD2, Panama and RIPEMD160 are the only hashes I've implemented; HAVAL and 
others will follow. (Although, for whatever reason, HAVAL is being a bitch 
and doesn't like compiling properly. Don't know why yet.)

Besides all of the C++ stuff, I've been working on C functions to access 
from the PHP code. (extern "C" stuff, that all jazz.) They're mostly 
complete for the cipher side; I haven't started on C stuff for the hashes 
yet.

I'm thinking the PHP fuctions themselves will work much like the mcrypt 
library, something like described below. These function names are all 
subject to change, obviously, since I haven't started writing this portion 
of the project yet. I may end up going the object oriented route using PHP 
classes; I'm not sure yet. Depends on feedback. (And more importantly, what 
work wants -- please remember, this extension is being worked on for my 
job; the fact that I can allow everyone else to use it as free software is 
a luxury.)


- resource cryptopp_create_cipher(int cipher) -- cipher is a constant that 
refers to the cipher algorithm, like CRYPTOPP_CIPHER_BLOWFISH, or 
CRYPTOPP_CIPHER_AES for AES/Rijnadael. The function returns a PHP resource 
that will be used for the other functions, or false on error.

- bool cryptopp_destroy_cipher(resource cipher) -- closes a cipher.

- bool cryptopp_set_rand_iv(resource cipher, int length [, int rand]) -- 
creates a random IV for cipher of the length specified. This is created via 
/dev/urandom or /dev/random on systems that support them; otherwise, it 
uses the standard rand() function. The rand argument can be used to specify 
the method used to create the IV, i.e. CRYPTOPP_RAND_URANDOM for 
/dev/urandom, CRYPTOPP_RAND_RAND for the rand() function, etc. Returns true 
on success, false on error. By default, win32 systems will likely use the 
rand() function, while systems that can provide either /dev/random or 
/dev/urandom will use one of them, preferably urandom.

- bool cryptopp_set_iv(resource cipher, string iv [, bool hex]) -- add a 
specific IV to the resource. hex is used to determine whether the IV being 
added is being given in hex or in binary, with binary being the default. 
True/false on success/error.

- string cryptopp_get_iv(resource cipher [, bool hex]) -- returns the IV of 
resource or false on error. hex specifies whether the IV should be returned 
in binary or in hex, with binary being the default. false on error.

- bool cryptopp_set_mode(resource cipher, int mode) -- sets the mode of the 
cipher, i.e. CRYPTOPP_MODE_PAD

[PHP-DEV] Re: Sockets: new socket_select() example

[J Smith]

I think I got a handle on it now, thanks. Basically, I just had to replace 
a few of the socket_fd_* calls with things like adding to an array for 
socket_fd_set() and and in_array() instead of socket_fd_isset(). 

Attached is a decent example of a multiplexing server using the sockets 
extension. It's similar to what I've been using in 4.1.x, which has run 
fine on a production server for quite a while now.

Basically, it accepts up to 5 clients, waits for data from any one of the 
clients, then echoes that data back to all of the clients, kind of like a 
little chat server. 

Might be a nice example as a somewhat advanced use of the sockets 
extension. It's meant to be run via the CLI interface, of course.

J


Jason Greene wrote:

> Due to popular request, here is an example of the new socket_select():
> NOTE: ***This code does not do any error handling***
> 


#!/usr/local/bin/php -q
 $maxi)
$maxi = $i;

if (--$nready <= 0)
continue;
}


// check the clients for incoming data.

for ($i = 0; $i <= $maxi; $i++)
{
if ($client[$i] == null)
continue;

if (in_array($client[$i], $rfds))
{
$n = trim(socket_read($client[$i], MAXLINE));

if (!$n)
closeClient($i);
else
{
// if a client has sent some data, do one of these:

if ($n == "/killme")
killDaemon();
else if ($n == "/quit")
closeClient($i);
else
{
// print something on the server, then echo the incoming
// data to all of the clients in the $client array.

print "From {$remote_host[$i]}:{$remote_port[$i]}, client[$i]: $n\n";
for ($j = 0; $j <= $maxi; $j++)
{
if ($client[$j] != null)
socket_write($client[$j], "From client[$i]: $n\r\n");
}
}
}

if  (--$nready <= 0)
break;
}
}
}

?>



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

Re: [PHP-DEV] buildconf for 4.1.2 breaks Solaris 8

[J Smith]

The extension which caused the breakage was a custom extension, but it was 
built initially with ext_skel. I think either I did something screwy when I 
fixed up the config.m4 file (I've noticed that the file does indeed use 
'$something == "yes"', rather than the current method, which is '$something 
!= "no"') or the PHP version I original wrote the extension did '== "yes"' 
rather than '!= "no"' on it's own in ext_skel. I forget which version of 
PHP I originally used, but it was a while ago, something like 4.0.3 or 
before.

Either way, the problem seems to be fine now.

J



[EMAIL PROTECTED] wrote:

> On Wed, 13 Mar 2002, J Smith wrote:
> 
>> 
>> That seemed to do the trick. configure was rebuilt fine, although there
>> was a slight problem with new extensions built using ext_skel.
>> (Specifically, a few tests added to configure used a line like
>> 
>> if test $something == "yes" ; then
>> 
>> Which causes errors like "unexpected token ==" or something, which was
>> easily fixed by changing "==" to "=" in the configure script.
> 
> if test "$something" == "yes" ; then
> 
> is the preferred way. Can you point me where it goes wrong (which
> extension), so that it canbe fixed?
> 
>> 
>> But other than that, everything seems fine now. The remaining "=="
>> problem will probably be fixed in 4.2.x with the new build system.
> 
> 4.2.x will not have the new buildsystem.
> 
> Derick
> 


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

Re: [PHP-DEV] buildconf for 4.1.2 breaks Solaris 8

[J Smith]

That seemed to do the trick. configure was rebuilt fine, although there was 
a slight problem with new extensions built using ext_skel. (Specifically, a 
few tests added to configure used a line like

if test $something == "yes" ; then

Which causes errors like "unexpected token ==" or something, which was 
easily fixed by changing "==" to "=" in the configure script. 

But other than that, everything seems fine now. The remaining "==" problem 
will probably be fixed in 4.2.x with the new build system.

Thanks.

J


Jon Parise wrote:

> On Tue, Mar 12, 2002 at 06:33:34PM -0500, J Smith wrote:
> 
> What version of autoconf are you using?  You may need to step
> back to autoconf-2.13.
> 


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

[PHP-DEV] buildconf for 4.1.2 breaks Solaris 8

[J Smith]

This is the first time I've tried installing on Solaris, so maybe I'm way 
off, but anyways...

Here's how things look:

# ./buildconf
rebuilding configure
configure.in:124: warning: AC_PROG_LEX invoked multiple times
rebuilding main/php_config.h.in

# ./configure [any combination of configure arguments, it breaks regardless 
of what I use]
.
.
.
.
./configure: syntax error at line 3399: `fi' unexpected
# 


I could just have something screwy installed, or maybe I'm not doing this 
right. (I've done dozens of installs on Linux and win32 systems, this is my 
first Solaris install, so it might be me.)

Solutions? Suggestions>

J

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

Re: [PHP-DEV] Socket Rework Complete

[J Smith]

Never try to do something as complicated as attach some source to a mailing 
list post after two beer and a hefty lunch. 

Attachment is really here this time.

J



J Smith wrote:

> 
> Speaking of the FD_* macros and such, I'm trying to visualize how to
> re-write some code that I have that relies on the socket_fd_* functions.
> If you get the chance, could you look over this simplified version of what
> I'm doing and point me towards the proper direction to get it working with
> the new API. I want to have this stuff ready when PHP 4.2 or 4.3 come out,
> and seeing as you're the one closest to the sockets extension, I thought
> you could give me some pointers as to how it would work with the abscence
> of the sockets_fd_* functions. (I'm a little confused what to do without
> the FD_* stuff. This could make for a good example in the documentation,
> anyways, if it works as hoped.)
> 
> Attached is the stripped-down source.
> 
> J
> 
> 


#!/usr/local/bin/php -q
 $maxi)
$maxi = $i;

if (--$nready <= 0)
continue;
}


// check the clients for incoming data. 

for ($i = 0; $i <= $maxi; $i++)
{
if ($client[$i] < 0)
continue;

if (socket_fd_isset($allset, $client[$i]))
{
$n = trim(socket_read($client[$i], MAXLINE));

if (!$n)
closeClient($i);
else
{
// if a client has sent some data, do one of these:

if ($n == "/killme")
killDaemon();
else if ($n == "/quit")
closeClient($i);
else
{
// print something on the server, then echo the incoming
// data to all of the clients in the $client array.

print "From {$remote_host[$i]}:{$remote_port[$i]}, client[$i]: $n\n";
for ($j = 0; $j <= $maxi; $j++)
{
if ($client[$j] != -1)
socket_write($client[$j], "From client[$i]: $n\r\n");
}
}
}

if  (--$nready <= 0)
break;
}
}
}

?>



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

Re: [PHP-DEV] Socket Rework Complete

[J Smith]

Speaking of the FD_* macros and such, I'm trying to visualize how to 
re-write some code that I have that relies on the socket_fd_* functions. If 
you get the chance, could you look over this simplified version of what I'm 
doing and point me towards the proper direction to get it working with the 
new API. I want to have this stuff ready when PHP 4.2 or 4.3 come out, and 
seeing as you're the one closest to the sockets extension, I thought you 
could give me some pointers as to how it would work with the abscence of 
the sockets_fd_* functions. (I'm a little confused what to do without the 
FD_* stuff. This could make for a good example in the documentation, 
anyways, if it works as hoped.)

Attached is the stripped-down source.

J


Jason Greene wrote:

> 
> The correct behavior that is consistent with the API follows(that I am
> planning):
> Set retval of socket_select() to be the number of file descriptors
> available. If error occurs set to false.
> 
> Using the c-api one commonly writes code like this
> --
> Error on an actual error or no sockets available:
> 
> ret=select(rfds, NULL, NULL, &tv);
> if (ret < 0)
>error_func();
> 
> Error differently:
> 
> ret=select(rfds, NULL, NULL, &tv);
> if (ret == -1)
> error_sys();
> if (ret == 0)
> error_noavail();
> 
> 
> The equiv in php using false:
> --
> 
> Error on an actual error or no sockets available:
> 
> $ret=socket_select($rfds, NULL, NULL, 1);
> if (ret == 0)
>error_func();
> 
> Error differently:
> 
> $ret=socket_select($rfds, NULL, NULL, 1);
> if (ret === FALSE)
>error_sys();
> if (ret === 0)
>error_noavail();
> 
> 
>> According to the man file:
>>
> 
>> (Although without the functions equivalent
>> to the FD_* macros', the extension as a whole is getting pretty far
>> removed from the standard sockets library as it is.)
>> 
>> J
> 
> Yes, the goal is to follow a more php like behavior. Those who follow
> the C-API will have some slight adjusting to, but the beauty of the
> high-level language is that we can automate and simplify the
> functionality.
> 
> This also makes it easier for people who don't know C to pickup the
> functionality.
> 
> -Jason
>> --
>> 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] Socket Rework Complete

[J Smith]

I don't think that's a hot idea. The return value of select() is an int for 
reason and not merely true or false. It's supposed to return the number of 
file descriptors that are ready for reading, writing or exceptions. 
According to the man file:

"On success, select and pselect return the number of descriptors contained 
in the descriptor sets, which may be zero if  the  timeout expires before 
anything interesting happens.  On error, -1 is returned, and errno is set 
appropriately; the sets and timeout become undefined, so do not rely on 
their contents after an error."

Returning true or false probably isn't a good idea -- how are you supposed 
to know how many file descriptors are available if the answer is either 1 
or 0?

Another function may be needed that can take a peek at the number of ready 
file descriptors if you really want socket_select() to return true/false. 
I'm thinking that this functionality is a bit too far removed from the 
standard select() call, though. (Although without the functions equivalent 
to the FD_* macros', the extension as a whole is getting pretty far removed 
from the standard sockets library as it is.)

J


Jason Greene wrote:

>> 
>> The way I would go about fixing it would be to change socket_select() to
>> return true or false, and if there was an error (as indicated by retval),
>> store errno somewhere and let socket_last_error()/socket_clear_error()
>> retrieve that value if there isn't a socket specified.
> 
> I agree with this approach, however, IMO this is a functionality
> enhancement (soring a global last error), and probably should wait till
> 4.3.0.
> 
> Thoughts anyone?
> 


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

[PHP-DEV] Re: Socket Rework Complete

[J Smith]

Slight correction -- the fix is actually something more like this (at least 
currently):

If the user passes "null" for the sec argument, pass NULL to select() for 
tv. I think it would probably be better to handle it with the following 
conditions:

1. if the user passes null for both sec AND usec, pass NULL to select(). 
However, if either are non-null values, set tv.sec and tv.usec accordingly. 
This is to account for the unlikely event where the user wants to determine 
sec and usec dynamically. This way, they can also pass NULL for sec and a 
value for usec and still have the non-blocking call based on usec, while 
passing 0 for sec.

2. if the user passes null for sec and leaves off the usec argument, pass 
NULL to select(). This is sort of how the original worked, but if you 
passed null for sec and a proper value for usec, usec wouldn't be used and 
NULL would still be passed to select(). The above case would handle this, 
as usec could still be used.

3. if the user leaves off both sec and usec, pass NULL to select().

That would seem to be a bit more friendly than the current 4.1.2 behaviour, 
and would account for passing null as sec and a value for usec.

J



J Smith wrote:

> 
> I think I see bug number 1...
> 
> The system call for select() you to perform an indefinite blocking call if
> you pass NULL as tv, but PHP's socket_select() doesn't seem to have that
> feature. (It did in previous versions, from sometime in 4.0.7dev and up. I
> caught that bug originally, actually.)
> 
> The old fix is still a valid one -- if the user doesn't pass arguments sec
> and usec, pass NULL as the tv argument to the system select() call. I've
> implemented it in last night's snapshot and it seems to work fine.
> (Although I'm having a bitch re-writing our sockets stuff -- I have no
> idea how to use the arrays yet versus the file descriptors, but I'll
> report as I go.)
> 
> J
> 


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

[PHP-DEV] Re: Socket Rework Complete

[J Smith]

I think I see bug number 1...

The system call for select() you to perform an indefinite blocking call if 
you pass NULL as tv, but PHP's socket_select() doesn't seem to have that 
feature. (It did in previous versions, from sometime in 4.0.7dev and up. I 
caught that bug originally, actually.)

The old fix is still a valid one -- if the user doesn't pass arguments sec 
and usec, pass NULL as the tv argument to the system select() call. I've 
implemented it in last night's snapshot and it seems to work fine. 
(Although I'm having a bitch re-writing our sockets stuff -- I have no idea 
how to use the arrays yet versus the file descriptors, but I'll report as I 
go.)

J


Jason Greene wrote:

> For all those who don't follow CVS. The sockets extension modifications
> I listed out a few weeks ago are complete, and will be included in the
> 4.2.0 release.
> 
> The extension will still be marked as experimental; however, if 4.2.0
> goes well, and there are few bugs, perhaps it can be marked as stable by
> 4.3.0.
> 
> I ask all those that use the sockets extension try and get any bug
> reports to me before RC1 closes (That way the fixes will make 4.2.0).
> Also, between 4.2.0 and 4.3.0 would be a good time frame to suggest
> behavior changes because once the extension is marked stable, these will
> be a lot tougher to put through.
> 
> 
> Thanks,
> 
> -Jason
> 
> 
> 


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

Re: [PHP-DEV] New Module

[J Smith]

Not yet, as it is still in the early, early stages. I need to get an idea 
as to how the class hierarchy is going to look first, and get used to 
working with Crypto++ (which seems quite easy -- I'm not having any major 
problems yet, although for the time being I'm just dealing with fixed-size 
block ciphers, so things might get harder eventually -- can't wait to try 
the symetric stream ciphers.)

I doubt I'll go the sourceforge route, as this is being done for my actual 
work. We rely on a lot of free software and open source tools for our 
business, so when we can give something back to the community, we try to. 
(So far, we've only released two small PHP extensions, but there's more 
forthcoming, including this crypto extension if I ever get it done.)

J


Brent R. Matzelle wrote:

> --- J Smith <[EMAIL PROTECTED]> wrote:
>> I have no idea of how much longer I'll be working on the extension
>> as I
>> have a ton of other stuff to do, but I'll keep plugging away at it.
>> No idea
>> what kind of timeframe I'm looking at, or even if I'll finish it,
>> just
>> thought I'd mention that there is a bit of work being done on a
>> cross-platform crypto extension for PHP.
> 
> Crypto++ is exactly the project from which I was hoping someone would
> build a PHP extension.  Have you considered posting the project on
> Sourceforge or some other site with CVS so that others might help you
> out?
> 
> Brent
> 



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

RE: [PHP-DEV] New Module

[J Smith]

That's would be ideal. 

I've never worked with Crypto++ before or with heavy duty crypto libraries 
in general, and I was kind of delegated to take on the project at work, so 
I'm kind of stuck. And the only reason I started the project up was because 
libmcrypt/libmhash don't work too well under Windows, and we needed 
something as portable as possible.

I haven't written up any plans for how the extension would work, but I'd 
like to keep it as simple as possible. I'm just kind of tooling around 
right now, but basically, it's just the Crypto++ API wrapped in a couple of 
extra classes, which will then provide interfaces to PHP's C code. Right 
now, you can code something like this in C++ using the wrapper classes:

JBlowfish myBlowfish;

/* create an IV with a length of 128 random characters from /dev/urandom,
   or the standard rand() function if your OS doesn't support urandom /*

myBlowfish.setIV(new JIV(128));
myBlowfish.setKeylength(16);
myBlowfish.setKey("this is the secret key");
myBlowfish.setPlaintext("this is secret data to encrypt");
myBlowfish.setMode(JCRYPTO_MODE_CBC);
myBlowfish.encrypt();

cout << "Ciphertext: " << myBlowfish.getCiphertext() << endl;

To decrypt the steps are similar. Of course, there are various constructors 
to cut down on the calls to member functions and stuff. (As for the "J" 
prefixed to everything, like JIV or JBlowfish, that was mostly to avoid 
confusion -- is this Crypto++'s Blowfish class, or the wrappers?) I picture 
a similar, OO interface from PHP-land. 

Writing the interface from C to C++ is going to be a major biatch. Then 
there's writing all of the other wrappers for the various ciphers (so far 
I've only done three, and just for ECB and various CBC modes). 

I can't make any promises, but hopefully I'll be able to get something 
going over the next few weeks.

J



[EMAIL PROTECTED] wrote:

> On Tue, 5 Mar 2002, Joseph Tate wrote:
> 
>> Well, J Smith has mentioned Crypto++.  I haven't looked into it, but that
>> sounds like a good little module as a substitute for mcrypt.  If he truly
>> is working on a php extension using it, then it's purely acedemic to add
>> it to your module.
> 
> IMO, if there will be an interface to crypto++ it should be merged into
> the current mcrypt one, forming together a new combined module. (Just like
> Sterling is trying to do for XSLT).
> 
> Derick
> 


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

Re: [PHP-DEV] New Module

[J Smith]

I hesitate to mention this because I don't want to get stuck in a corner 
here, but I've been working on and off on a PHP encryption extension for 
precisely the reasons you mention. I'm using Crypto++, a public domain 
crypto library written in C++. 

A few months back, I was faced with a somewhat similar situation as yours. 
Basically, I working on getting PHP to produce ciphertext that was 
compatible with Microsoft's Crypto API for Windows. Unfortunately, the API 
uses a bunch of non-standard ASNs and such (naturally) so incompatibility 
forced me to look into other crypto libraries. Basically, I was trying to 
secure Windows Media Services without having to shell out for full-on DRM 
by passing encrypted timestamps embedded in URLs from PHP to WMS. The goal 
was to prevent users from posting links and such to the video server, as 
they wouldn't get anywhere because the URLs would only work within a 
certain timeframe, hence the encrypted timestamps. 

Naturally, mcrypt couldn't produce anything remotely compatible with the 
non-standard MS crypto API. So I was off to find something I could wrap in 
a PHP extension and use in a WMS plugin. Crypto++ seemed like a good 
choice, as it compiles fine on UNIX-y systems as well as win32. (And 
without the need for cygwin, which was a key factor.)

Right now, that project is kind of on the backburner, but I have a bit of a 
framework going now, so it's coming along. All I've done so far is wrap a 
couple of extra C++ classes around Crypto++ to make it a bit easier to use, 
which will then have interfaces to the C code in the PHP engine. I have a 
number of cipher algorithms working so far, such as Rijndael, blowfish and 
three way, and have a number of cipher modes working. (ECB, padded CBC, 
etc.)

I have no idea of how much longer I'll be working on the extension as I 
have a ton of other stuff to do, but I'll keep plugging away at it. No idea 
what kind of timeframe I'm looking at, or even if I'll finish it, just 
thought I'd mention that there is a bit of work being done on a 
cross-platform crypto extension for PHP.

J




Brent R. Matzelle wrote:

> --- [EMAIL PROTECTED] wrote:
>> Hey,
>> 
>> why not simply use the mcrypt functions available in PHP?
> 
> I will tell you why.  Mcrypt is nearly useless for developers like
> myself who develop PHP applications for both *NIX and win32
> platforms.  The mcrypt libraries are not distributed with the Windows
> binaries package and I have tried to build them myself only to find
> that you need Cygwin, which is an unacceptable dependency.
> 
> I have been looking for months for a standard method to perform
> encryption with PHP and have only found php_blowfish
> (http://www.brisse.dk/linux/phpext/blowfish.htm) as a reasonable
> alternative that runs on both *NIX and win32 without many problems.
> Unfortunately this module is not distributed with PHP so I am nervous
> basing my software on it.
> 
> I require two way encryption so that I can store passwords in a
> database to prevent unscrupulous database administrators from
> stealing them so it is extremely important to my business.
> 
> If anyone has any input on this issue I would be delighted to hear
> it.
> 
> Warm regards,
> 
> Brent
> 


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

[PHP-DEV] Re: PHP 5 Features

[J Smith]

I doubt you're going to get a really good answer for this question because

1. PHP 5.0 isn't out yet and won't be out for a while. (Not until Zend 
Engine 2.0 is done, I'd assume.)

2. This is a PHP development group, so do you really think you're going to 
get an unbaised answer here? Would you ask a Microsoft representative 
whether or not Windows XP is better than linux? 

J


Michael Heuberger wrote:

> Hi
> 
> I'd like to have a look on the new features in PHP 5.0 because I need to
> evaluate different technologies for a new big website.
> 
> I ask: PHP 5.0 or JSP, what's better?
> 
> Can you give me some information, links or documents?
> 
> Thank you!
> 
>  - Mickey from Switzerland
> 
> ---
> Dipl. Ing. Inf. Michael Heuberger
> SoftCon Informatik AG
> Dufourstrasse 185a
> CH - 8008 Zürich
> Fax   +41 1 388 71 22
> 
> www.softcon.ch
> mailto:[EMAIL PROTECTED]
> 
> This e-mail and any attachments are confidential and contains information
> that may be privileged or otherwise protected from disclosure. If you are
> not the intended recipient, you should not disseminate, distribute, copy
> or otherwise make use of this e-mail. Please notify the sender immediately
> by e-mail, if you have received this e-mail by mistake and delete this
> e-mail from your system. We undertake every effort to keep our network
> free from viruses. Please do nonetheless verify that this email and any
> attachments are free of viruses. We do not take responsibility for any
> computer virus which might be transferred by way of this e-mail. By
> sending me/us messages through e-mail, you agree to correspond by e-mail
> in the relevant matter.


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

[PHP-DEV] Re: PHP Dev

[J Smith]

PHP runs on top of the Zend engine, which is basically a scripting engine. 
They also have a bunch of PHP development tools.

J


Ray Hunter wrote:

> What role does zend have in the development of PHP?
> 
> 
> Ray Hunter
> Firmware Engineer
> 
> ENTERASYS NETWORKS
> 
> Phone:801 887-9888
> Fax:  801 972-5789
> Email:[EMAIL PROTECTED] 
> www:  www.enterasys.com 


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

Re: [PHP-DEV] Re: Sockets Extension Rework (API, etc...) VERY LONG

[J Smith]

Coo. I never really got into the rationale behind the C API, all that 
kernel optimization, which is interesting. I haven't had any problems yet 
with fd_clear, but I don't use it intensely. (Once, maybe twice in a 
script.)

Anyways, anything that will make the extension better is a good thing. (I'm 
just glad it won't take much to fix existing code to work with the changes.)

J
 

Jason Greene wrote:
> 
> 
> Well, since you know the C-API, lets look at if from the C socket API
> perspective. select() is designed to take 3 arrays. The problem with
> arrays is that they take up memory and processing time. In application
> space this really isn't a problem, but in the kernel, every saved byte
> counts. To optimize this they emulated arrays using bit masks. Another
> optimization they performed is to have you pass the highest file
> descriptor + 1 into select. (that way they only process part of the bit
> mask.)
> 
> 
> What I am getting at, is that FD_* was an interface designed strictly
> for kernel performance. Direct manipulation of these low level values
> does not really belong in a high-level language.
> 
> The method that makes the most sense is to use php arrays in place of
> the fd masks. Everything would work exactly the same, except it would be
> much easier to interface, it would be less buggy, and require less code.
> 
> By the way, the bug with the socket_fd_functions, is that it may set
> your maximum file descriptor incorrectly, and this would cause you to
> miss events occurring on ready sockets. (This occurs anytime you call
> socket_fd_clear() on a socket, or if you don't add sockets in order they
> were opened ex. 3, 1, 2 will cause you to lose file descriptor 3.
> 
> 
> example
> 
> 
>  
> // ...
> 
> $read_flds=array($socket1, $socket2, $socket3, $socket4, $socket5);
> $write_flds=array($socket6, $socket7, $socket8);
> $except_flds=array($socket9);
> 
> 
> // Wait on sockets specified in arrays, and modify them to contain
> // sockets that are ready
> $retval = socket_select($read_flds, $write_flds, $except_flds, 1);
> 
> //Perform actions on sockets waiting to be read
> foreach($read_flds as $read_sock)
> perform_read_action($read_sock);
> 
> //Perform actions on sockets waiting to be written
> foreach($write_flds as $write_sock)
> perform_write_action($write_sock);
> 
> //Perform actions on exceptions
> foreach($except_flds as $except_sock)
> process_exception($except_sock);
> 
> 
> // ...
> 
> ?>
> 
>  
> I would like to see this extension become stable so that people can
> start relying on somewhat frozen behavior.
> 
> To answer your question It should be pretty easy to port your code to
> the newer API.
>  
> 
> I appreciate hearing concerns like this, and I hope you and others
> continue to speak up. : )
> 
> -Jason
> 


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

[PHP-DEV] Re: Sockets Extension Rework (API, etc...) VERY LONG

[J Smith]

I'm all for fixing this extension up to make it better, but I'm a little 
concerned with totally dropping the fd_* functions. How would you mimic 
their use in something like a multiplexing using a blocking call situation 
after the change? I have no idea how it can be done without using the fd_* 
function. (But then again, I'm used to using the FD_* macros in C, so maybe 
there's better way in PHP.)

Just wondering, because I acutally use this extension in a multiplexing 
kind of way with indefinite socket_select blocking and multiple clients and 
all that jazz already. Yeah, I know it's experimental and stuff, but it has 
yet to fail, even with my "daemon" script running for weeks on end under a 
fair load. I use the socket functions in a search engine that's constantly 
listening for connections using socket_select, and the socket_fd* functions 
are used quite a bit, hence my concern. (Not that I'm adverse to the 
change, 'cause I'm sure I'll cope, but I'd like to know if it will be 
possible to port my existing stuff over to the new API.)

J


Jason Greene wrote:

> 
> 2. Get rid of socket_fd_*.
> -
> 
> It makes little sense to make fd masks available to the user, because
> this can be much easier to handle by using arrays.
> 
> This will fix the max_fd code that attempts to calculate the highest
> file descriptor in the fd_set.
> 
> Select would then look like
> socket_select (array read_socks(), array write_socks(), array
> except_socks(), int tv_sec, int uv_sec)
> 


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

Re: [PHP-DEV] CLI and php.ini

[J Smith]

To a certain extent, but it doesn't work well at all. And it isn't portable.

For instance, when I use this on my machine (linux, 2.4.9 kernel)

#!/usr/local/bin/php -c /path/to/ini -q

The path is set to " /path/to/ini -q", with a leading space and the -q. If 
I try this:

#!/usr/local/bin/php -q -c /path/to/ini

PHP won't run at all, and spits out error messages about options not being 
found. 

#!/usr/local/bin/php -c/path/to/ini

This actually works. The leading space is removed, and there's no trailing 
options.

On FreeBSD, the problem doesn't occur at all. The first example works right 
away.

This is mostly due to a lack of standardization as to how the #! magic 
token works. On FreeBSD, the kernel passes the arguments as if you ran the 
script from a shell, i.e. the first example is passed as

argv[0] -- php
argv[1] -- -c
argv[2] -- /path/to/ini
argv[3] -- -q
argv[4] -- scriptname.php

However, on linux, the arguments are passed as

argv[0] -- php
argv[1] -- -c /path/to/ini -q
argv[2] -- scriptname.php

It's different across many unices. Some allow a few thousand characters in 
the magic string; others allow only 30.

This was a thread about this a while back, it should be in the archives.

J



Brad Lafountain wrote:

> 
> The magic
> #!/usr/local/bin/php -c local.ini
> already works
> 
> 


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

[PHP-DEV] CLI and php.ini

[J Smith]

>From what I understand, starting with PHP 4.2.x, PHP is going to 
automatically build with a CLI executable by default. This means that even 
when you install as, say, an Apache SAPI module, you're still going to get 
the CLI, correct?

That being the case, a few months ago a thread popped up about seperating 
the php.ini files that web server modules and the CLI executable run on. 
Has there been any more thought on this? 

The differences between the CLI executable and web server modules can be 
drastic enough to warrant this sort of thing, imho. I regularly build both 
the executable and web server modules all the time on the same machine, and 
having them both point to the same php.ini can sometimes cause havoc, as 
usually they're not configured anything alike. (For instance, I usually use 
output buffering for the web server configuration, but not for the CLI.) 

I've also run into problems with a few extensions that don't run with 
things like the Zend optimizer. (PCNTL comes to mind -- obviously it's only 
useful in the CLI executable, but the Zend optimizer refuses to work with 
it at all, yet I still want to use it on the web server -- thus requiring 
seperate php.ini configurations.)

I know that you can set PHPRC to another path before starting PHP up, 
either as CLI or from a web server, but it's quite a pain. There are also a 
few other work arounds, like the magic "#!" token at the beginning of shell 
scripts (which isn't at all portable), but I'm still thinking the best 
solution would be to split the php.ini files in two -- one for the web 
server SAPI and one for the CLI. Call them php.ini and php-cli.ini or 
something.

Or am I just crazy?

J



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

[PHP-DEV] Re: Extension format (fwd)

[J Smith]

Look at README.EXTENSIONS in the top level of the PHP source. 

Basically, the zend_module_entry was changed a bit. That's about it.

J


David Croft wrote:

> 
> Could someone please update me on what needs to be changed to make an
> 4.0.6 extension function on 4.1.1?
> 
> Thanks.
> 


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

[PHP-DEV] Re: Constants

[J Smith]

I think it's 2^31 because that's 2147483648, the largest value available 
for a long signed int in ANSI C.I t's also the value of RAND_MAX in 
stdlib.h on many systems. (It is on my system at any rate, linux using 
glibc.)

J



Evan Nemerson wrote:

> I was thinking about putting together a list of constants, their purpose,
> what version of PHP they initially appeared in, etc.
> 
> So far, I have figured out a function called "REGISTER_LONG_CONSTANT" is
> used, or a constant is defined in the source with a name that has a
> preceeding "PHP_" (eg "PHP_RAND_MAX"- which is 2^31??? why not 2^32? sorry
> off the point.) Are there any other ways? Are these ways inaccurate?
> 
> Please reply to my e-mail address ([EMAIL PROTECTED]). I don't
> subscribe to this list.
> 
> 
> Evan Nemerson


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

RE: [PHP-DEV] New extension: stem

[J Smith]

It's a great little tool if you're into search engines and that sort of 
thing, as word stemming has been quite a useful tool in the field of 
information retrieval. (Actually, I've built a search engine at work, which 
used an earlier stemmer I wrote based on Porter's original article using 
regexes and such. It could only handle English, so after looking at 
snowball, I decided to expand our search engine's capabilities a bit, hence 
the new extension.)

The number of languages that can be supported is pretty much wide open. All 
someone would need to do is write a stemmer in Snowball, add the ANSI C it 
outputs to the extension and add a few constants and a line or two of code 
to the extension itself. I haven't looked around for any other languages 
besides those found on the Snowball site, which are all under BSD-like 
licenses, although I'm sure there are more out there. Anybody who finds a 
new one should let me know.

I haven't really looked at PECL, but after reading a bit on it, that's 
probably where this extension should go. If I'm understanding the terms of 
the licenses allowed in PECL, any OSS license will do, so I'm thinking BSD 
license, just to follow the Snowball license.

I'll clean the extension up a bit and offer it to the library.

J
 


James Cox wrote:

> well, this definitely looks cool, from a language point of view.
> 
> i would go for new_stem or such like, and expect the language to be
> determined as a variable.
> 
> I hope this allows for more work on various language features... perhaps
> you'd want to spend time looking at what else is available.
> 
> one final note, is that you may wish to put this in the PEAR PECL library,
> since it's a: a pretty exclusive extension, and b: that's where it should
> go. :)
> 
> James
> 


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

Re: [PHP-DEV] New extension: stem

[J Smith]

I know no German at all besides what I've been able to learn from 
Wolfenstein 3D. I just cut and pasted a random word from the snowball site 
into the script. Naturally, I took what was probably the only misspelled 
one in the list.

J


Sebastian Bergmann wrote:

> J Smith wrote:
>> echo "German: aufeinanderschlügen -> " . stem("aufeinanderschlügen",
>> STEM_GERMAN) . "\n";
> 
>   The 'ü' should be 'a'. Hm, just curious :-)
> 


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

[PHP-DEV] New extension: stem

[J Smith]

Greetings.

A few months ago, I mentioned that I had written a PHP extension that 
provided English language suffix stemming using a "Porter stemmer", an 
algorithm devised by Dr. Martin Porter for stripping the suffix (or 
suffixes) off of an English word. 

After a mention in the PHP weekly summary, I received a few emails 
expressing some interest. I decided to go back to the drawing board and 
redo the extension, adding a lot of functionality. Namely, I've added a 
bunch of languages.

After reading about Dr. Porter's latest stemming adventure, Snowball, I 
decided that the logical course would be to build an extension around 
Snowball. Snowball (see http://snowball.sourceforge.net) is essentially a 
string parsing language that parses a file describing a stemming algorithm 
and then spits out the equivalent C code. 

Although I have no idea how to write a stemmer in Snowball, I do know C and 
PHP, so I've taken the stemmers available at Dr. Porter's site and wrote a 
PHP extension around them. The stemmers, and Snowball itself, are all 
covered under a BSD-like license, so I figured they'd be a good fit with 
PHP.

Anyways, here's the basic synopsis of the extension:

Stemmers can be called in one of two manners. 

string stem(string wordToStem [, int language)
string stem_LANGUAGE(string wordToStem)

I'm not sure which is preferred, so for the time being, either can be used. 
In the first form, language is one of:

STEM_PORTER -- the original Porter stemmer
STEM_ENGLISH -- an improved English stemmer
STEM_FRENCH
STEM_SPANISH
STEM_DUTCH
STEM_DANISH
STEM_GERMAN
STEM_ITALIAN
STEM_NORWEGIAN
STEM_PORTUGUESE
STEM_RUSSIAN
STEM_SWEDISH

By default, STEM_PORTER is used.

In the second form, LANGAUGE is one of the aforementioned languages, 
without the STEM_, i.e. stem_french(), stem_spanish(), etc. 

I'll likely add aliases like "STEM_FRANCAIS", "STEM_ESPANOL", etc.

On success, stem() or stem_LANGAUGE() return the word without it's suffix. 
On error, E_NOTICE will be raised, and the function will return false.

Each stemmer uses standard latin encodings, except for the Russian stemmer, 
which uses Cyrillic KO18-R encoding.

A quick demonstration (minus the Russian stemmer, 'cause the encoding might 
screw up this post):

 " . 
stem("assassinations") . "\n";
echo "English: devestating -> " . stem("devestating", STEM_ENGLISH) . "\n";
echo "French: majestueusement -> " . stem("majestueusement", STEM_FRENCH) 
. "\n";
echo "Spanish: chicharrones -> " . stem("chicharrones", STEM_SPANISH) . 
"\n";
echo "Dutch: lichamelijkheden -> " . stem("lichamelijkheden", STEM_DUTCH) 
. "\n";
echo "German: aufeinanderschlügen -> " . stem("aufeinanderschlügen", 
STEM_GERMAN) . "\n";
echo "Italian: pronunciamento -> " . stem("pronunciamento", STEM_ITALIAN) 
. "\n";
echo "Norwegian: havnemyndighetene -> " . stem("havnemyndighetene", 
STEM_NORWEGIAN) . "\n";
echo "Portuguese: quilométricas -> " . stem("quilométricas", 
STEM_PORTUGUESE) . "\n";
echo "Swedish: klostergården -> " . stem("klostergården", STEM_SWEDISH) . 
"\n";

?>

Output:

Original porter (default): assassinations -> assassin
English: devestating -> devest
French: majestueusement -> majestu
Spanish: chicharrones -> chicharron
Dutch: lichamelijkheden -> licham
German: aufeinanderschlügen -> aufeinanderschlüg
Italian: pronunciamento -> pronunc
Norwegian: havnemyndighetene -> havnemyndighet
Portuguese: quilométricas -> quilométr
Swedish: klostergården -> klostergård


Case is sensitive at the moment, but only on a suffix. Words should be sent 
to the functions in lower-case. (I.e., AsSaSSinations stems to "AsSaSSin", 
while "assassinaTions" stems to "assassinaTion".)

If there's any interest in the extension for either personal use or as an 
addition to PHP itself (or any general comments, questions or suggestions) 
let me know.

J



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

[PHP-DEV] Re: Bug #15283: Not a bug, just a suggestion.

[J Smith]

"Feature Request" is in the "Type of Bug" drop-down list. It's the third 
item.

You'd have to use OpenSSH/SSH for secure FTP, I would think, not OpenSSL. 

Don't know how hard it would be to implement. (Never worked much with the 
OpenSSH library, although I use SSH/sftp/scp all the time.) I'm thinking it 
would be better to have a seperate extension for it, though, rather than 
implement it in conjunction with the standard ftp functions, because 
they're different enough to warrant it.

J


[EMAIL PROTECTED] wrote:

> From: [EMAIL PROTECTED]
> Operating system: NA
> PHP version:  4.1.0
> PHP Bug Type: Unknown/Other Function
> Bug description:  Not a bug, just a suggestion.
> 
> Well... I was trying to get to the "request a new feature or language
> change" but I believe that just links to this bugs page anyways, so sorry
> if this is being directed to the wrong person.
> 
> Anyway, Im trying to implement Secure FTP through PHP with OpenSSL without
> much luck. It would be cool if this was added to the "ftp_connect"
> function call as an argument (0 for regular ftp, 1 for SSL). That would
> make it really easy.
> 
> Just a suggestion though, for all I know it might already be as easy as
> that and Im just too dense to figure it out.


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

[PHP-DEV] Re: Bug #15203: ereg_replace fails on strings containing backslashes

[J Smith]

While I did reproduce this on a linux system (2.4.9 kernel) with PHP 4.1.1, 
the goal of the script doesn't seem to match the description -- the regexes 
are looking to replace four backslashes with two, not two backslashes with 
one. (Unless you're not counting that two backslashes are actually seen as 
a single backslash because they're being escaped.)

I did notice something odd, though. I wrote a similar script in Perl to see 
if preg_replace was acting properly, 'cause it seemed a little wonky. It 
seems the ereg is acting correctly (obviously -- it's not going to match 
four (escaped) backslashes to a string of two backslashes. However, the 
preg_replace is acting weird -- why is it matching a string of two 
backslashes to a regex containing four? The Perl script that this should be 
equivalent to is something like

$d = "";
print "--$d--" . length($d) . "\n";
$d =~ s///;
print "--$d--" . length($d) . "\n";

Which spits out 

--\\--2
--\\--2

which matches the ereg_replace as expected, but not the preg_replace.

So I guess there is a bug there, just not with ereg_replace, but with 
preg_replace.

J



Josef Svoboda wrote:

> From: [EMAIL PROTECTED]
> Operating system: FreeBSD 4.2
> PHP version:  4.0.5
> PHP Bug Type: POSIX related
> Bug description:  ereg_replace fails on strings containing backslashes
> 
> The goal is to replace sequence of two backslashes in $text by one
> backslash. While preg_replace works, ereg_replace does not make any change
> to $text.
> 
> 
> echo "preg_replace\n";
> $text="";
> echo "--".$text."--".strlen($text)."\n";
> $text=preg_replace( "//", "", $text);
> echo "--".$text."--".strlen($text)."\n";
> echo "\n";
> echo "ereg_replace\n";
> $text="";
> echo "--".$text."--".strlen($text)."\n";
> $text=ereg_replace( "", "", $text);
> echo "--".$text."--".strlen($text)."\n";
> 
> 
> ./configure \
> --with-mysql=/usr/local/mysql \
> --with-imap=/usr/ports/new/imap \
> --enable-track-vars \
> --enable-trans-sid
> 
> 


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

[PHP-DEV] Re: PHP Documentation

[J Smith]

The PHP documentation is already available in Windows help format. (The new 
HTML-ish kind, I believe.) See http://www.php.net/download-docs.php.

J


Emanuel Dejanu wrote:

> 
> Hi,
> 
> Do you know how can I ($PHP_SELF :) compile the
> PHP documentation in Windows HTML Help format?
> Any guide line?
> 
> Best regards,
> 
> Emanuel Dejanu


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

[PHP-DEV] Re: Bug #14930 Updated: CLI header suppression problems

[J Smith]

The second work around seems to work fine, but the first one has problems 
The php.ini override path is set to "c /some/path" if you try "-qc 
/some/path" -- seems to like adding that c option in with the path for 
whatever reason. (The problem is likely in ap_php_getopt(), but I haven't 
really looked into it yet.) 

Setting PHPRC seems to be the best solution for the time being, but I'm at 
least somewhat confident that if Perl can get it working at least to some 
extent, PHP should be able to, too. (I kind-of-almost-sort-of got it 
kind-of-sort-of working to some extent, at least with my OS and setup, and 
maybe a patch will be on it's way Real Soon Now, maybe. But if I can't get 
it to be portable, beyond my machine, it's not much good, is it...)

J



[EMAIL PROTECTED] wrote:

> ID: 14930
> Updated by: edink
> Reported By: [EMAIL PROTECTED]
> Old Status: Analyzed
> Status: Closed
> Bug Type: Output Control
> Operating System: linux 2.4.9
> PHP Version: 4.1.1
> New Comment:
> 
> After some research on the subject I found out
> that there is no good and
> portable way of solving this. Some unix systems
> simply allow only one argument in the #! line. One
> of those systems is Linux. Some others limit the
> line length to 32 characters.
> 
> For a good description of these limitations see
> 
http://groups.google.com/groups?q=shell+limit+one+argument&hl=en&selm=qij4tk2zgp9.fsf%40lambda.ai.mit.edu&rnum=7
> 
> Workarounds:
> * You can put all the options that do not require
>   parameters as one, for example -qC
> * Use PHPRC env variable to set the php.ini path
> 


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

[PHP-DEV] Re: Bug #14930 Updated: CLI header suppression problems

[J Smith]

I've been looking at the source code for Perl and comparing how it reads 
arguments versus PHP's method, and it seems to be expected behaviour, as 
Perl handles the arguments as edink has shown below. 

As to why this behaviour is such, I'm at a loss. You'd think that the 
behaviour would try to match starting up a process from a shell, i.e. 
having a whole array of arguments in argv rather than having everything 
mashed into argv[1]. Maybe it's a POSIX thing or something?

J



[EMAIL PROTECTED] wrote:

> ID: 14930
> Updated by: elixer
> Reported By: [EMAIL PROTECTED]
> Status: Analyzed
> Bug Type: Output Control
> Operating System: linux 2.4.9
> PHP Version: 4.1.1
> New Comment:
> 
> I don't think this is a glibc issue.  Its (AFAIK) the kernel's
> responsibility to set this stuff up.  Take a look at load_script() in
> fs/binfmt_script.c of the linux source.  It seems that only one argument
> is allowed, and everything after the interpreter (/usr/local/bin/php) up
> until the EOL is considered one argument.  I'm sure there is a reason
> for implementing it this way, I just don't know what it is.
> 
> Sean
> 
> 
> Previous Comments:
> 
> 
> [2002-01-08 19:29:05] [EMAIL PROTECTED]
> 
> I was able to reproduce this. However it does not appear
> to be a php bug. Most likely a glibc bug.
> 
> If I put this line on top of my script:
> #!/usr/bin/php -q -c /path/to/ini/file -C
> 
> the following values get passed to
> php's main() function.
> 
> argc=3
> argv[0]: php
> argv[1]: -q -c /path/to/ini/file -C
> argv[2]: ./test (which is the name of the script)
> 
> With parameters passed like that, php has
> no chance of passing them correctly.
> 
> FreeBSD systems appear to be free of this problem.
> 
> 


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

[PHP-DEV] Re: Bug #14930 Updated: CLI header suppression problems

[J Smith]

Ack, didn't mean to hit that send button yet!

I wrote this while experimenting, and it seems that just when I thought I 
had it, I didn't, of course, but I sent this to the list anyways, 
accidentally. 

At first I thought I was golden, because my little fix did work... so long 
as you didn't have anything after your -c argument. Of course, try doing 
something like this:

#!/usr/local/bin/php -c /some/path -q

And your script dies, or at least it can't find the php.ini file, because 
it thinks that the path should be "-c /some/path -q". Argh.

Let me get back on this in a bit, I'll fix it next time, really.

J



J Smith wrote:

> 
> Here's what I can tell so far:
> 
> the arguments do get passed to cgi_main.c's main() function just fine, and
> the arguments are even parsed okay. The problem seems to occur because
> when the arguments are parsed from a script like so:
> 
> #!/usr/bin/php -c /path/to/ini/file
>  ...
> ?>
> 
> it seems that there's at least one leading space in the argument to the -c
> option, i.e. in sapi/cgi/cgi_main.c, cgi_sapi_module.php_ini_path_override
> is set to " /path/to/ini/file" instead of "/path/to/ini/file". This in
> turn ends up confusing php_init_config() in main/php_ini.c, and although
> it will return SUCCESS (as the file isn't found thanks to the leading
> spaces), which is okay because the defaults are used instead, and no
> warning or error is given about not being able to find php.ini in "
> /path/to/ini/file".
> 
> I didn't catch this until about an hour ago, but all of my CLI PHP scripts
> were relying on default settings rather than the ones I had set in
> "/usr/local/zend/etc/cli/php.ini", or as far as php_init_config() was
> concerned, said file with a leading space.
> 
> A quick fix for the problem would be to trim off those leading spaces to
> the argument to -c, but I'm not sure if that wouldn't cause more problems
> in the long run. For instance, is it possible to have leading spaces in
> directory names on some operating systems? It's not a problem for me, and
> it probably wouldn't be a huge problem overall, but if there's a chance
> guaranteed it will affect somebody.
> 
> Anyways, quick solution, very in-elegant and probably not very safe (but
> it worked, so at least it proves I'm somewhat right on this) was to stick
> the following bit of code (my additions prefixed with >):
> 
>   if (php_ini_path_override) {
>   php_ini_search_path = php_ini_path_override;
>> while (php_ini_search_path[0] == ' ') {
>> for (i = 0; i < strlen(php_ini_search_path); i++) {
>> php_ini_search_path[i] = php_ini_search_path[i + 1];
>> }
>> }
>   free_ini_search_path = 0;
>   }
> 
> in main/php_ini.c. Strips out the leading spaces and lets my scripts work
> properly again, with the proper php.ini settings.
> 
> Comments?
> 
> J
> 
> 
> 
>

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