Re: [PHP-DEV] [PATCH] disallow --enable-versioning with shared modules

[Sascha Schumann]

Guys, --enable-versioning has always been for those who don't
need shared extensions and who want to run multiple PHP
versions concurrently.  It does not need to suit everyone's
needs to be useful.

- Sascha

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

[PHP-DEV] Re: PATCH ssize_t without messing with fcgi source

[Ard Biesheuvel]

Works with everything.  (phew!)

You might wanna use long instead of int here, as sizeof(ssize_t) is 
supposed to match the native pointer size.

--
Ard




Index: main/config.w32.h
===
RCS file: /repository/php-src/main/config.w32.h,v
retrieving revision 1.80
diff -u -r1.80 config.w32.h
--- main/config.w32.h   13 Nov 2003 10:32:04 -  1.80
+++ main/config.w32.h   14 Nov 2003 00:56:36 -
@@ -174,7 +174,7 @@
 #define SIZEOF_LONG_LONG_INT 0
 #define SIZEOF_LONG_LONG 0
 #define SIZEOF_INTMAX_T 0
-#define ssize_t SSIZE_T
+#define ssize_t int
 #ifdef _WIN64
 # define SIZEOF_SIZE_T 8
 # define SIZEOF_PTRDIFF_T 8
Index: sapi/cgi/libfcgi/include/fcgi_config_win32.h
===
RCS file: /repository/php-src/sapi/cgi/libfcgi/include/fcgi_config_win32.h,v
retrieving revision 1.2
diff -u -r1.2 fcgi_config_win32.h
--- sapi/cgi/libfcgi/include/fcgi_config_win32.h13 Nov 2003 10:32:05 - 
 1.2
+++ sapi/cgi/libfcgi/include/fcgi_config_win32.h14 Nov 2003 00:56:38 -
@@ -106,3 +106,6 @@
 /* Define as `__inline' if that's what the C compiler calls it, or to nothing
if it is not supported. */
 /* #undef inline */
+
+/* Define to `int' if  does not define. */
+#define ssize_t int
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PATCH ssize_t without messing with fcgi source

[Ard Biesheuvel]

Steph wrote:
Works with everything.  (phew!)
Are you sure this will work on Win64 ?
I think sizeof(ssize_t) is supposed to match the native pointer size.
--
Ard


Index: main/config.w32.h
===
RCS file: /repository/php-src/main/config.w32.h,v
retrieving revision 1.80
diff -u -r1.80 config.w32.h
--- main/config.w32.h   13 Nov 2003 10:32:04 -  1.80
+++ main/config.w32.h   14 Nov 2003 00:56:36 -
@@ -174,7 +174,7 @@
 #define SIZEOF_LONG_LONG_INT 0
 #define SIZEOF_LONG_LONG 0
 #define SIZEOF_INTMAX_T 0
-#define ssize_t SSIZE_T
+#define ssize_t int
 #ifdef _WIN64
 # define SIZEOF_SIZE_T 8
 # define SIZEOF_PTRDIFF_T 8
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: PATCH ssize_t without messing with fcgi source

[Steph]

Ard, hi -

ssize_t was originally defined as ptrdiff_t in config.w32.h, which is itself
defined as int in win32 (in stddef.h).  It was then redefined as int in the
fcgi configuration.  It was also redefined in gd_jpeg.c (one of the few
win32-affecting places that uses it) prior to any includes:

#if PHP_WIN32 && !defined(ssize_t)
typedef int ssize_t;
#endif

- this was originally preventing some of the gd functions from working,
because ssize_t WAS defined already (in config.w32.h) - as ptrdiff_t, which
there was no definition for that gd_jpeg.c knew of.

>From to the Single Unix Specification
(http://www.opengroup.org/onlinepubs/007908799/xsh/systypes.h.html):

"ssize_t
Used for a count of bytes or an error indication.

ssize_t is a signed integral type .. capable of storing values at least in
the range [-1, SSIZE_MAX]."

Windows - uniquely - uses the definition SSIZE_T (type:  INT_PTR) - note
that ssize_t isn't the same thing as SSIZE_T, anywhere - but if I go that
route for ssize_t definition (as I already tried to do) we end up with the
fcgi redefinition to int anyway.

Basically all I'm doing here is going back to the original, just saying it
in a less obfuscated and more generic way :)  so if it breaks on 64-bit
architectures (which it shouldn't), it's not going to break in a way that it
wouldn't have broken if I'd never been born.  If you follow.

Steph



> -Original Message-
> From: Ard Biesheuvel [mailto:[EMAIL PROTECTED]
> Sent: 14 November 2003 11:17
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] Re: PATCH ssize_t without messing with fcgi source
>
>
> > Works with everything.  (phew!)
> >
>
> You might wanna use long instead of int here, as sizeof(ssize_t) is
> supposed to match the native pointer size.
>
> --
> Ard
>
>
>
> > 
> >
> > Index: main/config.w32.h
> > ===
> > RCS file: /repository/php-src/main/config.w32.h,v
> > retrieving revision 1.80
> > diff -u -r1.80 config.w32.h
> > --- main/config.w32.h   13 Nov 2003 10:32:04 -  1.80
> > +++ main/config.w32.h   14 Nov 2003 00:56:36 -
> > @@ -174,7 +174,7 @@
> >  #define SIZEOF_LONG_LONG_INT 0
> >  #define SIZEOF_LONG_LONG 0
> >  #define SIZEOF_INTMAX_T 0
> > -#define ssize_t SSIZE_T
> > +#define ssize_t int
> >  #ifdef _WIN64
> >  # define SIZEOF_SIZE_T 8
> >  # define SIZEOF_PTRDIFF_T 8
> > Index: sapi/cgi/libfcgi/include/fcgi_config_win32.h
> > ===
> > RCS file:
> /repository/php-src/sapi/cgi/libfcgi/include/fcgi_config_win32.h,v
> > retrieving revision 1.2
> > diff -u -r1.2 fcgi_config_win32.h
> > --- sapi/cgi/libfcgi/include/fcgi_config_win32.h13 Nov 2003
> 10:32:05 -1.2
> > +++ sapi/cgi/libfcgi/include/fcgi_config_win32.h14 Nov 2003
> 00:56:38 -
> > @@ -106,3 +106,6 @@
> >  /* Define as `__inline' if that's what the C compiler calls
> it, or to nothing
> > if it is not supported. */
> >  /* #undef inline */
> > +
> > +/* Define to `int' if  does not define. */
> > +#define ssize_t int
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] minor install issue (apache 1 sapi)

[terry chay]

Jani,

	Yes, this happens when I create an RPM, however this is still a bug. 
Here is RPM's build process:
1) read spec file and look in /usr/src/redhat/SOURCES for files 
necessary to build RPM
2) configure and compile with settings targeted at "/"
3) make install into a temporary directory targetted at a temporary 
directory
4) if this succeeds, bundle sources and spec file into a source RPM
5) bundle temporary directory and spec file into binary RPM

	First, it is perfectly valid that I create a php package against my 
installed apache. In fact, this is how Red Hat does it themselves and 
the only valid way to safely replace an RPM with a non-distribution one 
(this is why you should normally compile into /opt or /usr/local). The 
reason Fedora hasn't found this bug has to do with the fact that the 
later versions of Red Hat (since 9.0?) link against Apache 2 which 
doesn't have this bug.

	Second, this does not apply specifically to the RPM build process, it 
applies generically to any build process that doesn't install the files 
directly, uses a late version PHP 4.3.3+ and links against Apache 1.3. 
It also applies to anyone (PHP 4.3.3+/Apache 1.3) doing a make install 
to a target directory (mostly these are packagers).

	Third, if apxs modifies any files in the file system that aren't 
built, my patch doesn't work--instead, one would have to build out a 
new httpd.conf file from the current one by perl and a lot of needless 
but necessary complexity. (But I don't believe this is the case since I 
think apxs is like the apache version of phpize.)

	Take care,

		terry

P.S. The Fedora PHP RPM is an absolute mess. It applies 12 patches and 
separately compiles the cgi/sapi modules even though PHP has long since 
built out both when you compile the SAPI. I don't know if there is 
anything interesting in there, but you can download it from them and 
apply "rpm2cpio  | cpio -ivmud" and rummage around at 
the patches.

This is the patch I applied (obviously my SPEC is much different from 
Fedora's because I'm compiling against 1.3 instead of 2.0).
--- php-4.3.3/sapi/apache/config.m4.orig  Thu Nov 13 11:04:05 2003
+++ php-4.3.3/sapi/apache/config.m4   Thu Nov 13 11:04:41 2003
@@ -80,7 +80,7 @@
$APXS -S LIBEXECDIR='$APXS_LIBEXECDIR' \
  -i -n php4 $SAPI_SHARED"
 else
-  APXS_SYSCONFDIR='$(INSTALL_ROOT)'`$APXS -q SYSCONFDIR`
+  APXS_SYSCONFDIR=`$APXS -q SYSCONFDIR`
   APACHE_INSTALL="\$(mkinstalldirs) '$APXS_LIBEXECDIR' && \
   \$(mkinstalldirs) '$APXS_SYSCONFDIR' && \
$APXS -S LIBEXECDIR='$APXS_LIBEXECDIR' \

On Nov 13, 2003, at 4:20 PM, Jani Taskinen wrote:

This happens while _creating_ the rpm? In that case,
I wouldn't call it a bug..you shouldn't be creating the
package against your installed apache, but the one you're
gonna package too.
Diclaimer: this is purely 'common sense' guess as I have never
   done any rpms of php myself.
--Jani

On Thu, 13 Nov 2003, terry chay wrote:

	I'm not too sure this belongs here or on PHP-INST (there was a 
message
by Dinesh Anchan back in July 17 on PHP-INST where the replier wasn't
helpful to the poor guy). In any case...

I'm running into a minor issue, easily patched, installing PHP 4.3.3+
on Apache 1.3.
PROBLEM
Creating a php RPM script linked against apache 1.3 fails during
install with an error:
apxs: Error: Config file /var/tmp/php-root/etc/httpd/conf/httpd.conf
not found
make: *** [install-sapi] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.30157
SOLUTION
In php/sapi/apache/config.m4 replace the line:
APXS_SYSCONFDIR='$(INSTALL_ROOT)' `APXS -q SYSCONFDIR`
with
APXS_SYSCONFDIR=`APXS -q SYSCONFDIR`
EXPLANATION:
When php installs mod_php, it executes apxs with a reference to
SYSCONFDIR (i.e. "apxs -S SYSCONFDIR='/etc/httpd/conf'). If the above
solution isn't applied and your packager script does something like:
make install INSTALL_ROOT=/some/temp/dir
then as it stands, apxs will now look for a file that doesn't exist
(/some/temp/dir/etc/httpd/conf/httpd.conf) and crap out.
	Take care,

terry
--
terry chay  


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

Re: [PHP-DEV] Re: PATCH ssize_t without messing with fcgi source

[Ard Biesheuvel]

Steph,

Windows - uniquely - uses the definition SSIZE_T (type:  INT_PTR) - note
that ssize_t isn't the same thing as SSIZE_T, anywhere - but if I go that
route for ssize_t definition (as I already tried to do) we end up with the
fcgi redefinition to int anyway.
Basically all I'm doing here is going back to the original, just saying it
in a less obfuscated and more generic way :)  so if it breaks on 64-bit
architectures (which it shouldn't), it's not going to break in a way that it
wouldn't have broken if I'd never been born.  If you follow.
... except that INT_PTR is 64-bit on Win64, and int is not.

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

RE: [PHP-DEV] Re: PATCH ssize_t without messing with fcgi source

[Steph]

> ... except that INT_PTR is 64-bit on Win64, and int is not.
>
yeah, I just found that too :)

This means that php-src is currently correct for all architectures but fcgi
src is not.  So what's the best line of attack here?

#ifdef _WIN64
+ # define ssize_t SSIZE_T
# define SIZEOF_SIZE_T 8
# define SIZEOF_PTRDIFF_T 8
#else
+ # define ssize_t int
# define SIZEOF_SIZE_T 4
# define SIZEOF_PTRDIFF_T 4
#endif

?

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

Re: [PHP-DEV] [PATCH] disallow --enable-versioning with shared modules

[Zeev Suraski]

At 17:56 14/11/2003, Sascha Schumann wrote:
Guys, --enable-versioning has always been for those who don't
need shared extensions and who want to run multiple PHP
versions concurrently.  It does not need to suit everyone's
needs to be useful.
I agree completely.

Zeev

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

Re: [PHP-DEV] [PATCH] disallow --enable-versioning with shared modules

[Jani Taskinen]

On Fri, 14 Nov 2003, Sascha Schumann wrote:

>Guys, --enable-versioning has always been for those who don't
>need shared extensions and who want to run multiple PHP
>versions concurrently.  It does not need to suit everyone's
>needs to be useful.

I guess I didn't make it clear enough in my mail:

   --enable-versioning does not work at all.

I was merely suggesting ways to make it work, or just get rid of it.
This has nothing to do with the fact that when --enable-versioning
is used shared extensions will not work. It was just one issue with it.

--Jani


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

Re: [PHP-DEV] [PATCH] disallow --enable-versioning with shared modules

[Sascha Schumann]

> I was merely suggesting ways to make it work, or just get rid of it.
> This has nothing to do with the fact that when --enable-versioning
> is used shared extensions will not work. It was just one issue with it.

Either it is working as expected (symbols are not exported;
shared extensions don't work), or it is not (symbols are
exported; shared extensions are not affected).

So, which is it?

- Sascha

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

[PHP-DEV] --enable-versioning does not work (was: Re: [PHP-DEV] [PATCH] disallow --enable-versioning with shared modules)

[Jani Taskinen]

On Fri, 14 Nov 2003, Sascha Schumann wrote:

>> I was merely suggesting ways to make it work, or just get rid of it.
>> This has nothing to do with the fact that when --enable-versioning
>> is used shared extensions will not work. It was just one issue with it.
>
>Either it is working as expected (symbols are not exported;
>shared extensions don't work), or it is not (symbols are
>exported; shared extensions are not affected).
>
>So, which is it?

I say again: PHP shared extensions has nothing to do with this.

If you compile PHP 5 (or 4, or both) with --enable-versioning
and load them in same apache, it will crash.

It WILL work if you use libtool 1.5 or this patch:

  http://mail.gnu.org/archive/html/libtool/2002-07/msg00029.html

(Provided you change some stuff in sapi/apache/mod_php5.c, of course)

--Jani





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

Re: [PHP-DEV] Re: PATCH ssize_t without messing with fcgi source

[Ard Biesheuvel]

Steph wrote:
... except that INT_PTR is 64-bit on Win64, and int is not.

yeah, I just found that too :)

This means that php-src is currently correct for all architectures but fcgi
src is not.  So what's the best line of attack here?
What about

#define ssize_t INT_PTR

for Win{32|64} ??

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

RE: [PHP-DEV] Re: PATCH ssize_t without messing with fcgi source

[Steph]

> What about
>
> #define ssize_t INT_PTR
>
> for Win{32|64} ??
>
> --
> Ard

SSIZE_T is already an INT_PTR in both architectures.  Calling it INT_PTR
directly, doesn't actually change anything from the current php-src (the
patch Edin put in for me yesterday).  The objection Wez made to that was
that it involves either altering fcgi source or living with the subsequent
redefinition (to int).

All I want for Christmas is to get the number of PHP5 win32 warnings down to
a sane level, if fcgi configuration is b0rked on win64 currently there's not
a great deal we can do about it (exceptions: Sascha, Shane, Frank).  int
works for win32, and is the most frequently used definition of ssize_t I've
come across for systems without sys/types.h.  It would be nicer if fcgi's
win32|64 configuration used SSIZE_T, but it doesn't...

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

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

[PHP-DEV] CVS Account Request: jakerator

[Evgeniy Tsimbalyuk]

I need the access to the CVS for few php-programmers from different countries.

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

Re: [PHP-DEV] --enable-versioning does not work (was: Re: [PHP-DEV] [PATCH] disallow --enable-versioning with shared modules)

[Marcus Boerger]

Hello Jani,

Friday, November 14, 2003, 5:15:39 PM, you wrote:

> On Fri, 14 Nov 2003, Sascha Schumann wrote:

>>> I was merely suggesting ways to make it work, or just get rid of it.
>>> This has nothing to do with the fact that when --enable-versioning
>>> is used shared extensions will not work. It was just one issue with it.
>>
>>Either it is working as expected (symbols are not exported;
>>shared extensions don't work), or it is not (symbols are
>>exported; shared extensions are not affected).
>>
>>So, which is it?

> I say again: PHP shared extensions has nothing to do with this.

> If you compile PHP 5 (or 4, or both) with --enable-versioning
> and load them in same apache, it will crash.

> It WILL work if you use libtool 1.5 or this patch:

>   http://mail.gnu.org/archive/html/libtool/2002-07/msg00029.html

> (Provided you change some stuff in sapi/apache/mod_php5.c, of course)

Since especially you Jani know the problems of upgrading build environment i
suggest that for the moment we should use the patch then. Right ?



-- 
Best regards,
 Marcusmailto:[EMAIL PROTECTED]

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

Re: [PHP-DEV] return by reference behaviors in PHP 5

[Daniel Convissor]

Hi Folks:

I'm sorry to be a nudge, but am surprised no one has replied to my prior
post.  Perhaps someone is doing some testing or research before replying?  
Perhaps it got overlooked?  Perhaps everyone is busy and thought someone
else would answer?

Regardless, it would be great if someone could reply.

Thanks,

--Dan

 Message-ID: <[EMAIL PROTECTED]>
 Archive URI: http://marc.theaimsgroup.com/?l=php-dev&m=106866036715442

-- 
 FREE scripts that make web and database programming easier
   http://www.analysisandsolutions.com/software/
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
 4015 7th Ave #4AJ, Brooklyn NYv: 718-854-0335   f: 718-854-0409

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

Re: [PHP-DEV] return by reference behaviors in PHP 5

[Andi Gutmans]

I'll try and take a look at it next week (I had no time this week).
The problem is that there where bugs in the past when returning by 
reference not variables, which could cause memory corruptions. This is why 
we didn't allow it. In order not to completely break every script in some 
cases we can turn a blind eye and allow it (such as return 4;) because it 
can be dealt with.
Anyway, as I said it's something I need to look into more detail again 
which I'll do soon.
Andi

At 01:39 PM 11/14/2003 -0500, Daniel Convissor wrote:
Hi Folks:

I'm sorry to be a nudge, but am surprised no one has replied to my prior
post.  Perhaps someone is doing some testing or research before replying?
Perhaps it got overlooked?  Perhaps everyone is busy and thought someone
else would answer?
Regardless, it would be great if someone could reply.

Thanks,

--Dan

 Message-ID: <[EMAIL PROTECTED]>
 Archive URI: http://marc.theaimsgroup.com/?l=php-dev&m=106866036715442
--
 FREE scripts that make web and database programming easier
   http://www.analysisandsolutions.com/software/
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
 4015 7th Ave #4AJ, Brooklyn NYv: 718-854-0335   f: 718-854-0409
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CVS Account Request: baoengb

[Enrique Garcia Briones]

To help in the spanish translation of the documentation

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

Re: [PHP-DEV] return by reference behaviors in PHP 5

[Daniel Convissor]

Hi Andi:

On Fri, Nov 14, 2003 at 10:24:45PM +0200, Andi Gutmans wrote:
> I'll try and take a look at it next week (I had no time this week).

Understandable.  Thanks for the update.


> The problem is that there where bugs in the past when returning by 
> reference not variables, which could cause memory corruptions.

Yes, yes.


> In order not to completely break every script in some 
> cases we can turn a blind eye and allow it (such as return 4;) because it 
> can be dealt with.

I assume by something along the lines of internally assigning it to a
variable with a pointer to it (pardon the potential lack of computer
science / C programming terminology).  I guess, then this begs the already
answered question -- why not do the same with methods, etc?  The answer
thus far has been that it's too hard to do, which is okay by me.


> Anyway, as I said it's something I need to look into more detail again 
> which I'll do soon.

Just to clarify, my main concern is that everyone know what the behavior 
is going to be and that it's not going to change again, then document the 
precise rules.  I'll be glad to help with documentation, when it comes to 
that point.

Though, it seems the behavior should be consistent -- sometimes I'm too
logical :) -- so returning a variable is okay and the rest of it should be
blocked, OR rework the system so anything can be returend.

Thanks again,

--Dan

-- 
 FREE scripts that make web and database programming easier
   http://www.analysisandsolutions.com/software/
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
 4015 7th Ave #4AJ, Brooklyn NYv: 718-854-0335   f: 718-854-0409

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

Re: [PHP-DEV] return by reference behaviors in PHP 5

[Daniel Convissor]

Hello Again:

Pardon the followup to myself...

On Fri, Nov 14, 2003 at 05:51:12PM -0500, Daniel Convissor wrote:

> Though, it seems the behavior should be consistent -- sometimes I'm too
> logical :) -- so returning a variable is okay and the rest of it should be
> blocked, OR rework the system so anything can be returend.

I did some more testing on this front and ran into some VERY weird 
behavior which seems to reinforce the point I made above.  The test script 
is below by sig.

Thanks,

--Dan

-- 
 FREE scripts that make web and database programming easier
   http://www.analysisandsolutions.com/software/
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
 4015 7th Ave #4AJ, Brooklyn NYv: 718-854-0335   f: 718-854-0409


Data['DATETIME'] = 'st 10-21-03 06:01 et';

/*
 * Commenting out next three lines changes output to:
 * Ref 1
 * Fatal error: Cannot return overloaded elements or
 * string offsets by reference... line 43.
 */
if ( preg_match('/st (\d\d)-(\d\d)-(\d\d) (\d\d):(\d\d) et/i',
$this->Data['DATETIME'], $Atom) ) {
}
}

function &Ref() {
return $this->int;
}

function &RefAdd() {
return ++$this->int;// Line 43
}

function Not() {
return $this->int;
}
}

$y = new x;

/*
 * Uncommenting the next two lines changes the output to:
 * Fatal error: Only variables or references can be returned
 * by reference... line 43
 */
// $a =& $y->RefAdd();
// echo "RefAdd $a";

$b =& $y->Ref();
echo "Ref $b";

/*
 * Uncommenting the next two lines changes the output to:
 * Ref 1
 * Not 1
 * RefAdd 2
 */
// $c = $y->Not();
// echo "Not $c";

$d =& $y->RefAdd();
echo "RefAdd $d";

?>

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

[PHP-DEV] Running 4.3.x and 5.0.x on WinXP/Apache1.3

[GPHemsley]

Forgive me if this is the wrong place to ask, but I'd like to be able to run 
both the latest version of the 4.3.x branch and the 5.0.x branch 
simultaneously, differentiating only by extension (.php vs. .php5). I am running 
Windows XP 
Professional and Apache 1.3, and would like to be able to do this for both my 
own developmental purposes and for whatever bugs I may find for my current 
setup. If this isn't the right place to ask, I'd appreciate any insight into 
where I should ask.

Thanks,
Gordon Hemsley