RE: [PHP-DEV] Make Windows PHP Fork
This requires some Win32 magic in the invoking Win32 program, not in the generic PHP executable - so your question is somewhat off-topic for this list (though this may not have been apparent). The hint: STARTUPINFO si; memset(si,0,sizeof(si)); si.cb = sizeof(si); si.dwFlags = STARTF_USESTDHANDLES | STARTF_USESHOWWINDOW; si.wShowWindow = SW_HIDE; I'd expect you to be able to figure out the rest :). -Original Message- From: Adam Voigt [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 06, 2003 9:31 AM Is it possible to make the php.exe under window's fork, so it isn't visible in the start bar? I ask because I would like to make a PHP program that runs periodically in the background, and I know how to start it at computer start time, but it makes that damned dos window pop up. There are external programs to make it be hidden but they require seperate install's which makes it not an option. Any ideas? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Just for the record, there is no fork() on Win32. I have little doubt Sterling meant the Win32 equivalent :). The only reason I felt this worth mentioning is that fork() on Unix is a relatively cheap operation, and an advantage unique to Unix. Some have posted here of service providers that host huge numbers of low volume websites using PHP in CGI mode. On Win32 you only have one choice - start a new php.exe instance on every request. This is an expensive operation - possibly even more expensive than the equivalent operation on Unix. On Unix you have another *potential* choice - load the php executable once and fork() on each request. The presence of fork() on Unix offers (at least in theory) a unique performance advantage over Win32. -Original Message- From: Sterling Hughes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 7:50 AM Just as a note to this, under windows using PHP as a CGI is actually ideal when you're not serving high traffic stuff, like for example the company intranet, or a small extranet. PHP is heavily used for such purposes, and you most likely won't run into a bottleneck from forking php in these cases. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Thanks Hartmut, that added some much needed clarity. One comment I have to offer is the clutter you mention strongly suggests a refactoring was needed to lift from common code the CLI or CGI affected code. Including or omitting entire modules appropriate for each environment is also a pretty good argument for seperating the two variants. As Leon has suggested, why not just compile the variants into different directories? Say add a cli/ (since the CLI is newer). Only one directory would go into the PATH (presumably). In the case of the Win32 variant, it looks like distinct DLLs (if using a PHP DLL) might be a good idea. -Original Message- From: Hartmut Holzgraefe [mailto:[EMAIL PROTECTED]] Sent: Monday, December 09, 2002 8:44 AM Shane Caraveo wrote: It would have been simple enough to combine cli into the cgi binary and be done with it, and I suggested as much that it should be done a very long time ago. I don't recall any major reasons why it wasn't done, other than that cli has been experimental. Way back CGI and CLI *did* share one binary (the CGI binary) and the code was cluttered with code behaviour depending on the environment the binary was called in. The code with all these situation-dependant if() blocks was a true mess getting even worse with every new CGI- or CLI-only feature added. Even worse: some features and extensions don't make sense in a CGI (ncurses, gtk, pcntl, argc/argv parsing) while other features belong into a CGI binary only. The introduction of the seperate CLI binary or SAPI happened for two reasons: - removal of situation-dependant code in the CGI thus cleaning up the code base(as stated above) - the ability to build the CLI alongside with *every* SAPI So we can argue about binary naming, but definetly *not* about about the CGI/CLI split. No matter how similar the two binaries might look, they *aren't* -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Admittedly I didn't hear whatever discussion went on before, but I wonder why the need for two different executables? It seems that the presence of the CGI variables SERVER_NAME and SERVER_SOFTWARE are pretty big hints, so you could decide at runtime whether to act as CGI or CLI. For completeness add a couple command line option to force CLI or CGI behavior and you're pretty much done. -Original Message- From: Marcus Borger [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 08, 2002 9:50 AM At 17:55 08.12.2002, Philip Olson wrote: Wait, so there used to be a php-cli.exe ? Add that to the history request question :) And so a user tries to install via some install tutorial on foo.com, what problems/errors will they see when accessing via the browser? Philip There was no spoon :-) ok start again: There was no cli and only cgi binary called php.exe. Then we decided to have a command line executable (abbrevation CLI). And the we decided to use 'php.exe' for the new CLI and to avoid confusion we chose to rename the CGI binary from 'php.exe'. So now there will be some books and other papers and online docs out there which state that php.exe has to be installedIn other words there will be users who install CLI as CGI what will lead into errors. marcuis -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] New changes to ext_skel for C++
That would be a big YES - as in practically all C++ compilers. It was a
part of the draft ANSI standard for C++ for rather a long time (but not in
the final standard?).
-Original Message-
From: Stig S. Bakken [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 04, 2002 1:23 AM
Isn't __cplusplus defined for all C++ compilers?
#ifdef __cplusplus
extern C {
#endif
#ifdef __cplusplus
}
#endif
This is pretty common in library header files at least.
- Stig
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] useless config.w32.h and solutions
There is an impedence mismatch here between typical usage on Unix and typical usage on Windows. Some infomation that can typically be compiled-in on Unix must be determined at runtime on Windows. I don't believe the environment is really a good place to be expecting this information - not on Windows. You run into trouble with differing applications (bundling PHP) needing to use differing values. If any of this is run from a service context - it's just not going to work out well. There is a logical approach to deriving most or all this information on Windows that works out a bit more cleanly. Lets start from the beginning. PHP_BINDIR c:\\php4 PEAR_INSTALLDIR c:\\php4\\pear PHP_CONFIG_FILE_PATH PHP_CONFIG_FILE_SCAN_DIR PHP_DATADIR c:\\php4 PHP_EXTENSION_DIR c:\\php4 PHP_INCLUDE_PATH.;c:\\php4\\pear PHP_LIBDIR c:\\php4 PHP_LOCALSTATEDIR c:\\php4 PHP_PREFIX c:\\php4 PHP_SYSCONFDIR c:\\php4 PHP_BINDIR can be exactly determined at runtime (using GetModuleHandle() and GetModuleFileName() - I can supply the idiom and bewares). Once you know where PHP was installed, you can assume by default the other directories as relative. So you have: PHP_DATADIR %PHP_BINDIR% PHP_EXTENSION_DIR %PHP_BINDIR% PHP_INCLUDE_PATH.;%PHP_BINDIR% PHP_LIBDIR %PHP_BINDIR% PHP_LOCALSTATEDIR %PHP_BINDIR% PHP_PREFIX %PHP_BINDIR% PHP_SYSCONFDIR %PHP_BINDIR% PEAR_INSTALLDIR %PHP_BINDIR%\\pear Since these are all computed values, it would be a good idea to eliminate the compile-time constants. Better to not pretend - as this will help you find code that might be a problem. Finally you go looking for a configuration file to override the defaults. If the configuration file was not specified on the command line, then you pick it up from (usually) the installation directory. ( Microsoft sells the idea of using the registry at this point, but in practice I've found it better to make only minimal use of the registry ). What I had not figured out last I had time to look at the code, was how to plug in computed values as though they were compiled in. -Original Message- From: Frank M. Kromann [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 01, 2002 11:55 AM Yu are right. Two of the values needs to be constants, as these are used in building the INI array. Setting the constants to this works: #define PEAR_INSTALLDIR (getenv(PEAR_INSTALLDIR))?getenv(PEAR_INSTALLDIR):c:\\php4\\pear #define PHP_BINDIR (getenv(PHP_BINDIR))?getenv(PHP_BINDIR):c:\\php4 #define PHP_CONFIG_FILE_PATH (getenv(PHP_CONFIG_FILE_PATH))?getenv(PHP_CONFIG_FILE_PATH): #define PHP_CONFIG_FILE_SCAN_DIR (getenv(PHP_CONFIG_FILE_SCAN_DIR))?getenv(PHP_CONFIG_FILE_SCAN_DIR): #define PHP_DATADIR (getenv(PHP_DATADIR))?getenv(PHP_DATADIR):c:\\php4 #define PHP_EXTENSION_DIR c:\\php4 #define PHP_INCLUDE_PATH .;c:\\php4\\pear #define PHP_LIBDIR (getenv(PHP_LIBDIR))?getenv(PHP_LIBDIR):c:\\php4 #define PHP_LOCALSTATEDIR (getenv(PHP_LOCALSTATEDIR))?getenv(PHP_LOCALSTATEDIR):c:\\php4 #define PHP_PREFIX (getenv(PHP_PREFIX))?getenv(PHP_PREFIX):c:\\php4 #define PHP_SYSCONFDIR (getenv(PHP_SYSCONFDIR))?getenv(PHP_SYSCONFDIR):c:\\php4 PHP_EXTENSION_DIR and PHP_INCLUDE_PATH can both be specified in php.ini and perhaps we can find a way to set them by environment variables ? - Frank On Sun, 01 Dec 2002 07:57:18 -0800 Frank M. Kromann [EMAIL PROTECTED] wrote: We could change it to something like this: #define PEAR_INSTALLDIR (getenv(PEAR_INSTALLDIR))?getenv(PEAR_INSTALLDIR):c:\\php4\\pear As far as I remember, that s what has been done weeks ago and causes a compile error. Can you test it on a win32 build ? I should do it later tonight or tomorrow. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] C++ extensions and ext_skel
There is nothing about using a C++ compiler that makes your code less efficient. The primary determinant is still overwhelmingly the programmer. C++ has *never* gotten in my way when writing extremely efficient programs, and in fact I find it a great help. The flip side is I've seen a lot of hideously inefficient C code. You can write inefficient code in any language. Keep in mind that PHP is a (usually) compile-at-runtime, interpreted language :). John Coggeshall wrote: Well, Personally I don't have any problem with introducing C++ into PHP so no argument there from me. I'm curious if using C++ as opposed to C would cause a performace hit? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] ereg to pcre conversion
Unfortunately I have to agree with Markus on this.
If we don't care very much about the risk of breaking backwards
compatibility then altering calls to the ereg functions is a perfectly fine
idea.
If we *do* care about backwards compatibility then *before* committing the
changes in any permanent fashion we need to be pretty near certain there
aren't any surprises. With the ereg functions any change could easily
impact thousands of sites.
We all miss things from time to time, so to be reasonably confident about
the changes you will need some peer review. This could be a lot of work.
Lacking time from a couple regex-gurus, you will want to make clear the
semantic equivalence of your changes. This means compiling a list of the
differences between ereg and pcre, and the corresponding changes in the
code.
With lots of eyeballs we *should* be able to spot any differences not
properly identified. Once clearly explained and understood the risk is much
less.
This can be a lot of work :).
The flip side is once done you could have code useful to far more than just
PHP. An adaptor to allow the pcre code to be used whereever the old regex
code was used might be useful to others.
-Original Message-
From: Markus Fischer [mailto:mfischer;guru.josefine.at]
Sent: Friday, November 01, 2002 11:12 PM
To: Ilia A.
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] [PATCH] ereg to pcre conversion
I somehow don't like the idea. Mostly because I fear we
introduce some BC change regarding to the ereg*
functionality we yet do not forsee which brings us in the end
more trouble (i.e. use complaining) then it's really worth.
Just let ereg* functions stay where they are, if people
complain because something doesn't work, rather tell them to
use the pcre* family.
After your patch, how sure can you be that all ereg* pattern
will work without any trouble? This would mean testing many
use apps out there ... is it worth the work?
Also, I haven't seen much maintainance needed in the both the
existing regular expression code.
I simply don't see a reason to change the inner functionality
and risk to introduce BC problems.
Also I don't see a reason to drop the ereg* function in some
future point (I see the point with emulating them, but see
above).
-1
On Thu, Oct 31, 2002 at 02:47:27PM -0500, Ilia A. wrote :
Currently PHP ships with two regular expression libraries that are both
installed by default, PCRE regex. The regex library that is responsible
for
ereg_* functions is fairly old and offers a very limited functionality
compared to the PCRE library. In most cases the PCRE functions are also
much
faster then the old ereg functions.
I would like to propose that we drop the old ereg library and use only
a single regular expression library, PCRE. For BC purposes I've written a
patch (see attached file), which emulates the old ereg_* functions for
people
who still rely on those, using PCRE.
This cleanup would mean we'd only need to maintain one set of regular
expression code, which as far as code goes is pretty complex as well as
give
speed-up for people still using ereg.
Perhaps, at some future point this would allow us to drop the ereg_*
functions
all together.
Ilia
Index: pcre/php_pcre.c
===
RCS file: /repository/php4/ext/pcre/php_pcre.c,v
retrieving revision 1.130
diff -u -3 -p -r1.130 php_pcre.c
--- pcre/php_pcre.c 24 Oct 2002 19:06:19 - 1.130
+++ pcre/php_pcre.c 31 Oct 2002 13:57:58 -
@@ -553,6 +553,110 @@ static void php_pcre_match(INTERNAL_FUNC
}
/* }}} */
+/* {{{ ereg_to_pcre_convert
+*/
+static inline zval *ereg_to_pcre_convert(zval **reg_expr, int case_sens)
+{
+ char *p, *pp;
+ int extra_len = 3;
+ zval *new_reg;
+
+ if (case_sens) {
+ extra_len++;
+ }
+
+ MAKE_STD_ZVAL(new_reg);
+
+ Z_STRVAL_P(new_reg) = emalloc(Z_STRLEN_PP(reg_expr) * 2 + extra_len +
1);
+ Z_TYPE_P(new_reg) = IS_STRING;
+
+ pp = Z_STRVAL_PP(reg_expr);
+ p = Z_STRVAL_P(new_reg);
+
+ *p++ = '/';
+ while (*pp) {
+ if (*pp != '/') {
+ *p++ = *pp;
+ } else {
+ *p++ = '\\';
+ *p++ = '/';
+ extra_len++;
+ }
+ pp++;
+ }
+
+ *p++ = '/';
+ if (case_sens) {
+ *p++ = 'i';
+ }
+ *p++ = 's';
+ *p = '\0';
+
+ Z_STRLEN_P(new_reg) = Z_STRLEN_PP(reg_expr) + extra_len;
+
+ return new_reg;
+}
+/* }}} */
+
+/* {{{ php_pcre_ereg_match
+*/
+static void php_pcre_ereg_match(INTERNAL_FUNCTION_PARAMETERS, int
case_sens)
+{
+ zval **old_regex, **m_string, **subpats = NULL;
+ zval **args[3];
+ zval *retval, *pcre_func, *new_regx;
+
+ int argc = ZEND_NUM_ARGS();
+
+ if ((argc != 2 argc !=
RE: [PHP-DEV] [PATCH] include statement in php.ini file
I'd vote with Rasmus here. Adding an include statement (whatever it's called) looks to be very low risk for inclusion in the 4.3 release. I am a little uncomfortable with the auto-magic function to include all files in directory. I've been bitten more than a few times by magic that didn't do exactly what was expected. Not clear where the balance between risk and convenience falls in this case. Put me down as +1 for including specific files, and -0.5 including entire directories. BTW - if entire directories are included then I think it *very* important the directory/name of each INI actually used be remembered by PHP and reported by phpinfo(). Otherwise folks doing support are going to have a bit tougher time. On occasion we'd get stuck with the scenario where it should have worked, if this INI file was included, but I can't tell if it was. -Original Message- From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] Sent: Friday, September 27, 2002 11:01 AM I'd like to see this in 4.3. It's not a huge change, and it is something that would make my life easier now. I realize that is somewhat selfish, but sometimes being selfish is good. -Rasmus I would recommend to wait with committing this until after PHP_4_3_0 has been branches, and thus we have this nice and stable for PHP 5. Derick On Fri, 27 Sep 2002, David Viner wrote: here is a revised patch that uses additional_ini keyword instead of include. [snip] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] apache 2.40
Might depend on their usage. Using Apache 2 with PHP through CGI or FastCGI should be OK. PHP as an Apache 2 module you'd expect to take a bit longer to settle down - especially if threading is involved. -Original Message- From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] Sent: Monday, August 26, 2002 11:50 AM To: Jonas Eriksson Is it now safe to set up apache 2 with php in a production server? Nope When will it be safe? Depends which Apache2 MPM you use. Hopefully by PHP 4.3 it should be safe for the prefork MPM. For any other MPM, perhaps never. We should be able to get the threaded ones stable with a limited set of extensions eventually, but don't hold your breath on that one. When will next version of php be relised? When we finish it. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Moving away from ASP to PHP
By as many platforms as possible do you mean different web servers on Windows (in which case using ActiveX components is viable), or different operating systems (Linux? Apple's OS? Sun? z/OS?)? Which specific platforms do you have in mind? I would not ordinarily recommend writing code in C unless absolutely necessary. What skills currently exist within your programming group? Which of those people are interested in learning new technologies, and which will resist? All the above will influence your choices. BTW - some portable equivalent to COM/ActiveX components would be great. The Mozilla project has XPCOM but I have no opinion on how well this was done. If XPCOM has any legs outside Mozilla then building XPCOM support into PHP could be a big win. -Original Message- From: Anthony Kauffmann [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 31, 2002 2:26 AM I've recently joined a new company and we're doing all of our web development (server-side) in ASP at the moment. We have to create a rather large scale application that will run on as many platforms as possible, so you can see how IIS can be restrictive to us at this point. The one thing that is imperative that we do, is to be able to hide the code of the application. In ASP, we would simple make a DLL and then create the COM object from the ASP scripts. I'm not the best with the Unix/Linux flavours of this sort of thing, so I'm not quite sure how we'd accomplish something of the same sort. I've been a PHP programmer for over a year at my old job, and I -definitely- prefer it over ASP or JSP as a scripting language of choice. I looked into making modules (binaries?) and then re-compiling them with the code to hide them. I assume this would mean we would have to write our code in C and then recompile from there? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] oo != php
From: Ilker Cetinkaya [mailto:[EMAIL PROTECTED]] [snip] but after getting known of the ze2 features, I personally saw PHP finally growing out of that PHP, language for kiddies-image. IMHO PHP is a real good language for its target purpose, but it has potential to be much better. PHP is a nicely done scripting language. Scripting languages tend to be easier to get into, easier to make changes with, and do a good job of gluing disparate components together. Java is a compiled language. Good for building complex tightly knit applications at the higher end of the performance spectrum. For tasks that could be done with a scripting language, the implementation cost is usually higher in Java. C++ is a lower level compiled language. Good for getting every last bit of performance possible out of the hardware. Also good for complex tightly knit applications - but at an even higher development cost. Think of each as a different tool in your toolbox. You choose the tool to fit the job at hand. A screwdriver is not a kiddie hammer. Each is well suited for different kinds of tasks. To extend the metaphor - think of an all-in-one tool - a combination of hammer and screwdriver, say. In trying to combine the two tools meant for different purposes you end up with something that is neither a particularly good hammer, or a particularly good screwdriver. So the focus on improving PHP in the role as a scripting language (not trying to make PHP into Java or C++) makes a great deal of sense. my 2c and may this topic never arise again, Amen :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Performance of Apache 2.0 Filter
A user posted [1] a benchmark today in the German PHP Newsgroup [2] stating that Apache 2.0 and PHP (current HEAD) are about 20% slower than Apache 1.3. On Thu, Jun 06, 2002 at 09:05:16AM -0700, Rasmus Lerdorf wrote: It doesn't really surprise me. The bucket brigade stuff adds overhead as does the thread stuff in PHP. There is nothing inherently faster about threaded apps. They tend to scale a little bit better in most cases, so under extreme load performance should be better. But under light loads I would expect a non-threaded Apache+PHP to be quicker. From: Aaron Bannert [mailto:[EMAIL PROTECTED]] Right, so I'd expect (hope) that at low load the performance is still reasonably fast, but at high concurrency and high load it still performs. Another thing that is gained in the new Apache 2.0 multithreaded architecture is memory conservation -- I've run a 500-thread system on under 20MB resident memory. Under Apache 1.3 that would require hundreds of MB of memory. This is a subject about which I still wonder. Multi-threading is a huge win for applications where the amount of computation is small, and most of the time is spent waiting on I/O. File servers are a classic example (NFS, SMB, FTP, file only HTTP) where multi-threading is a huge win. There are major downsides to multi-threading that need mention. For one making an application thread-safe requires substantial code, and the added code effectively imposes a run-time tax. For another applications that do a lot of computation are very often complex, and complex applications naturally contain more bugs. So a complex application - one with lots of computation between each context switch - may well be slower and less reliable when written as a multi-threaded application. Where is the cross-over point? Another question is the true memory footprint. Back in the late 1980's pretty much every Unix vendor added copy-on-write fork() semantics to their implementation. I believe Linux also uses the same copy-on-write (sometimes known as COW) behavior in fork(). Copy-on-write means that when you fork() a process, each process gets it's own virtual memory address space, but the physical memory is in fact *shared* between two processes. Immediately after fork() the contents of memory is exactly the same, so why store it twice? When a process writes to one of the shared pages a copy is made, and the virtual pages no longer share physical memory. Naturally the operating system still has to allocate virtual memory and swap space for the new process, but the amount of added physical memory used may in fact be very small. So the physical memory footprint for a multi-threaded application may in fact not be much different from a tradition Unix application that uses multiple processes. I don't know how to verify this - dig out the physical memory usage and check the copy-on-write behavior - on Linux. -- Preston L. Bannister http://members.cox.net/preston.bannister/ pbannister on Yahoo Messenger -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: I need your support: Reinstatement of msession
From: Stig S. Bakken [mailto:[EMAIL PROTECTED]] I would like to point out that moving to PECL (pickling) is not the same as not having stuff bundled with PHP anymore. The main point is to separate CVS areas, so the main PHP distribution has more control on what versions of different extensions it bundles. As good as every extension (except ext/standard) could move to PECL, where they can live happily with their own release cycles, and PHP be released with the latest stable version of each it wants to bundle. In addition, since each PECL extension is also a PEAR package, extensions may be upgraded individually if the extension was build as a shared lib. How far we want to go one way or the other is still in the open. This is good to hear. Another consideration is performance for how PHP is used. For usage where PHP is loaded once and used for a relatively long period of time (as in mod_php?), releasing a very lean core PHP and dynamically loading extensions is perfectly reasonable. The runtime cost of loading the extensions is amortized over a large number of requests. For usage where PHP is loaded often (as in CGI usage) the cost to load the extensions seperately can be have a much larger impact. In this case you want to think about building in all the often used extensions. -- Preston L. Bannister http://members.cox.net/preston.bannister/ pbannister on Yahoo Messenger -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Tip of the day: embedding php code in scripts
From: Stig S. Bakken [mailto:[EMAIL PROTECTED]] Did anyone come up with this one before or do I have a first post? :-) #!/bin/sh exec php -d output_buffering=1 $0 $@ ?php ob_end_clean(); print Hello World!\n; ? Or the shorter (and faster) version: #!/usr/local/bin/php -d output_buffering=1 ?php ob_end_clean(); print Hello World!\n; ? Or perhaps you had something else in mind? I believe most (all?) modern Unix implementations do #! handling in the kernel's exec() function, so you avoid the /bin/sh startup. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] ActiveScript sapi now in CVS
It might be of help when migrating from ASP to PHP. If you can pass values(?) between ASP and PHP then you might be able to convert incrementally from ASP to PHP. For applications that have too much code to convert (and test!) in one release cycle, this could be a significant advantage. You *do* expect folks to convert from ASP to PHP someday? :) From: Michael Dransfield [mailto:[EMAIL PROTECTED]] it would make migration from asp to php easier... sell it to your clients as enhanced asp, then show then the benefits of the php additions thats all i can think of ;) Mike At 20:59 19/05/2002 -0700, Rasmus Lerdorf wrote: Ok, so that is how it works. Could you talk a little bit about why anybody would want to do this? On Mon, 20 May 2002, Wez Furlong wrote: Well, I've added the new activescript sapi to CVS; it's still experimental, but it should work for quite a few uses. I've tested it with IE using syntax like this: script language=ActivePHP $window-alert(hello); /script input type=submit value=clickme onclick=$window-alert(hello); It also works with the Windows Scripting Host; you can either explicitly set the engine on the command line like this: cscript //e:ActivePHP myscript.php or you can use a .wsf file like this: job id=test script language=ActivePHP $WScript-Echo(hello); /script /job ASP should also work; something like this should do the trick (untested!) %@lanugage=ActivePHP% % $Response-Write(hello); % It should also be possible to write a windows script component as well. Caveats/Notes: There may be some threading issues, particularly with multi-threaded scripting hosts (WSH and ASP). The scripting host architecture says that the engine should be free threaded, but then forces callbacks to occur on a particular thread. On top of that, we need to contain all PHP state in a thread of it's own. There's some interesting code in there... If you use multiple scripting languages in a script/job, the other languages will most probably be able to access PHP globals, but PHP will not be able to access their globals unless the scripting host explicitely registers them in the PHP global namespace. However, you can use expandos on an existing global object to share data between engines: $window-foo = new foo(); will add the object foo as a property of the window object in IE. JavaScript should then be able to access it: property access and method calls are implemented (only for non-overloaded objects!). echo and print will send output to the debugger, not to the browser, console or a message box. It might be possible to tie it into IE, but that will require some investigation (query the script site for one of the well-known IE interfaces?). Currently, the main engine object is implemented in C++, which has a few annoying compilation quirks when mixed with C. I plan to rewrite it in plain old C, so don't panic. I'm using a recent platform SDK, so if you get warnings/errors concerning IActiveScriptParseProcedure, you need a newer set of headers. I've added a generic COM wrapper for PHP objects to the COM extension: you will be able to use it with other win32 sapis to pass PHP objects to COM servers that expect an IDispatch-able object. The same mechanism could be extended to have the COM wrapper act as an event sink. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Updated run-tests.php
Updated run-tests.php to work well on Win32. The changes *should* work on Unix as well, and I'll do some testing once I finish getting my newer Linux box set up :). Added some tricks I've found useful in writing unit tests: * Require a specific explicit path to the PHP executable. * Require a php.ini file (to control the exact configuration). * Abort the test if any requirement is not met. * Log what exactly is being tested (version path, etc.). * On failure log additional detail (to a seperate file). Some enhancements: * Run basic (non-extension/PEAR) tests first. * Added project to Win32 workspace, and made dependent on php4ts. * Generate compiler-style error reports that Emacs/MSVC can grok. Put a little work into the test cases. The entire tests.log file for Win32 is attached, with an abbreviated version below: = TIME 2002-05-17 00:39:59 - start of test run CWD : C:\net.php\php4-work PHP : Debug_TS\\php-cgi.exe PHP_SAPI: cgi PHP_VERSION : 4.3.0-dev PHP_OS : WINNT INI actual : C:\net.php\php4-work\tests\php.ini INI wanted : C:\net.php\php4-work\tests\php.ini INI tests : C:\net.php\php4-work\Debug_TS\php.ini = Will test compiled extension: standard Will test compiled extension: bcmath Will test compiled extension: calendar Will test compiled extension: ctype Will test compiled extension: com Will test compiled extension: ftp Will test compiled extension: mbstring Will test compiled extension: mysql Will test compiled extension: odbc Will test compiled extension: overload Will test compiled extension: pcre Will test compiled extension: session Will test compiled extension: tokenizer Will test compiled extension: xml Will test compiled extension: wddx = [snip] = TIME 2002-05-17 00:40:23 - end of test run TEST RESULT SUMMARY = Number of tests : 223 Tests skipped : 70 (31.4%) Tests failed: 22 ( 9.9%) Tests passed: 131 (58.7%) = Skipped 24 extensions = TIME 2002-05-17 00:39:59 - start of test run CWD : C:\net.php\php4-work PHP : Debug_TS\\php-cgi.exe PHP_SAPI: cgi PHP_VERSION : 4.3.0-dev PHP_OS : WINNT INI actual : C:\net.php\php4-work\tests\php.ini INI wanted : C:\net.php\php4-work\tests\php.ini INI tests : C:\net.php\php4-work\Debug_TS\php.ini = Will test compiled extension: standard Will test compiled extension: bcmath Will test compiled extension: calendar Will test compiled extension: ctype Will test compiled extension: com Will test compiled extension: ftp Will test compiled extension: mbstring Will test compiled extension: mysql Will test compiled extension: odbc Will test compiled extension: overload Will test compiled extension: pcre Will test compiled extension: session Will test compiled extension: tokenizer Will test compiled extension: xml Will test compiled extension: wddx = directory C:\net.php\php4-work\tests\basic PASS Trivial Hello World test PASS Simple POST Method test PASS GET and POST Method combined PASS Two variables in POST data PASS Three variables in POST data PASS Add 3 variables together and print result PASS Multiply 3 variables and print result PASS Divide 3 variables and print result PASS Subtract 3 variables and print result PASS Testing | and operators PASS Testing $argc and $argv handling directory C:\net.php\php4-work\tests\classes PASS Classes general test PASS Classes inheritance test directory C:\net.php\php4-work\tests PASS dirname test directory C:\net.php\php4-work\tests\func PASS Strlen() function test PASS Static variables in functions PASS General function test PASS General function test PASS Testing register_shutdown_function() FAIL Output buffering tests (006.phpt). C:\net.php\php4-work\tests\func\006.phpt(1) : Output buffering tests C:\net.php\php4-work\tests\func\006.log(1) : Output buffering tests PASS INI functions test directory C:\net.php\php4-work\tests\lang PASS Simple If condition test PASS Simple While Loop Test PASS Simple Switch Test PASS Simple If/Else Test PASS Simple If/ElseIf/Else Test PASS Nested If/ElseIf/Else Test PASS Function call with global and static variables PASS Testing recursive function PASS Testing function parameter passing PASS Testing function parameter passing with a return value PASS Testing nested functions PASS Testing stack after early function return PASS Testing eval function PASS Testing eval function
RE: [PHP-DEV] Updated run-tests.php
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] testing right away on Linux :) I've some comments: [root@kossu php-4.3.0dev]# php run-tests.php FAIL environment variable TEST_PHP_EXECUTABLE must be set to specify PHP executable! Nice message, but I think it would be a good idea to default to the CLI if it exists, and otherwise give this message. I think it's a nice thing that as soon as PHP is compiled, users can do php run-tests.php without having to tinker with environment variables. (And it annoyed me :) Hopefully with something like the patch (at the end) you can just run make test. After I settled the ini file problem, I encountered this: [...(40 more extensions)...] Will test compiled extension: dba Will test compiled extension: curl Will test compiled extension: ctype Will test compiled extension: zlib = directory /dat/dev/php/php-4.3.0dev/tests/basic Cannot open file ''! [root@kossu php-4.3.0dev]# I can not dig in further right now, because I've no time. Hmmm ... any reason realpath() would fail? I'll check this out after I can convince the new Linux box to talk to the network. (Don't want to push the old Linux box - after the power supply fan failed :). Change that *should* be what is needed for the Unix make follows. This is not committed (oddly enough) as it is untested. In file Makefile.global change: test: sapi/cli/php TOP_BUILDDIR=$(top_builddir) TOP_SRCDIR=$(top_srcdir) \ $(top_builddir)/sapi/cli/php -c php.ini-dist $(top_srcdir)/run-tests.php $(TESTS) to the following: - test: sapi/cli/php cd $(top_srcdir) \ TEST_PHP_EXECUTABLE=$(top_builddir)/sapi/cli/php \ TEST_PHP_DETAILED=0 \ TEST_PHP_ERROR_STYLE=EMACS \ $(TEST_PHP_EXECUTABLE) -c tests run-tests.php - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Command line compilation under win32
From: Wez Furlong [mailto:[EMAIL PROTECTED]] I'm in the process of getting a more permanent win32 build environment sorted out, and one of the things I'd like to do is avoid the VS IDE as much as possible, and automate builds so that I can test changes that I make under unix. (Perhaps even by rshing to my win32 box). I know it's possible to build projects from the command line using something like msdev xxx.dsw, but so far I've not succeeded (and have little patience with win32 and the command line, because it is generally quite limited). If you try to do automated builds through msdev you run two risks: 1. The build environment is somewhat uncontrolled. 2. The IDE under some conditions will throw up dialogs and stop. The first concern is with the global environment inherited from MSVC and used in the build. MSVC pulls in libraries and include files from you-don't-know-where and this makes it more difficult to know exactly what has changed between builds. If the machine used for automated builds is strictly controlled, and used for nothing else this is less of a risk. The second concern is simply that MSVC was designed as an interactive application and may at any time decide to ask a question of the user by presenting a dialog. Naturally this brings an automated build to a complete stop :). You may on occasion have to check the box doing the builds to make sure it has not become stopped in this fashion. There is another approach to this that is a more hassle, but is without the above problems. In MSVC you can say Projects | Export Makefile... for all projects. This generates nmake makefiles (*.mak) for all projects in the workspace. If you then specify the *exact* environment variables set when you run nmake then you know *exactly* the build environment in effect. For my production builds (anything that might be shipped to a customer) and only after all the unit tests pass, I use a Perl script to: 1) Set the environment to use in the build. 2) Update local sources from CVS. 3) Bump the build number (updates version .h and .rc files). 4) Run make clean. 5) Commit all changes to CVS. 6) Run make dist to build a distribution. 7) Tag the sources in CVS with the build number. 8) (Optional) upload the distribution to an FTP server. The exact same build script works in exactly the same way (with the exception of the platform-specific makefiles) on Unix, Windows, and (in one case) on OS/390. OK - so maybe this is a lot more complicated :). The upside is that from the build number compiled into the executables you know *exactly* the sources and build environment used. There are no manual intermediate steps and no possibility of human error. -- Preston L. Bannister http://members.cox.net/preston.bannister/ pbannister on Yahoo Messenger -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Win32 testing and run-tests.php (was: PHP 4 Bug Summary Report)
I'm not asking you to do all the work, rather I'm trying to figure out who is working on what, so I don't duplicate someone's work. I take it you're testing on Unix? The current tests are checked in to CVS? -Original Message- From: James Cox [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 04, 2002 6:18 PM Yes, i'm working on getting tests working on all platforms... but not today, probably very soon. -Original Message- From: Preston L. Bannister [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 05, 2002 2:14 AM Is anyone working on getting the run-tests.php and tests/* running on Win32? Who is adding test cases as bugs are closed? Fixed run-tests.php and added a Win32 project to run the tests. During the test run PHP faults (bad pointer/index during mbstring tests). This is a good thing, as it looks like this found a real PHP bug. Configuration: tests - Win32 Debug set TEST_PHP_EXECUTABLE=Debug_TS\php-cgi.exe cd .. Debug_TS\php-cgi.exe -q -c php.ini-dist run-tests.php OK - TEST_PHP_EXECUTABLE = Debug_TS\\php-cgi.exe Running tests in C:/net.php/php4-current/ext/bz2/tests == [all 2 test(s) skipped] Running tests in C:/net.php/php4-current/ext/crack/tests [all 1 test(s) skipped] Running tests in C:/net.php/php4-current/ext/ctype/tests ctype on integers ... passed ctype on strings (002.phpt) ... failed Running tests in C:/net.php/php4-current/ext/cybermut/tests === [all 1 test(s) skipped] Running tests in C:/net.php/php4-current/ext/db/tests = [all 6 test(s) skipped] Running tests in C:/net.php/php4-current/ext/dbplus/tests = [all 1 test(s) skipped] Running tests in C:/net.php/php4-current/ext/dbx/tests == [all 8 test(s) skipped] Running tests in C:/net.php/php4-current/ext/dio/tests == [all 1 test(s) skipped] Running tests in C:/net.php/php4-current/ext/domxml/tests = [all 1 test(s) skipped] Running tests in C:/net.php/php4-current/ext/exif/tests === [all 3 test(s) skipped] Running tests in C:/net.php/php4-current/ext/gmp/tests == [all 3 test(s) skipped] Running tests in C:/net.php/php4-current/ext/iconv/tests [all 5 test(s) skipped] Running tests in C:/net.php/php4-current/ext/interbase/tests [all 6 test(s) skipped] Running tests in C:/net.php/php4-current/ext/mbstring/tests === Simple multi-byte print test (EUC-JP) ... passed mb_internal_encoding() test ... passed mb_http_input() (003.phpt) ... failed mb_http_output() ... passed mb_detect_order() (005.phpt) ... failed mb_substitute_character() ... passed mb_output_handler() (EUC-JP) ... passed mb_preferred_mime_name() ... passed mb_strlen() ... passed mb_strpos() ... passed mb_strrpos() ... passed mb_substr() ... passed mb_strcut() ... passed mb_strimwidth() ... passed mb_convert_variables() (015.phpt) ... failed mb_convert_encoding() ... passed mb_detect_encoding() ... passed mb_strwidth() ... passed mb_strlen() ... passed Running tests in C:/net.php/php4-current/ext/mcrypt/tests = [all 1 test(s) skipped] Running tests in C:/net.php/php4-current/ext/mcve/tests === [all 1 test(s) skipped] Running tests in C:/net.php/php4-current/ext/ncurses/tests == [all 1 test(s) skipped] Running tests in C:/net.php/php4-current/ext/openssl/tests == [all 1 test(s) skipped] Running tests in C:/net.php/php4-current/ext/pcntl/tests [all 1 test(s) skipped] Running tests in C:/net.php/php4-current/ext/pgsql/tests [all 19 test(s) skipped] Running tests in C:/net.php/php4-current/ext/pspell/tests = [all 1 test(s) skipped] Running tests in C:/net.php/php4-current/ext
RE: [PHP-DEV] Win32 testing and run-tests.php (was: PHP 4 Bug Summary Report)
From: James Cox [mailto:[EMAIL PROTECTED]] My plan is to revamp the way that tests work, so it's more efficient. But, you are more than welcome to work on the current testing system, -- all the tests will be converted anyhow :) First iteration - regularize the output to allow easy post-processing (to HTML or for generating summaries), and made to run on Win32. Added information on context of test run to log (when, where, version). Made fatal any errors within the test scripts (rather than PHP). Require an exactly specified version of PHP (no guessing!). I'd really like to commit this stuff. The patches are getting large... Output from run-tests.php = TIME 2002-05-05 12:52:51 - start of test run CWD : C:\net.php\php4-current PHP : Debug_TS\\php-cgi.exe PHP SAPI: cgi PHP version : 4.3.0-dev - testing extension: ctype directory C:\net.php\php4-current/ext/ctype/tests PASS ctype on integers FAIL ctype on strings (002.phpt) - testing extension: mbstring directory C:\net.php\php4-current/ext/mbstring/tests PASS Simple multi-byte print test (EUC-JP) PASS mb_internal_encoding() test FAIL mb_http_input() (003.phpt) PASS mb_http_output() FAIL mb_detect_order() (005.phpt) PASS mb_substitute_character() PASS mb_output_handler() (EUC-JP) PASS mb_preferred_mime_name() PASS mb_strlen() PASS mb_strpos() PASS mb_strrpos() PASS mb_substr() PASS mb_strcut() PASS mb_strimwidth() FAIL mb_convert_variables() (015.phpt) PASS mb_convert_encoding() PASS mb_detect_encoding() PASS mb_strwidth() PASS mb_strlen() - testing extension: session directory C:\net.php\php4-current/ext/session/tests PASS Session Object Serialization PASS session_unset() without any session PASS Session Object Deserialization PASS session_set_save_handler test PASS Custom save handler, multiple session_start()s, complex data structure test. PASS References between variables in sessions - testing extension: standard directory C:\net.php\php4-current/ext/standard/tests/aggregation FAIL aggregating everything (aggregate.phpt) FAIL aggregating all methods (aggregate_methods.phpt) FAIL aggregating methods specified in the list (aggregate_methods_by_list.phpt) FAIL aggregating methods matching regular expression (aggregate_methods_by_regexp.phpt) FAIL aggregating all default properties (aggregate_properties.phpt) FAIL aggregating default properties specified in the list (aggregate_properties_by_list.phpt) FAIL aggregating default properties matching regular expression (aggregate_properties_by_regexp.phpt) FAIL retrieving aggregation info (aggregation_info.phpt) FAIL deaggreating (deaggregate.phpt) directory C:\net.php\php4-current/ext/standard/tests/array FAIL Test array_merge and array_walk (001.phpt) FAIL Test arsort, asort, krsort, ksort, rsort, and sort (002.phpt) FAIL Test usort, uksort and uasort (003.phpt) PASS Test natsort and natcasesort FAIL search_array and in_array (including bug 13567) (array_search.phpt) PASS count directory C:\net.php\php4-current/ext/standard/tests/assert PASS assert() directory C:\net.php\php4-current/ext/standard/tests/file FAIL File type functions (001.phpt) FAIL File/Stream functions (002.phpt) FAIL is_file/file_exist (003.phpt) directory C:\net.php\php4-current/ext/standard/tests/general_functions PASS sprintf() function PASS quoted_printable_decode() function test PASS levenshtein() function test PASS fgetcsv() with tab delimited fields (BUG #8258) PASS is_scalar() function test FAIL quoted_printable_decode() function test with CR/LF (006.phpt) directory C:\net.php\php4-current/ext/standard/tests/math FAIL Simple math tests (abs.phpt) FAIL Tests for floor en ceil (floorceil.phpt) FAIL Various pow() tests (pow.phpt) FAIL Simple math tests (round.phpt) directory C:\net.php\php4-current/ext/standard/tests/reg PASS RegReplace test 1 PASS RegReplace test 2 PASS ereg_replace single-quote test PASS simple ereg test PASS Test Regular expression register support in ereg PASS Test ereg_replace of start-of-line PASS Test empty result buffer in reg_replace PASS Test back-references in regular expressions FAIL Test split() (009.phpt) PASS Long back references PASS \0 back reference PASS nonexisting back reference PASS escapes in replace string PASS backreferences not replaced recursively PASS replace empty matches PASS test backslash handling in regular expressions directory C:\net.php\php4-current/ext/standard/tests/serialize PASS serialize()/unserialize()/var_dump() PASS serialize() (Bug #14293) directory C:\net.php\php4-current/ext/standard/tests/strings PASS strtr() function FAIL
[PHP-DEV] CVS Account Request: pbannister
Smoothing out the rough spots in the Win32 version of PHP. Help to get running and add to the unit tests for PHP - particularly on Win32. If you want to know what I've done in the past, you can get a hint from Google: http://groups.google.com/groups?q=+%22Preston+L.+Bannister%22hl=ennewwindow=1scoring=d (presuming the URL survives :). -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Win32 testing and run-tests.php (was: PHP 4 Bug Summary Report)
Testing eval function inside user-defined function ... passed Testing include ... passed Testing user-defined function in included file ... passed Testing user-defined function falling out of an If into another ... passed eval() test ... passed eval() test ... passed Switch test 1... passed Switch test 2... passed Switch test 3... passed Regression test ... passed Looped regression test (may take a while)... passed Mean recursion test ... passed Testing string scanner confirmance ... passed Testing do-while loop... passed Testing calling user-level functions from C ... passed OO Bug Test (Bug #7515) (029.phpt) ... failed $this in constructor test... passed Internal hash position bug on assignment (Bug #16227) (031.phpt) ... failed Class method registration... passed Alternative syntaxes test... passed Running tests in C:/net.php/php4-current/tests/strings == String functions ... passed Formatted print functions... passed HTML entities... passed TEST RESULT SUMMARY = Number of tests: 297 Tests skipped: 118 ( 40%) Tests failed: 70 ( 39%) Tests passed: 109 ( 61%) = Skipped 0 extensions. NMAKE : fatal error U1077: 'cd' : return code '0xff' Stop. Error executing nmake. __test_run_complete__ - 5 error(s), 0 warning(s) -- Preston L. Bannister http://members.cox.net/preston.bannister/ pbannister on Yahoo Messenger -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] config.w32.h...registry configuration
From: Zeev Suraski [mailto:[EMAIL PROTECTED]] IMHO, the enemy of the good is the better. We can implement the binary-dir solution in no time, and it covers 95% of the problems easily, but instead we'll be discussing perfect solutions and end up doing nothing :) Yes, please! :) Remember KISS ... (and I'm not getting over-friendly here). In fact you can get pretty near 100% with the simple solution just by having multiple copies of the PHP executable in different directories - one for each differing configuration. On modern disks the size of PHP is insignificant, so having multiple copies is a non-issue. In fact this is an advantage. If (say) you are running multiple PHP-based web applications, each requiring different configurations, you may in fact be dependent on different versions of PHP. A good, careful sysadmin will want to upgrade one application at a time (and test!) rather than all at once, and will want each application using it's own PHP executable. IMHO the more complicated solutions aren't really needed. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] config.w32.h...registry configuration
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] Well, you are correct that the size of the executable is irrelevant, but having different instances of PHP means less shared pages when multiple copies are loaded. There is a definite advantage to having a single httpd binary that is the same for everyone when it comes to runtime memory usage. This is true, there will be less shared pages. I *want* this! (Though I was talking about PHP and not httpd). When we ship a new version of our application to our customers, it will have been tested with a specific version of PHP. If the customer installs another application that uses PHP, and that application installs it's own version of PHP, there is some risk (if PHP were shared) then this could break our application. We really don't want our application to break! Oddly enough the customer feels pretty much the same. Given the choice of burning a bit of memory and disk space versus risking failure (and this could effect hundreds or thousands of users), the customer will gladly buy just a bit more memory :). -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Win32: config.w32.h.in - config.w32.h
From: Sebastian Bergmann [mailto:[EMAIL PROTECTED]] I now changed the MSVC project files in order to generate config.w32.h from config.w32.h.in during the build, if config.w32.h does not already exist. However, as I of course found out only after committing, MSVC deletes config.w32.h when doing a /REBUILD, so this is a bit pointless. Does anyone know a way to exclude config.w32.h from being delete during this cleanup for rebuilds? Yep, use a project with a makefile. You are then in control. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] A better strlcat()
Was looking at the strlcat() implementation in the PHP source
and saw that it does not take advantage of history :).
Look at xxx_strlcat() in the following example.
You are almost always better off using the compiler's built-in
string functions, due to the optimizations built-in (many years ago)
to improve Dhrystone benchmark scores. The benchmark turned out to
be a bit bogus, but the improvements made to the string functions
are a benefit to us all :).
This is more readable (and thus more likely correct), slightly faster
(about 4% in my testing), and in the debug build better checked.
Full comparison benchmark program:
-
#include stdlib.h
#include stdio.h
#include string.h
#include time.h
#include assert.h
/*
* Appends src to string dst of size siz (unlike strncat, siz is the
* full size of dst, not space left). At most siz-1 characters
* will be copied. Always NUL terminates (unless siz == 0).
* Returns strlen(src); if retval = siz, truncation occurred.
*/
size_t php_strlcat(char* dst,const char* src,size_t siz)
{
register char *d = dst;
register const char *s = src;
register size_t n = siz;
size_t dlen;
/* Find the end of dst and adjust bytes left but don't go past end */
while (*d != '\0' n-- != 0)
d++;
dlen = d - dst;
n = siz - dlen;
if (n == 0)
return(dlen + strlen(s));
while (*s != '\0') {
if (n != 1) {
*d++ = *s;
n--;
}
s++;
}
*d = '\0';
return(dlen + (s - src)); /* count does not include NUL */
}
/*
* Take full advantage of any compiler/library optimizations built in
* to the standard string routines. Look up the history of compiler
* comparisons with Dhrystone benchmark to understand why this wins.
* Pre-Internet history - check Google's USENET archive.
*/
size_t xxx_strlcat(char* s1,const char* s2,size_t nMax)
{
size_t n1 = strlen(s1);
size_t n2 = strlen(s2);
size_t nCopy = (nMax = (n1+n2)) ? (nMax - n1 - 1) : n2;
/* Better to leave this out and require a valid string return */
if (!nMax) return 0;
assert(n1 nMax); /* Catch pre-existing oversize strings */
assert(0 nMax); /* Insure return is always a valid string */
memcpy(s1+n1,s2,nCopy);
s1[n1+nCopy] = 0;
return n1+n2; /* as documented for strlcat() */
/*return n1+nCopy;/* actual number of characters */
}
/*
*
*/
int main(int ac, char** av)
{
clock_t t1,dt;
#ifdef WIN32
__int64 nTotal;
#else
long long nTotal;
#endif
char s1[85];
static char s2[] = 1234567890;
int nLoops = 10;
if (1 ac) {
nLoops = atoi(av[1]);
}
printf(Compare two strlcat() implementations for %d iterations.\n,nLoops);
t1 = clock();
nTotal = 0;
for (int i=0; inLoops; ++i) {
s1[0] = 0;
nTotal += php_strlcat(s1,s2,sizeof(s1));
nTotal += php_strlcat(s1,s2,sizeof(s1));
nTotal += php_strlcat(s1,s2,sizeof(s1));
nTotal += php_strlcat(s1,s2,sizeof(s1));
nTotal += php_strlcat(s1,s2,sizeof(s1));
nTotal += php_strlcat(s1,s2,sizeof(s1));
nTotal += php_strlcat(s1,s2,sizeof(s1));
nTotal += php_strlcat(s1,s2,sizeof(s1));
nTotal += php_strlcat(s1,s2,sizeof(s1));
nTotal += php_strlcat(s1,s2,sizeof(s1));
}
dt = clock() - t1;
printf(php_strlcat() copied %1.0f characters in %ld
ticks\n,(double)nTotal,(long)dt);
t1 = clock();
nTotal = 0;
for (i=0; inLoops; ++i) {
s1[0] = 0;
nTotal += xxx_strlcat(s1,s2,sizeof(s1));
nTotal += xxx_strlcat(s1,s2,sizeof(s1));
nTotal += xxx_strlcat(s1,s2,sizeof(s1));
nTotal += xxx_strlcat(s1,s2,sizeof(s1));
nTotal += xxx_strlcat(s1,s2,sizeof(s1));
nTotal += xxx_strlcat(s1,s2,sizeof(s1));
nTotal += xxx_strlcat(s1,s2,sizeof(s1));
nTotal += xxx_strlcat(s1,s2,sizeof(s1));
nTotal += xxx_strlcat(s1,s2,sizeof(s1));
nTotal += xxx_strlcat(s1,s2,sizeof(s1));
}
dt = clock() - t1;
printf(xxx_strlcat() copied %1.0f characters in %ld
ticks\n,(double)nTotal,(long)dt);
return 0;
}
-
--
Preston L. Bannister
http://members.cox.net/preston.bannister/
pbannister on Yahoo Messenger
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] config.w32.h...registry configuration
From: Zeev Suraski [mailto:[EMAIL PROTECTED]] At 15:09 02/05/2002, [EMAIL PROTECTED] wrote: Ok then, perhaps we should have an .ini setting for it? :) So you want to add an .ini setting where the .ini file could be found? That just doesn't make sense to me :) That was a joke.. The only two options I see, in that case are: - Add the binary path to the 3 existing lookup places - Add a configuration option that would determine whether CWD would be used, or the binary path would be used. I lean towards option #2 myself... yeah, but it still doesn't make sense :) It does (configuration option == configure option, not php.ini option) Tricky :). I'd suggest the default be to omit CWD from the php.ini search path. This does break the compatibility for sites that use this feature. If a site chooses to look for php.ini this is a security risk. Better for the default to be secure. If the site is on Unix and uses chroot() before PHP runs, then the security risk may be eliminated. If the site is on Windows and wants to allow customer-hosted PHP scripts on a shared server ... this seems inherently risky in every case. Eh. Neither argument is especially compelling. BTW, if you are going to look for php.ini in the current directory then a feature like ASP's global.asa is interesting. Instead of just checking CWD you also check in each parent directory up to the application/web root. Slightly less efficient, but this makes having common settings for an application (in a directory sub-tree on the web) somewhat simpler. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] config.w32.h...registry configuration
From: Andi Gutmans [mailto:[EMAIL PROTECTED]] At 14:44 02/05/2002 +0300, Zeev Suraski wrote: At 14:00 02/05/2002, [EMAIL PROTECTED] wrote: On Thu, 2 May 2002, Zeev Suraski wrote: At 13:36 02/05/2002, [EMAIL PROTECTED] wrote: Some hosters use this feature to have different settigns for different customers... Do you know this for a fact, or is this an estimate? This is a fact, some hoster here in .nl uses it. Ok then, perhaps we should have an .ini setting for it? :) The only two options I see, in that case are: - Add the binary path to the 3 existing lookup places - Add a configuration option that would determine whether CWD would be used, or the binary path would be used. I lean towards option #2 myself... How about if we don't have a php.in in CWD we fall back to where php.exe is located? On second thought we *can* have both backwards compatibility AND a default PHP installation that is more secure. The approach is simple: Load php.ini from PHP_CONFIG_FILE_PATH (unix) or the same directory as php.exe (Win32). Do *not* search CWD. Add an include directive to the INI file. Looking at the PHP implementation it looks like this could be a psuedo-setting with an on_modify function that loads as an INI file using the value as a file name. So sites that *want* to load from CWD would add: [PHP] include_ini = ./php.ini So sites that want to be less secure have make the above entry once in the site's global php.ini. It is a good thing to require action and thought on the part of the site to become less secure :). -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] A better strlcat()
Heh - there's a question :).
Looking at the two implementations, which do you think you better
understand (with complete certainty), and which would you be willing
to (say) bet your life on?
Personally I'm *almost* certain I know what the first does :).
I would not want to bet it is bug-free.
I'm sure the shorter implementation matches the *documented*
strlcat() function. The fact it runs faster is likely an artifact
of compiler optimizations specific to string functions.
I'll send this off to the OpenBSD folks just for grins.
From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
Are you sure it behaves *exactly* like the existing one?
I stole the implementation from OpenBSD so it might be a good idea for you
to send it to them.
They are the best to shed light on this and see if it's exactly the same
and faster.
Andi
At 09:00 02/05/2002 -0700, Preston L. Bannister wrote:
Was looking at the strlcat() implementation in the PHP source
and saw that it does not take advantage of history :).
Look at xxx_strlcat() in the following example.
You are almost always better off using the compiler's built-in
string functions, due to the optimizations built-in (many years ago)
to improve Dhrystone benchmark scores. The benchmark turned out to
be a bit bogus, but the improvements made to the string functions
are a benefit to us all :).
This is more readable (and thus more likely correct), slightly faster
(about 4% in my testing), and in the debug build better checked.
Full comparison benchmark program:
-
#include stdlib.h
#include stdio.h
#include string.h
#include time.h
#include assert.h
/*
* Appends src to string dst of size siz (unlike strncat, siz is the
* full size of dst, not space left). At most siz-1 characters
* will be copied. Always NUL terminates (unless siz == 0).
* Returns strlen(src); if retval = siz, truncation occurred.
*/
size_t php_strlcat(char* dst,const char* src,size_t siz)
{
register char *d = dst;
register const char *s = src;
register size_t n = siz;
size_t dlen;
/* Find the end of dst and adjust bytes left but don't go past end */
while (*d != '\0' n-- != 0)
d++;
dlen = d - dst;
n = siz - dlen;
if (n == 0)
return(dlen + strlen(s));
while (*s != '\0') {
if (n != 1) {
*d++ = *s;
n--;
}
s++;
}
*d = '\0';
return(dlen + (s - src)); /* count does not include NUL */
}
/*
* Take full advantage of any compiler/library optimizations built in
* to the standard string routines. Look up the history of compiler
* comparisons with Dhrystone benchmark to understand why this wins.
* Pre-Internet history - check Google's USENET archive.
*/
size_t xxx_strlcat(char* s1,const char* s2,size_t nMax)
{
size_t n1 = strlen(s1);
size_t n2 = strlen(s2);
size_t nCopy = (nMax = (n1+n2)) ? (nMax - n1 - 1) : n2;
/* Better to leave this out and require a valid string return */
if (!nMax) return 0;
assert(n1 nMax); /* Catch pre-existing oversize strings */
assert(0 nMax); /* Insure return is always a valid string */
memcpy(s1+n1,s2,nCopy);
s1[n1+nCopy] = 0;
return n1+n2; /* as documented for strlcat() */
/*return n1+nCopy;/* actual number of characters */
}
/*
*
*/
int main(int ac, char** av)
{
clock_t t1,dt;
#ifdef WIN32
__int64 nTotal;
#else
long long nTotal;
#endif
char s1[85];
static char s2[] = 1234567890;
int nLoops = 10;
if (1 ac) {
nLoops = atoi(av[1]);
}
printf(Compare two strlcat() implementations for %d
iterations.\n,nLoops);
t1 = clock();
nTotal = 0;
for (int i=0; inLoops; ++i) {
s1[0] = 0;
nTotal += php_strlcat(s1,s2,sizeof(s1));
nTotal += php_strlcat(s1,s2,sizeof(s1));
nTotal += php_strlcat(s1,s2,sizeof(s1));
nTotal += php_strlcat(s1,s2,sizeof(s1));
nTotal += php_strlcat(s1,s2,sizeof(s1));
nTotal += php_strlcat(s1,s2,sizeof(s1));
nTotal += php_strlcat(s1,s2,sizeof(s1));
nTotal += php_strlcat(s1,s2,sizeof(s1));
nTotal += php_strlcat(s1,s2,sizeof(s1));
nTotal += php_strlcat(s1,s2,sizeof(s1));
}
dt = clock() - t1;
printf(php_strlcat() copied %1.0f characters in %ld
ticks\n,(double)nTotal,(long)dt);
t1 = clock();
nTotal = 0;
for (i=0; inLoops; ++i) {
s1[0] = 0;
nTotal += xxx_strlcat(s1,s2,sizeof(s1));
nTotal += xxx_strlcat(s1,s2,sizeof(s1));
nTotal += xxx_strlcat(s1,s2,sizeof(s1));
nTotal += xxx_strlcat(s1,s2,sizeof(s1));
nTotal
RE: [PHP-DEV] config.w32.h
From: Daniel Beulshausen [mailto:[EMAIL PROTECTED]] At 18:35 01.05.2002 +0200, Sebastian Bergmann wrote: Daniel Beulshausen wrote: do you mean constants like PHP_EXTENSION_DIR? For instance, yes. they should be changed to use the windows registry anyway... Feel free to do it :) this isn't going to be a big task, i'll put it onto my todo. I'd rather strongly suggest this value not be in the registry. What happens in the case were two different applications are installed on the same machine, and both use PHP - but different versions and with different libraries? You really don't want machine-global settings. This isn't a theoretical question! :) We will be using PHP in our application and need to be certain that any changes the customer makes to there global use of PHP does not crater out application. We can get this assurance by using a local copy of PHP in our application, with a local php.ini file. Instead I'd suggest that the settings stay in php.ini, but that PHP look for php.ini first local to the installation of php.exe. I posted a (tested!) patch a few days back to do exactly this. -- Preston L. Bannister http://members.cox.net/preston.bannister/ pbannister on Yahoo Messenger -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] config.w32.h
From: Daniel Beulshausen [mailto:[EMAIL PROTECTED]] At 18:35 01.05.2002 +0200, Sebastian Bergmann wrote: Daniel Beulshausen wrote: do you mean constants like PHP_EXTENSION_DIR? For instance, yes. they should be changed to use the windows registry anyway... Feel free to do it :) this isn't going to be a big task, i'll put it onto my todo. From: Sebastian Bergmann [mailto:[EMAIL PROTECTED]] Preston L. Bannister wrote: Instead I'd suggest that the settings stay in php.ini, but that PHP look for php.ini first local to the installation of php.exe. The settings we're talking about are not in php.ini. Perhaps I misunderstood. Are we talking about (for example) changing this value? main\main.c(270): STD_PHP_INI_ENTRY(extension_dir, PHP_EXTENSION_DIR, PHP_INI_SYSTEM, OnUpdateStringUnempty, extension_dir, php_core_globals, core_globals) Or these? main\main.c(1000): REGISTER_MAIN_STRINGL_CONSTANT(PEAR_EXTENSION_DIR, PHP_EXTENSION_DIR, sizeof(PHP_EXTENSION_DIR)-1, CONST_PERSISTENT | CONST_CS); REGISTER_MAIN_STRINGL_CONSTANT(PHP_EXTENSION_DIR, PHP_EXTENSION_DIR, sizeof(PHP_EXTENSION_DIR)-1, CONST_PERSISTENT | CONST_CS); -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] to get mbstring.c to compile
The latest patch mbstring.c prevents PHP from compiling when none of the
HAVE_MBSTR_* defines are present (which would be most sites!). The code
requires the php_mbstr_default_identify_list array must always be defined.
Now as an English-only person I have no notion which values and ordering is
correct. Presumably someone with this knowledge can make the appropriate
adjustments :).
Although looking at this code, I suspect that the encodings chosen should be
chosen not a compile time, but at run time. There was a rather a lot of
discussion in the Apache Jakarta mailing lists about encodings chosen on a
per-request basis.
In any case - this patch allows the code to compile anywhere.
Index: ext/mbstring/mbstring.c
===
RCS file: /repository/php4/ext/mbstring/mbstring.c,v
retrieving revision 1.66
diff -u -b -r1.66 mbstring.c
--- ext/mbstring/mbstring.c 30 Apr 2002 12:00:42 - 1.66
+++ ext/mbstring/mbstring.c 30 Apr 2002 13:56:16 -
@@ -71,43 +71,32 @@
#include mbregex.h
#endif
-#if defined(HAVE_MBSTR_JA)
static const enum mbfl_no_encoding php_mbstr_default_identify_list[] = {
mbfl_no_encoding_ascii,
+
+#if defined(HAVE_MBSTR_JA)
mbfl_no_encoding_jis,
- mbfl_no_encoding_utf8,
mbfl_no_encoding_euc_jp,
mbfl_no_encoding_sjis
-};
#endif
-
-#if defined(HAVE_MBSTR_CN) !defined(HAVE_MBSTR_JA)
-static const enum mbfl_no_encoding php_mbstr_default_identify_list[] = {
- mbfl_no_encoding_ascii,
- mbfl_no_encoding_utf8,
+#if defined(HAVE_MBSTR_CN)
mbfl_no_encoding_euc_cn,
mbfl_no_encoding_cp936
-};
#endif
-#if defined(HAVE_MBSTR_TW) !defined(HAVE_MBSTR_JA)
-static const enum mbfl_no_encoding php_mbstr_default_identify_list[] = {
- mbfl_no_encoding_ascii,
- mbfl_no_encoding_utf8,
+#if defined(HAVE_MBSTR_TW)
mbfl_no_encoding_euc_tw,
mbfl_no_encoding_big5
-};
#endif
-#if defined(HAVE_MBSTR_KR) !defined(HAVE_MBSTR_JA)
-static const enum mbfl_no_encoding php_mbstr_default_identify_list[] = {
- mbfl_no_encoding_ascii,
- mbfl_no_encoding_utf8,
+#if defined(HAVE_MBSTR_KR)
mbfl_no_encoding_euc_kr,
mbfl_no_encoding_uhc
-};
#endif
+
+ mbfl_no_encoding_utf8
+};
static const int php_mbstr_default_identify_list_size =
sizeof(php_mbstr_default_identify_list)/sizeof(enum mbfl_no_encoding);
--
Preston L. Bannister
[EMAIL PROTECTED]
pbannister on Yahoo Messenger
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] to temporary file open
On Win32 you can use the environment variables TMP and TEMP to obtain the
directory for temporary files. For portability of applications it makes a
great deal of sense (especially when documenting your application!) if the
same overrides for temporary file placement is checked in the same order on
every platform.
Note that this change is backwards compatible in the sense that absent any
overrides the placement of temporary files is the default for each platform.
Index: main/php_open_temporary_file.c
===
RCS file: /repository/php4/main/php_open_temporary_file.c,v
retrieving revision 1.14
diff -u -b -r1.14 php_open_temporary_file.c
--- main/php_open_temporary_file.c 28 Feb 2002 08:27:03 - 1.14
+++ main/php_open_temporary_file.c 30 Apr 2002 13:56:36 -
-150,47 +150,40
*/
PHPAPI FILE *php_open_temporary_file(const char *dir, const char *pfx, char
**opened_path_p TSRMLS_DC)
{
- static char path_tmp[] = /tmp;
- FILE *fp;
-
-
+FILE* fp = 0;
if (!pfx) {
pfx = tmp.;
}
-
if (opened_path_p) {
*opened_path_p = NULL;
}
-
- if ((fp=php_do_open_temporary_file((char *) dir, pfx, opened_path_p
TSRMLS_CC))) {
+fp = php_do_open_temporary_file((char *) dir, pfx, opened_path_p
TSRMLS_CC);
+if (fp) {
return fp;
}
-
- if ((fp=php_do_open_temporary_file(getenv(TMPDIR), pfx, opened_path_p
TSRMLS_CC))) {
+fp = php_do_open_temporary_file(getenv(TMPDIR), pfx, opened_path_p
TSRMLS_CC);
+if (fp) {
return fp;
}
-#if PHP_WIN32
- {
- char *TempPath;
-
- TempPath = (char *) emalloc(MAXPATHLEN);
- if (GetTempPath(MAXPATHLEN, TempPath)) {
- fp = php_do_open_temporary_file(TempPath, pfx, opened_path_p
TSRMLS_CC);
- }
- efree(TempPath);
+fp = php_do_open_temporary_file(getenv(TEMP), pfx, opened_path_p
TSRMLS_CC);
+if (fp) {
return fp;
}
-#else
- if ((fp=php_do_open_temporary_file(P_tmpdir, pfx, opened_path_p
TSRMLS_CC))) {
+fp = php_do_open_temporary_file(getenv(TMP), pfx, opened_path_p
TSRMLS_CC);
+if (fp) {
return fp;
}
-
- if ((fp=php_do_open_temporary_file(path_tmp, pfx, opened_path_p
TSRMLS_CC))) {
+#ifdef P_tmpdir
+fp = php_do_open_temporary_file(P_tmpdir, pfx, opened_path_p
TSRMLS_CC);
+if (fp) {
return fp;
}
#endif
-
- return NULL;
+fp = php_do_open_temporary_file(/tmp, pfx, opened_path_p TSRMLS_CC);
+if (fp) {
+return fp;
+}
+return 0;
}
/* }}} */
--
Preston L. Bannister
http://members.cox.net/preston.bannister/
pbannister on Yahoo Messenger
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] to locate php.ini on Win32 with executable
Searching for php.ini only in %windir% is a problem when more than
application is using PHP on the same Win32 machine. What you really want is
behavior similar to PHP on Unix where php.ini is first looked for local to
the PHP executable.
The following patch has PHP looking for the php.ini first in the same
directory as PHP.exe and next in the Windows installation directory.
Note that this change is backwards compatible.
Index: main/php_ini.c
===
RCS file: /repository/php4/main/php_ini.c,v
retrieving revision 1.85
diff -u -b -r1.85 php_ini.c
--- main/php_ini.c 19 Apr 2002 05:48:22 - 1.85
+++ main/php_ini.c 30 Apr 2002 14:51:59 -
-226,19 +226,19
php_ini_search_path = php_ini_path_override;
free_ini_search_path = 0;
} else {
- char *default_location;
- int free_default_location;
-
#ifdef PHP_WIN32
- default_location = (char *) emalloc(512);
+char sSearchPath[1024];
+char *default_location = sSearchPath;
- if (!GetWindowsDirectory(default_location, 255)) {
- default_location[0]=0;
- }
- free_default_location=1;
+/* Look in the same directory as the executable. */
+GetModuleFileName(0,sSearchPath,sizeof(sSearchPath)) || (sSearchPath[0] = 0);
+{ char* p = strrchr(sSearchPath,'\\'); if (p) *++p = 0; }
+
+/* Add the Windows base directory as well. */
+strncat(sSearchPath,;,sizeof(sSearchPath));
+{ int n = strlen(sSearchPath);
+GetWindowsDirectory(sSearchPath+n,sizeof(sSearchPath)-n); }
#else
- default_location = PHP_CONFIG_FILE_PATH;
- free_default_location=0;
+char *default_location = PHP_CONFIG_FILE_PATH;
#endif
php_ini_search_path = (char *)
emalloc(sizeof(.)+strlen(env_location)+strlen(default_location)+2+1);
free_ini_search_path = 1;
-255,9 +255,6
sprintf(php_ini_search_path, .%c%s,
ZEND_PATHS_SEPARATOR, default_location);
}
}
- if (free_default_location) {
- efree(default_location);
- }
}
PG(safe_mode) = 0;
--
Preston L. Bannister
http://members.cox.net/preston.bannister/
pbannister on Yahoo Messenger
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] to not require cgi.force_redirect= 0 under IIS on Win32
Takes a step out of setting up PHP for IIS.
My understanding of the previous discussion was that cgi.force_redirect
is not required if running under IIS. This patch detects IIS.
One less thing to go wrong configuring under Win32 and IIS :).
Index: sapi/cgi/cgi_main.c
===
RCS file: /repository/php4/sapi/cgi/cgi_main.c,v
retrieving revision 1.158
diff -u -b -r1.158 cgi_main.c
--- sapi/cgi/cgi_main.c 12 Apr 2002 00:20:29 - 1.158
+++ sapi/cgi/cgi_main.c 30 Apr 2002 15:06:59 -
-577,6 +577,14
/* check force_cgi after startup, so we have proper output */
if (cfg_get_long(cgi.force_redirect, force_redirect) == FAILURE) {
force_redirect = 1;
+{
+/* We don't need force_cgi on if running under IIS. */
+char* sServerSoftware = getenv(SERVER_SOFTWARE);
+char* sExpected = Microsoft-IIS;
+if (sServerSoftware (0 ==
+strncmp(sServerSoftware,sExpected,strlen(sExpected {
+force_redirect = 0;
+}
+}
}
if (cgi force_redirect) {
if (cfg_get_string(cgi.redirect_status_env, redirect_status_env) ==
FAILURE) {
--
Preston L. Bannister
http://members.cox.net/preston.bannister/
pbannister on Yahoo Messenger
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] to reflect installation values unknown at build time on Win32
There are values known at compile time on Unix that are *not* known at compile time on Win32. Rather than compile in something misleading (and very likely wrong), better to *not* supply a value. Index: ext/standard/info.c === RCS file: /repository/php4/ext/standard/info.c,v retrieving revision 1.171 diff -u -b -r1.171 info.c --- ext/standard/info.c 29 Mar 2002 10:19:23 - 1.171 +++ ext/standard/info.c 30 Apr 2002 14:51:54 - -250,7 +250,7 php_info_print_table_row(2, Virtual Directory Support, disabled ); #endif - php_info_print_table_row(2, Configuration File (php.ini) Path, php_ini_opened_path?php_ini_opened_path:PHP_CONFIG_FILE_PATH); + php_info_print_table_row(2, Configuration File (php.ini) Path, +php_ini_opened_path?php_ini_opened_path:(none)); #if ZEND_DEBUG php_info_print_table_row(2, Debug Build, yes ); Index: main/config.w32.h === RCS file: /repository/php4/main/config.w32.h,v retrieving revision 1.58 diff -u -b -r1.58 config.w32.h --- main/config.w32.h 28 Apr 2002 17:50:09 - 1.58 +++ main/config.w32.h 30 Apr 2002 14:51:57 - -5,18 +5,6 $Id: config.w32.h,v 1.58 2002/04/28 17:50:09 sebastian Exp $ */ -/* Default PHP / PEAR directories */ -#define CONFIGURATION_FILE_PATH php.ini -#define PHP_BINDIR c:\\php4 -#define PHP_CONFIG_FILE_PATH (getenv(SystemRoot))?getenv(SystemRoot): -#define PHP_DATADIR c:\\php4 -#define PHP_EXTENSION_DIR c:\\php4 -#define PHP_INCLUDE_PATH .;c:\\php4\\pear -#define PHP_LIBDIR c:\\php4 -#define PHP_LOCALSTATEDIR c:\\php4 -#define PHP_SYSCONFDIR c:\\php4 -#define PEAR_INSTALLDIR c:\\php4\\pear - /* Enable / Disable BCMATH extension (default: enabled) */ #define WITH_BCMATH 1 -156,3 +144,15 #undef HAVE_RINT #define HAVE_STRFTIME 1 #define SIZEOF_INT 4 + +/* Values that cannot be known at compile time. */ +#define PEAR_INSTALLDIR +#define PHP_BINDIR +#define PHP_CONFIG_FILE_PATH +#define PHP_DATADIR +#define PHP_EXTENSION_DIR +#define PHP_EXTENSION_DIR +#define PHP_INCLUDE_PATH +#define PHP_LIBDIR +#define PHP_LOCALSTATEDIR +#define PHP_SYSCONFDIR Index: main/main.c === RCS file: /repository/php4/main/main.c,v retrieving revision 1.446 diff -u -b -r1.446 main.c --- main/main.c 30 Apr 2002 00:17:48 - 1.446 +++ main/main.c 30 Apr 2002 14:51:58 - -990,6 +990,11 REGISTER_MAIN_STRINGL_CONSTANT(PHP_VERSION, PHP_VERSION, sizeof(PHP_VERSION)-1, CONST_PERSISTENT | CONST_CS); REGISTER_MAIN_STRINGL_CONSTANT(PHP_OS, php_os, strlen(php_os), CONST_PERSISTENT | CONST_CS); REGISTER_MAIN_STRINGL_CONSTANT(PHP_SAPI, sapi_module.name, strlen(sapi_module.name), CONST_PERSISTENT | CONST_CS); + +/* + * The following directories are known at the time PHP + * is configured and built on Unix, but not on Win32. + */ REGISTER_MAIN_STRINGL_CONSTANT(DEFAULT_INCLUDE_PATH, PHP_INCLUDE_PATH, sizeof(PHP_INCLUDE_PATH)-1, CONST_PERSISTENT | CONST_CS); REGISTER_MAIN_STRINGL_CONSTANT(PEAR_INSTALL_DIR, PEAR_INSTALLDIR, sizeof(PEAR_INSTALLDIR)-1, CONST_PERSISTENT | CONST_CS); REGISTER_MAIN_STRINGL_CONSTANT(PEAR_EXTENSION_DIR, PHP_EXTENSION_DIR, sizeof(PHP_EXTENSION_DIR)-1, CONST_PERSISTENT | CONST_CS); Index: main/win95nt.h === RCS file: /repository/php4/main/win95nt.h,v retrieving revision 1.13 diff -u -b -r1.13 win95nt.h --- main/win95nt.h 25 Apr 2002 09:01:35 - 1.13 +++ main/win95nt.h 30 Apr 2002 14:51:59 - -55,7 +55,9 #define NOOPENFILE /* sendmail is built-in */ +/* #ifdef PHP_PROG_SENDMAIL #undef PHP_PROG_SENDMAIL #define PHP_PROG_SENDMAIL Built in mailer #endif +*/ -- Preston L. Bannister http://members.cox.net/preston.bannister/ pbannister on Yahoo Messenger -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] to get mbstring.c to compile
Duh - wrong diff. This is what I get for doing too many things at once :).
The following compiles w/o trouble on Win32.
Index: ext/mbstring/mbstring.c
===
RCS file: /repository/php4/ext/mbstring/mbstring.c,v
retrieving revision 1.66
diff -u -b -r1.66 mbstring.c
--- ext/mbstring/mbstring.c 30 Apr 2002 12:00:42 - 1.66
+++ ext/mbstring/mbstring.c 30 Apr 2002 15:21:26 -
@@ -71,45 +71,34 @@
#include mbregex.h
#endif
-#if defined(HAVE_MBSTR_JA)
static const enum mbfl_no_encoding php_mbstr_default_identify_list[] = {
mbfl_no_encoding_ascii,
+
+#if defined(HAVE_MBSTR_JA)
mbfl_no_encoding_jis,
- mbfl_no_encoding_utf8,
mbfl_no_encoding_euc_jp,
- mbfl_no_encoding_sjis
-};
+ mbfl_no_encoding_sjis,
#endif
-
-#if defined(HAVE_MBSTR_CN) !defined(HAVE_MBSTR_JA)
-static const enum mbfl_no_encoding php_mbstr_default_identify_list[] = {
- mbfl_no_encoding_ascii,
- mbfl_no_encoding_utf8,
+#if defined(HAVE_MBSTR_CN)
mbfl_no_encoding_euc_cn,
- mbfl_no_encoding_cp936
-};
+ mbfl_no_encoding_cp936,
#endif
-#if defined(HAVE_MBSTR_TW) !defined(HAVE_MBSTR_JA)
-static const enum mbfl_no_encoding php_mbstr_default_identify_list[] = {
- mbfl_no_encoding_ascii,
- mbfl_no_encoding_utf8,
+#if defined(HAVE_MBSTR_TW)
mbfl_no_encoding_euc_tw,
- mbfl_no_encoding_big5
-};
+ mbfl_no_encoding_big5,
#endif
-#if defined(HAVE_MBSTR_KR) !defined(HAVE_MBSTR_JA)
-static const enum mbfl_no_encoding php_mbstr_default_identify_list[] = {
- mbfl_no_encoding_ascii,
- mbfl_no_encoding_utf8,
+#if defined(HAVE_MBSTR_KR)
mbfl_no_encoding_euc_kr,
- mbfl_no_encoding_uhc
-};
+ mbfl_no_encoding_uhc,
#endif
-static const int php_mbstr_default_identify_list_size =
sizeof(php_mbstr_default_identify_list)/sizeof(enum mbfl_no_encoding);
+ mbfl_no_encoding_utf8
+};
+
+static const int php_mbstr_default_identify_list_size =
sizeof(php_mbstr_default_identify_list)/sizeof(php_mbstr_default_identify_list[0]);
static unsigned char third_and_rest_force_ref[] = { 3, BYREF_NONE, BYREF_NONE,
BYREF_FORCE_REST };
static unsigned char second_args_force_ref[] = { 2, BYREF_NONE, BYREF_FORCE };
-Original Message-
From: Preston L. Bannister [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 30, 2002 7:21 AM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] [PATCH] to get mbstring.c to compile
The latest patch mbstring.c prevents PHP from compiling when none of the
HAVE_MBSTR_* defines are present (which would be most sites!). The code
requires the php_mbstr_default_identify_list array must always be defined.
Now as an English-only person I have no notion which values and ordering is
correct. Presumably someone with this knowledge can make the appropriate
adjustments :).
Although looking at this code, I suspect that the encodings chosen should be
chosen not a compile time, but at run time. There was a rather a lot of
discussion in the Apache Jakarta mailing lists about encodings chosen on a
per-request basis.
In any case - this patch allows the code to compile anywhere.
[snipped wrong diff]
--
Preston L. Bannister
http://members.cox.net/preston.bannister/
pbannister on Yahoo Messenger
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS account request?
I submitted a CVS account request via the web page (http://www.php.net/cvs-php.php), but I don't see a corresponding message in the mailing list. Is the web page broken, or is this normal? We're using PHP in our web application, and I'd like to take off some of the rough edges from the Win32 version of PHP :). -- Preston L. Bannister http://members.cox.net/preston.bannister/ pbannister on Yahoo Messenger -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
