[PHP-DEV] PHP-4.3.0RC1 + Oracle client - SIGSERV
Hello php-dev,
OS: SuSE 7.3, Linux gap 2.4.19-rmap14a ()
Ora: 9.2.0.2.0
pre
?
$d = $u = 'si';
$p = '***';
putenv('ORACLE_SID=GAP');
$db = OCILogon($u,$p, GAP);
if ($db)
echo Connected;
else
{
echo Can not connect.;
print_r(OCIError());
}
?
#gdb sapi/cli/php
#run -f c.php
[New Thread 1024 (LWP 20609)]
pre
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 20609)]
0x40a65301 in snauca_check_adapter () from /opt/oracle/lib/libclntsh.so.9.0
(gdb) bt
#0 0x40a65301 in snauca_check_adapter () from /opt/oracle/lib/libclntsh.so.9.0
#1 0x40a63a04 in nau_viat () from /opt/oracle/lib/libclntsh.so.9.0
#2 0x40a5cc5c in nau_gettab () from /opt/oracle/lib/libclntsh.so.9.0
#3 0x40a5b2db in nau_ini () from /opt/oracle/lib/libclntsh.so.9.0
#4 0x40a50c43 in nainit () from /opt/oracle/lib/libclntsh.so.9.0
#5 0x409fd846 in nsnainit () from /opt/oracle/lib/libclntsh.so.9.0
#6 0x409f24c0 in nsopen () from /opt/oracle/lib/libclntsh.so.9.0
#7 0x409db309 in nscall1 () from /opt/oracle/lib/libclntsh.so.9.0
#8 0x409da840 in nscall () from /opt/oracle/lib/libclntsh.so.9.0
#9 0x40a0dd24 in niotns () from /opt/oracle/lib/libclntsh.so.9.0
#10 0x40a7bb59 in nigcall () from /opt/oracle/lib/libclntsh.so.9.0
#11 0x40a12ec3 in osncon () from /opt/oracle/lib/libclntsh.so.9.0
#12 0x40838553 in kpuadef () from /opt/oracle/lib/libclntsh.so.9.0
#13 0x408c7565 in upiini () from /opt/oracle/lib/libclntsh.so.9.0
#14 0x408b685b in upiah0 () from /opt/oracle/lib/libclntsh.so.9.0
#15 0x40810536 in kpuatch () from /opt/oracle/lib/libclntsh.so.9.0
#16 0x408aaaec in OCIServerAttach () from /opt/oracle/lib/libclntsh.so.9.0
#17 0x08100554 in _oci_open_server (dbname=0x83facd4 GAP, persistent=0)
at /home/work/install/php-4.3.0RC1/ext/oci8/oci8.c:2432
#18 0x08100df0 in oci_do_connect (ht=3, return_value=0x83faa54, this_ptr=0x0,
return_value_used=1, persistent=0, exclusive=0)
at /home/work/install/php-4.3.0RC1/ext/oci8/oci8.c:2588
#19 0x08105daf in zif_ocilogon (ht=3, return_value=0x83faa54, this_ptr=0x0,
return_value_used=1)
at /home/work/install/php-4.3.0RC1/ext/oci8/oci8.c:4223
#20 0x08248422 in execute (op_array=0x83f617c) at
/home/work/install/php-4.3.0RC1/Zend/zend_execute.c:1595
#21 0x08234e64 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at
/home/work/install/php-4.3.0RC1/Zend/zend.c:840
#22 0x081f872e in php_execute_script (primary_file=0xb2e0) at
/home/work/install/php-4.3.0RC1/main/main.c:1560
#23 0x0824ed27 in main (argc=3, argv=0xb364) at
/home/work/install/php-4.3.0RC1/sapi/cli/php_cli.c:711
#24 0x410767ee in __libc_start_main () from /lib/libc.so.6
Best regards,
Andrew Sitnikov
e-mail : [EMAIL PROTECTED]
GSM: (+372) 56491109
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/standard/tests/math/log.phpt coredump on Tru64
Pollita [EMAIL PROTECTED] wrote:
log(0) in any base (except 0, which would be silly) is an undefined
number.
Yes, that's what the teachers told us before they admitted the existance
of infinity.
the libc log() function will return an exceedingly small number
to avoid causing widepsread panic when log(0) is attempted
(-1.7976931348623E+308 shown below).
Are you sure?
% cat log.c
#include stdio.h
#include math.h
int main()
{
printf(%g\n,log(0));
}
% gcc log.c -o log -lm
% ./log
-inf
That's on Linux. On Tru64, it prints:
-1.79769e+308
The test function for log:
$x2 = (int) pow($base, log($x, $base));
attempts to check that $x2 is close to $x, but since log(0,*) will return
an excessively small number, pow() winds up choking.
Suggest: $x2 = (int) log(pow($x,base),$base); instead.
Thanks for the suggestion, but it dumps core nevertheless:
% sapi/cli/php -r 'echo log(pow(0,2),2),\n;'
Floating point exception (core dumped)
% sapi/cli/php -r 'echo log(0,2),\n;'
Floating point exception (core dumped)
P.S. example below using log in base 1 is also nonsensical... only
log(1,1) is a valid use of log with a base parameter of 1, any other value
results in undefined
Umm, yes, maybe - but my point was that PHP should not dump core in such
situations, and it certainly should not do so in a make test (Wait a
minute, what's that core file here? And now you want me to 'make
install'?!).
Regards...
Michael
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Break down RETR from telnet
Hi, I'm wondering how to parse the actual email message (body) from RETR in telnet, I am able to parse all the other information needed (using TOP in telnet) but cannot get the actual message... could anyone help please? Thanks for any help -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATH] update to earlier proposed patch for getanyrr()function addition
On Sun, 17 Nov 2002 [EMAIL PROTECTED] wrote: Hello, Who can commit that now? I don't think it's ready yet. I agree with Marcus that the name of the function should be different then getanyrr(), it definitely doesn't fit into the naming things we have (with that getmxrr() doesn't fit either). I also think that the selection of the type of record to fetch should be made a constant so that we don't need to strncasecmp it everytime, and I would favor an implementation with zend_parse_parameters() to get rid of the (IMO) ugly parameter handling. Also, a lot of lines don't follow coding standards, like: n = res_nmkquery(res,QUERY,Z_STRVAL_P(host),C_IN,type_to_fetch,NULL,0,NULL,buf.qb2,sizeof buf); instead of: n = res_nmkquery(res, QUERY, Z_STRVAL_P(host), C_IN, type_to_fetch, NULL, 0, NULL, buf.qb2, sizeof(buf)); And I miss autoconf checks for all those DNS functions (like res_mkquery, dn_expand) which might not exist on all platforms. regards, Derick Marcus Börger [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] Function is nice but the function name is not. Attached is a second revised patch that fixes the build problems. marcus At 00:11 17.11.2002, Pollita wrote: Per corrections suggested by [EMAIL PROTECTED], attached is a revised pacth to ext/standard/dns.c for addition of getanyrr() function. -- 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 -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] on the subject of overloading: __call()
BB related topic: in the current state of ze2, there are several ways to BB call methods directly that can't be emulated by call_user_func() - BB calling self::method() for instance, or the visibility of $this if BB you call class::method(). is that likely to stay true? Since __call is the method of the class, calling self::method can be achieved, I think. As for the second point - could you please explain furher what you mean, maybe with an example? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] GD segfault in 4.3.0RC1
When trying out the RC1 code I found that my GD test segfaults every time. I traced the problem to the fact that efree is used on memory that was allocated with strdup. See the fontlist variable in ext\gd\libgd\gdft.c:fontFetch() This started happening when gdhelpers.c was changed to use emalloc etc in r1.3. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GD segfault in 4.3.0RC1
On Sun, 17 Nov 2002, Brian Havard wrote: When trying out the RC1 code I found that my GD test segfaults every time. I traced the problem to the fact that efree is used on memory that was allocated with strdup. See the fontlist variable in ext\gd\libgd\gdft.c:fontFetch() This started happening when gdhelpers.c was changed to use emalloc etc in r1.3. Thanks, I'll check the whole source for strdup now. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GD segfault in 4.3.0RC1
On Sun, 17 Nov 2002, Derick Rethans wrote: On Sun, 17 Nov 2002, Brian Havard wrote: When trying out the RC1 code I found that my GD test segfaults every time. I traced the problem to the fact that efree is used on memory that was allocated with strdup. See the fontlist variable in ext\gd\libgd\gdft.c:fontFetch() This started happening when gdhelpers.c was changed to use emalloc etc in r1.3. Thanks, I'll check the whole source for strdup now. Okay, I committed this, but I found that some of the functions use malloc, others emalloc and more others use gdMalloc (which is a wrapper for emalloc). I don't think this is what we want, but I'm also afraid that changing everything to the gd* functions is a bad thing, as some of the structures should be persistent. regards, Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATH] update to earlier proposed patch for getanyrr() function addition
I could do the autoconf stuff and i vould go for naming all these function dns_get_xx() and such. marcus At 12:38 17.11.2002, Derick Rethans wrote: On Sun, 17 Nov 2002 [EMAIL PROTECTED] wrote: Hello, Who can commit that now? I don't think it's ready yet. I agree with Marcus that the name of the function should be different then getanyrr(), it definitely doesn't fit into the naming things we have (with that getmxrr() doesn't fit either). I also think that the selection of the type of record to fetch should be made a constant so that we don't need to strncasecmp it everytime, and I would favor an implementation with zend_parse_parameters() to get rid of the (IMO) ugly parameter handling. Also, a lot of lines don't follow coding standards, like: n = res_nmkquery(res,QUERY,Z_STRVAL_P(host),C_IN,type_to_fetch,NULL,0,NULL,buf.qb2,sizeof buf); instead of: n = res_nmkquery(res, QUERY, Z_STRVAL_P(host), C_IN, type_to_fetch, NULL, 0, NULL, buf.qb2, sizeof(buf)); And I miss autoconf checks for all those DNS functions (like res_mkquery, dn_expand) which might not exist on all platforms. regards, Derick Marcus Börger [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] Function is nice but the function name is not. Attached is a second revised patch that fixes the build problems. marcus At 00:11 17.11.2002, Pollita wrote: Per corrections suggested by [EMAIL PROTECTED], attached is a revised pacth to ext/standard/dns.c for addition of getanyrr() function. -- 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 -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- 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: Aggregation ZE2 fix
We should either commit this patch OR skipp all aggregation tests in ZE2 until we have it in. marcus At 20:16 16.11.2002, Andrei Zmievski wrote: On Sat, 16 Nov 2002, Marcus Börger wrote: With the following patch aggregation works for me with ZE1 and ZE2, php 4.3.0 and php4.4-dev. If noone objects i will commit this. Aggregation will be implemented at the engine level in ZE2. Don't commit this patch. -Andrei http://www.gravitonic.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATH] update to earlier proposed patch for getanyrr()function addition
On Sun, 17 Nov 2002, Marcus Börger wrote: I could do the autoconf stuff and i vould go for naming all these function dns_get_xx() and such. nice, but I dont think we need to introduce (about) 10 functions which do basically the same thing except for returning a different record. What I meant was something like this: dns_get_record(php.net, DNS_MX); and of course having all the other DNS_* records defined as constant in PHP. We can then also wrap the original getmxrr() function to use this new function. Derick At 12:38 17.11.2002, Derick Rethans wrote: On Sun, 17 Nov 2002 [EMAIL PROTECTED] wrote: Hello, Who can commit that now? I don't think it's ready yet. I agree with Marcus that the name of the function should be different then getanyrr(), it definitely doesn't fit into the naming things we have (with that getmxrr() doesn't fit either). I also think that the selection of the type of record to fetch should be made a constant so that we don't need to strncasecmp it everytime, and I would favor an implementation with zend_parse_parameters() to get rid of the (IMO) ugly parameter handling. Also, a lot of lines don't follow coding standards, like: n = res_nmkquery(res,QUERY,Z_STRVAL_P(host),C_IN,type_to_fetch,NULL,0,NULL,buf..qb2,sizeof buf); instead of: n = res_nmkquery(res, QUERY, Z_STRVAL_P(host), C_IN, type_to_fetch, NULL, 0, NULL, buf.qb2, sizeof(buf)); And I miss autoconf checks for all those DNS functions (like res_mkquery, dn_expand) which might not exist on all platforms. regards, Derick Marcus Börger [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] Function is nice but the function name is not. Attached is a second revised patch that fixes the build problems. marcus At 00:11 17.11.2002, Pollita wrote: Per corrections suggested by [EMAIL PROTECTED], attached is a revised pacth to ext/standard/dns.c for addition of getanyrr() function. -- 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 -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATH] update to earlier proposed patch for getanyrr() function addition
Sure but anyway we would need to review the config file if everything we need is in place. marcus At 14:54 17.11.2002, Derick Rethans wrote: On Sun, 17 Nov 2002, Marcus Börger wrote: I could do the autoconf stuff and i vould go for naming all these function dns_get_xx() and such. nice, but I dont think we need to introduce (about) 10 functions which do basically the same thing except for returning a different record. What I meant was something like this: dns_get_record(php.net, DNS_MX); and of course having all the other DNS_* records defined as constant in PHP. We can then also wrap the original getmxrr() function to use this new function. Derick At 12:38 17.11.2002, Derick Rethans wrote: On Sun, 17 Nov 2002 [EMAIL PROTECTED] wrote: Hello, Who can commit that now? I don't think it's ready yet. I agree with Marcus that the name of the function should be different then getanyrr(), it definitely doesn't fit into the naming things we have (with that getmxrr() doesn't fit either). I also think that the selection of the type of record to fetch should be made a constant so that we don't need to strncasecmp it everytime, and I would favor an implementation with zend_parse_parameters() to get rid of the (IMO) ugly parameter handling. Also, a lot of lines don't follow coding standards, like: n = res_nmkquery(res,QUERY,Z_STRVAL_P(host),C_IN,type_to_fetch,NULL,0,NULL ,buf..qb2,sizeof buf); instead of: n = res_nmkquery(res, QUERY, Z_STRVAL_P(host), C_IN, type_to_fetch, NULL, 0, NULL, buf.qb2, sizeof(buf)); And I miss autoconf checks for all those DNS functions (like res_mkquery, dn_expand) which might not exist on all platforms. regards, Derick Marcus Börger [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] Function is nice but the function name is not. Attached is a second revised patch that fixes the build problems. marcus At 00:11 17.11.2002, Pollita wrote: Per corrections suggested by [EMAIL PROTECTED], attached is a revised pacth to ext/standard/dns.c for addition of getanyrr() function. -- 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 -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATH] update to earlier proposed patch for getanyrr()function addition
On Sun, 17 Nov 2002, Marcus Börger wrote: Sure but anyway we would need to review the config file if everything we need is in place. uhm, what config file? Derick At 14:54 17.11.2002, Derick Rethans wrote: On Sun, 17 Nov 2002, Marcus Börger wrote: I could do the autoconf stuff and i vould go for naming all these function dns_get_xx() and such. nice, but I dont think we need to introduce (about) 10 functions which do basically the same thing except for returning a different record. What I meant was something like this: dns_get_record(php.net, DNS_MX); and of course having all the other DNS_* records defined as constant in PHP. We can then also wrap the original getmxrr() function to use this new function. Derick At 12:38 17.11.2002, Derick Rethans wrote: On Sun, 17 Nov 2002 [EMAIL PROTECTED] wrote: Hello, Who can commit that now? I don't think it's ready yet. I agree with Marcus that the name of the function should be different then getanyrr(), it definitely doesn't fit into the naming things we have (with that getmxrr() doesn't fit either). I also think that the selection of the type of record to fetch should be made a constant so that we don't need to strncasecmp it everytime, and I would favor an implementation with zend_parse_parameters() to get rid of the (IMO) ugly parameter handling. Also, a lot of lines don't follow coding standards, like: n = res_nmkquery(res,QUERY,Z_STRVAL_P(host),C_IN,type_to_fetch,NULL,0,NULL ,buf..qb2,sizeof buf); instead of: n = res_nmkquery(res, QUERY, Z_STRVAL_P(host), C_IN, type_to_fetch, NULL, 0, NULL, buf.qb2, sizeof(buf)); And I miss autoconf checks for all those DNS functions (like res_mkquery, dn_expand) which might not exist on all platforms. regards, Derick Marcus Börger [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] Function is nice but the function name is not. Attached is a second revised patch that fixes the build problems. marcus At 00:11 17.11.2002, Pollita wrote: Per corrections suggested by [EMAIL PROTECTED], attached is a revised pacth to ext/standard/dns.c for addition of getanyrr() function. -- 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 -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] XP?
Who says Xtreme Programming can't work over long distances.. :) iliaa Sat Nov 16 19:07:33 2002 EDT Modified files: (Branch: PHP_4_3) /php4/main streams.c Log: MFH wez Sat Nov 16 19:08:42 2002 EDT Modified files: (Branch: PHP_4_3) /php4/main streams.c Log: Remove debugging printf iliaa Sat Nov 16 19:11:20 2002 EDT Modified files: (Branch: PHP_4_3) /php4/main streams.c Log: Fix compile warning. wez Sat Nov 16 20:06:32 2002 EDT Modified files: (Branch: PHP_4_3) /php4/main streams.c Log: Avoid a potential double fclose(). -Andrei http://www.gravitonic.com/ Any sufficiently advanced bug is indistinguishable from a feature. -- Rich Kulawiec -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] XP?
Plus we were using IRC to bounce ideas off each other at the same time :) --Wez. On 11/17/02, Andrei Zmievski [EMAIL PROTECTED] wrote: Who says Xtreme Programming can't work over long distances.. :) iliaa Sat Nov 16 19:07:33 2002 EDT Modified files: (Branch: PHP_4_3) /php4/main streams.c Log: MFH wez Sat Nov 16 19:08:42 2002 EDT Modified files: (Branch: PHP_4_3) /php4/main streams.c Log: Remove debugging printf iliaa Sat Nov 16 19:11:20 2002 EDT Modified files: (Branch: PHP_4_3) /php4/main streams.c Log: Fix compile warning. wez Sat Nov 16 20:06:32 2002 EDT Modified files: (Branch: PHP_4_3) /php4/main streams.c Log: Avoid a potential double fclose(). -Andrei http://www.gravitonic.com/ Any sufficiently advanced bug is indistinguishable from a feature. -- Rich Kulawiec -- 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] [Fwd: [Zend Engine 2] Rethinking overloaded calls]
FYI:
-Forwarded Message-
From: Timm Friebe [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Zend Engine 2] Rethinking overloaded calls
Date: 17 Nov 2002 17:40:44 +0100
I'd like to pick up on Alan Knowles' suggestion to php-dev from a couple
of days ago. There was some +1s and some argumentation against it,
saying we already have a standard: __get and __set.
The thing is: __get and __set are only called for non-existant members.
What Alan suggested is declaring getters and setters that would be
always called. Come to think about it, what's the point anyway in having
__get and __set only be called for non-existant members, anyway? I can
see a nice usage for __call (for non-existant methods) - SOAP. __get and
__set being called for non-existant members would make people construct
ugly things such as [1] simply to have the functionality of getters and
setters for their variables.
It was argued that if getters and setters were introduced, there'd have
to be an extra hashtable lookup for each set and get operation, which,
of course, has a performance impact. Well, with the example[1] provided,
the performance would be even worse due to the fact that the user is
doing it in PHP. Plus, people who write OOP code do this because they
want to make their code more maintainable. They don't do it for reasons
of speed - they'd be writing their web applications with PHP embedded
into HTML, not using functions (nevermind classes). Or they'd just ditch
PHP and write it all in C. But that's not the point. Using OOP is about
team work, maintainability and code reuse, which makes it more efficient
since developers' time can be saved - and there is nothing as expensive
as that. I can decide between employing one additional developer for
half a year or simply buying another server. People in deciding
positions buy bigger, better and faster hardware first.
Just for proof of concept, I took Zend Engine 1 and some code from
ext/overload and implemented getters and setters in a similar way
suggested by Alan (see example [2]). In ZE2, this would be even easier
since one would only need to patch the zend_std_write_property and
zend_std_read_property functions.
I know, of course, that in Zend Engine 2, I could simply use private or
protected members and write getters and setters for them to ensure that
noone goes ahead and abuses the API by directly using member
variables, but this is valid for PHP, but not in C, AFAIS. Having Zend
Engine take care of property access via API functions that could be used
by ext/*-programmers would be of real benefit: With the OOP power
provided by ZE2, we might one day see extensions written in C providing
classes. The base PEAR class could be seamlessly integrated (./configure
--with-pear=/usr/local/), for example, not requiring the user to
actually know where (in the filesystem) the PEAR extension framework is,
actually making PEAR a lot faster and (from the user's point of view)
more integrated.
I was actually think of doing exactly this for my own framework (which
comes closer to the Java architecture) - I could boost performance by
rewriting the base class Object in C and registering it as an internal
class. It's required by any class within the framework anyway and thus
parsed and compiled on every request (same goes for some other classes
such as Exception, XPClass, ...). Then again, to hell with
performance:-) - although it would probably make sense here.
So here's my suggestion: Drop __get and __set in favor of declared
getters and setters unless there's a good reason (I can't think of) to
keep them. Keep __call since there's a point in having it[3]. It's not
abusing the PHP way - think of how protected members have to be
declared in child classes. Declaration makes things clear to programmers
instead of having those magic __*-functions, makes code cleaner (just
see [1] and imagine some more ifs or switch/case-statements there) and
does not enforce coding standards on users (some might prefer
set_lastchange, some setLastchange, some lastchange and _lastchange, for
instance). Plus, always call getters and setters if declared.
To save memory and gain performance, there could be some sort of member
name mangling (as seen in private and protected members) instead of
another two hashtables in zend_class_entry for getters and setters
(assuming pointer arithmetic is faster than hashtable lookups).
1] Example for work-around:
class Forum::Article {
var $_lastchange;
// more property declarations
function __set($k, $v) {
if ('lastchange' == $k) {
$this-_lastchange= is_a($v, 'Date') ? $v : new Date($v);
}
// more ifs or maybe a switch / case?
}
function __get($k) {
if ('lastchange' == $k) return $this-_lastchange;
// more ifs or maybe a switch / case?
}
}
2] Example for new
[PHP-DEV] PHP Rsync
All, After a lot of tweaking, rsync is now back up and ready to rock. there are still going to be some teething errors, due to phpdoc errors, but i will be working with the phpdoc team to iron these out. Thanks, James -- James Cox :: [EMAIL PROTECTED] :: http://james.blogs.at/ Was I helpful? http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Updated getanyrr.patch, now dns_getrecord.patch
Attached is dns_getrecord.patch, previously known as getanyrr.patch for
introducing a new function. I've made the changes suggested including:
* Rename function
* Add whitespace in argument list of functions called
* Change parameter two from string to int, use defined constants instead
DNS_ANY DNS_A DNS_MX DNS_NS DNS_CNAME DNS_PTR DNS_TXT DNS_SOA DNS_HINFO
* Caught the fact I wasn't checking for a user supplied type of HINFO
*whoops*
What I unfortunately don't know how to do is update the ./configure
process to check for existance of: res_nmkquery, res_nsend, and dn_expand.
At the moment all I can do is rely on the fact that libresolv *is* being
tested for, and that it should contain these functions. If someone could
point me to documentation on updating that process I'd appreciate it,
otherwise I'll go back to searching for it.
-Pollita
cvs -z3 -q diff basic_functions.c dns.c dns.h (in directory S:\php4-HEAD\ext\standard)
Index: basic_functions.c
===
RCS file: /repository/php4/ext/standard/basic_functions.c,v
retrieving revision 1.543
diff -u -r1.543 basic_functions.c
--- basic_functions.c 8 Nov 2002 15:49:32 - 1.543
+++ basic_functions.c 17 Nov 2002 00:15:19 -
@@ -17,7 +17,7 @@
+--+
*/
-/* $Id: basic_functions.c,v 1.543 2002/11/08 15:49:32 sterling Exp $ */
+/* $Id: basic_functions.c,v 1.543 2002/11/16 13:18:21 pollita Exp $ */
#include php.h
#include php_streams.h
@@ -440,6 +440,7 @@
#if HAVE_RES_SEARCH !(defined(__BEOS__) || defined(PHP_WIN32) || defined(NETWARE))
PHP_FE(checkdnsrr,
NULL)
+PHP_FE(dns_getrecord,third_and_rest_force_ref)
PHP_FE(getmxrr,second_and_third_args_force_ref)
#endif
Index: dns.c
===
RCS file: /repository/php4/ext/standard/dns.c,v
retrieving revision 1.44
diff -u -r1.44 dns.c
--- dns.c 18 Oct 2002 22:08:23 - 1.44
+++ dns.c 17 Nov 2002 17:49:37 -
@@ -16,7 +16,7 @@
+--+
*/
-/* $Id: dns.c,v 1.44 2002/10/18 22:08:23 sniper Exp $ */
+/* $Id: dns.c,v 1.44 2002/11/16 17:43:41 pollita Exp $ */
/* {{{ includes
*/
@@ -71,6 +71,13 @@
#include dns.h
/* }}} */
+#if HAVE_RES_SEARCH !(defined(__BEOS__)||defined(PHP_WIN32))
+typedef union {
+ HEADER qb1;
+ u_char qb2[65536];
+} querybuf;
+#endif
+
static char *php_gethostbyaddr(char *ip);
static char *php_gethostbyname(char *name);
@@ -276,6 +283,255 @@
#ifndef MAXHOSTNAMELEN
#define MAXHOSTNAMELEN 256
#endif /* MAXHOSTNAMELEN */
+
+#ifndef MAXRESOURCERECORDS
+#define MAXRESOURCERECORDS 64
+#endif /* MAXRESOURCERECORDS */
+
+REGISTER_LONG_CONSTANT(DNS_ANY, T_ANY, CONST_CS | CONST_PERSISTENT);
+REGISTER_LONG_CONSTANT(DNS_A, T_A, CONST_CS | CONST_PERSISTENT);
+REGISTER_LONG_CONSTANT(DNS_MX, T_MX, CONST_CS | CONST_PERSISTENT);
+REGISTER_LONG_CONSTANT(DNS_CNAME, T_CNAME, CONST_CS | CONST_PERSISTENT);
+REGISTER_LONG_CONSTANT(DNS_NS, T_NS, CONST_CS | CONST_PERSISTENT);
+REGISTER_LONG_CONSTANT(DNS_TXT, T_TXT, CONST_CS | CONST_PERSISTENT);
+REGISTER_LONG_CONSTANT(DNS_PTR, T_PTR, CONST_CS | CONST_PERSISTENT);
+REGISTER_LONG_CONSTANT(DNS_SOA, T_SOA, CONST_CS | CONST_PERSISTENT);
+REGISTER_LONG_CONSTANT(DNS_HINFO, T_HINFO, CONST_CS | CONST_PERSISTENT);
+
+/* {{{ php_parserr
+ */
+u_char *php_parserr(u_char *cp, querybuf *answer, int type_to_fetch, zval **subarray)
+{
+ u_short type, class, dlen;
+ u_long ttl;
+ long n, i;
+ char name[MAXHOSTNAMELEN];
+
+ n = dn_expand(answer-qb2, answer-qb2+65536, cp, name, (sizeof name) - 2);
+ if (n 0) {
+ return NULL;
+ }
+ cp += n;
+
+ GETSHORT(type, cp);
+ GETSHORT(class, cp);
+ GETLONG(ttl, cp);
+ GETSHORT(dlen, cp);
+ if (type_to_fetch != T_ANY type != type_to_fetch) {
+ /* Should never actually occour */
+ cp += dlen;
+ return NULL;
+ }
+
+ MAKE_STD_ZVAL(*subarray);
+ if (array_init(*subarray) != SUCCESS) {
+ return NULL;
+ }
+ add_assoc_string(*subarray, host, name, 1);
+
+ switch (type) {
+ case T_A:
+ add_assoc_string(*subarray, type, A, 1);
+ sprintf(name, %d.%d.%d.%d, cp[0], cp[1], cp[2], cp[3]);
+ add_assoc_string(*subarray, ip, name, 1);
+ cp += dlen;
+ break;
+ case T_MX:
+ add_assoc_string(*subarray, type, MX, 1);
+ GETSHORT(n, cp);
+ add_assoc_long(*subarray, pri, n);
+ case T_CNAME:
+
Oops: [PHP-DEV] Updated getanyrr.patch, now dns_getrecord.patch
Ooops, after running the diff, I made a last minute change, adding RETURN_TRUE; to the end of the function and was too lazy to rerun the diff forgetting that the lines-to-insert count would go up Here's a version of that diff that'll actually patch right: Attached is dns_getrecord.patch, previously known as getanyrr.patch for introducing a new function. I've made the changes suggested including: * Rename function * Add whitespace in argument list of functions called * Change parameter two from string to int, use defined constants instead DNS_ANY DNS_A DNS_MX DNS_NS DNS_CNAME DNS_PTR DNS_TXT DNS_SOA DNS_HINFO * Caught the fact I wasn't checking for a user supplied type of HINFO *whoops* What I unfortunately don't know how to do is update the ./configure process to check for existance of: res_nmkquery, res_nsend, and dn_expand. At the moment all I can do is rely on the fact that libresolv *is* being tested for, and that it should contain these functions. If someone could point me to documentation on updating that process I'd appreciate it, otherwise I'll go back to searching for it. -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] compiliation of latest cvs fails von cygwin
Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ ext/xml/xml.o(.text+0xad5): In function `zm_info_xml': /tmp/work/php4-cvs/ext/xml/xml.c:233: undefined reference to `__imp__php_XML_ExpatVersion' ext/xml/xml.o(.text+0xdbb): In function `xml_parser_dtor': /tmp/work/php4-cvs/ext/xml/xml.c:297: undefined reference to `__imp__php_XML_ParserFree' ext/xml/xml.o(.text+0x2506): In function `zif_xml_parser_create': /tmp/work/php4-cvs/ext/xml/xml.c:1043: undefined reference to `__imp__php_XML_ParserCreate' ext/xml/xml.o(.text+0x2527):/tmp/work/php4-cvs/ext/xml/xml.c:1047: undefined reference to `__imp__php_XML_SetUserData' ext/xml/xml.o(.text+0x2770): In function `zif_xml_parser_create_ns': /tmp/work/php4-cvs/ext/xml/xml.c:1101: undefined reference to `__imp__php_XML_ParserCreateNS' ext/xml/xml.o(.text+0x2794):/tmp/work/php4-cvs/ext/xml/xml.c:1105: undefined reference to `__imp__php_XML_SetUserData' ext/xml/xml.o(.text+0x2afa): In function `zif_xml_set_element_handler': /tmp/work/php4-cvs/ext/xml/xml.c:1165: undefined reference to `__imp__php_XML_SetElementHandler' ext/xml/xml.o(.text+0x2bc9): In function `zif_xml_set_character_data_handler': /tmp/work/php4-cvs/ext/xml/xml.c:1184: undefined reference to `__imp__php_XML_SetCharacterDataHandler' ext/xml/xml.o(.text+0x2c99): In function `zif_xml_set_processing_instruction_handler': /tmp/work/php4-cvs/ext/xml/xml.c:1203: undefined reference to `__imp__php_XML_SetProcessingInstructionHandler' ext/xml/xml.o(.text+0x2d69): In function `zif_xml_set_default_handler': /tmp/work/php4-cvs/ext/xml/xml.c:1221: undefined reference to `__imp__php_XML_SetDefaultHandler' ext/xml/xml.o(.text+0x2e39): In function `zif_xml_set_unparsed_entity_decl_handler': /tmp/work/php4-cvs/ext/xml/xml.c:1240: undefined reference to `__imp__php_XML_SetUnparsedEntityDeclHandler' ext/xml/xml.o(.text+0x2f09): In function `zif_xml_set_notation_decl_handler': /tmp/work/php4-cvs/ext/xml/xml.c:1258: undefined reference to `__imp__php_XML_SetNotationDeclHandler' ext/xml/xml.o(.text+0x2fd9): In function `zif_xml_set_external_entity_ref_handler': /tmp/work/php4-cvs/ext/xml/xml.c:1276: undefined reference to `__imp__php_XML_SetExternalEntityRefHandler' ext/xml/xml.o(.text+0x30a9): In function `zif_xml_set_start_namespace_decl_handler': /tmp/work/php4-cvs/ext/xml/xml.c:1295: undefined reference to `__imp__php_XML_SetStartNamespaceDeclHandler' ext/xml/xml.o(.text+0x3179): In function `zif_xml_set_end_namespace_decl_handler': /tmp/work/php4-cvs/ext/xml/xml.c:1314: undefined reference to `__imp__php_XML_SetEndNamespaceDeclHandler' ext/xml/xml.o(.text+0x3274): In function `zif_xml_parse': /tmp/work/php4-cvs/ext/xml/xml.c:1342: undefined reference to `__imp__php_XML_Parse' ext/xml/xml.o(.text+0x3495): In function `zif_xml_parse_into_struct': /tmp/work/php4-cvs/ext/xml/xml.c:1377: undefined reference to `__imp__php_XML_SetDefaultHandler' ext/xml/xml.o(.text+0x34b1):/tmp/work/php4-cvs/ext/xml/xml.c:1378: undefined reference to `__imp__php_XML_SetElementHandler' ext/xml/xml.o(.text+0x34c5):/tmp/work/php4-cvs/ext/xml/xml.c:1379: undefined reference to `__imp__php_XML_SetCharacterDataHandler' ext/xml/xml.o(.text+0x34ed):/tmp/work/php4-cvs/ext/xml/xml.c:1381: undefined reference to `__imp__php_XML_Parse' ext/xml/xml.o(.text+0x361a): In function `zif_xml_get_error_code': /tmp/work/php4-cvs/ext/xml/xml.c:1399: undefined reference to `__imp__php_XML_GetErrorCode' ext/xml/xml.o(.text+0x36a7): In function `zif_xml_error_string': /tmp/work/php4-cvs/ext/xml/xml.c:1414: undefined reference to `__imp__php_XML_ErrorString' ext/xml/xml.o(.text+0x37aa): In function `zif_xml_get_current_line_number': /tmp/work/php4-cvs/ext/xml/xml.c:1433: undefined reference to `__imp__php_XML_GetCurrentLineNumber' ext/xml/xml.o(.text+0x383a): In function `zif_xml_get_current_column_number': /tmp/work/php4-cvs/ext/xml/xml.c:1449: undefined reference to `__imp__php_XML_GetCurrentColumnNumber' ext/xml/xml.o(.text+0x38ca): In function `zif_xml_get_current_byte_index': /tmp/work/php4-cvs/ext/xml/xml.c:1465: undefined reference to `__imp__php_XML_GetCurrentByteIndex' collect2: ld returned 1 exit status make: *** [sapi/cgi/php-cgi] Error 1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: Oops: [PHP-DEV] Updated getanyrr.patch, now dns_getrecord.patch
On Sun, 17 Nov 2002, Pollita wrote: Ooops, after running the diff, I made a last minute change, adding RETURN_TRUE; to the end of the function and was too lazy to rerun the diff forgetting that the lines-to-insert count would go up Here's a version of that diff that'll actually patch right: Hmm, empty attachments are indeed easy to apply :-) I think you forgot it. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATH] update to earlier proposed patch for getanyrr() function addition
I guessed we'd have to look into ext/standard/config.m4 for that new functionality. At 16:19 17.11.2002, Derick Rethans wrote: On Sun, 17 Nov 2002, Marcus Börger wrote: Sure but anyway we would need to review the config file if everything we need is in place. uhm, what config file? Derick At 14:54 17.11.2002, Derick Rethans wrote: On Sun, 17 Nov 2002, Marcus Börger wrote: I could do the autoconf stuff and i vould go for naming all these function dns_get_xx() and such. nice, but I dont think we need to introduce (about) 10 functions which do basically the same thing except for returning a different record. What I meant was something like this: dns_get_record(php.net, DNS_MX); and of course having all the other DNS_* records defined as constant in PHP. We can then also wrap the original getmxrr() function to use this new function. Derick At 12:38 17.11.2002, Derick Rethans wrote: On Sun, 17 Nov 2002 [EMAIL PROTECTED] wrote: Hello, Who can commit that now? I don't think it's ready yet. I agree with Marcus that the name of the function should be different then getanyrr(), it definitely doesn't fit into the naming things we have (with that getmxrr() doesn't fit either). I also think that the selection of the type of record to fetch should be made a constant so that we don't need to strncasecmp it everytime, and I would favor an implementation with zend_parse_parameters() to get rid of the (IMO) ugly parameter handling. Also, a lot of lines don't follow coding standards, like: n = res_nmkquery(res,QUERY,Z_STRVAL_P(host),C_IN,type_to_fetch,NULL,0, NULL ,buf..qb2,sizeof buf); instead of: n = res_nmkquery(res, QUERY, Z_STRVAL_P(host), C_IN, type_to_fetch, NULL, 0, NULL, buf.qb2, sizeof(buf)); And I miss autoconf checks for all those DNS functions (like res_mkquery, dn_expand) which might not exist on all platforms. regards, Derick Marcus Börger [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] Function is nice but the function name is not. Attached is a second revised patch that fixes the build problems. marcus At 00:11 17.11.2002, Pollita wrote: Per corrections suggested by [EMAIL PROTECTED], attached is a revised pacth to ext/standard/dns.c for addition of getanyrr() function. -- 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 -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: Oops: [PHP-DEV] Updated getanyrr.patch, now dns_getrecord.patch
*sigh* shoot me billy On Sun, 17 Nov 2002, Pollita wrote: Ooops, after running the diff, I made a last minute change, adding RETURN_TRUE; to the end of the function and was too lazy to rerun the diff forgetting that the lines-to-insert count would go up Here's a version of that diff that'll actually patch right: Hmm, empty attachments are indeed easy to apply :-) I think you forgot it. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATH] update to earlier proposed patch for getanyrr()function addition
On Sun, 17 Nov 2002, Marcus Börger wrote: I guessed we'd have to look into ext/standard/config.m4 for that new functionality. Ah, of course. Derick At 16:19 17.11.2002, Derick Rethans wrote: On Sun, 17 Nov 2002, Marcus Börger wrote: Sure but anyway we would need to review the config file if everything we need is in place. uhm, what config file? Derick At 14:54 17.11.2002, Derick Rethans wrote: On Sun, 17 Nov 2002, Marcus Börger wrote: I could do the autoconf stuff and i vould go for naming all these function dns_get_xx() and such. nice, but I dont think we need to introduce (about) 10 functions which do basically the same thing except for returning a different record. What I meant was something like this: dns_get_record(php.net, DNS_MX); and of course having all the other DNS_* records defined as constant in PHP. We can then also wrap the original getmxrr() function to use this new function. Derick At 12:38 17.11.2002, Derick Rethans wrote: On Sun, 17 Nov 2002 [EMAIL PROTECTED] wrote: Hello, Who can commit that now? I don't think it's ready yet. I agree with Marcus that the name of the function should be different then getanyrr(), it definitely doesn't fit into the naming things we have (with that getmxrr() doesn't fit either). I also think that the selection of the type of record to fetch should be made a constant so that we don't need to strncasecmp it everytime, and I would favor an implementation with zend_parse_parameters() to get rid of the (IMO) ugly parameter handling. Also, a lot of lines don't follow coding standards, like: n = res_nmkquery(res,QUERY,Z_STRVAL_P(host),C_IN,type_to_fetch,NULL,0, NULL ,buf..qb2,sizeof buf); instead of: n = res_nmkquery(res, QUERY, Z_STRVAL_P(host), C_IN, type_to_fetch, NULL, 0, NULL, buf.qb2, sizeof(buf)); And I miss autoconf checks for all those DNS functions (like res_mkquery, dn_expand) which might not exist on all platforms. regards, Derick Marcus Börger [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] Function is nice but the function name is not. Attached is a second revised patch that fixes the build problems. marcus At 00:11 17.11.2002, Pollita wrote: Per corrections suggested by [EMAIL PROTECTED], attached is a revised pacth to ext/standard/dns.c for addition of getanyrr() function. -- 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 -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: Oops: [PHP-DEV] Updated getanyrr.patch, now dns_getrecord.patch
On Sun, 17 Nov 2002, Pollita wrote: *sigh* shoot me billy I'll shoot you again then :) Still nothing ... Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Updated getanyrr.patch, now dns_getrecord.patch
On Sun, 17 Nov 2002 10:56:45 -0800 (PST), [EMAIL PROTECTED] (Pollita) wrote: What I unfortunately don't know how to do is update the ./configure process to check for existance of: res_nmkquery, res_nsend, and dn_expand. At the moment all I can do is rely on the fact that libresolv *is* being tested for, and that it should contain these functions. $ uname -rs ld -lresolv BSD/OS 4.3 ld: cannot find -lresolv DNS is very tricky. Before screwing around it withit, please have replacement functions ready or use the portable functions. Additionally, some systems have these in libc, AND have a libresolv. Concentrating on libresolv adds a fair ammount to the php binary and is slower than using the core function. Sascha and Jani, created the PHP_CHECK_FUNC macro for this. See acinclude.m4 and usage in configure.in:1319 Melvyn Sopacua ?php include_once(not_reflecting_employers_views.txt; ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Support for Birdstep RDM Server database engine
Hello again,
I've not heard anything from anybody regarding my previous post. My first
thought is that everyone is caught up in the release activities, but I would
appreciate any comments that anyone might be able to offer.
Thanks,
Diggy
Diggy Bell [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Hello All,
I have recently been approached by Birdstep about updating the PHP module
to
support their database engine for an internal project. In the past
(v4.1.2
and earlier IIRC), PHP has provided support for the Birdstep (formerly
Velocis) database as part of the distribution. Since v4.1.2 (IIRC) this
support has been dropped in the standard source tree. But, I was able to
locate the old code under ./ext/odbc and so I have resurrected the module.
In the process, I have made a number of modifications and additions to the
library to bring it up to date with the latest version of Birdstep's
product.
My main question is: Is this module something that the community would
like
to have available again? If so, I am willing to pick up the maintenance
duties on the module. I'm a former employee of the company and have
access
to 'back-door' support when necessary.
I've taken a bit of time and put together some notes on the modifications
that I have made to this point. These notes are copied below for review.
I've also attached the modified source files. (NOTE: I realize these
aren't formatted to PHP standards...please let me slide on that one while
I'm making more significant changes :-P) If there is interest, I am also
considering addiing some enhancements for connection management and error
handling.
Any thoughts/comments would be appreciated.
--
William D. 'Diggy' Bell
Principal
DB Software Development
http://www.dbsoftdev.com
/* CUT HERE */
Birdstep PHP Extension
Design Specification
Date: 11/14/2002
By: William D. 'Diggy' Bell
INTRODUCTION
The Birdstep PHP Extension allows PHP applications to access the Birdstep
RDM Server database engine.
REQUIREMENTS
1. Support for LONG VARCHAR columns
2. Positioned fetch operations
3. Support for birdstep_fetch_array()
4. Support for birdstep_num_fields()
5. Support for birdstep_affected_rows()
DESIGN CONSIDERATIONS
1. API conflict between SQLFetchScroll and SQLGetData
There is a current design limitation in the RDM Server that prevents the
use
of SQLGetData() with rowsets that have been retrieved using
SQLFetchScroll(). This
limitation strongly impacts how LONG VARCHAR fields can be handled. Two
methods are described below.
a. Use SQLFetch() instead of SQLFetchScroll().
The requirement for positioned fetch operations eliminates this option.
b. Use a maximum sized buffer for LONG VARCHAR columns
In this method, a buffer of a fixed maximum size would be allocated for
each
LONG VARCHAR column. The column would then be bound using SQLBindCol() to
retrieve the data in one operation.
Option (b) was chosen because it allows support for SQLFetchScroll().
This
can have
significant implications on applications that have a large number of LONG
VARCHAR
columns due to unnecessarily high memory requirements.
NOTE: There are additional limitations in the RDM Server engine that have
prevented
implementation of cursor positioning. SQLFetchScroll will continue to be
used for
smoothest migration when RDM Server support for cursor positioning is
added.
INTERNAL DATA STRUCTURES
typedef struct VConn {
HDBC hdbc;
long index;
int connected;
} VConn;
typedef struct {
char name[32];
char*value;
long vallen;
SDWORD valtype;
} VResVal;
typedef struct Vresult {
HSTMThstmt;
VConn* conn;
long index;
VResVal* values;
long numcols;
int fetched;
} Vresult;
typedef struct _php_birdstep_globals
{
long num_links;
long max_links;
int le_link;
int le_result;
} php_birdstep_globals;
INTERNAL FUNCTIONS
PHP_MINIT_FUNCTION(birdstep)
PHP_MSHUTDOWN_FUNCTION(birdstep)
PHP_RINIT_FUNCTION(birdstep)
PHP_RSHUTDOWN_FUNCTION(birdstep)
PHP_MINFO_FUNCTION(birdstep)
APPLICATION PROGRAMMING INTERFACE
birdstep_connect($server, $user, $password)
-
Parameters:
$server - RDM Server name
$user - database user name
$password - user's password
Returns:
connection handle
Description:
This function will connection to the RDM Server identified by $server.
The
$user and $password must be valid users on the server.
birdstep_close($conn)
-
Parameters:
$conn - connection handle to close
Returns:
TRUE if successful, FALSE if an error occurred.
Description:
This function will close the specified connection to the RDM Server
birdstep_exec($conn, $sql)
[PHP-DEV] CVS Account Request: kriga
German translation of the PEAR documentation. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] dns_getrecord.patch -- trying again
I'll put the text in the body of my message AND attach with .txt this
time.
Index: basic_functions.c
===
RCS file: /repository/php4/ext/standard/basic_functions.c,v
retrieving revision 1.543
diff -u -r1.543 basic_functions.c
--- basic_functions.c 8 Nov 2002 15:49:32 - 1.543
+++ basic_functions.c 17 Nov 2002 20:28:34 -
@@ -17,7 +17,7 @@
+--+
*/
-/* $Id: basic_functions.c,v 1.543 2002/11/08 15:49:32 sterling Exp $ */
+/* $Id: basic_functions.c,v 1.543 2002/11/16 13:18:21 pollita Exp $ */
#include php.h
#include php_streams.h
@@ -440,6 +440,7 @@
#if HAVE_RES_SEARCH !(defined(__BEOS__) || defined(PHP_WIN32) ||
defined(NETWARE))
PHP_FE(checkdnsrr,
NULL)
+PHP_FE(dns_getrecord,third_and_rest_force_ref)
PHP_FE(getmxrr,second_and_third_args_force_ref)
#endif
@@ -1021,6 +1022,7 @@
register_html_constants(INIT_FUNC_ARGS_PASSTHRU);
register_string_constants(INIT_FUNC_ARGS_PASSTHRU);
+ PHP_MINIT(dns) (INIT_FUNC_ARGS_PASSTHRU);
PHP_MINIT(regex) (INIT_FUNC_ARGS_PASSTHRU);
PHP_MINIT(file) (INIT_FUNC_ARGS_PASSTHRU);
PHP_MINIT(pack) (INIT_FUNC_ARGS_PASSTHRU);
Index: dns.c
===
RCS file: /repository/php4/ext/standard/dns.c,v
retrieving revision 1.44
diff -u -r1.44 dns.c
--- dns.c 18 Oct 2002 22:08:23 - 1.44
+++ dns.c 17 Nov 2002 20:28:34 -
@@ -16,7 +16,7 @@
+--+
*/
-/* $Id: dns.c,v 1.44 2002/10/18 22:08:23 sniper Exp $ */
+/* $Id: dns.c,v 1.44 2002/11/16 17:43:41 pollita Exp $ */
/* {{{ includes
*/
@@ -71,6 +71,13 @@
#include dns.h
/* }}} */
+#if HAVE_RES_SEARCH !(defined(__BEOS__)||defined(PHP_WIN32))
+typedef union {
+ HEADER qb1;
+ u_char qb2[65536];
+} querybuf;
+#endif
+
static char *php_gethostbyaddr(char *ip);
static char *php_gethostbyname(char *name);
@@ -276,6 +283,257 @@
#ifndef MAXHOSTNAMELEN
#define MAXHOSTNAMELEN 256
#endif /* MAXHOSTNAMELEN */
+
+#ifndef MAXRESOURCERECORDS
+#define MAXRESOURCERECORDS 64
+#endif /* MAXRESOURCERECORDS */
+
+PHP_MINIT_FUNCTION(dns) {
+ REGISTER_LONG_CONSTANT(DNS_ANY, T_ANY, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_A, T_A, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_MX, T_MX, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_CNAME, T_CNAME, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_NS, T_NS, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_TXT, T_TXT, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_PTR, T_PTR, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_SOA, T_SOA, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_HINFO, T_HINFO, CONST_CS | CONST_PERSISTENT);
+}
+
+/* {{{ php_parserr
+ */
+u_char *php_parserr(u_char *cp, querybuf *answer, int type_to_fetch, zval
**subarray) {
+ u_short type, class, dlen;
+ u_long ttl;
+ long n, i;
+ char name[MAXHOSTNAMELEN];
+
+ n = dn_expand(answer-qb2, answer-qb2+65536, cp, name, (sizeof name) - 2);
+ if (n 0) {
+ return NULL;
+ }
+ cp += n;
+
+ GETSHORT(type, cp);
+ GETSHORT(class, cp);
+ GETLONG(ttl, cp);
+ GETSHORT(dlen, cp);
+ if (type_to_fetch != T_ANY type != type_to_fetch) {
+ /* Should never actually occour */
+ cp += dlen;
+ return NULL;
+ }
+
+ MAKE_STD_ZVAL(*subarray);
+ if (array_init(*subarray) != SUCCESS) {
+ return NULL;
+ }
+ add_assoc_string(*subarray, host, name, 1);
+
+ switch (type) {
+ case T_A:
+ add_assoc_string(*subarray, type, A, 1);
+ sprintf(name, %d.%d.%d.%d, cp[0], cp[1], cp[2], cp[3]);
+ add_assoc_string(*subarray, ip, name, 1);
+ cp += dlen;
+ break;
+ case T_MX:
+ add_assoc_string(*subarray, type, MX, 1);
+ GETSHORT(n, cp);
+ add_assoc_long(*subarray, pri, n);
+ case T_CNAME:
+ if (type == T_CNAME)
+ add_assoc_string(*subarray, type, CNAME, 1);
+ case T_NS:
+ if (type == T_NS)
+ add_assoc_string(*subarray, type, NS, 1);
+ case T_PTR:
+ if (type == T_PTR)
+ add_assoc_string(*subarray, type, PTR, 1);
+ n = dn_expand(
Re: [PHP-DEV] Re: Support for Birdstep RDM Server database engine
Hello Diggy,
Birdstep was rolled into the ODBC functionality, and has really not
seen any support since. I don't believe anyone currently on the PHP
staff is really familiar with the way the Birdstep systems work. The
reality is though that I don't see many PHP users using
Birdstep/Velocis support. This could of course be a chicken/egg
problem, where the PHP support is lacking etc etc...
What are the changes you're planning to do? If you'd like to make
birdstep it's own module, I'd suggest looking at creating it as a PECL
module, and working from there.
Typically we don't discourage integration with systems/API's,
especially if the author is willing to maintain it :)
On Sunday, November 17, 2002, at 03:30 PM, Diggy Bell wrote:
Hello again,
I've not heard anything from anybody regarding my previous post. My
first
thought is that everyone is caught up in the release activities, but I
would
appreciate any comments that anyone might be able to offer.
Thanks,
Diggy
Diggy Bell [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Hello All,
I have recently been approached by Birdstep about updating the PHP
module
to
support their database engine for an internal project. In the past
(v4.1.2
and earlier IIRC), PHP has provided support for the Birdstep (formerly
Velocis) database as part of the distribution. Since v4.1.2 (IIRC)
this
support has been dropped in the standard source tree. But, I was
able to
locate the old code under ./ext/odbc and so I have resurrected the
module.
In the process, I have made a number of modifications and additions
to the
library to bring it up to date with the latest version of Birdstep's
product.
My main question is: Is this module something that the community
would
like
to have available again? If so, I am willing to pick up the
maintenance
duties on the module. I'm a former employee of the company and have
access
to 'back-door' support when necessary.
I've taken a bit of time and put together some notes on the
modifications
that I have made to this point. These notes are copied below for
review.
I've also attached the modified source files. (NOTE: I realize these
aren't formatted to PHP standards...please let me slide on that one
while
I'm making more significant changes :-P) If there is interest, I am
also
considering addiing some enhancements for connection management and
error
handling.
Any thoughts/comments would be appreciated.
--
William D. 'Diggy' Bell
Principal
DB Software Development
http://www.dbsoftdev.com
/* CUT HERE */
Birdstep PHP Extension
Design Specification
Date: 11/14/2002
By: William D. 'Diggy' Bell
INTRODUCTION
The Birdstep PHP Extension allows PHP applications to access the
Birdstep
RDM Server database engine.
REQUIREMENTS
1. Support for LONG VARCHAR columns
2. Positioned fetch operations
3. Support for birdstep_fetch_array()
4. Support for birdstep_num_fields()
5. Support for birdstep_affected_rows()
DESIGN CONSIDERATIONS
1. API conflict between SQLFetchScroll and SQLGetData
There is a current design limitation in the RDM Server that prevents
the
use
of SQLGetData() with rowsets that have been retrieved using
SQLFetchScroll(). This
limitation strongly impacts how LONG VARCHAR fields can be handled.
Two
methods are described below.
a. Use SQLFetch() instead of SQLFetchScroll().
The requirement for positioned fetch operations eliminates this
option.
b. Use a maximum sized buffer for LONG VARCHAR columns
In this method, a buffer of a fixed maximum size would be allocated
for
each
LONG VARCHAR column. The column would then be bound using
SQLBindCol() to
retrieve the data in one operation.
Option (b) was chosen because it allows support for SQLFetchScroll().
This
can have
significant implications on applications that have a large number of
LONG
VARCHAR
columns due to unnecessarily high memory requirements.
NOTE: There are additional limitations in the RDM Server engine that
have
prevented
implementation of cursor positioning. SQLFetchScroll will continue
to be
used for
smoothest migration when RDM Server support for cursor positioning is
added.
INTERNAL DATA STRUCTURES
typedef struct VConn {
HDBC hdbc;
long index;
int connected;
} VConn;
typedef struct {
char name[32];
char*value;
long vallen;
SDWORD valtype;
} VResVal;
typedef struct Vresult {
HSTMThstmt;
VConn* conn;
long index;
VResVal* values;
long numcols;
int fetched;
} Vresult;
typedef struct _php_birdstep_globals
{
long num_links;
long max_links;
int le_link;
int le_result;
} php_birdstep_globals;
INTERNAL FUNCTIONS
PHP_MINIT_FUNCTION(birdstep)
PHP_MSHUTDOWN_FUNCTION(birdstep)
PHP_RINIT_FUNCTION(birdstep)
PHP_RSHUTDOWN_FUNCTION(birdstep)
PHP_MINFO_FUNCTION(birdstep)
APPLICATION PROGRAMMING INTERFACE
birdstep_connect($server, $user, $password)
[PHP-DEV] Re: dns_getrecord.patch -- trying again
There we go :-)
--
Regards.
M.CHAILLAN Nicolas
[EMAIL PROTECTED]
www.WorldAKT.com Hébergement de sites internets.
Pollita [EMAIL PROTECTED] a écrit dans le message de news:
[EMAIL PROTECTED]
I'll put the text in the body of my message AND attach with .txt this
time.
Index: basic_functions.c
===
RCS file: /repository/php4/ext/standard/basic_functions.c,v
retrieving revision 1.543
diff -u -r1.543 basic_functions.c
--- basic_functions.c 8 Nov 2002 15:49:32 - 1.543
+++ basic_functions.c 17 Nov 2002 20:28:34 -
@@ -17,7 +17,7 @@
+--+
*/
-/* $Id: basic_functions.c,v 1.543 2002/11/08 15:49:32 sterling Exp $ */
+/* $Id: basic_functions.c,v 1.543 2002/11/16 13:18:21 pollita Exp $ */
#include php.h
#include php_streams.h
@@ -440,6 +440,7 @@
#if HAVE_RES_SEARCH !(defined(__BEOS__) || defined(PHP_WIN32) ||
defined(NETWARE))
PHP_FE(checkdnsrr, NULL)
+PHP_FE(dns_getrecord,third_and_rest_force_ref)
PHP_FE(getmxrr,second_and_third_args_force_ref)
#endif
@@ -1021,6 +1022,7 @@
register_html_constants(INIT_FUNC_ARGS_PASSTHRU);
register_string_constants(INIT_FUNC_ARGS_PASSTHRU);
+ PHP_MINIT(dns) (INIT_FUNC_ARGS_PASSTHRU);
PHP_MINIT(regex) (INIT_FUNC_ARGS_PASSTHRU);
PHP_MINIT(file) (INIT_FUNC_ARGS_PASSTHRU);
PHP_MINIT(pack) (INIT_FUNC_ARGS_PASSTHRU);
Index: dns.c
===
RCS file: /repository/php4/ext/standard/dns.c,v
retrieving revision 1.44
diff -u -r1.44 dns.c
--- dns.c 18 Oct 2002 22:08:23 - 1.44
+++ dns.c 17 Nov 2002 20:28:34 -
@@ -16,7 +16,7 @@
+--+
*/
-/* $Id: dns.c,v 1.44 2002/10/18 22:08:23 sniper Exp $ */
+/* $Id: dns.c,v 1.44 2002/11/16 17:43:41 pollita Exp $ */
/* {{{ includes
*/
@@ -71,6 +71,13 @@
#include dns.h
/* }}} */
+#if HAVE_RES_SEARCH !(defined(__BEOS__)||defined(PHP_WIN32))
+typedef union {
+ HEADER qb1;
+ u_char qb2[65536];
+} querybuf;
+#endif
+
static char *php_gethostbyaddr(char *ip);
static char *php_gethostbyname(char *name);
@@ -276,6 +283,257 @@
#ifndef MAXHOSTNAMELEN
#define MAXHOSTNAMELEN 256
#endif /* MAXHOSTNAMELEN */
+
+#ifndef MAXRESOURCERECORDS
+#define MAXRESOURCERECORDS 64
+#endif /* MAXRESOURCERECORDS */
+
+PHP_MINIT_FUNCTION(dns) {
+ REGISTER_LONG_CONSTANT(DNS_ANY, T_ANY, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_A, T_A, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_MX, T_MX, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_CNAME, T_CNAME, CONST_CS |
CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_NS, T_NS, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_TXT, T_TXT, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_PTR, T_PTR, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_SOA, T_SOA, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_HINFO, T_HINFO, CONST_CS |
CONST_PERSISTENT);
+}
+
+/* {{{ php_parserr
+ */
+u_char *php_parserr(u_char *cp, querybuf *answer, int type_to_fetch, zval
**subarray) {
+ u_short type, class, dlen;
+ u_long ttl;
+ long n, i;
+ char name[MAXHOSTNAMELEN];
+
+ n = dn_expand(answer-qb2, answer-qb2+65536, cp, name, (sizeof name) -
2);
+ if (n 0) {
+ return NULL;
+ }
+ cp += n;
+
+ GETSHORT(type, cp);
+ GETSHORT(class, cp);
+ GETLONG(ttl, cp);
+ GETSHORT(dlen, cp);
+ if (type_to_fetch != T_ANY type != type_to_fetch) {
+ /* Should never actually occour */
+ cp += dlen;
+ return NULL;
+ }
+
+ MAKE_STD_ZVAL(*subarray);
+ if (array_init(*subarray) != SUCCESS) {
+ return NULL;
+ }
+ add_assoc_string(*subarray, host, name, 1);
+
+ switch (type) {
+ case T_A:
+ add_assoc_string(*subarray, type, A, 1);
+ sprintf(name, %d.%d.%d.%d, cp[0], cp[1], cp[2], cp[3]);
+ add_assoc_string(*subarray, ip, name, 1);
+ cp += dlen;
+ break;
+ case T_MX:
+ add_assoc_string(*subarray, type, MX, 1);
+ GETSHORT(n, cp);
+ add_assoc_long(*subarray, pri, n);
+ case T_CNAME:
+ if (type == T_CNAME)
+ add_assoc_string(*subarray, type, CNAME, 1);
+ case T_NS:
+ if (type == T_NS)
+ add_assoc_string(*subarray, type, NS, 1);
+ case T_PTR:
+ if (type == T_PTR)
+ add_assoc_string(*subarray, type, PTR, 1);
+ n = dn_expand( answer-qb2, answer-qb2+65536, cp, name, (sizeof name)
- 2);
+ if (n 0) {
+ return NULL;
+ }
+ cp += n;
+ add_assoc_string(*subarray, target, name, 1);
+ break;
+ case T_HINFO:
+ /* See RFC 1010 for values */
+ GETSHORT(n, cp);
+ add_assoc_long(*subarray, cpu, n);
+ GETSHORT(n, cp);
+ add_assoc_long(*subarray, os, n);
+ break;
+ case T_TXT:
+ add_assoc_string(*subarray, type, TXT, 1);
+ n = cp[0];
+ for(i=1; i=n; i++)
+ name[i-1] = cp[i];
+ name[i-1] = '\0';
+ cp += dlen;
+ add_assoc_string(*subarray, txt, name, 1);
+ break;
+
Re: [PHP-DEV] Re: dns_getrecord.patch -- trying again
I suggest dns_get_record().
Andi
At 09:43 PM 11/17/2002 +0100, [EMAIL PROTECTED] wrote:
There we go :-)
--
Regards.
M.CHAILLAN Nicolas
[EMAIL PROTECTED]
www.WorldAKT.com Hébergement de sites internets.
Pollita [EMAIL PROTECTED] a écrit dans le message de news:
[EMAIL PROTECTED]
I'll put the text in the body of my message AND attach with .txt this
time.
Index: basic_functions.c
===
RCS file: /repository/php4/ext/standard/basic_functions.c,v
retrieving revision 1.543
diff -u -r1.543 basic_functions.c
--- basic_functions.c 8 Nov 2002 15:49:32 - 1.543
+++ basic_functions.c 17 Nov 2002 20:28:34 -
@@ -17,7 +17,7 @@
+--+
*/
-/* $Id: basic_functions.c,v 1.543 2002/11/08 15:49:32 sterling Exp $ */
+/* $Id: basic_functions.c,v 1.543 2002/11/16 13:18:21 pollita Exp $ */
#include php.h
#include php_streams.h
@@ -440,6 +440,7 @@
#if HAVE_RES_SEARCH !(defined(__BEOS__) || defined(PHP_WIN32) ||
defined(NETWARE))
PHP_FE(checkdnsrr, NULL)
+PHP_FE(dns_getrecord,third_and_rest_force_ref)
PHP_FE(getmxrr,second_and_third_args_force_ref)
#endif
@@ -1021,6 +1022,7 @@
register_html_constants(INIT_FUNC_ARGS_PASSTHRU);
register_string_constants(INIT_FUNC_ARGS_PASSTHRU);
+ PHP_MINIT(dns) (INIT_FUNC_ARGS_PASSTHRU);
PHP_MINIT(regex) (INIT_FUNC_ARGS_PASSTHRU);
PHP_MINIT(file) (INIT_FUNC_ARGS_PASSTHRU);
PHP_MINIT(pack) (INIT_FUNC_ARGS_PASSTHRU);
Index: dns.c
===
RCS file: /repository/php4/ext/standard/dns.c,v
retrieving revision 1.44
diff -u -r1.44 dns.c
--- dns.c 18 Oct 2002 22:08:23 - 1.44
+++ dns.c 17 Nov 2002 20:28:34 -
@@ -16,7 +16,7 @@
+--+
*/
-/* $Id: dns.c,v 1.44 2002/10/18 22:08:23 sniper Exp $ */
+/* $Id: dns.c,v 1.44 2002/11/16 17:43:41 pollita Exp $ */
/* {{{ includes
*/
@@ -71,6 +71,13 @@
#include dns.h
/* }}} */
+#if HAVE_RES_SEARCH !(defined(__BEOS__)||defined(PHP_WIN32))
+typedef union {
+ HEADER qb1;
+ u_char qb2[65536];
+} querybuf;
+#endif
+
static char *php_gethostbyaddr(char *ip);
static char *php_gethostbyname(char *name);
@@ -276,6 +283,257 @@
#ifndef MAXHOSTNAMELEN
#define MAXHOSTNAMELEN 256
#endif /* MAXHOSTNAMELEN */
+
+#ifndef MAXRESOURCERECORDS
+#define MAXRESOURCERECORDS 64
+#endif /* MAXRESOURCERECORDS */
+
+PHP_MINIT_FUNCTION(dns) {
+ REGISTER_LONG_CONSTANT(DNS_ANY, T_ANY, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_A, T_A, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_MX, T_MX, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_CNAME, T_CNAME, CONST_CS |
CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_NS, T_NS, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_TXT, T_TXT, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_PTR, T_PTR, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_SOA, T_SOA, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_HINFO, T_HINFO, CONST_CS |
CONST_PERSISTENT);
+}
+
+/* {{{ php_parserr
+ */
+u_char *php_parserr(u_char *cp, querybuf *answer, int type_to_fetch, zval
**subarray) {
+ u_short type, class, dlen;
+ u_long ttl;
+ long n, i;
+ char name[MAXHOSTNAMELEN];
+
+ n = dn_expand(answer-qb2, answer-qb2+65536, cp, name, (sizeof name) -
2);
+ if (n 0) {
+ return NULL;
+ }
+ cp += n;
+
+ GETSHORT(type, cp);
+ GETSHORT(class, cp);
+ GETLONG(ttl, cp);
+ GETSHORT(dlen, cp);
+ if (type_to_fetch != T_ANY type != type_to_fetch) {
+ /* Should never actually occour */
+ cp += dlen;
+ return NULL;
+ }
+
+ MAKE_STD_ZVAL(*subarray);
+ if (array_init(*subarray) != SUCCESS) {
+ return NULL;
+ }
+ add_assoc_string(*subarray, host, name, 1);
+
+ switch (type) {
+ case T_A:
+ add_assoc_string(*subarray, type, A, 1);
+ sprintf(name, %d.%d.%d.%d, cp[0], cp[1], cp[2], cp[3]);
+ add_assoc_string(*subarray, ip, name, 1);
+ cp += dlen;
+ break;
+ case T_MX:
+ add_assoc_string(*subarray, type, MX, 1);
+ GETSHORT(n, cp);
+ add_assoc_long(*subarray, pri, n);
+ case T_CNAME:
+ if (type == T_CNAME)
+ add_assoc_string(*subarray, type, CNAME, 1);
+ case T_NS:
+ if (type == T_NS)
+ add_assoc_string(*subarray, type, NS, 1);
+ case T_PTR:
+ if (type == T_PTR)
+ add_assoc_string(*subarray, type, PTR, 1);
+ n = dn_expand( answer-qb2, answer-qb2+65536, cp, name, (sizeof name)
- 2);
+ if (n 0) {
+ return NULL;
+ }
+ cp += n;
+ add_assoc_string(*subarray, target, name, 1);
+ break;
+ case T_HINFO:
+ /* See RFC 1010 for values */
+ GETSHORT(n, cp);
+ add_assoc_long(*subarray, cpu, n);
+ GETSHORT(n, cp);
+ add_assoc_long(*subarray, os, n);
+ break;
+ case T_TXT:
+ add_assoc_string(*subarray, type, TXT, 1);
+ n = cp[0];
+ for(i=1; i=n; i++)
+ name[i-1] = cp[i];
+
Re: [PHP-DEV] Re: dns_getrecord.patch -- trying again
+1
Regards.
M.CHAILLAN Nicolas
[EMAIL PROTECTED]
www.WorldAKT.com Hébergement de sites internets.
- Original Message -
From: Andi Gutmans [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, November 17, 2002 9:49 PM
Subject: Re: [PHP-DEV] Re: dns_getrecord.patch -- trying again
I suggest dns_get_record().
Andi
At 09:43 PM 11/17/2002 +0100, [EMAIL PROTECTED] wrote:
There we go :-)
--
Regards.
M.CHAILLAN Nicolas
[EMAIL PROTECTED]
www.WorldAKT.com Hébergement de sites internets.
Pollita [EMAIL PROTECTED] a écrit dans le message de news:
[EMAIL PROTECTED]
I'll put the text in the body of my message AND attach with .txt this
time.
Index: basic_functions.c
===
RCS file: /repository/php4/ext/standard/basic_functions.c,v
retrieving revision 1.543
diff -u -r1.543 basic_functions.c
--- basic_functions.c 8 Nov 2002 15:49:32 - 1.543
+++ basic_functions.c 17 Nov 2002 20:28:34 -
@@ -17,7 +17,7 @@
+--+
*/
-/* $Id: basic_functions.c,v 1.543 2002/11/08 15:49:32 sterling Exp $ */
+/* $Id: basic_functions.c,v 1.543 2002/11/16 13:18:21 pollita Exp $ */
#include php.h
#include php_streams.h
@@ -440,6 +440,7 @@
#if HAVE_RES_SEARCH !(defined(__BEOS__) || defined(PHP_WIN32) ||
defined(NETWARE))
PHP_FE(checkdnsrr, NULL)
+PHP_FE(dns_getrecord,third_and_rest_force_ref)
PHP_FE(getmxrr,second_and_third_args_force_ref)
#endif
@@ -1021,6 +1022,7 @@
register_html_constants(INIT_FUNC_ARGS_PASSTHRU);
register_string_constants(INIT_FUNC_ARGS_PASSTHRU);
+ PHP_MINIT(dns) (INIT_FUNC_ARGS_PASSTHRU);
PHP_MINIT(regex) (INIT_FUNC_ARGS_PASSTHRU);
PHP_MINIT(file) (INIT_FUNC_ARGS_PASSTHRU);
PHP_MINIT(pack) (INIT_FUNC_ARGS_PASSTHRU);
Index: dns.c
===
RCS file: /repository/php4/ext/standard/dns.c,v
retrieving revision 1.44
diff -u -r1.44 dns.c
--- dns.c 18 Oct 2002 22:08:23 - 1.44
+++ dns.c 17 Nov 2002 20:28:34 -
@@ -16,7 +16,7 @@
+--+
*/
-/* $Id: dns.c,v 1.44 2002/10/18 22:08:23 sniper Exp $ */
+/* $Id: dns.c,v 1.44 2002/11/16 17:43:41 pollita Exp $ */
/* {{{ includes
*/
@@ -71,6 +71,13 @@
#include dns.h
/* }}} */
+#if HAVE_RES_SEARCH !(defined(__BEOS__)||defined(PHP_WIN32))
+typedef union {
+ HEADER qb1;
+ u_char qb2[65536];
+} querybuf;
+#endif
+
static char *php_gethostbyaddr(char *ip);
static char *php_gethostbyname(char *name);
@@ -276,6 +283,257 @@
#ifndef MAXHOSTNAMELEN
#define MAXHOSTNAMELEN 256
#endif /* MAXHOSTNAMELEN */
+
+#ifndef MAXRESOURCERECORDS
+#define MAXRESOURCERECORDS 64
+#endif /* MAXRESOURCERECORDS */
+
+PHP_MINIT_FUNCTION(dns) {
+ REGISTER_LONG_CONSTANT(DNS_ANY, T_ANY, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_A, T_A, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_MX, T_MX, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_CNAME, T_CNAME, CONST_CS |
CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_NS, T_NS, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_TXT, T_TXT, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_PTR, T_PTR, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_SOA, T_SOA, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_HINFO, T_HINFO, CONST_CS |
CONST_PERSISTENT);
+}
+
+/* {{{ php_parserr
+ */
+u_char *php_parserr(u_char *cp, querybuf *answer, int type_to_fetch,
zval
**subarray) {
+ u_short type, class, dlen;
+ u_long ttl;
+ long n, i;
+ char name[MAXHOSTNAMELEN];
+
+ n = dn_expand(answer-qb2, answer-qb2+65536, cp, name, (sizeof
name) -
2);
+ if (n 0) {
+ return NULL;
+ }
+ cp += n;
+
+ GETSHORT(type, cp);
+ GETSHORT(class, cp);
+ GETLONG(ttl, cp);
+ GETSHORT(dlen, cp);
+ if (type_to_fetch != T_ANY type != type_to_fetch) {
+ /* Should never actually occour */
+ cp += dlen;
+ return NULL;
+ }
+
+ MAKE_STD_ZVAL(*subarray);
+ if (array_init(*subarray) != SUCCESS) {
+ return NULL;
+ }
+ add_assoc_string(*subarray, host, name, 1);
+
+ switch (type) {
+ case T_A:
+ add_assoc_string(*subarray, type, A, 1);
+ sprintf(name, %d.%d.%d.%d, cp[0], cp[1], cp[2], cp[3]);
+ add_assoc_string(*subarray, ip, name, 1);
+ cp += dlen;
+ break;
+ case T_MX:
+ add_assoc_string(*subarray, type, MX, 1);
+ GETSHORT(n, cp);
+ add_assoc_long(*subarray, pri, n);
+ case T_CNAME:
+ if (type == T_CNAME)
+ add_assoc_string(*subarray, type, CNAME, 1);
+ case T_NS:
+ if (type == T_NS)
+ add_assoc_string(*subarray, type, NS, 1);
+ case T_PTR:
+ if (type == T_PTR)
+ add_assoc_string(*subarray, type, PTR, 1);
+ n = dn_expand( answer-qb2,
Re: [PHP-DEV] Re: Updated getanyrr.patch, now dns_getrecord.patch
On Sun, 2002-11-17 at 21:01, Melvyn Sopacua wrote: [...] $ uname -rs ld -lresolv BSD/OS 4.3 ld: cannot find -lresolv Not here, either:-) thekid@friebes:~ uname -rs ld -lresolv FreeBSD 4.7-STABLE /usr/libexec/elf/ld: cannot find -lresolv thekid@friebes:~ locate resolv|grep '\.so' /usr/compat/linux/lib/libresolv-2.1.2.so /usr/compat/linux/lib/libresolv.so.2 -- Timm Any sufficiently advanced bug is indistinguishable from a feature -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Updated getanyrr.patch, now dns_getrecord.patch
Alright, same for me. -- Regards. M.CHAILLAN Nicolas [EMAIL PROTECTED] www.WorldAKT.com Hébergement de sites internets. Timm Friebe [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] On Sun, 2002-11-17 at 21:01, Melvyn Sopacua wrote: [...] $ uname -rs ld -lresolv BSD/OS 4.3 ld: cannot find -lresolv Not here, either:-) thekid@friebes:~ uname -rs ld -lresolv FreeBSD 4.7-STABLE /usr/libexec/elf/ld: cannot find -lresolv thekid@friebes:~ locate resolv|grep '\.so' /usr/compat/linux/lib/libresolv-2.1.2.so /usr/compat/linux/lib/libresolv.so.2 -- Timm Any sufficiently advanced bug is indistinguishable from a feature -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] php4/configure.in.patch php4/ext/standard/dns_get_record.patch
This is to update configure.in so that configure checks for the existence
of res_nmkquery, res_nsend, and dn_expand which are needed by
dns_getrecord(). which is appearantly going to be dns_get_record
now
Speaking of which I've also attached dns_get_record.patch.txt to update my
previous patch which introduced the function as dns_getrecord
Pasting as text as well because of recent not-always-attaching issues in
my mail client.
php4/configure.in.patch
Index: configure.in
===
RCS file: /repository/php4/configure.in,v
retrieving revision 1.401
diff -u -r1.401 configure.in
--- configure.in15 Nov 2002 15:35:11 - 1.401
+++ configure.in17 Nov 2002 21:24:16 -
@@ -292,15 +292,17 @@
AC_CHECK_LIB(m, sin)
dnl Check for resolver routines.
-dnl Need to check for both res_search and __res_search
+dnl Need to check for both res_search and __res_search, as well as
res_nmkquery and res_nsend
dnl in -lc, -lbind, -lresolv and -lsocket
PHP_CHECK_FUNC(res_search, resolv, bind, socket)
+PHP_CHECK_FUNC(res_nmkquery, resolv, bind, socket)
+PHP_CHECK_FUNC(res_nsend, resolv, bind, socket)
-dnl Check for inet_aton and dn_skipname
+dnl Check for inet_aton, dn_skipname and dn_expand
dnl in -lc, -lbind and -lresolv
PHP_CHECK_FUNC(inet_aton, resolv, bind)
PHP_CHECK_FUNC(dn_skipname, resolv, bind)
-
+PHP_CHECK_FUNC(dn_expand, resolv, bind)
dnl Then headers.
dnl
-
php4/ext/standard/dns_get_record.patch
Index: basic_functions.c
===
RCS file: /repository/php4/ext/standard/basic_functions.c,v
retrieving revision 1.543
diff -u -r1.543 basic_functions.c
--- basic_functions.c 8 Nov 2002 15:49:32 - 1.543
+++ basic_functions.c 17 Nov 2002 20:28:34 -
@@ -17,7 +17,7 @@
+--+
*/
-/* $Id: basic_functions.c,v 1.543 2002/11/08 15:49:32 sterling Exp $ */
+/* $Id: basic_functions.c,v 1.543 2002/11/16 13:18:21 pollita Exp $ */
#include php.h
#include php_streams.h
@@ -440,6 +440,7 @@
#if HAVE_RES_SEARCH !(defined(__BEOS__) || defined(PHP_WIN32) ||
defined(NETWARE))
PHP_FE(checkdnsrr,
NULL)
+PHP_FE(dns_get_record,third_and_rest_force_ref)
PHP_FE(getmxrr,second_and_third_args_force_ref)
#endif
@@ -1021,6 +1022,7 @@
register_html_constants(INIT_FUNC_ARGS_PASSTHRU);
register_string_constants(INIT_FUNC_ARGS_PASSTHRU);
+ PHP_MINIT(dns) (INIT_FUNC_ARGS_PASSTHRU);
PHP_MINIT(regex) (INIT_FUNC_ARGS_PASSTHRU);
PHP_MINIT(file) (INIT_FUNC_ARGS_PASSTHRU);
PHP_MINIT(pack) (INIT_FUNC_ARGS_PASSTHRU);
Index: dns.c
===
RCS file: /repository/php4/ext/standard/dns.c,v
retrieving revision 1.44
diff -u -r1.44 dns.c
--- dns.c 18 Oct 2002 22:08:23 - 1.44
+++ dns.c 17 Nov 2002 20:28:34 -
@@ -16,7 +16,7 @@
+--+
*/
-/* $Id: dns.c,v 1.44 2002/10/18 22:08:23 sniper Exp $ */
+/* $Id: dns.c,v 1.44 2002/11/16 17:43:41 pollita Exp $ */
/* {{{ includes
*/
@@ -71,6 +71,13 @@
#include dns.h
/* }}} */
+#if HAVE_RES_SEARCH !(defined(__BEOS__)||defined(PHP_WIN32))
+typedef union {
+ HEADER qb1;
+ u_char qb2[65536];
+} querybuf;
+#endif
+
static char *php_gethostbyaddr(char *ip);
static char *php_gethostbyname(char *name);
@@ -276,6 +283,257 @@
#ifndef MAXHOSTNAMELEN
#define MAXHOSTNAMELEN 256
#endif /* MAXHOSTNAMELEN */
+
+#ifndef MAXRESOURCERECORDS
+#define MAXRESOURCERECORDS 64
+#endif /* MAXRESOURCERECORDS */
+
+PHP_MINIT_FUNCTION(dns) {
+ REGISTER_LONG_CONSTANT(DNS_ANY, T_ANY, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_A, T_A, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_MX, T_MX, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_CNAME, T_CNAME, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_NS, T_NS, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_TXT, T_TXT, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_PTR, T_PTR, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_SOA, T_SOA, CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(DNS_HINFO, T_HINFO, CONST_CS | CONST_PERSISTENT);
+}
+
+/* {{{ php_parserr
+ */
+u_char *php_parserr(u_char *cp, querybuf *answer, int type_to_fetch, zval
**subarray) {
+ u_short type, class, dlen;
+ u_long ttl;
+ long n, i;
+ char name[MAXHOSTNAMELEN];
+
+ n = dn_expand(answer-qb2, answer-qb2+65536, cp, name, (sizeof name) - 2);
+ if (n 0) {
+ return
[PHP-DEV] CVS Account Request: sedik23456
send more informations please -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/standard/tests/math/log.phpt coredump on Tru64
I wrote:
% cat log.c
#include stdio.h
#include math.h
int main()
{
printf(%g\n,log(0));
}
% gcc log.c -o log -lm
% ./log
-inf
That's on Linux. On Tru64, it prints:
-1.79769e+308
Apparently, there's a compiler switch to make it behave like on Linux:
% cc -ieee log.c -o log -lm
% ./log
-INF
man cc says:
-ieee
Ensure support of all portable features of the IEEE Standard for Binary
Floating-Point Arithmetic (ANSI/IEEE Std 754-1985), including the
treatment of denormalized numbers, NaNs, and infinities and the han-
dling of error cases. This option also sets the _IEEE_FP C preprocessor
macro.
For gcc, the same switch is named -mieee.
When PHP is compiled with -ieee, the log.phpt PASSes. Although the other
tests are not affected by -ieee, I guess it's a bit too late to
automatically add it for 4.3.0.
Regards...
Michael
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] php4/configure.in.patch php4/ext/standard/dns_get_record.patch
The last patch had some minor problems. Here is a reworked one attached.
I did:
-change php_error to php_error_docref
-added some error messages which should be rewritten again
i only wanted to point us to the problems.
-collected the autoconf information into one single define which
can be tested
-ws fixes
-minor fixes
-made the old functions alias names to the new dns_xxx functions
For me this stuff works now but i would expect dns_get_error(name,DNS_ANY)
to return all possible records. But when i use the call with DNS_ANY i receive
the NS records. To receive the A and MX entries i have to call the function
with the DNS_A and DNS_MX respectively. See example below
Any comments?
marcus
[marcus@zaphod php4-HEAD]$ php -r
'var_dump(dns_get_record(marcus-boerger.de,DNS_ANY));'
array(3) {
[0]=
array(5) {
[host]=
string(17) marcus-boerger.de
[type]=
string(2) NS
[target]=
string(14) dns.aixtra.net
[class]=
string(2) IN
[ttl]=
int(86400)
}
[1]=
array(5) {
[host]=
string(17) marcus-boerger.de
[type]=
string(2) NS
[target]=
string(20) ns2.pop-hannover.net
[class]=
string(2) IN
[ttl]=
int(86400)
}
[2]=
array(5) {
[host]=
string(17) marcus-boerger.de
[type]=
string(2) NS
[target]=
string(21) magrathea.aachalon.de
[class]=
string(2) IN
[ttl]=
int(86400)
}
}
[marcus@zaphod php4-HEAD]$ php -r
'var_dump(dns_get_record(marcus-boerger.de,DNS_A));'
array(1) {
[0]=
array(5) {
[host]=
string(17) marcus-boerger.de
[type]=
string(1) A
[ip]=
string(14) 212.42.230.204
[class]=
string(2) IN
[ttl]=
int(86400)
}
}
At 22:56 17.11.2002, Pollita wrote:
This is to update configure.in so that configure checks for the existence
of res_nmkquery, res_nsend, and dn_expand which are needed by
dns_getrecord(). which is appearantly going to be dns_get_record
now
Speaking of which I've also attached dns_get_record.patch.txt to update my
previous patch which introduced the function as dns_getrecord
Pasting as text as well because of recent not-always-attaching issues in
my mail client.
()
cvs -z3 -q diff basic_functions.c config.m4 dns.c dns.h (in directory
S:\php4-HEAD\ext\standard)
Index: basic_functions.c
===
RCS file: /repository/php4/ext/standard/basic_functions.c,v
retrieving revision 1.543
diff -u -r1.543 basic_functions.c
--- basic_functions.c 8 Nov 2002 15:49:32 - 1.543
+++ basic_functions.c 17 Nov 2002 23:25:02 -
@@ -17,7 +17,7 @@
+--+
*/
-/* $Id: basic_functions.c,v 1.543 2002/11/08 15:49:32 sterling Exp $ */
+/* $Id: basic_functions.c,v 1.543 2002/11/16 13:18:21 pollita Exp $ */
#include php.h
#include php_streams.h
@@ -31,6 +31,7 @@
#include ext/standard/info.h
#include ext/session/php_session.h
#include zend_operators.h
+#include ext/standard/dns.h
#include stdarg.h
#include stdlib.h
@@ -439,8 +440,13 @@
PHP_FE(gethostbynamel,
NULL)
#if HAVE_RES_SEARCH !(defined(__BEOS__) || defined(PHP_WIN32) || defined(NETWARE))
- PHP_FE(checkdnsrr,
NULL)
- PHP_FE(getmxrr,second_and_third_args_force_ref)
+ PHP_FE(dns_check_record,
+ NULL)
+ PHP_FALIAS(checkdnsrr, dns_check_record,
+ NULL)
+# if HAVE_DNS_FUNCS
+ PHP_FE(dns_get_record, third_and_rest_force_ref)
+ PHP_FE(dns_get_mx,
+second_and_third_args_force_ref)
+ PHP_FALIAS(getmxrr, dns_get_mx,
+ NULL)
+# endif
#endif
PHP_FE(getmyuid,
NULL)
@@ -1058,6 +1064,12 @@
# if HAVE_OPENSSL_EXT
php_register_url_stream_wrapper(https, php_stream_http_wrapper TSRMLS_CC);
php_register_url_stream_wrapper(ftps, php_stream_ftp_wrapper TSRMLS_CC);
+# endif
+#endif
+
+#if HAVE_RES_SEARCH !(defined(__BEOS__)||defined(PHP_WIN32) || defined(NETWARE))
+# if HAVE_DNS_FUNCS
+ PHP_MINIT(dns) (INIT_FUNC_ARGS_PASSTHRU);
# endif
#endif
Index: config.m4
===
RCS file: /repository/php4/ext/standard/config.m4,v
retrieving revision 1.47
diff -u -r1.47 config.m4
--- config.m4 30 Oct 2002 15:11:11 - 1.47
+++ config.m4 17 Nov 2002 23:25:03 -
@@ -237,6 +237,11 @@
AC_DEFINE(ENABLE_CHROOT_FUNC, 1,
Re: [PHP-DEV] [PATCH] php4/configure.in.patch php4/ext/standard/dns_get_record.patch
At 00:38 18.11.2002, Marcus Börger wrote:
The last patch had some minor problems. Here is a reworked one attached.
I did:
-change php_error to php_error_docref
-added some error messages which should be rewritten again
i only wanted to point us to the problems.
-collected the autoconf information into one single define which
can be tested
-ws fixes
-minor fixes
-made the old functions alias names to the new dns_xxx functions
For me this stuff works now but i would expect dns_get_error(name,DNS_ANY)
to return all possible records. But when i use the call with DNS_ANY i receive
the NS records. To receive the A and MX entries i have to call the function
with the DNS_A and DNS_MX respectively. See example below
Seems to be a timing problem. Sometimes i get more than the NS records for
DNS_ANY. Is there any way to say i want all?
Any comments?
marcus
[marcus@zaphod php4-HEAD]$ php -r
'var_dump(dns_get_record(marcus-boerger.de,DNS_ANY));'
array(3) {
[0]=
array(5) {
[host]=
string(17) marcus-boerger.de
[type]=
string(2) NS
[target]=
string(14) dns.aixtra.net
[class]=
string(2) IN
[ttl]=
int(86400)
}
[1]=
array(5) {
[host]=
string(17) marcus-boerger.de
[type]=
string(2) NS
[target]=
string(20) ns2.pop-hannover.net
[class]=
string(2) IN
[ttl]=
int(86400)
}
[2]=
array(5) {
[host]=
string(17) marcus-boerger.de
[type]=
string(2) NS
[target]=
string(21) magrathea.aachalon.de
[class]=
string(2) IN
[ttl]=
int(86400)
}
}
[marcus@zaphod php4-HEAD]$ php -r
'var_dump(dns_get_record(marcus-boerger.de,DNS_A));'
array(1) {
[0]=
array(5) {
[host]=
string(17) marcus-boerger.de
[type]=
string(1) A
[ip]=
string(14) 212.42.230.204
[class]=
string(2) IN
[ttl]=
int(86400)
}
}
At 22:56 17.11.2002, Pollita wrote:
This is to update configure.in so that configure checks for the existence
of res_nmkquery, res_nsend, and dn_expand which are needed by
dns_getrecord(). which is appearantly going to be dns_get_record
now
Speaking of which I've also attached dns_get_record.patch.txt to update my
previous patch which introduced the function as dns_getrecord
Pasting as text as well because of recent not-always-attaching issues in
my mail client.
()
--
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
Re: [PHP-DEV] [PATCH] php4/configure.in.patch php4/ext/standard/dns_get_record.patch
I have worked a bit on the dns stuff and now i get all my entries. The patch behind the url below introduces a new constant DNS_ALL which queries all types one by one. As a result we have the original meaning of DNS_ANY = 'any entry' and the new DNS_ALL if you want all entries. http://marcus-boerger.de/dns_get_record.diff marcus At 00:38 18.11.2002, Marcus Börger wrote: The last patch had some minor problems. Here is a reworked one attached. I did: -change php_error to php_error_docref -added some error messages which should be rewritten again i only wanted to point us to the problems. -collected the autoconf information into one single define which can be tested -ws fixes -minor fixes -made the old functions alias names to the new dns_xxx functions For me this stuff works now but i would expect dns_get_error(name,DNS_ANY) to return all possible records. But when i use the call with DNS_ANY i receive the NS records. To receive the A and MX entries i have to call the function with the DNS_A and DNS_MX respectively. See example below Any comments? (...) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] on the subject of overloading: __call()
On Sun, 17 Nov 2002, Stanislav Malyshev wrote:
BB related topic: in the current state of ze2, there are several ways to
BB call methods directly that can't be emulated by call_user_func() -
BB calling self::method() for instance, or the visibility of $this if
BB you call class::method(). is that likely to stay true?
Since __call is the method of the class, calling self::method can be
achieved, I think. As for the second point - could you please explain
furher what you mean, maybe with an example?
right, because static method calls don't get caught by __call, so you
always have $this.
the basic problem is that as it is now, if i do any of these
self::a_method($arg1,$arg2);
parent::a_method($arg1,$arg2);
some_other_class::a_method($arg1,$arg2);
inside of a class's method, $this is visible inside those called methods,
and points to the calling object.
but there is no way to make equivalent calls using call_user_func()
or call_user_func_array(). you can't use parent::a_method,
array($this,'parent::a_method'), array(parent,a_method),
or array('parent',a_method). if you use the literal class name,
call_user_func_array(array(get_parent_class($this),'a_method'), $args);
it doesn't fail, but it's as if you were making a static method call
from outside of an object context - $this is not defined.
it's the last two cases - parent:: and some_other_class:: - that relate
to __call(), as you point out. and what truly matters is call_user_func_array(),
because not having it means you can't hand off the arguments from __call()'s
parameters to a method in the parent class or in some other class. not without
writing some pretty hacky eval() code, that is.
(btw, there should probably be a warning in the docs that methods that
are expecting to force their parameters to be references will not work
as expected when called by call_user_func_array().)
i'm attaching kind of long test case code resulting output that
show what i mean.
?php
class bar
{
var $z = 'initial value of z for bar';
function test($x=NULL,$y=NULL)
{
print \tthis is bar::test x=.var_export($x,TRUE). y=$y\n;
if (isset($this))
{
print \tbar::test - this-z = {$this-z}\n;
}
else
{
print \tbar::test - this is not set\n;
}
}
function __call($m,$a) {}
}
class base
{
var $z = 'initial value of z for base';
function test($x=NULL,$y=NULL)
{
print \tthis is base::test x=.var_export($x,TRUE). y=$y\n;
if (isset($this))
{
print \tbase::test - this-z = {$this-z}\n;
}
else
{
print \tbase::test - this is not set\n;
}
self::whoami('self::whoami from base::test');
}
function __call($m,$a) {}
function whoami($caller=NULL)
{
print \twhoami caller=$caller: __CLASS__ = .__CLASS__.\n;
$class = get_class(new self);
print \twhoami caller=$caller: get_class(new self) = $class\n;
$class = get_class('self');
print \twhoami caller=$caller: get_class('self') = $class\n;
if (isset($this))
{
$class = get_class($this);
}
else
{
$class = '$this is not set';
}
print \twhoami caller=$caller: get_class(this) = $class\n;
}
}
class foo extends base
{
var $z = 'initial value of z for foo';
function test($x=NULL,$y=NULL)
{
print \tthis is foo::test x=.var_export($x,TRUE). y=$y\n;
if (isset($this))
{
print \tfoo::test - this-z = {$this-z}\n;
}
else
{
print \tfoo::test - this is not set\n;
}
self::whoami('self::whoami from foo::test');
}
function test_parent($x=NULL,$y=NULL)
{
ob_start();
$results = '';
$results .= this is foo::test_parent x=.var_export($x,TRUE).
y=$y\n;
if (isset($this))
{
$results .= foo::test_parent - this-z = {$this-z}\n;
}
else
{
$results .= foo::test_parent - this is not set\n;
}
$results .= \n-\n;
$results .= __CLASS__.'::'.__FUNCTION__.'['.__LINE__.']
parent::test($x,$y);'.\n;
parent::test($x,$y);
Re: [PHP-DEV] [PATH] update to earlier proposed patch for getanyrr()function addition
Wouldn't it make sense to move this to it's own extension? It would make it easier to maintain and keep the configure scripts readable.. :) --Jani On Sun, 17 Nov 2002, Marcus Börger wrote: Function is nice but the function name is not. Attached is a second revised patch that fixes the build problems. marcus At 00:11 17.11.2002, Pollita wrote: Per corrections suggested by [EMAIL PROTECTED], attached is a revised pacth to ext/standard/dns.c for addition of getanyrr() function. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- - For Sale! - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] php4/configure.in.patch php4/ext/standard/dns_get_record.patch
Yay finally we use constant for that. Very nice work ! -- Regards. M.CHAILLAN Nicolas [EMAIL PROTECTED] www.WorldAKT.com Hébergement de sites internets. Marcus Börger [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] I have worked a bit on the dns stuff and now i get all my entries. The patch behind the url below introduces a new constant DNS_ALL which queries all types one by one. As a result we have the original meaning of DNS_ANY = 'any entry' and the new DNS_ALL if you want all entries. http://marcus-boerger.de/dns_get_record.diff marcus At 00:38 18.11.2002, Marcus Börger wrote: The last patch had some minor problems. Here is a reworked one attached. I did: -change php_error to php_error_docref -added some error messages which should be rewritten again i only wanted to point us to the problems. -collected the autoconf information into one single define which can be tested -ws fixes -minor fixes -made the old functions alias names to the new dns_xxx functions For me this stuff works now but i would expect dns_get_error(name,DNS_ANY) to return all possible records. But when i use the call with DNS_ANY i receive the NS records. To receive the A and MX entries i have to call the function with the DNS_A and DNS_MX respectively. See example below Any comments? (...) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATH] update to earlier proposed patch for getanyrr() function addition
I don't think so. It is only a small extension to the functionality we have already. If there would be more functionality to add during the next release cycle i would agree to move this to a new extension. But let's here the others. marcus At 02:47 18.11.2002, Jani Taskinen wrote: Wouldn't it make sense to move this to it's own extension? It would make it easier to maintain and keep the configure scripts readable.. :) --Jani On Sun, 17 Nov 2002, Marcus Börger wrote: Function is nice but the function name is not. Attached is a second revised patch that fixes the build problems. marcus At 00:11 17.11.2002, Pollita wrote: Per corrections suggested by [EMAIL PROTECTED], attached is a revised pacth to ext/standard/dns.c for addition of getanyrr() function. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- - For Sale! - -- 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] Limitations of the ZendEngine2 Object Model?
Hello,
I've been following the developments of the latest ZE2-enabled PHP for a
while, and I feel that some of the work regarding namespaces/nested classes
aren't quite doing what they are suppose to. An example:
?php
class Root {
class Nested {
function Nested() {
print(Root::Nested constructed\n);
}
}
}
class Child extends Root {
class Nested {
function Nested() {
parent::Nested();
print(Child::Nested constructed\n);
}
}
}
$object = new Child::Nested;
?
If you attempt to execute this script with the PHP 4.3.0 ZE2 alphas (either
1 or 2), you'll get a fatal error specifying that Cannot fetch parent:: as
current class scope has no parent, referring to the Child::Nested
constructor and the parent::Nested(); line. Is the outer classes just
meant to be for namespacing purposes? Any class deriving from the parent
will not have its nested classes derive from the parents nested classes. So
then why can't nested classes be extended from anything? Just some
symbolism: P is parent, defines P.n is nested, D extends P, defines D.n
nested, yet D.n has no relation to P.n and is not allowed to extend it
explicitly (wouldn't it be implicit, with the same name and all?), nor any
other class. Doesn't quite seem to be the intended behaviour or one that
does justice to nested class or packaging/namespacing.
I think nested classes are themselves a useful language component, but
nested classes and namespaces should be handled separately. But then scoping
issues come back. Does anyone have any ideas? I'm new to the internals side
of PHP so my apologizes if these are non-issues.
Pete
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] php4/configure.in.patch php4/ext/standard/dns_get_record.patch
And for the last time i have updated it and now it does what i suspected...(sorry for all the mails) At 02:32 18.11.2002, Marcus Börger wrote: I have worked a bit on the dns stuff and now i get all my entries. The patch behind the url below introduces a new constant DNS_ALL which queries all types one by one. As a result we have the original meaning of DNS_ANY = 'any entry' and the new DNS_ALL if you want all entries. http://marcus-boerger.de/dns_get_record.diff marcus At 00:38 18.11.2002, Marcus Börger wrote: The last patch had some minor problems. Here is a reworked one attached. I did: -change php_error to php_error_docref -added some error messages which should be rewritten again i only wanted to point us to the problems. -collected the autoconf information into one single define which can be tested -ws fixes -minor fixes -made the old functions alias names to the new dns_xxx functions For me this stuff works now but i would expect dns_get_error(name,DNS_ANY) to return all possible records. But when i use the call with DNS_ANY i receive the NS records. To receive the A and MX entries i have to call the function with the DNS_A and DNS_MX respectively. See example below Any comments? (...) -- 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
Re: [PHP-DEV] Re: Support for Birdstep RDM Server database engine
Thanks Dan, From looking at the module that was in ./ext/odbc, it was created using a somewhat earlier release of the RDM Server/Velocis (circa Velocis v2.x). I had to make a number of changes related to API changes in Birdstep's libraries to support ODBC 3.51. I've also started laying the groundwork to take advantage of scrollable cursors (a painful omission from the current version of RDM Server). Since there doesn't seem to be anyone familiar with Birdstep, I guess I could volunteer to be the 'expert'. In reality, I was the first beta and deployed customer back in '92, and later went to work for the company (then Raima) in '94. I was a Sr. Proj. Lead and Eng. Mgr. for their consulting subsidiary (Vista Development) until late 2000. These days I'm running my own business and use PHP for a variety of needs. But with Birdstep wanting this module, I became interested in being able to give back to the community more directly. Supporters are great, but sometimes someone needs to get in the trenches and I guess I'm silly enough to want to do it. ;) With respect to the changes, I listed the changes that I've already made in the original post, but there are some additional mods that are needed. 1. There is currently no way to ensure that connections are closed properly. If a script doesn't call birdstep_close() the module will leak connection handles and will eventually exhaust available connections on the server. 2. Birdstep's support for LONG VARCHAR columns has some limitations surrounding use of SQLFetch vs. SQLFetchScroll. To meet Birdstep's needs, I am using fixed buffers for these columns in the module. I'm looking at the possibility of using RDM Server's BLOB handling functions (the 'd_' API) to allow for more efficient handling of these columns. 3. There are some significant improvements that could be made to the error handling. The module currently has no access to error information returned from the server. There are also a few places in the code that could be handled a little more gracefully if an error occurs. As for the PECL module, I'll have to do a little more investigation into what would be required. I got started with the standard extension architecture and worked from there. If the change to PECL is straightfoward, I'll go ahead and start looking at getting that done. If you can point at any good reference sources, I'd be most thankful! :-D Diggy - Original Message - From: Dan Kalowsky [EMAIL PROTECTED] To: Diggy Bell [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, November 17, 2002 12:42 PM Subject: Re: [PHP-DEV] Re: Support for Birdstep RDM Server database engine Hello Diggy, Birdstep was rolled into the ODBC functionality, and has really not seen any support since. I don't believe anyone currently on the PHP staff is really familiar with the way the Birdstep systems work. The reality is though that I don't see many PHP users using Birdstep/Velocis support. This could of course be a chicken/egg problem, where the PHP support is lacking etc etc... What are the changes you're planning to do? If you'd like to make birdstep it's own module, I'd suggest looking at creating it as a PECL module, and working from there. Typically we don't discourage integration with systems/API's, especially if the author is willing to maintain it :) On Sunday, November 17, 2002, at 03:30 PM, Diggy Bell wrote: Hello again, I've not heard anything from anybody regarding my previous post. My first thought is that everyone is caught up in the release activities, but I would appreciate any comments that anyone might be able to offer. Thanks, Diggy Diggy Bell [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hello All, I have recently been approached by Birdstep about updating the PHP module to support their database engine for an internal project. In the past (v4.1.2 and earlier IIRC), PHP has provided support for the Birdstep (formerly Velocis) database as part of the distribution. Since v4.1.2 (IIRC) this support has been dropped in the standard source tree. But, I was able to locate the old code under ./ext/odbc and so I have resurrected the module. In the process, I have made a number of modifications and additions to the library to bring it up to date with the latest version of Birdstep's product. My main question is: Is this module something that the community would like to have available again? If so, I am willing to pick up the maintenance duties on the module. I'm a former employee of the company and have access to 'back-door' support when necessary. I've taken a bit of time and put together some notes on the modifications that I have made to this point. These notes are copied below for review. I've also attached the modified source files. (NOTE: I realize these aren't formatted to PHP standards...please let me slide
RE: [PHP-DEV] Re: Support for Birdstep RDM Server database engine
fwiw, i have also meddled with birdstep slightly, by making the namechange from velocis to birdstep. I agree with Dan -- i think it should be pecl'ed, and perhaps not so reliant on the odbc stuff -- that whole extension is just confusing. That said, Dan is the best person to work on with this. -- james -Original Message- From: Diggy Bell [mailto:[EMAIL PROTECTED]] Sent: Monday, November 18, 2002 3:49 AM To: Dan Kalowsky Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Re: Support for Birdstep RDM Server database engine Thanks Dan, From looking at the module that was in ./ext/odbc, it was created using a somewhat earlier release of the RDM Server/Velocis (circa Velocis v2.x). I had to make a number of changes related to API changes in Birdstep's libraries to support ODBC 3.51. I've also started laying the groundwork to take advantage of scrollable cursors (a painful omission from the current version of RDM Server). Since there doesn't seem to be anyone familiar with Birdstep, I guess I could volunteer to be the 'expert'. In reality, I was the first beta and deployed customer back in '92, and later went to work for the company (then Raima) in '94. I was a Sr. Proj. Lead and Eng. Mgr. for their consulting subsidiary (Vista Development) until late 2000. These days I'm running my own business and use PHP for a variety of needs. But with Birdstep wanting this module, I became interested in being able to give back to the community more directly. Supporters are great, but sometimes someone needs to get in the trenches and I guess I'm silly enough to want to do it. ;) With respect to the changes, I listed the changes that I've already made in the original post, but there are some additional mods that are needed. 1. There is currently no way to ensure that connections are closed properly. If a script doesn't call birdstep_close() the module will leak connection handles and will eventually exhaust available connections on the server. 2. Birdstep's support for LONG VARCHAR columns has some limitations surrounding use of SQLFetch vs. SQLFetchScroll. To meet Birdstep's needs, I am using fixed buffers for these columns in the module. I'm looking at the possibility of using RDM Server's BLOB handling functions (the 'd_' API) to allow for more efficient handling of these columns. 3. There are some significant improvements that could be made to the error handling. The module currently has no access to error information returned from the server. There are also a few places in the code that could be handled a little more gracefully if an error occurs. As for the PECL module, I'll have to do a little more investigation into what would be required. I got started with the standard extension architecture and worked from there. If the change to PECL is straightfoward, I'll go ahead and start looking at getting that done. If you can point at any good reference sources, I'd be most thankful! :-D Diggy - Original Message - From: Dan Kalowsky [EMAIL PROTECTED] To: Diggy Bell [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, November 17, 2002 12:42 PM Subject: Re: [PHP-DEV] Re: Support for Birdstep RDM Server database engine Hello Diggy, Birdstep was rolled into the ODBC functionality, and has really not seen any support since. I don't believe anyone currently on the PHP staff is really familiar with the way the Birdstep systems work. The reality is though that I don't see many PHP users using Birdstep/Velocis support. This could of course be a chicken/egg problem, where the PHP support is lacking etc etc... What are the changes you're planning to do? If you'd like to make birdstep it's own module, I'd suggest looking at creating it as a PECL module, and working from there. Typically we don't discourage integration with systems/API's, especially if the author is willing to maintain it :) On Sunday, November 17, 2002, at 03:30 PM, Diggy Bell wrote: Hello again, I've not heard anything from anybody regarding my previous post. My first thought is that everyone is caught up in the release activities, but I would appreciate any comments that anyone might be able to offer. Thanks, Diggy Diggy Bell [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hello All, I have recently been approached by Birdstep about updating the PHP module to support their database engine for an internal project. In the past (v4.1.2 and earlier IIRC), PHP has provided support for the Birdstep (formerly Velocis) database as part of the distribution. Since v4.1.2 (IIRC) this support has been dropped in the standard source tree. But, I was able to locate the old code under ./ext/odbc and so I have resurrected the module. In the process, I have made a number of modifications and additions to the
Re: [PHP-DEV] Limitations of the ZendEngine2 Object Model?
Pete McCormick wrote:
class Root {
class Nested {
function Nested() {
The constructor should be called __construct(). Constructors with their
name beeing the class name are only supported for BC.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: #20461 [Opn-Bgs]: Unable to access $PHP_AUTH_USER or $PHP_AUTH_PW
I'm still not overly convinced that this isn't a restriction that should only kick in when safe_mode or open_basedir is active. This change is going to break working code and it is not a security fix on non-shared servers. -Rasmus On 18 Nov 2002 [EMAIL PROTECTED] wrote: ID: 20461 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache related Operating System: Linux 2.4.8 PHP Version: 4CVS-2002-11-17 New Comment: Then that is an external auth mechanism and means this is not a bug in PHP: From: http://www.php.net/manual/en/features.http-auth.php In order to prevent someone from writing a script which reveals the password for a page that was authenticated through a traditional external mechanism, the PHP_AUTH variables will not be set if external authentication is enabled for that particular page. In this case, REMOTE_USER can be used to identify the externally-authenticated user. So, $_SERVER['REMOTE_USER']. Configuration Note: PHP uses the presence of an AuthType directive to determine whether external authentication is in effect. Remember to avoid this directive for the context where you want to use PHP authentication (otherwise each authentication attempt will fail). There was a bug in previous PHP 4 versions which let the external authenticated usernames and passwords to be revealed for scripts. This is fixed in PHP 4.3.0. (btw. you really should upgrade your apache to 1.3.27! And forget Apache2, it really is not ready for production use) Previous Comments: [2002-11-17 22:45:43] [EMAIL PROTECTED] forgot to answer your other question.. using apache 1.3.20 -- been wanting to upgrade to 2.0 but have had a whole different set of problems w/ that, so taking things one step at a time... [2002-11-17 22:43:25] [EMAIL PROTECTED] tried using $_SERVER already, no dice. i meant using the mod_auth module in apache to protect certain directories.. when those directories are accessed, the browser pops up a window for the user to enter in their username/password for that resource... [2002-11-17 22:23:00] [EMAIL PROTECTED] I can not reproduce this, it works fine here. Try accessing the variables through $_SERVER variable: $_SERVER['PHP_AUTH_USER'] $_SERVER['PHP_AUTH_PW'] And what Apache version are you using? What do you mean with regular http authentication through apache ?? [2002-11-17 22:09:27] [EMAIL PROTECTED] not using any external auth... simply using regular http authentication through apache... certain directories on the webserver are protected, and so it pops up the box asking the user for username/password.. and then rather then ask them AGAIN for a login for some of my web-based apps, i simply pass the http auth info (via $PHP_AUTH_USER and $PHP_AUTH_PW) along to these apps. the only problem is, those 2 variables don't seem to exist anymore for me. nothing has changed in my configuration except for the fact that i'm now using the cvs version of php as opposed to 4.2.3 (if you read in my original bug report it explains why). [2002-11-17 20:13:05] [EMAIL PROTECTED] Are you using some external auth mechanism? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20461 -- Edit this bug report at http://bugs.php.net/?id=20461edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20461 [Opn-Bgs]: Unable to access $PHP_AUTH_USERor $PHP_AUTH_PW
On Sun, 17 Nov 2002, Rasmus Lerdorf wrote: I'm still not overly convinced that this isn't a restriction that should only kick in when safe_mode or open_basedir is active. This change is going to break working code and it is not a security fix on non-shared servers. True, but it was clearly documented that it shouldn't work. Do we really have to make a feature out of every bug? I'd say no... Derick ID: 20461 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache related Operating System: Linux 2.4.8 PHP Version: 4CVS-2002-11-17 New Comment: Then that is an external auth mechanism and means this is not a bug in PHP: From: http://www.php.net/manual/en/features.http-auth.php In order to prevent someone from writing a script which reveals the password for a page that was authenticated through a traditional external mechanism, the PHP_AUTH variables will not be set if external authentication is enabled for that particular page. In this case, REMOTE_USER can be used to identify the externally-authenticated user. So, $_SERVER['REMOTE_USER']. Configuration Note: PHP uses the presence of an AuthType directive to determine whether external authentication is in effect. Remember to avoid this directive for the context where you want to use PHP authentication (otherwise each authentication attempt will fail). There was a bug in previous PHP 4 versions which let the external authenticated usernames and passwords to be revealed for scripts. This is fixed in PHP 4.3.0. (btw. you really should upgrade your apache to 1.3.27! And forget Apache2, it really is not ready for production use) Previous Comments: [2002-11-17 22:45:43] [EMAIL PROTECTED] forgot to answer your other question.. using apache 1.3.20 -- been wanting to upgrade to 2.0 but have had a whole different set of problems w/ that, so taking things one step at a time... [2002-11-17 22:43:25] [EMAIL PROTECTED] tried using $_SERVER already, no dice. i meant using the mod_auth module in apache to protect certain directories.. when those directories are accessed, the browser pops up a window for the user to enter in their username/password for that resource... [2002-11-17 22:23:00] [EMAIL PROTECTED] I can not reproduce this, it works fine here. Try accessing the variables through $_SERVER variable: $_SERVER['PHP_AUTH_USER'] $_SERVER['PHP_AUTH_PW'] And what Apache version are you using? What do you mean with regular http authentication through apache ?? [2002-11-17 22:09:27] [EMAIL PROTECTED] not using any external auth... simply using regular http authentication through apache... certain directories on the webserver are protected, and so it pops up the box asking the user for username/password.. and then rather then ask them AGAIN for a login for some of my web-based apps, i simply pass the http auth info (via $PHP_AUTH_USER and $PHP_AUTH_PW) along to these apps. the only problem is, those 2 variables don't seem to exist anymore for me. nothing has changed in my configuration except for the fact that i'm now using the cvs version of php as opposed to 4.2.3 (if you read in my original bug report it explains why). [2002-11-17 20:13:05] [EMAIL PROTECTED] Are you using some external auth mechanism? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20461 -- Edit this bug report at http://bugs.php.net/?id=20461edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20461 [Opn-Bgs]: Unable to access $PHP_AUTH_USERor $PHP_AUTH_PW
On Mon, 18 Nov 2002, Derick Rethans wrote: On Sun, 17 Nov 2002, Rasmus Lerdorf wrote: I'm still not overly convinced that this isn't a restriction that should only kick in when safe_mode or open_basedir is active. This change is going to break working code and it is not a security fix on non-shared servers. True, but it was clearly documented that it shouldn't work. Do we really have to make a feature out of every bug? I'd say no... But why do you assume that the documentation was right and the code was wrong and not the other way around? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] php4/configure.in.patch php4/ext/standard/dns_get_record.patch
On Mon, 18 Nov 2002, Marcus Börger wrote:
The last patch had some minor problems. Here is a reworked one attached.
I did:
-change php_error to php_error_docref
-added some error messages which should be rewritten again
i only wanted to point us to the problems.
-collected the autoconf information into one single define which
can be tested
-ws fixes
-minor fixes
-made the old functions alias names to the new dns_xxx functions
For me this stuff works now but i would expect dns_get_error(name,DNS_ANY)
to return all possible records. But when i use the call with DNS_ANY i receive
the NS records. To receive the A and MX entries i have to call the function
with the DNS_A and DNS_MX respectively. See example below
Maybe it's a good idea to make the type a bitfield so that you can do
something like:
dns_get_record(php.net, DNS_A | DNS_MX); and then get something along
this back:
array(2) {
[A]=
[MX]=
}
I think that would be the most useful API.
Derick
--
---
Derick Rethans http://derickrethans.nl/
JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATH] update to earlier proposed patch for getanyrr()function addition
On Mon, 18 Nov 2002, Marcus Börger wrote: I don't think so. It is only a small extension to the functionality we have already. If there would be more functionality to add during the next release cycle i would agree to move this to a new extension. But let's here the others. It's only 2 functions for now, IMO it doesn't warrant a new extention yet. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20461 [Opn-Bgs]: Unable to access $PHP_AUTH_USERor $PHP_AUTH_PW
On Sun, 17 Nov 2002, Rasmus Lerdorf wrote: On Mon, 18 Nov 2002, Derick Rethans wrote: On Sun, 17 Nov 2002, Rasmus Lerdorf wrote: I'm still not overly convinced that this isn't a restriction that should only kick in when safe_mode or open_basedir is active. This change is going to break working code and it is not a security fix on non-shared servers. True, but it was clearly documented that it shouldn't work. Do we really have to make a feature out of every bug? I'd say no... But why do you assume that the documentation was right and the code was wrong and not the other way around? Because it was working like documented before. (When the documentation was written). Anyway, not sure what to do with this one... Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20461 [Opn-Bgs]: Unable to access $PHP_AUTH_USERor $PHP_AUTH_PW
But why do you assume that the documentation was right and the code was wrong and not the other way around? Because it was working like documented before. (When the documentation was written). Anyway, not sure what to do with this one... I don't have the energy to do a cvs check, but I remember adding this restriction years ago (php2 days) and then removing it (by commenting out the check) ages ago as well. I'm not sure PHP4 ever had this check turned on (the commented out check was ported to php4), so the documentation has not reflected reality in a very long time. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] error handling
I think in a modern web application the error handling function should do the following: in case of error (any: parse error, internal application error,) 1. a message should be shown to the user sayng that an error has occured like an internal error has occured. the webmaster has been notified via email 2. a more detailed message should be logged in a generic system ErrorLog, or notified via email or fax, or telephone, or SMS. Depending on the severity of the error (warning, fatal,...) All this done with PHP error handling function (this is not to male distinction between PHP error and application internal error), and the ErrorLog kept via system/server methods (like syslogd). The message shown to the user should be accompained by an HTTP 500 (or more) error. This to make clear to human users that an error has occured therefore the request cannot be fulfilled, and if the cliens is another computer (robot,...) to make it as well (computer look at error codes rather than at things written for humans. I know this is possible now, but not within the error handling function of PHP, or without setting a custom error handler. Mattia Cazzola -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
|I know this is possible now, but not within the error handling |function of PHP, or without setting a custom error handler. Well, it's not really possible now -- a E_PARSE won't get thrown to a custom PHP handler, it'll just die with a parse error. If there is an improvement to be made, perhaps something like what Apache does: Parse Error on line blah blah, Additionaly, there was XYZ error in errorhandle.php. Maybe I can look into this... I'm kinda busy right now though. John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
