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

[Zeev Suraski]

[Stas answered you in a very thorough and accurate way, and since it took 
several hours since I started composing this reply and the time I actually 
sent it, I cut it down to minimum]

Marcus,

I (as well as basically all major OO languages I can think of) disagree 
with you.
OO and inheritance are TOTALLY about 'is a'.  If you want a quick 
verification for this, look for any serious comparison between inheritance 
and aggregation, and you'd see that inheritance is about 'is a', and 
aggregation about 'has a'.  You may argue about which is better, but 
there's no argument about what inheritance relationship is.

Saying "Visibility is about information hiding not showing" is wrong.  It 
has truth to it, as in, visibility is about information hiding, but it most 
certainly is also about information showing.  When you write a class that 
exposes a certain interface (i.e., its public methods), inheriting from 
that class means that the derived class should satisfy the same API as the 
parent (and possibly more).  Inheritance is about specialization.  Your 
derived classes must be able to implement the same API as their parents, 
and possibly (usually) more, specialized features.

I agree with Stas that increasing visibility is not such a necessity.  It's 
not useful in most cases, and I haven't had the opportunity to ever take 
advantage of it myself.  However, increasing visibility does not, in any 
way, violate the principles of OO.  Derived classes can still interface 
with code designed for their base classes, and that's what 
matters.  Therefore, I see no problem in allowing increase in 
visibility.  Remember - private elements pretty much do not exist for 
anything outside the class.  In turn, this means that 'overriding' a 
private method with a public method is allowed, since if it wasn't allowed, 
it would mean that the private method IS exposed in some way to the child, 
if only for the fact it's preventing the child class from using this 
name.  With protected, the parent class is declaring explicitly that the 
derived class may alternate functionality.  It's up to the derived class to 
decide whether this alternative functionality should be publicly available 
or not.  The important thing is that it's available.

Decreasing visibility, however, breaks the most fundamental rule of 
inheritance.  Objects from derived classes can no longer be considered to 
also of the type of their parent classes.  In Java, for instance, it would 
mean that you cant up-cast the object safely (or, in other words, send an 
object of type Square to a function that knows how to deal with 
Rectangles), which would seriously break the language fundamentals.
I agree with Stas too that a typecasting operating is a non issue in 
PHP.  We have no kind of compile-time linkage at all - all of our method 
calls behave like 'virtual' method calls.  Since we have a single path 
inheritance tree like Java, we can safely avoid the headaches C++ bumped 
into with its wide variety of ugly typecast operators.

We could, I suppose, implement a Java-equivalent typecasting operator in 
some way, so you'd be able to call Rectangle's area() instead of 
Square's.  I'm not sure how necessary this is, and how feasible it is, but 
most of all - I don't see how it relates in any way to the visibility 
discussion we had here...

Bottom line - I'm not sure why you're under the impression that "visibility 
hiding is king" and that "the 'is a' concept is not important".  With 
inheritance, it's simply the other way around.

Zeev

At 16:38 12/12/2002, Marcus Börger wrote:
Let me say two things first:
1) Visibility is about information hiding not showing.
2) You are wrong about 'is-a' in general. Our main problem here is that we
do not have a typecast operator.

1) Visibility modifiers are for information hiding. That is you can hide 
certain
implementation details. Each class has three interfaces: i) the interface
accessible from any other scope. ii) the interface accessible from any
derived class

Suppose you are going to design an encryption framework. Then you surely will
first design an interface. In php you will create an abstract class to 
accomplish
this. Then you will implement general features which will handle unencrypted
content and such. Also you may implement general key handling. In the class
hierarchy you will make all acess to uncencrypted content protected or even
private starting from here. Doing this you ensure that no user and in case of
private even no derived class can access unencrypted content.
=> Only information hiding = decreasing visibility.

Or suppose you have a class for content handling and you will base 
encryption on
top of this. Then you will derive the encryption handling from content 
handling and
mark unencrypted acess methods/properties as private.
=> Only information hiding = decreasing visibility.

Note the different motivations for deriving classes above.

More examples could be made but

Re: [PHP-DEV] Re: #20972 [Opn->Csd]: make fails during gd.c

[Ilia A.]

On December 12, 2002 06:13 pm, Mike Robinson wrote:
> Ilia A. wrote:
> > This is a different bug (xpm) caused by a bug in the external
> > GD library, this
> > particular bug has been solved in the CVS. Unless you've
> > patched your GD with
> > gif write support you have nothing to gain from not using the bundled
> > library, which offers more functionality and is more stable.
> > The problem with
> > free/gd_free is likely due to you having 2 sets of the GD
> > library on your
> > computer. This confuses the check, because the headers do not
> > correspond with
> > the library itself.
>
> Is the xpm fix going to make it into 4.3 then?

Yes.

>
> Regards
> Mike Robinson


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

RE: [PHP-DEV] Re: #20972 [Opn->Csd]: make fails during gd.c

[Mike Robinson]

Ilia A. wrote:
> This is a different bug (xpm) caused by a bug in the external 
> GD library, this 
> particular bug has been solved in the CVS. Unless you've 
> patched your GD with 
> gif write support you have nothing to gain from not using the bundled 
> library, which offers more functionality and is more stable. 
> The problem with 
> free/gd_free is likely due to you having 2 sets of the GD 
> library on your 
> computer. This confuses the check, because the headers do not 
> correspond with 
> the library itself.

Is the xpm fix going to make it into 4.3 then?

Regards
Mike Robinson
 


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

Re: [PHP-DEV] Re: #20972 [Opn->Csd]: make fails during gd.c

[Ilia A.]

When I say CV,S I am referring to the latest version of the PHP_4_3 tree, you 
can download snapshots of that tree (generated every 2 hours) from 
http://snaps.php.net

Ilia 

On December 12, 2002 04:55 pm, electroteque wrote:
> sure i do but i have prefixed where gd is so it shouldnt be confused, its
> obviously not checking for 2.0.8 ? i have made my patches to gd
>
> s/php/php-4.3.0RC3/TSRM  -g -O2  -prefer-pic -c
> /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c -o ext/gd/gd.lo
> /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function
> `_php_image_create_from':
> /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1363: warning: assignment
> makes pointer from integer without a cast
> /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function
> `zif_imagecreatefromxpm':
> /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: `gdImageCreateFromXpm'
> undeclared (first use in this function)
> /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: (Each undeclared
> identifier is reported only once
> /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: for each function it
> appears in.)
>
> hmm RC2 never gave me this after i renamed the functions so its something
> else, i'm going to try --with-gd without a prefix and see what happens, are
> you talking the latest snapshot when u say cvs, saying cvs is too vague ,
> as 0RC3 is the latest stable i have also tried the snapshots, but still
> showing errors
>
> "Ilia A." <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>
> > This is a different bug (xpm) caused by a bug in the external GD library,
>
> this
>
> > particular bug has been solved in the CVS. Unless you've patched your GD
>
> with
>
> > gif write support you have nothing to gain from not using the bundled
> > library, which offers more functionality and is more stable. The problem
>
> with
>
> > free/gd_free is likely due to you having 2 sets of the GD library on your
> > computer. This confuses the check, because the headers do not correspond
>
> with
>
> > the library itself.
> >
> > Ilia
> >
> > On December 12, 2002 04:37 pm, electroteque wrote:
> > > i'm sorry this is not fixed , i have RC03
> > >
> > > In file included from /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:89:
> > >
> > > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c: In function
> > > `_php_image_output_ctx':
> > >
> > > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c:73: structure has no
> > > member named `free'
> > >
> > > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c:105: structure has no
> > > member named `free'
> > >
> > > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function
> > > `_php_image_type':
> > >
> > > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1156: structure has no
>
> member
>
> > > named `free'
> > >
> > > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1163: structure has no
>
> member
>
> > > named `free'
> > >
> > > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function
> > > `_php_image_create_from':
> > >
> > > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1345: structure has no
>
> member
>
> > > named `free'
> > >
> > > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1363: warning: assignment
> > > makes pointer from integer without a cast
> > >
> > > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function
> > > `zif_imagecreatefromxpm':
> > >
> > > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433:
>
> `gdImageCreateFromXpm'
>
> > > undeclared (first use in this function)
> > >
> > > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: (Each undeclared
> > > identifier is reported only once
> > >
> > > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: for each function
> > > it appears in.)
> > >
> > >
> > >
> > > i can honestly say checking for a particular version will not help
>
> instead
>
> > > check for versions less than the version that requires gd_free which is
> > > gd-2.0.8
> > >
> > > #if HAVE_LIBGD204
> > >
> > > io_ctx->gd_free(io_ctx);
> > >
> > > #else
> > >
> > > io_ctx->free(io_ctx);
> > >
> > > #endif
> > >
> > > i cant see where this define is coming from HAVE_LIBGD204 ??
> > >
> > >
> > >
> > > <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]...
> > >
> > > > ID:   20972
> > > >  Updated by:   [EMAIL PROTECTED]
> > > >  Reported By:  [EMAIL PROTECTED]
> > > > -Status:   Open
> > > > +Status:   Closed
> > > >  Bug Type: Compile Failure
> > > >  Operating System: Linux - 2.4.18 - SuSE 7.2
> > > >  PHP Version:  4.3.0RC3
> > > >  New Comment:
> > > >
> > > > This bug has been fixed in CVS.
> > > >
> > > > In case this was a PHP problem, snapshots of the sources are packaged
> > > > every three hours; this change will be in the next snapshot. You can
> > > > grab the snapshot at http://snaps.php.net/.
> > > >
> > > > In case this was a documentation problem, the fix will show up soon
> > > > at http://www.php.net/manual/.
> > > >
> > > > In case this was a PHP.net website

Re: [PHP-DEV] Re: #20972 [Opn->Csd]: make fails during gd.c

[electroteque]

ok now its spits the dummy about freetype

In file included from
/usr/src/sources/php/php-4.3.0RC3/ext/gd/libgd/gdft.c:49:
/usr/local/etc/freetype/include/freetype2/freetype/freetype.h:41:22:
ft2build.h: No such file or directory
/usr/local/etc/freetype/include/freetype2/freetype/freetype.h:42:10:
#include expects "FILENAME" or 
/usr/local/etc/freetype/include/freetype2/freetype/freetype.h:43:10:
#include expects "FILENAME" or 
/usr/local/etc/freetype/include/freetype2/freetype/freetype.h:44:10:
#include expects "FILENAME" or 

and then all these errors for 1000 lines which would be silly to post

the end looks like this

union
/usr/src/sources/php/php-4.3.0RC3/ext/gd/libgd/gdft.c:1032: request for
member `yMax' in something not a structure or
union
/usr/src/sources/php/php-4.3.0RC3/ext/gd/libgd/gdft.c:1033: request for
member `xMin' in something not a structure or
union
/usr/src/sources/php/php-4.3.0RC3/ext/gd/libgd/gdft.c:1033: request for
member `yMax' in something not a structure or
union
make: *** [ext/gd/libgd/gdft.lo] Error 1

"Ilia A." <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> This is a different bug (xpm) caused by a bug in the external GD library,
this
> particular bug has been solved in the CVS. Unless you've patched your GD
with
> gif write support you have nothing to gain from not using the bundled
> library, which offers more functionality and is more stable. The problem
with
> free/gd_free is likely due to you having 2 sets of the GD library on your
> computer. This confuses the check, because the headers do not correspond
with
> the library itself.
>
> Ilia
>
> On December 12, 2002 04:37 pm, electroteque wrote:
> > i'm sorry this is not fixed , i have RC03
> >
> > In file included from /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:89:
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c: In function
> > `_php_image_output_ctx':
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c:73: structure has no
> > member named `free'
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c:105: structure has no
> > member named `free'
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function
> > `_php_image_type':
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1156: structure has no
member
> > named `free'
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1163: structure has no
member
> > named `free'
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function
> > `_php_image_create_from':
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1345: structure has no
member
> > named `free'
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1363: warning: assignment
> > makes pointer from integer without a cast
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function
> > `zif_imagecreatefromxpm':
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433:
`gdImageCreateFromXpm'
> > undeclared (first use in this function)
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: (Each undeclared
> > identifier is reported only once
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: for each function it
> > appears in.)
> >
> >
> >
> > i can honestly say checking for a particular version will not help
instead
> > check for versions less than the version that requires gd_free which is
> > gd-2.0.8
> >
> > #if HAVE_LIBGD204
> >
> > io_ctx->gd_free(io_ctx);
> >
> > #else
> >
> > io_ctx->free(io_ctx);
> >
> > #endif
> >
> > i cant see where this define is coming from HAVE_LIBGD204 ??
> >
> >
> >
> > <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> >
> > > ID:   20972
> > >  Updated by:   [EMAIL PROTECTED]
> > >  Reported By:  [EMAIL PROTECTED]
> > > -Status:   Open
> > > +Status:   Closed
> > >  Bug Type: Compile Failure
> > >  Operating System: Linux - 2.4.18 - SuSE 7.2
> > >  PHP Version:  4.3.0RC3
> > >  New Comment:
> > >
> > > This bug has been fixed in CVS.
> > >
> > > In case this was a PHP problem, snapshots of the sources are packaged
> > > every three hours; this change will be in the next snapshot. You can
> > > grab the snapshot at http://snaps.php.net/.
> > >
> > > In case this was a documentation problem, the fix will show up soon at
> > > http://www.php.net/manual/.
> > >
> > > In case this was a PHP.net website problem, the change will show
> > > up on the PHP.net site and on the mirror sites in short time.
> > >
> > > Thank you for the report, and for helping us make PHP better.
> > >
> > >
> > >
> > >
> > > Previous Comments:
> >
> 
> > >
> > > [2002-12-12 13:46:02] [EMAIL PROTECTED]
> > >
> > > /bin/sh libtool --silent --mode=compile gcc -I/usr/local/src/gd-1.8.4/
> > > -Iext/gd/ -I/usr/local/src/apache2/php-4.3.0RC3/ext/gd/ -DPHP_ATOM_INC
> > > -I/usr/local/src/apache2/php-4.3.0RC3/include
> > > -I/usr/local/src/apache2/php-4.3.0RC3/main
> > > -I/us

Re: [PHP-DEV] Re: #20972 [Opn->Csd]: make fails during gd.c

[electroteque]

sure i do but i have prefixed where gd is so it shouldnt be confused, its
obviously not checking for 2.0.8 ? i have made my patches to gd

s/php/php-4.3.0RC3/TSRM  -g -O2  -prefer-pic -c
/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c -o ext/gd/gd.lo
/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function
`_php_image_create_from':
/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1363: warning: assignment
makes pointer from integer without a cast
/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function
`zif_imagecreatefromxpm':
/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: `gdImageCreateFromXpm'
undeclared (first use in this function)
/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: (Each undeclared
identifier is reported only once
/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: for each function it
appears in.)

hmm RC2 never gave me this after i renamed the functions so its something
else, i'm going to try --with-gd without a prefix and see what happens, are
you talking the latest snapshot when u say cvs, saying cvs is too vague , as
0RC3 is the latest stable i have also tried the snapshots, but still showing
errors

"Ilia A." <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> This is a different bug (xpm) caused by a bug in the external GD library,
this
> particular bug has been solved in the CVS. Unless you've patched your GD
with
> gif write support you have nothing to gain from not using the bundled
> library, which offers more functionality and is more stable. The problem
with
> free/gd_free is likely due to you having 2 sets of the GD library on your
> computer. This confuses the check, because the headers do not correspond
with
> the library itself.
>
> Ilia
>
> On December 12, 2002 04:37 pm, electroteque wrote:
> > i'm sorry this is not fixed , i have RC03
> >
> > In file included from /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:89:
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c: In function
> > `_php_image_output_ctx':
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c:73: structure has no
> > member named `free'
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c:105: structure has no
> > member named `free'
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function
> > `_php_image_type':
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1156: structure has no
member
> > named `free'
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1163: structure has no
member
> > named `free'
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function
> > `_php_image_create_from':
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1345: structure has no
member
> > named `free'
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1363: warning: assignment
> > makes pointer from integer without a cast
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function
> > `zif_imagecreatefromxpm':
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433:
`gdImageCreateFromXpm'
> > undeclared (first use in this function)
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: (Each undeclared
> > identifier is reported only once
> >
> > /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: for each function it
> > appears in.)
> >
> >
> >
> > i can honestly say checking for a particular version will not help
instead
> > check for versions less than the version that requires gd_free which is
> > gd-2.0.8
> >
> > #if HAVE_LIBGD204
> >
> > io_ctx->gd_free(io_ctx);
> >
> > #else
> >
> > io_ctx->free(io_ctx);
> >
> > #endif
> >
> > i cant see where this define is coming from HAVE_LIBGD204 ??
> >
> >
> >
> > <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> >
> > > ID:   20972
> > >  Updated by:   [EMAIL PROTECTED]
> > >  Reported By:  [EMAIL PROTECTED]
> > > -Status:   Open
> > > +Status:   Closed
> > >  Bug Type: Compile Failure
> > >  Operating System: Linux - 2.4.18 - SuSE 7.2
> > >  PHP Version:  4.3.0RC3
> > >  New Comment:
> > >
> > > This bug has been fixed in CVS.
> > >
> > > In case this was a PHP problem, snapshots of the sources are packaged
> > > every three hours; this change will be in the next snapshot. You can
> > > grab the snapshot at http://snaps.php.net/.
> > >
> > > In case this was a documentation problem, the fix will show up soon at
> > > http://www.php.net/manual/.
> > >
> > > In case this was a PHP.net website problem, the change will show
> > > up on the PHP.net site and on the mirror sites in short time.
> > >
> > > Thank you for the report, and for helping us make PHP better.
> > >
> > >
> > >
> > >
> > > Previous Comments:
> >
> 
> > >
> > > [2002-12-12 13:46:02] [EMAIL PROTECTED]
> > >
> > > /bin/sh libtool --silent --mode=compile gcc -I/usr/local/src/gd-1.8.4/
> > > -Iext/gd/ -I/usr/local/src/apache2/php-4.3.0RC3/ext/gd/ -DPHP_ATOM_INC
> > > -I/usr/

Re: [PHP-DEV] Re: #20972 [Opn->Csd]: make fails during gd.c

[Ilia A.]

This is a different bug (xpm) caused by a bug in the external GD library, this 
particular bug has been solved in the CVS. Unless you've patched your GD with 
gif write support you have nothing to gain from not using the bundled 
library, which offers more functionality and is more stable. The problem with 
free/gd_free is likely due to you having 2 sets of the GD library on your 
computer. This confuses the check, because the headers do not correspond with 
the library itself.

Ilia

On December 12, 2002 04:37 pm, electroteque wrote:
> i'm sorry this is not fixed , i have RC03
>
> In file included from /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:89:
>
> /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c: In function
> `_php_image_output_ctx':
>
> /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c:73: structure has no
> member named `free'
>
> /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c:105: structure has no
> member named `free'
>
> /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function
> `_php_image_type':
>
> /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1156: structure has no member
> named `free'
>
> /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1163: structure has no member
> named `free'
>
> /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function
> `_php_image_create_from':
>
> /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1345: structure has no member
> named `free'
>
> /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1363: warning: assignment
> makes pointer from integer without a cast
>
> /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function
> `zif_imagecreatefromxpm':
>
> /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: `gdImageCreateFromXpm'
> undeclared (first use in this function)
>
> /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: (Each undeclared
> identifier is reported only once
>
> /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: for each function it
> appears in.)
>
>
>
> i can honestly say checking for a particular version will not help instead
> check for versions less than the version that requires gd_free which is
> gd-2.0.8
>
> #if HAVE_LIBGD204
>
> io_ctx->gd_free(io_ctx);
>
> #else
>
> io_ctx->free(io_ctx);
>
> #endif
>
> i cant see where this define is coming from HAVE_LIBGD204 ??
>
>
>
> <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>
> > ID:   20972
> >  Updated by:   [EMAIL PROTECTED]
> >  Reported By:  [EMAIL PROTECTED]
> > -Status:   Open
> > +Status:   Closed
> >  Bug Type: Compile Failure
> >  Operating System: Linux - 2.4.18 - SuSE 7.2
> >  PHP Version:  4.3.0RC3
> >  New Comment:
> >
> > This bug has been fixed in CVS.
> >
> > In case this was a PHP problem, snapshots of the sources are packaged
> > every three hours; this change will be in the next snapshot. You can
> > grab the snapshot at http://snaps.php.net/.
> >
> > In case this was a documentation problem, the fix will show up soon at
> > http://www.php.net/manual/.
> >
> > In case this was a PHP.net website problem, the change will show
> > up on the PHP.net site and on the mirror sites in short time.
> >
> > Thank you for the report, and for helping us make PHP better.
> >
> >
> >
> >
> > Previous Comments:
> > 
> >
> > [2002-12-12 13:46:02] [EMAIL PROTECTED]
> >
> > /bin/sh libtool --silent --mode=compile gcc -I/usr/local/src/gd-1.8.4/
> > -Iext/gd/ -I/usr/local/src/apache2/php-4.3.0RC3/ext/gd/ -DPHP_ATOM_INC
> > -I/usr/local/src/apache2/php-4.3.0RC3/include
> > -I/usr/local/src/apache2/php-4.3.0RC3/main
> > -I/usr/local/src/apache2/php-4.3.0RC3 -I/usr/local/apache2/include
> > -I/usr/local/src/apache2/php-4.3.0RC3/Zend -I/usr/local/ssl/include
> > -I/usr/local/include -I/usr/local/src/gd-1.8.4/ -I/usr/include/mysql
> > -I/usr/local/verisign/payflowpro/linux/lib
> > -I/usr/local/src/apache2/php-4.3.0RC3/ext/xml/expat
> > -I/usr/local/src/apache2/php-4.3.0RC3/TSRM  -g -O2  -prefer-pic -c
> > /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c -o ext/gd/gd.lo
> > /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c: In function
> > `_php_image_create_from':
> > /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c:1363: warning:
> > assignment makes pointer from integer without a cast
> > /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c: In function
> > `zif_imagecreatefromxpm':
> > /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c:1433:
> > `gdImageCreateFromXpm' undeclared (first use in this function)
> > /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c:1433: (Each undeclared
> > identifier is reported only once
> > /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c:1433: for each function
> > it appears in.)
> > make: *** [ext/gd/gd.lo] Error 1
> >
> > 
> >
> >
> > --
> > Edit this bug report at http://bugs.php.net/?id=20972&edit=1


-- 
PHP Development Mailing List 
To unsubscr

[PHP-DEV] Re: #20972 [Opn->Csd]: make fails during gd.c

[electroteque]

i'm sorry this is not fixed , i have RC03

In file included from /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:89:

/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c: In function
`_php_image_output_ctx':

/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c:73: structure has no
member named `free'

/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c:105: structure has no
member named `free'

/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function
`_php_image_type':

/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1156: structure has no member
named `free'

/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1163: structure has no member
named `free'

/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function
`_php_image_create_from':

/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1345: structure has no member
named `free'

/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1363: warning: assignment
makes pointer from integer without a cast

/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function
`zif_imagecreatefromxpm':

/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: `gdImageCreateFromXpm'
undeclared (first use in this function)

/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: (Each undeclared
identifier is reported only once

/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: for each function it
appears in.)



i can honestly say checking for a particular version will not help instead
check for versions less than the version that requires gd_free which is
gd-2.0.8

#if HAVE_LIBGD204

io_ctx->gd_free(io_ctx);

#else

io_ctx->free(io_ctx);

#endif

i cant see where this define is coming from HAVE_LIBGD204 ??



<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> ID:   20972
>  Updated by:   [EMAIL PROTECTED]
>  Reported By:  [EMAIL PROTECTED]
> -Status:   Open
> +Status:   Closed
>  Bug Type: Compile Failure
>  Operating System: Linux - 2.4.18 - SuSE 7.2
>  PHP Version:  4.3.0RC3
>  New Comment:
>
> This bug has been fixed in CVS.
>
> In case this was a PHP problem, snapshots of the sources are packaged
> every three hours; this change will be in the next snapshot. You can
> grab the snapshot at http://snaps.php.net/.
>
> In case this was a documentation problem, the fix will show up soon at
> http://www.php.net/manual/.
>
> In case this was a PHP.net website problem, the change will show
> up on the PHP.net site and on the mirror sites in short time.
>
> Thank you for the report, and for helping us make PHP better.
>
>
>
>
> Previous Comments:
> 
>
> [2002-12-12 13:46:02] [EMAIL PROTECTED]
>
> /bin/sh libtool --silent --mode=compile gcc -I/usr/local/src/gd-1.8.4/
> -Iext/gd/ -I/usr/local/src/apache2/php-4.3.0RC3/ext/gd/ -DPHP_ATOM_INC
> -I/usr/local/src/apache2/php-4.3.0RC3/include
> -I/usr/local/src/apache2/php-4.3.0RC3/main
> -I/usr/local/src/apache2/php-4.3.0RC3 -I/usr/local/apache2/include
> -I/usr/local/src/apache2/php-4.3.0RC3/Zend -I/usr/local/ssl/include
> -I/usr/local/include -I/usr/local/src/gd-1.8.4/ -I/usr/include/mysql
> -I/usr/local/verisign/payflowpro/linux/lib
> -I/usr/local/src/apache2/php-4.3.0RC3/ext/xml/expat
> -I/usr/local/src/apache2/php-4.3.0RC3/TSRM  -g -O2  -prefer-pic -c
> /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c -o ext/gd/gd.lo
> /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c: In function
> `_php_image_create_from':
> /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c:1363: warning:
> assignment makes pointer from integer without a cast
> /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c: In function
> `zif_imagecreatefromxpm':
> /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c:1433:
> `gdImageCreateFromXpm' undeclared (first use in this function)
> /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c:1433: (Each undeclared
> identifier is reported only once
> /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c:1433: for each function
> it appears in.)
> make: *** [ext/gd/gd.lo] Error 1
>
> 
>
>
> --
> Edit this bug report at http://bugs.php.net/?id=20972&edit=1
>



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

Re: [PHP-DEV] Bug #20887 (Two separate issues)

[Moriyoshi Koizumi]

Note that the patche is still incomplete because it dismisses many *nix OS 
out there other than SunOS, Linux, FreeBSD, OpenBSD and NetBSD.

Moriyoshi

"Sara Golemon" <[EMAIL PROTECTED]> wrote:

> > ??? The original report goes:
> >
> >   If /php.ini exists, that one is used no matter what PHPRC env is set
> > or compiled in when starting up apache from a SysV script. Is it a bug
> > in php, or could it be the Mandrake Linux 9.0 system?
> >
> My bad, the fact does remain however, that there is a command line issue.
> 
> >> the system checks the PATH variable to find an executable and run PHP.
> >> When php_ini.c runs, it finds a 'binary_location' of "php"
> >> (inaccurate! Our CWD is ~ and ~/php does not exist)  Neither my patch
> >> nor Moriyoshi's fixes this.
> >
> > My patch would give the accurate location of the binary being executed
> > since it doesn't rely on argv[0].
> >
> Once again, my bad... When I tested your patch on my system I forgot about
> the fact that the php found in the path would be my copy of 4.2.3 and
> would therefore not have your patch! Whoops... :)
> 
> I retested with sapi/cli/php put into the path and lo-and-behold:
> open("/usr/local/bin//php-cli.ini", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> open("/usr/local/lib/php-cli.ini", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> open("/usr/local/bin//php.ini", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> open("/usr/local/lib/php.ini", O_RDONLY) = 3
> 
> Exactly the right behavior!
> 
> +1 your patch.
> 
> 


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

Re: [PHP-DEV] Bug #20887 (Two separate issues)

[Sara Golemon]

> ??? The original report goes:
>
>   If /php.ini exists, that one is used no matter what PHPRC env is set
> or compiled in when starting up apache from a SysV script. Is it a bug
> in php, or could it be the Mandrake Linux 9.0 system?
>
My bad, the fact does remain however, that there is a command line issue.

>> the system checks the PATH variable to find an executable and run PHP.
>> When php_ini.c runs, it finds a 'binary_location' of "php"
>> (inaccurate! Our CWD is ~ and ~/php does not exist)  Neither my patch
>> nor Moriyoshi's fixes this.
>
> My patch would give the accurate location of the binary being executed
> since it doesn't rely on argv[0].
>
Once again, my bad... When I tested your patch on my system I forgot about
the fact that the php found in the path would be my copy of 4.2.3 and
would therefore not have your patch! Whoops... :)

I retested with sapi/cli/php put into the path and lo-and-behold:
open("/usr/local/bin//php-cli.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/local/lib/php-cli.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/local/bin//php.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/local/lib/php.ini", O_RDONLY) = 3

Exactly the right behavior!

+1 your patch.



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

Re: [PHP-DEV] Bug #20887 (Two separate issues)

[Moriyoshi Koizumi]

Hi,

> The original complaint in bug 20887 was that the CLI version was picking
> up ini files in the wrong places.  The patch I suggested last night does
> address that problem (albiet not correctly, see below).

??? The original report goes:

  If /php.ini exists, that one is used no matter what PHPRC env is set
  or compiled in when starting up apache from a SysV script. Is it
  a bug in php, or could it be the Mandrake Linux 9.0 system?

> the system checks the PATH variable to find an executable and run PHP.
> When php_ini.c runs, it finds a 'binary_location' of "php" (inaccurate!
> Our CWD is ~ and ~/php does not exist)  Neither my patch nor Moriyoshi's
> fixes this.

My patch would give the accurate location of the binary being executed 
since it doesn't rely on argv[0].

Moriyoshi


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

Re: [PHP-DEV] php-cgi vs php-cli naming issue

[Derick Rethans]

On Thu, 12 Dec 2002, Sterling Hughes wrote:

> > How about we simply add a configure option to control this?
> > 
> > --enable-simple-cli-name would build CGI as php-cgi and CLI as php
> > 
> > That way we preserve BC and let those who like CLI named 'php' have that
> > too.

This will break the idea of having 'php' (the CLI) on as much systems as 
possible (for PEAR). It seems that integrating the two (CGI and CLI) 
_seems_ like the best solution, although I do not favor this due to 
technical reasons.

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


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

[PHP-DEV] Bug #20887 (Two separate issues)

[Sara Golemon]

The original complaint in bug 20887 was that the CLI version was picking
up ini files in the wrong places.  The patch I suggested last night does
address that problem (albiet not correctly, see below).

The secondary "bug" which isn't really a bug is the complaint that CWD is
included in the ini search path.  While that *should* be suspended as the
arguments for keeping "." in the search path for non-CLI sapis is valid.
It really has nothing to do with the issues in bug 20887.

The problem with the double forward slash is trivial and doesn't cause a
real issue, the problem I mentioned above is with php being launched
without a path (without even ./)

If PHP is launched directly from the command line a la:
mybox:~$ php -f myscript.php

the system checks the PATH variable to find an executable and run PHP.
When php_ini.c runs, it finds a 'binary_location' of "php" (inaccurate!
Our CWD is ~ and ~/php does not exist)  Neither my patch nor Moriyoshi's
fixes this.


If PHP is launched via a script's pound-bang declaration a la:
mybox:/usr/local/bin$ ./myscript.php

--- /usr/local/bin/myscript.php (filemode 755)
#!php


The shell (bash in the case of my tests) only looks for php in the CWD, If
it finds one then it'll run and php_ini.c will show a binary_location of
'php' (correct in this instance, since /usr/local/bin/php does exist and
is our executable).  The current code in php_ini.c however, will try to
look for the php.ini in 'php/php.ini' Ooops! (Both my patch and
Moriyoshi's approach solves this one)

In the former instance, ./php.ini shold not be scanned for CLI sapi,
/usr/local/bin/php should be scanned instead except that we can't find it.
(that's the whole discussion about not icluding '.' in the search path for
CLI)

In the latter instance, ./php.ini SHOULD be scanned for the CLI sapi as
that is indeed where the binary is located.

-Pollita






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

Re: [PHP-DEV] php-cgi vs php-cli naming issue

[Sterling Hughes]

> How about we simply add a configure option to control this?
> 
> --enable-simple-cli-name would build CGI as php-cgi and CLI as php
> 
> That way we preserve BC and let those who like CLI named 'php' have that
> too.
>

you mean instead of ::

# mv php-cli php

?

-Sterling

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

[PHP-DEV] php-cgi vs php-cli naming issue

[Andrei Zmievski]

How about we simply add a configure option to control this?

--enable-simple-cli-name would build CGI as php-cgi and CLI as php

That way we preserve BC and let those who like CLI named 'php' have that
too.

-Andrei


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

Re: [PHP-DEV] Re: cleaning/building just one extension

[Sascha Schumann]

On Thu, 12 Dec 2002, Andrei Zmievski wrote:

> On Thu, 12 Dec 2002, Sascha Schumann wrote:
> > We could add a target clean-ext-EXTNAME..
> >
> > - Sascha
>
> What about build-ext-EXTNAME? I ran into this yesterday when I checked
> out a fresh copy of the tree and wanted to build only wddx module as a
> shared library.

If you want to build a stand-alone extension, I suggest you
use phpize.

- Sascha


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

[PHP-DEV] Re: cleaning/building just one extension

[Andrei Zmievski]

On Thu, 12 Dec 2002, Sascha Schumann wrote:
> We could add a target clean-ext-EXTNAME..
> 
> - Sascha

What about build-ext-EXTNAME? I ran into this yesterday when I checked
out a fresh copy of the tree and wanted to build only wddx module as a
shared library.

-Andrei   http://www.gravitonic.com/

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

Re: [PHP-DEV] cleaning/building just one extension

[Derick Rethans]

On Thu, 12 Dec 2002, Andrei Zmievski wrote:

> With the new build system, is there a way to clean/build just one
> extension, as opposed to having to do it to the whole tree? Something
> like "make clean ext=wddx", perhaps?

Install ccache? You'd still do a make clean for everything, but it 
speeds up compiling about as much...

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


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

Re: [PHP-DEV] Re: cleaning/building just one extension

[Hans Zaunere]

--- Sascha Schumann <[EMAIL PROTECTED]> wrote:
> On Thu, 12 Dec 2002, Andrei Zmievski wrote:
> 
> > With the new build system, is there a way to clean/build just one
> > extension, as opposed to having to do it to the whole tree? Something
> > like "make clean ext=wddx", perhaps?
> 
> We could add a target clean-ext-EXTNAME..

This is akin to my questions yesterday, as obfuscated as they may have been. 
To my understanding, this is what phpize is for? ie, given a PHP source tree,
you can build the framework in any directory for a personal extension.

But in general, what's the excepted way to distribute compiled extensions,
if, for example, I wanted to release a .so that would work with 4.2.x and
newer (and assuming only Apache at this point)?  Would I need to release
specific versions; if so, how many permutations would I need to consider, and
what variables would I need to accomodate?  Initially, I see that
Apache/Apache2->MPM is a big one.



=
Hans Zaunere
New York PHP
http://nyphp.org
[EMAIL PROTECTED]

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

[PHP-DEV] Re: cleaning/building just one extension

[Sascha Schumann]

On Thu, 12 Dec 2002, Andrei Zmievski wrote:

> With the new build system, is there a way to clean/build just one
> extension, as opposed to having to do it to the whole tree? Something
> like "make clean ext=wddx", perhaps?

We could add a target clean-ext-EXTNAME..

- Sascha


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

[PHP-DEV] ZendEngine2 / zend_object_handlers.c __get __set __call

[Laurent Bedubourg]

Well may be i'm the only one (hard to say as nobody talk about this) but 
i don't agree with accessors design, i allready posted a mail to Andrei 
a month ago (may be lost, may be the wrong person) and i try here as 
i'm sure someone will explain me 'why this design'.

Comment found in zend_object_handlers.c :

/*
  __X accessors explanation:

if we have __get and property that is not part of the properties array 
is requested, we call __get handler. If it fails, we return 
uninitialized.

if we have __set and property that is not part of the properties array 
is set, we call __set handler. If it fails, we do not change the array.

for both handlers above, when we are inside __get/__set, no further 
calls for __get/__set for these objects will be made, to prevent 
endless recursion and enable accessors to change properties array.

if we have __call and method which is not part of the class function 
table is called, we cal __call handler.
*/


--- here we go -

The way python handle this is just fine and allow much more code magic 
in classes.


The python rule : if we have a __get, __set, __call, we use it. no more 
no less.



What i expect from my __set by example :

/**
 * My magic class Foo 
 */
class Foo {

/** 
 * bar is visible in the interface, 
 * declared public, 
 * no documentation problem 
 * the user know that he can use it safely
 */
var $bar;

/**
 * Hidden from user, he don't have to worry about what's behind
 * the scene.
 */
function __set($var, $value)
{
if ($var == 'bar') {
// ... 
// if $value is an id, we use it to load bar
// object from database and do complex stuff

// ...
// else if $value is an object conform
// to what 'bar' variable waits for we save 
// it to database, mail to the president, send
// a teddy bear to mars.

// now $value was modified to fit $this->bar 
// requirements the last line of this function will 
// set it 
}

// here i don't use $this->$var = $value because i'm a 
// carefull coder who know what he does and who know 
// what he doesn't want (no infinite call to __set)
// but if for some advanced magic i'd like to do it
// i could and it's cool.
object_set_var($this, $var, $value);
}
};

and to be sure this design will be usuable, php would produce 3 
functions with references everywhere:
 
  object_set($object, $varName, $value)
  object_get($object, $varName)
  object_call($object, $method, $arguments[])

tada ! python way of coding : clean, simple, powerfull within your 
favorite web scripting language.



Of course this thing is possible with the current system but it requires 
the following :

1 - do not declare 'var $bar' or declare it private (need some more test 
for private but not the right solution as the magic requires public 
access). 

2 - create a private hashtable which will handle undeclared variables 
(because once a variable is set in the object's properties array, __get 
and __set won't work anymore with it)

3 - create the __get() method so we can retrieve the variable from the 
private hashtable.

4 - disable error_reporting(E_ALL) because $object->myvar is not 
declared and you can't ask it in your code.


Well, all this will make the code uggly, unclear to document, hard to 
maintain, and will take anybody about 3 times the same to develop the 
above example... And of course you're limited as you can't call other 
variables setters while in __set (same for __get and __call)!


To finish with, i hope you'll teach me advantages of the current design 
because i took a look at the zend_object_handlers.c and ... well ... i 
really think there's a 5:00 am conception mistake behind the scene :)



also on this mailing list if you want more bugs report and features 
request :

- where are my modules ? (something like python or perl module 
import/use is just great) 

- when will "use()" be implemented (a package attempt i bet) ?

- why should 'import' complain if i try to import a class already 
imported in the current namespace ? The problem will occurs quite often 
with library inclusion and cross references.

- get_class_methods() do not return methods array when used on a 
namespaced class 

- do you plain to allow : "import class $className from $nameSpaceName;" 
? i do this kind of things often don't ask me why, i just like plugin 
way of life.

- will import include my php files if they are well named (module 
convention) ? ( i mean in final version of Zend

Re: [PHP-DEV] cleaning/building just one extension

[Andrey Hristov]

> isn't it possible to cd to ext/wddx and make clean there?
> Not sure but I think it's possible.

Nope, it is not :(

> Andrey

Andrey


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

Re: [PHP-DEV] cleaning/building just one extension

[Andrey Hristov]

isn't it possible to cd to ext/wddx and make clean there?
Not sure but I think it's possible.

Andrey

- Original Message - 
From: "Andrei Zmievski" <[EMAIL PROTECTED]>
To: "PHP Developers" <[EMAIL PROTECTED]>
Cc: "Sascha Schumann" <[EMAIL PROTECTED]>
Sent: Thursday, December 12, 2002 7:33 PM
Subject: [PHP-DEV] cleaning/building just one extension


> With the new build system, is there a way to clean/build just one
> extension, as opposed to having to do it to the whole tree? Something
> like "make clean ext=wddx", perhaps?
> 
> -Andrei   http://www.gravitonic.com/
> 
> I must say I find television very educational. The minute
> somebody turns it on, I go to the library and read a good book.
>- Groucho Marx
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

[PHP-DEV] cleaning/building just one extension

[Andrei Zmievski]

With the new build system, is there a way to clean/build just one
extension, as opposed to having to do it to the whole tree? Something
like "make clean ext=wddx", perhaps?

-Andrei   http://www.gravitonic.com/

I must say I find television very educational. The minute
somebody turns it on, I go to the library and read a good book.
   - Groucho Marx

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

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

[Stanislav Malyshev]

MB>> 1) Visibility is about information hiding not showing.

Visibility is both hiding and showing. Visibility is defining what is 
shown and what is hidden. 

MB>> 2) You are wrong about 'is-a' in general. Our main problem here is that we
MB>>  do not have a typecast operator.

I do not see why typecast operator is needed here. 

MB>> 1) Visibility modifiers are for information hiding. That is you can hide 
MB>> certain
MB>> implementation details. Each class has three interfaces: i) the interface
MB>> accessible from any other scope. ii) the interface accessible from any
MB>> derived class

OK.

MB>> Suppose you are going to design an encryption framework. Then you
MB>> surely will first design an interface. In php you will create an
MB>> abstract class to accomplish this. Then you will implement general
MB>> features which will handle unencrypted content and such. Also you may
MB>> implement general key handling. In the class hierarchy you will make
MB>> all acess to uncencrypted content protected or even private starting
MB>> from here. Doing this you ensure that no user and in case of private

That means here you have a design flaw. If you have class EncryptionBase 
with *public* method foo(), and you do not want users of class 
EncryptionExtended to access foo(), you *should not* derive 
EncryptionExtended from EncryptionBase. You should use aggregation, 
delegation and all that stuff. Inheritance means declaring that derived 
class is built along all the protocols defined for base class. If you use 
for inheritance just as a tool to avoid copy-paste - this is wrong. I.e., 
it may work in the short run, but that's not intent of the OO as I see it. 

MB>> Or suppose you have a class for content handling and you will base
MB>> encryption on top of this. Then you will derive the encryption
MB>> handling from content handling and mark unencrypted acess
MB>> methods/properties as private.

Then, again, you should not derive encrypted content handling from 
unencrypted, _unless_ you are going to give access to the same methods. 
Generally what people do is to use same protocols (i.e, same methods), but 
these methods would give different result - so, BaseStream::output would 
output unencrypted content while EncryptedStream::output will output 
encrypted content, but this code:

function printNumber($stream, $number) {
$stream->output("This is number: $number");
}

would work in any case, as long as stream is inherited from BaseStream. If 
you make output method hidden in derived class, you will have or to check 
before each call to printNumber, what stream do you have now, or get very 
hard-to-find errors in runtime.

MB>> More examples could be made but that's not the point here. The point
MB>> is that there is a need for decreasing visibility. And personally i
MB>> do not see any need for increasing visibility besides the 'is_a'
MB>> comment.

I don't know about _increasing_ visibility, but I'm firm in opinion that 
_decreasing_ visibility in inheritance violates inheritance protocol and 
prevents people from writing OO-style code. As for increasing, I 
personally don't need it - you can proxy needed methods anyway - but it at 
least doesn't violate inheritance principles. 

MB>> class A {
MB>>  function println($msg) {
MB>>  echo "$msg\n";
MB>>  }
MB>> }
MB>> class B {
MB>>  function println() {
MB>>  // whatever...
MB>>  }
MB>> }
MB>> 
MB>> when in this example you work on B instances with A's protocol you
MB>> will see that B's println does not recognize $msg. => When deriving

/* I base here on assumption that you meant B being inherited from A, 
otherwise there's nothing to discuss, so see all the following in this 
light */
The first question to ask is: why did you call the second function 
println? Answering this may alone bring some satori, but in case it does 
not, I will continue. 
This example is bad too, and actually if I could I would disallow this 
too. AFAIK, C++, which has means to do this, takes care for this by making 
parameters part of the function signature, so you can not do such things. 
I do not know if it is possible to fix this in PHP, but I clearly regard 
this as inheritance abuse. However, this is less important, since if you 
write it right - i.e., keep the protocol of println($msg) but ignore $msg 
- it is perfectly legitimate use of inheritance. 
So, I repeat, if it would be easy to prohibit such things, I would propose 
to do this too, but this is somewhat less important since you can live 
with it if it is not abused 'too much'. 
And yes, you can not prevent all cases of inheritance abuse, however hard
you try - for example, if you write extension to class List, which
overrides method getElement() to clean the list, and try to use this
extension with function SortList that uses getElement(), you will discover
that you are in a big trouble. To prevent people from shooting in their
feet 100% is an

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

[Sebastian Nohn]

Jan Schneider schrieb:
> I know this thread is ridden to death but I want to add
> one argument for
> completeness: If the cgi's name will be changed,
> thousands of administrators
> need to fix their servers. But if the cli's name will be
> changed thousands
> of "end users" of php cli scripts will have to change the
> scripts' shebang line.
> 
> I have no idea if there are more administrators who have
> to care about php
> cgi or users who use php cli. But at least the first
> group will have less
> problems fixing the name change than the latter.
> 

PHP-CLI was experimental so far, so anyone who uses it has to be aware
of any changes that can happen. PHP-CGI is very far from being
experimental. I have no problem with all that renaming thing, but if we
rename the CGI-PHP to php-cgi we should do it with php5, because more
people will realize that a lot of things change between 4.x and 5.x.
For psychological numbering-reasons people don't see any change between
4.2 and 4.3.

Regards, Sebastian Nohn
-- 
[EMAIL PROTECTED] - http://nohn.net/

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

[PHP-DEV] BC issues in cgi

[Edin Kadribasic]

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

Edin


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

[PHP-DEV] php 4.3.0RC3/tru64 test report

[Sebastian Nohn]

=
FAILED TEST SUMMARY
-
OpenSSL private key functions [ext/openssl/tests/001.phpt]
getopt [ext/standard/tests/general_functions/getopt.phpt]
Simple math tests [ext/standard/tests/math/abs.phpt]
log() tests [ext/standard/tests/math/log.phpt]
Various pow() tests [ext/standard/tests/math/pow.phpt]
Simple math tests [ext/standard/tests/math/round.phpt]
microtime() function [ext/standard/tests/time/001.phpt]
strtotime() function [ext/standard/tests/time/002.phpt]
=



/usr/users/nohn/php-4.3.0RC3/ext/openssl/tests/001.phpt


 EXPECTED OUTPUT
Creating private key
Export key to file
Load key from file - array syntax
Load key using direct syntax
Load key manually and use string syntax
OK!
 ACTUAL OUTPUT
Creating private key

Warning: unable to load random state; not enough random data! in 
/usr/users/nohn/php-4.3.0RC3/ext/openssl/tests/001.php on line 4
failed to create private key
 FAILED


002- Export key to file
002+ 
003- Load key from file - array syntax
003+ Warning: unable to load random state; not enough random data! in 
/usr/users/nohn/php-4.3.0RC3/ext/openssl/tests/001.php on line 4
004- Load key using direct syntax
004+ failed to create private key
005- Load key manually and use string syntax
006- OK!





/usr/users/nohn/php-4.3.0RC3/ext/standard/tests/general_functions/getopt.phpt


 EXPECTED OUTPUT
array(5) {
  ["v"]=>
  bool(false)
  ["h"]=>
  bool(false)
  ["d"]=>
  string(4) "test"
  ["m"]=>
  string(4) "1234"
  ["t"]=>
  bool(false)
}
 ACTUAL OUTPUT
array(0) {
}
 FAILED


001- array(5) {
001+ array(0) {
002-   ["v"]=>
002+ }
003-   bool(false)
004-   ["h"]=>
005-   bool(false)
006-   ["d"]=>
007-   string(4) "test"
008-   ["m"]=>
009-   string(4) "1234"
010-   ["t"]=>
011-   bool(false)
012- }





/usr/users/nohn/php-4.3.0RC3/ext/standard/tests/math/abs.phpt


 EXPECTED OUTPUT
1,1,0,0
OK
 ACTUAL OUTPUT
1,1,1,1

Assert failed:
-LONG_MIN+1 === abs(LONG_MIN-1)
Left:  int(-9223372036854775807)
Right: int(9223372036854775807)

Assert failed:
-LONG_MIN   === abs(LONG_MIN)
Left:  int(-9223372036854775808)
Right: float(9.22337203685E+18)
 FAILED


001- 1,1,0,0
001+ 1,1,1,1
002- OK
002+ 
003+ Assert failed:
004+ -LONG_MIN+1 === abs(LONG_MIN-1)
005+ Left:  int(-9223372036854775807)
006+ Right: int(9223372036854775807)
007+ 
008+ Assert failed:
009+ -LONG_MIN   === abs(LONG_MIN)
010+ Left:  int(-9223372036854775808)
011+ Right: float(9.22337203685E+18)





/usr/users/nohn/php-4.3.0RC3/ext/standard/tests/math/log.phpt


 EXPECTED OUTPUT
On failure, please mail result to [EMAIL PROTECTED]
200
50
50
50
50
50
50
50
50
50
 ACTUAL OUTPUT
On failure, please mail result to [EMAIL PROTECTED]
200
 FAILED


003- 50
004- 50
005- 50
006- 50
007- 50
008- 50
009- 50
010- 50
011- 50





/usr/users/nohn/php-4.3.0RC3/ext/standard/tests/math/pow.phpt


 EXPECTED OUTPUT
1,1,0,0
On failure, please mail result to [EMAIL PROTECTED]
OK
 ACTUAL OUTPUT
1,1,1,1
On failure, please mail result to [EMAIL PROTECTED]

Assert failed:
 TRUE === is_infinite(pow(0,-2))
Left:  bool(true)
Right: bool(false)

Assert failed:
 TRUE === is_infinite(pow(0,-1))
Left:  bool(true)
Right: bool(false)

Assert failed:
 TRUE === is_infinite(pow(0,-2.0))
Left:  bool(true)
Right: bool(false)

Assert failed:
 TRUE === is_infinite(pow(0,-1.0))
Left: 

Re: [PHP-DEV] PHP extension initialisation

[Tom Oram]

The best I ever came up with was doing what your saying but instead of using a
file I used an environment variable, it's still a mess but I think its probably
cleaner and safe than using file locking. I would still be interested if you
ever did find a "proper" solution though,

Sorry I can't help you anymore than that, I hope that was of some use to you

Tom

On Thu, 12 Dec 2002, you wrote:
> Hi Tom,
> 
> Did you ever get this problem solved?
> I'm fighting the same issue - and if no better solution present it self,
> I'm going
> to do it by accessing a file of my choise. If the file doesn't exist -
> create it and we
> know we are in the first call. If it does exist - delete it, and we know
> this is the
> second call. This is obviously an ugly hack, so I really hope you've
> come up with
> something cleaner.
> 
> TIA
>   Thomas
> 
> On  Wed, 21 Aug 2002, you wrote:
> >I had already assumed what Pete said was happening was happening, but I
> still
> >don't know how to tell whether I'm in the first one (apache test) or
> the second
> >(real init). Any ideas?
> >Tom
> 
> 
> >On Wed, 21 Aug 2002, you wrote:
> >> Hi,
> >>
> >> I asked about this a few weeks ago with apache on windows.
> >>
> >> The best answer I got was from George Schlossnagle:
> >>
> >> I believe this is because when apache does it's intial
> configtest run
> >> as
> >> part of start (to validate it's config), it has to do a complete
> startup
> >> (otherwise it wouldn't know about conf params used by modules loaded
> as
> >> DSOs.  So you see a startup; shutdown; startup.
> >>
> >> that's exactly what I saw happen so seeing as shutdown occurs as well
> it
> >> wasn't a problem in my case.
> >>
> >>
> >> Pete
> >>
> >> --
> >> "Tom Oram" <[EMAIL PROTECTED]> wrote in message
> >> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> >> On Thu, 15 Aug 2002, you wrote:
> >> > --- Tom Oram <[EMAIL PROTECTED]> wrote:
> >> >> Hi,
> >> >> Can someone please answer my question?
> >> >>
> >> >> When running a PHP extension when PHP is running as an apache
> module on
> >> linux
> >> >> it's module init function (PHP_MINIT_FUNCTION) gets called twice,
> once
> >> before
> >> >> apache forks then once after, is there any way of finding out
> which
> >> >> init you are in. I can't keep a global variable because it get
> losted in
> >> >> between init calls, and environment vars/file locks/shared
> mem/semephores
> >> are
> >> >> not options.
> >> >
> >> > Are you on Windows IIS? I believe someone recently just asked about
> that
> >> same
> >> > thing. There was a valid explination for it.
> >>
> >> No linux, I did say ;), but thanks anyway.
> >> The question still stands open, anyone?
> >>
> >> >> One other quicky, is there a way to find out inside the extension
> if it
> >> is
> >> >> being run from with an apache module or its it a standalone
> executable
> >> (or
> >> >> running under a different webserver as my module can only ever run
> with
> >> >> apache)?
> >> >
> >> > I believe you could
> >> > #include "SAPI.h"
> >> >
> >> > if(!strcmp(sapi_module.name, "cgi") || strcmp(sapi_module.name,
> "cli")) {
> >> >   printf("compiled as a command line executable");
> >> > }
> >>
> >> This is probably what I need thanks
> >>
> >> >>
> >> >> Thanks for your time,
> >> >> Tom
> >> >>
> >> >> --
> >> >>
> >> >> ***
> >> >> Tom Oram
> >> >> SCL Computer Services
> >> >> URL http://www.scl.co.uk/
> >> >> ***
> >> >>
> >> >> --
> >> >> PHP Development Mailing List 
> >> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >> >>
> >> >
> >> >
> >> > __
> >> > Do You Yahoo!?
> >> > HotJobs - Search Thousands of New Jobs
> >> > http://www.hotjobs.com
> >> --
> >>
> >> ***
> >> Tom Oram
> >> SCL Computer Services
> >> URL http://www.scl.co.uk/
> >> ***
> >> --
> >>
> >> ***
> >> Tom Oram
> >> SCL Computer Services
> >> URL http://www.scl.co.uk/
> >> ***
> >--
> 
> >***
> >Tom Oram
> >SCL Computer Services
> >URL http://www.scl.co.uk/
> >***
> 
> >--
> >PHP Development Mailing List 
> >To unsubscribe, visit: http://www.php.net/unsub.php
-- 

***
Tom Oram
SCL Computer Services
URL http://www.scl.co.uk/
***

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

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

[Marcus Börger]

Since more feedback may help here i also send this to php-dev


At 15:47 08.12.2002, Stanislav Malyshev wrote:

MB>> Therefor i would vote for allowing only decreasing the visibility or 
force
MB>> to keep it.

Decreasing visibility contradicts the basic inheritance principle - that
derived class "is-a" base class, i.e., basically, it can be used in any
place the base class is used. If you restrict methods in derived class, it
may lead to a situation where $foo->method() works with base class, but
fails with derived class - which is, as I said, against the inheritance
principle.
As for increasing visibility - I don't see major problem in it. What could
be the problem if derived class is allowed to open protected method to
public? After all, it could proxy it anyways...

Let me say two things first:
1) Visibility is about information hiding not showing.
2) You are wrong about 'is-a' in general. Our main problem here is that we
do not have a typecast operator.

1) Visibility modifiers are for information hiding. That is you can hide 
certain
implementation details. Each class has three interfaces: i) the interface
accessible from any other scope. ii) the interface accessible from any
derived class

Suppose you are going to design an encryption framework. Then you surely will
first design an interface. In php you will create an abstract class to 
accomplish
this. Then you will implement general features which will handle unencrypted
content and such. Also you may implement general key handling. In the class
hierarchy you will make all acess to uncencrypted content protected or even
private starting from here. Doing this you ensure that no user and in case of
private even no derived class can access unencrypted content.
=> Only information hiding = decreasing visibility.

Or suppose you have a class for content handling and you will base 
encryption on
top of this. Then you will derive the encryption handling from content 
handling and
mark unencrypted acess methods/properties as private.
=> Only information hiding = decreasing visibility.

Note the different motivations for deriving classes above.

More examples could be made but that's not the point here. The point is that
there is a need for decreasing visibility. And personally i do not see any 
need
for increasing visibility besides the 'is_a' comment.

When increasing the visibility you show functionality being hidden in a 
base class.
Most often this is done to fix wrong class design or to missuse baseclasses 
in ways
they are not designed for.

2) For our current implementation you are partly right with your comment on
'is_a' because you cannot use a parent interface of a class. But your comment
does not hold since 'is_a' does not work even without visibility in php 
like you want
it.

Example without visibility:

class A {
function println($msg) {
echo "$msg\n";
}
}
class B {
function println() {
// whatever...
}
}

when in this example you work on B instances with A's protocol you will see
that B's println does not recognize $msg. => When deriving classes in a typed
language an overloaded method must accept the same input and must return
the same output.

Maybe we decide that for PHP this is not a problem since we simply ignore
this fact what is possible in a loosely typed language. Otherwise deriving 
checks
would become much more complex since we need to store the input and check
for that, too. At least we must count required, optional and "..." input 
parameters
then.

In the above example I assumed we had inheritance working as in typed OO
languages. I further assumed that when having B as a subclass of A and b
as instance of B, b can be used with protocol A by using a typecast. That is:
is_a(b, A) === true implies that even methods made private in B can be used
with protocol A if they are public there. It does not imply that you can 
use A's
protocol without typecasting b to A. When in this scenario all methods are 
linked
dynamically we have what we want: by calling a method from b typecysted to A
the overwritten method from class B is being invoked.

Immediate conclusion: I tried changing visibility in other languages and 
read again
about it in some books. I came to the conclusion that both increasing and
decreasing works in some languages but only found hints for the need of
information hiding (decreasing visibility).

Example:
#include 

class A {
public:
virtual void pub() { cout << "A::pub" << endl; };

protected:
virtual void pro() { cout << "A::pro" << endl; };
};

class B: public A {
protected:
virtual void pub() { cout << "B::pub" << endl; };   // You can 
also make this private

public:
virtual void pro() { cout << "B::pro" << endl; };

};

int main(int argc, char **argv) {
B *b = new B();
b->pro();
dynamic_cast(b)->pub();
// b->pub(); B::pub is protected
delete b;
}

In this C++ 

Re: [PHP-DEV] PHP extension initialisation

[Thomas Wentzel]

Hi Tom,

Did you ever get this problem solved?
I'm fighting the same issue - and if no better solution present it self,
I'm going
to do it by accessing a file of my choise. If the file doesn't exist -
create it and we
know we are in the first call. If it does exist - delete it, and we know
this is the
second call. This is obviously an ugly hack, so I really hope you've
come up with
something cleaner.

TIA
  Thomas

On  Wed, 21 Aug 2002, you wrote:
>I had already assumed what Pete said was happening was happening, but I
still
>don't know how to tell whether I'm in the first one (apache test) or
the second
>(real init). Any ideas?
>Tom


>On Wed, 21 Aug 2002, you wrote:
>> Hi,
>>
>> I asked about this a few weeks ago with apache on windows.
>>
>> The best answer I got was from George Schlossnagle:
>>
>> I believe this is because when apache does it's intial
configtest run
>> as
>> part of start (to validate it's config), it has to do a complete
startup
>> (otherwise it wouldn't know about conf params used by modules loaded
as
>> DSOs.  So you see a startup; shutdown; startup.
>>
>> that's exactly what I saw happen so seeing as shutdown occurs as well
it
>> wasn't a problem in my case.
>>
>>
>> Pete
>>
>> --
>> "Tom Oram" <[EMAIL PROTECTED]> wrote in message
>> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>> On Thu, 15 Aug 2002, you wrote:
>> > --- Tom Oram <[EMAIL PROTECTED]> wrote:
>> >> Hi,
>> >> Can someone please answer my question?
>> >>
>> >> When running a PHP extension when PHP is running as an apache
module on
>> linux
>> >> it's module init function (PHP_MINIT_FUNCTION) gets called twice,
once
>> before
>> >> apache forks then once after, is there any way of finding out
which
>> >> init you are in. I can't keep a global variable because it get
losted in
>> >> between init calls, and environment vars/file locks/shared
mem/semephores
>> are
>> >> not options.
>> >
>> > Are you on Windows IIS? I believe someone recently just asked about
that
>> same
>> > thing. There was a valid explination for it.
>>
>> No linux, I did say ;), but thanks anyway.
>> The question still stands open, anyone?
>>
>> >> One other quicky, is there a way to find out inside the extension
if it
>> is
>> >> being run from with an apache module or its it a standalone
executable
>> (or
>> >> running under a different webserver as my module can only ever run
with
>> >> apache)?
>> >
>> > I believe you could
>> > #include "SAPI.h"
>> >
>> > if(!strcmp(sapi_module.name, "cgi") || strcmp(sapi_module.name,
"cli")) {
>> >   printf("compiled as a command line executable");
>> > }
>>
>> This is probably what I need thanks
>>
>> >>
>> >> Thanks for your time,
>> >> Tom
>> >>
>> >> --
>> >>
>> >> ***
>> >> Tom Oram
>> >> SCL Computer Services
>> >> URL http://www.scl.co.uk/
>> >> ***
>> >>
>> >> --
>> >> PHP Development Mailing List 
>> >> To unsubscribe, visit: http://www.php.net/unsub.php
>> >>
>> >
>> >
>> > __
>> > Do You Yahoo!?
>> > HotJobs - Search Thousands of New Jobs
>> > http://www.hotjobs.com
>> --
>>
>> ***
>> Tom Oram
>> SCL Computer Services
>> URL http://www.scl.co.uk/
>> ***
>> --
>>
>> ***
>> Tom Oram
>> SCL Computer Services
>> URL http://www.scl.co.uk/
>> ***
>--

>***
>Tom Oram
>SCL Computer Services
>URL http://www.scl.co.uk/
>***

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


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

Re: [PHP-DEV] mail() bug??

[Melvyn Sopacua]

Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this forum is not the
appropriate forum for asking support questions.

Thank you for your interest in PHP.

At 08:57 12-12-2002, stormryder wrote:


Hi,
I'm using the mail() function to send out mails.
The problem I'm having is the subject line shows up in the message body.

Anybody has any ideas?

TIA



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


With kind regards,

Melvyn Sopacua



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

Re: [PHP-DEV] PHP-4.3.0RC3 Windows - getopt function

[Hartmut Holzgraefe]

Kjartan Mannes wrote:

The NEWS file mentions a new function getopt(), but I can not get this
to work under windows.

  Fatal error: Call to undefined function:  getopt()

My guess is that getopt() isn't a standard system function, but PHP
mimics the function as it handles command line arguments. Is this
intentional or just an oversight?


for now it is Unix-only

( Actualy it is protected by #if HAVE_GETOPT and configure
  deals with it checking for getopt() in libc.
  On Windows there is nothing like configure so this has
  to be solved in a different way. )

any Win32 volunteers?

--
Six Offene Systeme GmbH http://www.six.de/
i.A. Hartmut Holzgraefe
Email: [EMAIL PROTECTED]
Tel.:  +49-711-99091-77


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

Re: [PHP-DEV] Critical Bug #20887

[Moriyoshi Koizumi]

Thanks for the pointer. As far as I looked over the thread, which is not 
so long as I expected, I don't feel there is that much need for including 
CWD in php.ini search path. +1 for removing that feature.

Moriyoshi

"Edin Kadribasic" <[EMAIL PROTECTED]> wrote:

> No because it was preciselly because of cgi that CWD wasn't removed
> from the php.ini search path. Have a look at the following thread:
> 
> http://www.zend.com/lists/php-dev/200202/msg01325.html
> 
> Edin
> 
> - Original Message -
> From: "Moriyoshi Koizumi" <[EMAIL PROTECTED]>
> To: "Edin Kadribasic" <[EMAIL PROTECTED]>
> Cc: "Derick Rethans" <[EMAIL PROTECTED]>; "Jani Taskinen"
> <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Thursday, December 12, 2002 12:44 PM
> Subject: Re: [PHP-DEV] Critical Bug #20887
> 
> 
> > > At the time CLI was introduced I argued to remove . from php.ini
> > > search path, but that was not accepted because some people
> > > apparently use this feature for having different configurations
> for
> > > different virtual hosts.
> > >
> > > Therefore . was removed only from CLI's php.ini search path.
> >
> > This feature looks somewhat evil since it enables users to bypass
> the safe
> > mode restrictions enforced by the administrator, or am I missing
> > something?
> >
> > Anyway, the following patch should make sense for #20887?
> >
> > Moriyoshi
> >
> > Index: main/php_ini.c
> >
> ===
> > RCS file: /repository/php4/main/php_ini.c,v
> > retrieving revision 1.106
> > diff -u -r1.106 php_ini.c
> > --- main/php_ini.c  12 Nov 2002 20:56:47 -  1.106
> > +++ main/php_ini.c  12 Dec 2002 11:22:17 -
> > @@ -272,7 +272,8 @@
> >
> > /* Add cwd */
> >  #ifdef INI_CHECK_CWD
> > -   if (strcmp(sapi_module.name, "cli")!=0) {
> > +   if (strcmp(sapi_module.name, "cgi")==0
> > +   || strcmp(sapi_module.name,
> "cgi-fcgi")==0) {
> > if (*php_ini_search_path) {
> > strcat(php_ini_search_path,
> paths_separator);
> > }
> >
> >
> 


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

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

[Peter Neuman]

hmm better is:

 #if HAVE_LIBGD => 204
 io_ctx->gd_free(io_ctx);
 #else
 io_ctx->free(io_ctx);
 #endif

or so, my C is not good my PHP is better :o) :P
or one makes which one ext/gd only with gd2.0.4 install can?

"Electroteque" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> firstly where can i add stuff to the cvs ? i have made a few posts before
> about an issue that hasnt changed , you guys still dont have it patched
>
> #if HAVE_LIBGD204
> io_ctx->gd_free(io_ctx);
> #else
> io_ctx->free(io_ctx);
> #endif
>
> HAVE_LIBGD204 - this obviously means version 2.0.4 ? i now have 2.0.8 so
of
> course it is going to use   io_ctx->free(io_ctx); instead and break
>
> "Melvyn Sopacua" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > On Wed, 11 Dec 2002, Juan Rosero wrote:
> >
> > JR>>> Whenever PHP 4.3.0 is released will it officially support Apache
2?
> >
> > I wasn't aware Apache 2 officially supported a working mpm yet?
> >
> > --
> > With kind regards,
> >
> > Melvyn Sopacua
> > 
> >
>
>


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

[PHP-DEV] PHP-4.3.0RC3 Windows - getopt function

[Kjartan Mannes]

The NEWS file mentions a new function getopt(), but I can not get this
to work under windows.

  Fatal error: Call to undefined function:  getopt()

My guess is that getopt() isn't a standard system function, but PHP
mimics the function as it handles command line arguments. Is this
intentional or just an oversight?

Running on Windows XP using:

  PHP 4.3.0RC3 (cli) (built: Dec 12 2002 01:24:29)
  Copyright (c) 1997-2002 The PHP Group
  Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies


-- 
Kjartan <[EMAIL PROTECTED]> (http://natrak.net/)
:: "A program is a spell cast over a computer, turning input
into error messages."


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

Re: [PHP-DEV] Critical Bug #20887

[Edin Kadribasic]

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

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

Edin

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


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


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

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

[electroteque]

firstly where can i add stuff to the cvs ? i have made a few posts before
about an issue that hasnt changed , you guys still dont have it patched

#if HAVE_LIBGD204
io_ctx->gd_free(io_ctx);
#else
io_ctx->free(io_ctx);
#endif

HAVE_LIBGD204 - this obviously means version 2.0.4 ? i now have 2.0.8 so of
course it is going to use   io_ctx->free(io_ctx); instead and break

"Melvyn Sopacua" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> On Wed, 11 Dec 2002, Juan Rosero wrote:
>
> JR>>> Whenever PHP 4.3.0 is released will it officially support Apache 2?
>
> I wasn't aware Apache 2 officially supported a working mpm yet?
>
> --
> With kind regards,
>
> Melvyn Sopacua
> 
>



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

Re: [PHP-DEV] Critical Bug #20887

[Moriyoshi Koizumi]

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

This feature looks somewhat evil since it enables users to bypass the safe 
mode restrictions enforced by the administrator, or am I missing 
something?

Anyway, the following patch should make sense for #20887?

Moriyoshi

Index: main/php_ini.c
===
RCS file: /repository/php4/main/php_ini.c,v
retrieving revision 1.106
diff -u -r1.106 php_ini.c
--- main/php_ini.c  12 Nov 2002 20:56:47 -  1.106
+++ main/php_ini.c  12 Dec 2002 11:22:17 -
@@ -272,7 +272,8 @@

/* Add cwd */
 #ifdef INI_CHECK_CWD
-   if (strcmp(sapi_module.name, "cli")!=0) {
+   if (strcmp(sapi_module.name, "cgi")==0
+   || strcmp(sapi_module.name, "cgi-fcgi")==0) {
if (*php_ini_search_path) {
strcat(php_ini_search_path, paths_separator);
}

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

Re: [PHP-DEV] Critical Bug #20887

[Edin Kadribasic]

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

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

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

Edin


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

Re: [PHP-DEV] Critical Bug #20887

[Moriyoshi Koizumi]

You are right. I verified Apache changes the cwd to / unless it's been 
launched in single process mode.

And I found results could be different by cases, using DSO or using CGI 
executable. When you run your script with CGI executable and php.ini is 
also present in that directory, the PHP binary tries to read that one as 
mod_cgi tries to chdir to where the script is put.
I'm not sure, but this appears to imply some security issues?

Moriyoshi

Derick Rethans <[EMAIL PROTECTED]> wrote:

> On Thu, 12 Dec 2002, Jani Taskinen wrote:
> 
> > On Thu, 12 Dec 2002, Moriyoshi Koizumi wrote:
> > 
> > >Hmm... it's natural that when apache is launched at /, it should read 
> > >/php.ini because of the current implementation shown below.
> > >
> > >274 #ifdef INI_CHECK_CWD 
> > >275 if (strcmp(sapi_module.name, "cli")!=0) {
> > >276if (*php_ini_search_path) {
> > >277strcat(php_ini_search_path, paths_separator);  
> > >278}
> > >279strcat(php_ini_search_path, ".");
> > >280 }
> > >281 #endif
> > 
> > Yeah, but I'm not launching it at /..
> 
> AFAIK apache always does a chdir('/') when you start it.
> 
> Derick
> 
> -- 
> 
> -
>  Derick Rethans http://derickrethans.nl/ 
>  PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
> -
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

[PHP-DEV] bug #15209 register_shutdown_function - please discuss

[Arpad Tamas]

Hi,
I know there was some hot discussion about this topic but I really need to get 
this bug fixed. Even I'll make a patch with my zero knowledge of c if no one 
would like to make it, but please try to find a reasonable sollution that 
fits (almost) everyone's need.

I thought of one. I think a new function with the name 
register_apache_shutdown_function (or somethink like this) might be good. 
It's name would say that it only works in apache, it could be documented that 
it's the *only* function that closes the connection before the registered 
functions are handled. Or maybe a parameter could tell if the connection 
should be closed before the first registered function is started.

I'll hope there's some way to solve this problem, because it's not easy to 
tell every customer to use our patch (or use 4.0.6) before they are staring 
to use our programs that rely on this forgotten feature.
Thanks,
Arpi

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

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

[Jan Schneider]

I know this thread is ridden to death but I want to add one argument for
completeness: If the cgi's name will be changed, thousands of administrators
need to fix their servers. But if the cli's name will be changed thousands
of "end users" of php cli scripts will have to change the scripts' shebang line.

I have no idea if there are more administrators who have to care about php
cgi or users who use php cli. But at least the first group will have less
problems fixing the name change than the latter.

Just my 0.02 Euro.

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft

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

Re: [PHP-DEV] Critical Bug #20887

[Derick Rethans]

On Thu, 12 Dec 2002, Jani Taskinen wrote:

> On Thu, 12 Dec 2002, Moriyoshi Koizumi wrote:
> 
> >Hmm... it's natural that when apache is launched at /, it should read 
> >/php.ini because of the current implementation shown below.
> >
> >274 #ifdef INI_CHECK_CWD 
> >275 if (strcmp(sapi_module.name, "cli")!=0) {
> >276  if (*php_ini_search_path) {
> >277  strcat(php_ini_search_path, paths_separator);  
> >278  }
> >279  strcat(php_ini_search_path, ".");
> >280 }
> >281 #endif
> 
> Yeah, but I'm not launching it at /..

AFAIK apache always does a chdir('/') when you start it.

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


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

[PHP-DEV] segfault in latest CVS

[Kai Schröder]

I got a segmentation fault during configure php (today cvs) on Linux (SuSE
7.3, Kernel 2.4.20). Last line was "checking getpwnam... no".

Regards, Kai



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

Re: [PHP-DEV] Critical Bug #20887

[Jani Taskinen]

On Thu, 12 Dec 2002, Moriyoshi Koizumi wrote:

>Hmm... it's natural that when apache is launched at /, it should read 
>/php.ini because of the current implementation shown below.
>
>274 #ifdef INI_CHECK_CWD 
>275 if (strcmp(sapi_module.name, "cli")!=0) {
>276if (*php_ini_search_path) {
>277strcat(php_ini_search_path, paths_separator);  
>278}
>279strcat(php_ini_search_path, ".");
>280 }
>281 #endif

Yeah, but I'm not launching it at /..

--Jani



>Moriyoshi
>
>Jani Taskinen <[EMAIL PROTECTED]> wrote:
>
>> 
>> But unfortunately neither of these fix the bug.
>> If there is php.ini in /, it's still used.
>> 
>> --Jani
>> 
>> 
>> 
>> On Thu, 12 Dec 2002, Moriyoshi Koizumi wrote:
>> 
>> >+1 for applying this patch.
>> >
>> >and attached is yet another fix as my suggestion.
>> >(a bit dirty, and not tested enough).
>> >
>> >Moriyoshi
>> >
>> >
>> >"Sara Golemon" <[EMAIL PROTECTED]> wrote:
>> >
>> >> I THINK the patch below will fix critical bug #20887, but it's late and
>> >> I've had a long day so I havn't begun to make sure it'll work properly in
>> >> any circumstance, could anyone else have a look and try it out?
>> >> 
>> >> See my note in Bug #20887 for an explanation of what my theory about the
>> >> problem is.
>> >> 
>> >> -Pollita
>> >> 
>> >> Index: main/php_ini.c
>> >> ===
>> >> RCS file: /repository/php4/main/php_ini.c,v
>> >> retrieving revision 1.106
>> >> diff -u -r1.106 php_ini.c
>> >> --- main/php_ini.c  12 Nov 2002 20:56:47 -  1.106
>> >> +++ main/php_ini.c  12 Dec 2002 06:49:50 -
>> >> @@ -298,7 +298,9 @@
>> >> char *separator_location =
>> >> strrchr(binary_location, DEFAULT_SLASH);
>> >> 
>> >> if (separator_location) {
>> >> -   *(separator_location+1) = 0;
>> >> +   separator_location[0] = '\0';
>> >> +   } else {
>> >> +   binary_location[0] = '\0';
>> >> }
>> >> if (*php_ini_search_path) {
>> >> strcat(php_ini_search_path, paths_separator);
>> >> 
>> >> 
>> >> 
>> >> 
>> >> -- 
>> >> PHP Development Mailing List 
>> >> To unsubscribe, visit: http://www.php.net/unsub.php
>> >> 
>> >
>> 
>> -- 
>> <- For Sale! ->
>> 
>> 
>> -- 
>> PHP Development Mailing List 
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] Critical Bug #20887

[Moriyoshi Koizumi]

Hmm... it's natural that when apache is launched at /, it should read 
/php.ini because of the current implementation shown below.

274 #ifdef INI_CHECK_CWD 
275 if (strcmp(sapi_module.name, "cli")!=0) {
276 if (*php_ini_search_path) {
277 strcat(php_ini_search_path, paths_separator);  
278 }
279 strcat(php_ini_search_path, ".");
280 }
281 #endif

Moriyoshi

Jani Taskinen <[EMAIL PROTECTED]> wrote:

> 
> But unfortunately neither of these fix the bug.
> If there is php.ini in /, it's still used.
> 
> --Jani
> 
> 
> 
> On Thu, 12 Dec 2002, Moriyoshi Koizumi wrote:
> 
> >+1 for applying this patch.
> >
> >and attached is yet another fix as my suggestion.
> >(a bit dirty, and not tested enough).
> >
> >Moriyoshi
> >
> >
> >"Sara Golemon" <[EMAIL PROTECTED]> wrote:
> >
> >> I THINK the patch below will fix critical bug #20887, but it's late and
> >> I've had a long day so I havn't begun to make sure it'll work properly in
> >> any circumstance, could anyone else have a look and try it out?
> >> 
> >> See my note in Bug #20887 for an explanation of what my theory about the
> >> problem is.
> >> 
> >> -Pollita
> >> 
> >> Index: main/php_ini.c
> >> ===
> >> RCS file: /repository/php4/main/php_ini.c,v
> >> retrieving revision 1.106
> >> diff -u -r1.106 php_ini.c
> >> --- main/php_ini.c  12 Nov 2002 20:56:47 -  1.106
> >> +++ main/php_ini.c  12 Dec 2002 06:49:50 -
> >> @@ -298,7 +298,9 @@
> >> char *separator_location =
> >> strrchr(binary_location, DEFAULT_SLASH);
> >> 
> >> if (separator_location) {
> >> -   *(separator_location+1) = 0;
> >> +   separator_location[0] = '\0';
> >> +   } else {
> >> +   binary_location[0] = '\0';
> >> }
> >> if (*php_ini_search_path) {
> >> strcat(php_ini_search_path, paths_separator);
> >> 
> >> 
> >> 
> >> 
> >> -- 
> >> PHP Development Mailing List 
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >> 
> >
> 
> -- 
> <- For Sale! ->
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

Re: [PHP-DEV] Re: #20947 [Opn->Bgs]: imap won't configure or compile

[Derick Rethans]

On Thu, 12 Dec 2002, Jani Taskinen wrote:

> On Thu, 12 Dec 2002, Derick Rethans wrote:
> 
> >On Thu, 12 Dec 2002, Jani Taskinen wrote:
> >
> >> On Thu, 12 Dec 2002, Derick Rethans wrote:
> >> 
> >> >> 
> >> >> /configure --with-apxs=/usr/local/apache/bin/apxs
> >> >> --with-config-file-path=/etc --with-mysql --with-mcrypt
> >> >> --with-openssl=/us
> >> >> r/local/ssl --with-imap-ssl=/usr/local/lib
> >> >>
> >> 
> >> Last option, the path..anything wrong in it?
> >
> >Right, I see that now. But if you just put that in the "quick fix 
> >comment" section this (l)user would be happy, and the problem is noted 
> >in the bugreport too for further use.
> 
> "Give man a fish and he lives a day, teach him how to fish.." :)
> 
> Point being: People are too hasty reporting bugs. And too lazy
> to search archives, bug database, etc.

True, but also "Developers being trigger happy to clean out bugreports" :)
Although I certainly think bugs are reported too fast, that doesn't mean 
we need to close them without any message. Quality is better than 
Quantity :)

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


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

Re: [PHP-DEV] Re: #20947 [Opn->Bgs]: imap won't configure or compile

[Jani Taskinen]

On Thu, 12 Dec 2002, Derick Rethans wrote:

>On Thu, 12 Dec 2002, Jani Taskinen wrote:
>
>> On Thu, 12 Dec 2002, Derick Rethans wrote:
>> 
>> >> 
>> >> /configure --with-apxs=/usr/local/apache/bin/apxs
>> >> --with-config-file-path=/etc --with-mysql --with-mcrypt
>> >> --with-openssl=/us
>> >> r/local/ssl --with-imap-ssl=/usr/local/lib
>> >>
>> 
>> Last option, the path..anything wrong in it?
>
>Right, I see that now. But if you just put that in the "quick fix 
>comment" section this (l)user would be happy, and the problem is noted 
>in the bugreport too for further use.

"Give man a fish and he lives a day, teach him how to fish.." :)

Point being: People are too hasty reporting bugs. And too lazy
to search archives, bug database, etc.

--Jani



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

Re: [PHP-DEV] Re: #20947 [Opn->Bgs]: imap won't configure or compile

[Derick Rethans]

On Thu, 12 Dec 2002, Jani Taskinen wrote:

> On Thu, 12 Dec 2002, Derick Rethans wrote:
> 
> >> 
> >> /configure --with-apxs=/usr/local/apache/bin/apxs
> >> --with-config-file-path=/etc --with-mysql --with-mcrypt
> >> --with-openssl=/us
> >> r/local/ssl --with-imap-ssl=/usr/local/lib
> >>
> 
> Last option, the path..anything wrong in it?

Right, I see that now. But if you just put that in the "quick fix 
comment" section this (l)user would be happy, and the problem is noted 
in the bugreport too for further use.

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


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

Re: [PHP-DEV] Re: #20947 [Opn->Bgs]: imap won't configure or compile

[Jani Taskinen]

On Thu, 12 Dec 2002, Derick Rethans wrote:

>> 
>> /configure --with-apxs=/usr/local/apache/bin/apxs
>> --with-config-file-path=/etc --with-mysql --with-mcrypt
>> --with-openssl=/us
>> r/local/ssl --with-imap-ssl=/usr/local/lib
>>

Last option, the path..anything wrong in it?

--Jani


>> output:
>> checking for IMAP support... no
>> After running make and make install and restarting apache (DSO module)
>> tried to use imap:
>> Fatal error:  Call to undefined function:  imap_open() in
>> /var/www/htdocs/tickets/imap_create.php on line 11
>> 
>> 2. Tried without "with-imap-ssl", but with "--with-imap":
>> 
>> ./configure --with-apxs=/usr/local/apache/bin/apxs
>> --with-config-file-path=/etc --with-mysql --with-mcrypt
>> --with-openssl=/u
>> sr/local/ssl --with-imap
>> 
>> output:
>> configure: error: This c-client library is built with SSL support.
>> 
>>   Add --with-imap-ssl<=DIR> to your configure line. Check
>> config.log for details.
>> 
>> So, the configure script is finding the c-client libraries.
>> 
>> Output from config.log:
>> 
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:268: the use
>> of `tmpnam' is dangerous, better use `mkstemp'
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:281: undefined
>> reference to `RAND_seed'
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:286: undefined
>> reference to `SSL_library_init'
>> /usr/local/lib/libc-client.a(osdep.o): In function `ssl_start_work':
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:388: undefined
>> reference to `TLSv1_client_method'
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:388: undefined
>> reference to `SSLv23_client_method'
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:388: undefined
>> reference to `SSL_CTX_new'
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:391: undefined
>> reference to `SSL_CTX_ctrl'
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:395: undefined
>> reference to `SSL_CTX_set_verify'
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:397: undefined
>> reference to `SSL_CTX_set_default_verify_paths'
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:398: undefined
>> reference to `SSL_new'
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:400: undefined
>> reference to `BIO_new_socket'
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Edit this bug report at http://bugs.php.net/?id=20947&edit=1
>> 
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] Critical Bug #20887

[Jani Taskinen]

But unfortunately neither of these fix the bug.
If there is php.ini in /, it's still used.

--Jani



On Thu, 12 Dec 2002, Moriyoshi Koizumi wrote:

>+1 for applying this patch.
>
>and attached is yet another fix as my suggestion.
>(a bit dirty, and not tested enough).
>
>Moriyoshi
>
>
>"Sara Golemon" <[EMAIL PROTECTED]> wrote:
>
>> I THINK the patch below will fix critical bug #20887, but it's late and
>> I've had a long day so I havn't begun to make sure it'll work properly in
>> any circumstance, could anyone else have a look and try it out?
>> 
>> See my note in Bug #20887 for an explanation of what my theory about the
>> problem is.
>> 
>> -Pollita
>> 
>> Index: main/php_ini.c
>> ===
>> RCS file: /repository/php4/main/php_ini.c,v
>> retrieving revision 1.106
>> diff -u -r1.106 php_ini.c
>> --- main/php_ini.c  12 Nov 2002 20:56:47 -  1.106
>> +++ main/php_ini.c  12 Dec 2002 06:49:50 -
>> @@ -298,7 +298,9 @@
>> char *separator_location =
>> strrchr(binary_location, DEFAULT_SLASH);
>> 
>> if (separator_location) {
>> -   *(separator_location+1) = 0;
>> +   separator_location[0] = '\0';
>> +   } else {
>> +   binary_location[0] = '\0';
>> }
>> if (*php_ini_search_path) {
>> strcat(php_ini_search_path, paths_separator);
>> 
>> 
>> 
>> 
>> -- 
>> PHP Development Mailing List 
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
>

-- 
<- For Sale! ->


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