Hi,
Testing the PHP version can be much easier and faster if the versions
details were exposed via the constants, like what we use internally.
This little patch expose what we have in php_version.h
#define PHP_MAJOR_VERSION 5
#define PHP_MINOR_VERSION 2
#define PHP_RELEASE_VERSION 6
#define PHP_EXTRA_VERSION "-dev"
#define PHP_VERSION "5.2.6-dev" << already available as contant
#define PHP_VERSION_ID 50206
Patch against 5.2 attached.
Any objections?
Cheers,
Hi!
Testing the PHP version can be much easier and faster if the versions
details were exposed via the constants, like what we use internally.
This little patch expose what we have in php_version.h
Looks ok, shouldn't harm anything.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi,
Testing the PHP version can be much easier and faster if the versions
details were exposed via the constants, like what we use internally.
This little patch expose what we have in php_version.h#define
PHP_MAJOR_VERSION5
#definePHP_MINOR_VERSION2
#definePHP_RELEASE_VERSION6
#definePHP_EXTRA_VERSION"-dev"
#definePHP_VERSION"5.2.6-dev" << already available as contant
#definePHP_VERSION_ID50206Patch against 5.2 attached.
Any objections?
Bla bla bla.. Commit the thing already :))
Cheers,
Pierre
http://blog.thepimp.net | http://www.libgd.org--
--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
Hello Pierre,
yeah nice idea. I am wondering if you might want to add the cvs tag, too?
E.g.: PHP_TAG = 'PHP_5_3'
marcus
Friday, February 8, 2008, 1:52:27 PM, you wrote:
Hi,
Testing the PHP version can be much easier and faster if the versions
details were exposed via the constants, like what we use internally.
This little patch expose what we have in php_version.h
#define
PHP_MAJOR_VERSION5
#definePHP_MINOR_VERSION2
#definePHP_RELEASE_VERSION6
#definePHP_EXTRA_VERSION"-dev"
#definePHP_VERSION"5.2.6-dev" << already available as contant
#definePHP_VERSION_ID50206
Patch against 5.2 attached.
Any objections?
Cheers,
Best regards,
Marcus
Hi Marcus,
Hello Pierre,
yeah nice idea. I am wondering if you might want to add the cvs tag, too?
E.g.: PHP_TAG = 'PHP_5_3'
Oh right, nice idea :) It would be nice to have it as well. The idea
is to ease the tests writing and configuration detections.
Cheers,
Hello,
Is there any chance that dirname(FILE) being exposed as a constant,
i.e. DIRNAME?
Hi Marcus,
Hello Pierre,
yeah nice idea. I am wondering if you might want to add the cvs tag,
too?
E.g.: PHP_TAG = 'PHP_5_3'Oh right, nice idea :) It would be nice to have it as well. The idea
is to ease the tests writing and configuration detections.Cheers,
Pierre
http://blog.thepimp.net | http://www.libgd.org--
--
Best regards,
Jingcheng Zhang
Room 304, Dormitory 26 of Yuquan Campus, Zhejiang University
P.R.China
Zitat von Jingcheng Zhang diogin@gmail.com:
Hello,
Is there any chance that dirname(FILE) being exposed as a constant,
i.e. DIRNAME?
No. Constants are per request, dirname(FILE) is obviously
different per file.
Jan.
--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
Jan Schneider wrote:
Zitat von Jingcheng Zhang diogin@gmail.com:
Hello,
Is there any chance that dirname(FILE) being exposed as a constant,
i.e. DIRNAME?No. Constants are per request, dirname(FILE) is obviously different
per file.
That's not entirely true, isn't it? Think FILE is per file, then we've
FUNCTION, LINE, etc.
sincerely,
- Markus
Is there any chance that dirname(FILE) being exposed as a constant,
i.e. DIRNAME?No. Constants are per request, dirname(FILE) is obviously different
per file.
Actually, just as FILE, LINE, CLASS etc. dirname(FILE)
can be a parser constant. And if somebody produces a good name and a
patch for it, I see no reason to reject it. Does anybody?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi Stanislav,
Am Sonntag, den 10.02.2008, 21:11 -0800 schrieb Stanislav Malyshev:
[...]
Actually, just as FILE, LINE, CLASS etc. dirname(FILE)
can be a parser constant. And if somebody produces a good name and a
patch for it, I see no reason to reject it. Does anybody?
For the name I would propose DIR, same as to FILE, CLASS,
NAMESPACE etc. pp.
I tried to do it yesterday, but I need some advice on how to do it. So
far I need to add another token and an ST_IN_SCRIPTING entry. Basically
the quick hack would be to use zend_get_compiled_filename() in it. I
stuck how to extract the dirname. Should I use php_dirname() (which is
platform sensitive but this is considered inappropriate from what I
heard), should php_dirname() be moved? Or should I introduce another
hash table entry for the current dirname?
cu, Lars
Hi,
Am Sonntag, den 10.02.2008, 21:11 -0800 schrieb Stanislav Malyshev:
[...]
Actually, just as FILE, LINE, CLASS etc. dirname(FILE)
can be a parser constant. And if somebody produces a good name and a
patch for it, I see no reason to reject it. Does anybody?
So here we are. The following patch[1] adds support for the constant
DIR which is dirname(FILE).
[1] http://lars.schokokeks.org/php/dir-constant-2.diff
cu, Lars
Hi,
Am Montag, den 11.02.2008, 12:51 +0100 schrieb Lars Strojny:
[...]
Updated version. Moved and renamed php_dirname() to zend_dirname() to
not use PHP internals in the Zend Engine. Fixed a memory leak and added
the TSRM-includes to have some macros/constants defined.
Comments? Critics?
cu, Lars
Hi,
Am Montag, den 11.02.2008, 12:51 +0100 schrieb Lars Strojny:
[...]Updated version. Moved and renamed php_dirname() to zend_dirname() to
not use PHP internals in the Zend Engine. Fixed a memory leak and added
the TSRM-includes to have some macros/constants defined.Comments? Critics?
I did not see the zend_dirname usage (wrong link?) and did not find
either this function/macro.
I slightly modified it to avoid too much strlen and to do not process
the string if there is nothing to process. Please find my version of
your patch as attachment.
Thanks for your work!
Hi Pierre,
Am Montag, den 11.02.2008, 17:15 +0100 schrieb Pierre Joye:
[...]
I did not see the zend_dirname usage (wrong link?) and did not find
either this function/macro.I slightly modified it to avoid too much strlen and to do not process
the string if there is nothing to process. Please find my version of
your patch as attachment.
I forgot to add the link, I'm so sorry.
http://lars.schokokeks.org/php/dir-constant-4.diff
cu, Lars
Hi Lars,
Hi Pierre,
Am Montag, den 11.02.2008, 17:15 +0100 schrieb Pierre Joye:
[...]I did not see the zend_dirname usage (wrong link?) and did not find
either this function/macro.I slightly modified it to avoid too much strlen and to do not process
the string if there is nothing to process. Please find my version of
your patch as attachment.I forgot to add the link, I'm so sorry.
http://lars.schokokeks.org/php/dir-constant-4.diff
Looks better :)
I did not test it but it looks good. Did you run the tests suite?
- dirname = estrndup(filename, strlen(filename));
- zend_dirname(dirname, strlen(dirname));
One strlen can be dropped here.
Grüße,
Hi Pierre,
Am Montag, den 11.02.2008, 17:42 +0100 schrieb Pierre Joye:
[...]
Looks better :)
Thank you!
I did not test it but it looks good. Did you run the tests suite?
- dirname = estrndup(filename, strlen(filename));
- zend_dirname(dirname, strlen(dirname));
One strlen can be dropped here.
Ah, good hint. See http://lars.schokokeks.org/php/dir-constant-5.diff
for the corrected version.
cu, Lars
Hi Pierre,
Am Montag, den 11.02.2008, 17:42 +0100 schrieb Pierre Joye:
[...]Looks better :)
Thank you!
I did not test it but it looks good. Did you run the tests suite?
dirname = estrndup(filename, strlen(filename));zend_dirname(dirname, strlen(dirname));One strlen can be dropped here.
Ah, good hint. See http://lars.schokokeks.org/php/dir-constant-5.diff
for the corrected version.
One more thing:
const size_t filename_len = strlen(filename);
and it should be good. Stan, looks ok for you?
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
Hi,
Am Montag, den 11.02.2008, 17:58 +0100 schrieb Pierre Joye:
[...]
One more thing:
const size_t filename_len = strlen(filename);
and it should be good. Stan, looks ok for you?
Done: http://lars.schokokeks.org/php/dir-constant-6.diff
cu, Lars
and it should be good. Stan, looks ok for you?
I'm not sure what happens if zend_dirname returns 0, also what happens
if this constant is used in eval(), stream of anything else with
non-canonical filename? Except that, looks ok.
Some tests won't hurt though :)
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi,
Am Montag, den 11.02.2008, 13:25 -0800 schrieb Stanislav Malyshev:
[...]
I'm not sure what happens if zend_dirname returns 0, also what happens
if this constant is used in eval(), stream of anything else with
non-canonical filename? Except that, looks ok.
Some tests won't hurt though :)
I have created a few (and added one using eval()). See
http://lars.schokokeks.org/php/constant-tests.tar.bz2
cu, Lars
Hello all, I was documenting the DIR patch, and I ran across some
curious behavior when the PHP file was in the Windows filesystem root:
C:\test.php
<?php
echo DIR;
?>
Output:
C:\
Is this intended?
--
Edward Z. Yang GnuPG: 0x869C48DA
HTML Purifier http://htmlpurifier.org Anti-XSS Filter
[[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
Hi Edward,
Hello all, I was documenting the DIR patch, and I ran across some
curious behavior when the PHP file was in the Windows filesystem root:C:\test.php
<?php
echo DIR;
?>Output:
C:\Is this intended?
Yes, or what would you expect?
Cheers,
Pierre Joye schreef:
Hi Edward,
Hello all, I was documenting the DIR patch, and I ran across some
curious behavior when the PHP file was in the Windows filesystem root:C:\test.php
<?php
echo DIR;
?>Output:
C:\Is this intended?
Yes, or what would you expect?
possibly 'C:' ?
Cheers,
Pierre Joye schreef:
Hi Edward,
Hello all, I was documenting the DIR patch, and I ran across some
curious behavior when the PHP file was in the Windows filesystem root:C:\test.php
<?php
echo DIR;
?>Output:
C:\Is this intended?
Yes, or what would you expect?
possibly 'C:' ?
That would be a drive name not the directory name (equivalent to its path).
Cheers,
Jochem Maas schrieb:
Output:
C:
Is this intended?
Yes, or what would you expect?
possibly 'C:' ?
Is "C:" not the volume whereas "C:" is the root directory on the
volume?
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Sebastian Bergmann schreef:
Jochem Maas schrieb:
Output:
C:
Is this intended?
Yes, or what would you expect?
possibly 'C:' ?Is "C:" not the volume whereas "C:" is the root directory on the
volume?
this is what I thought, kind of, but I was just proposing what the OP
was expecting.
it does make one think a little about the small discrepancy with regard to
whether the slash is 'appended' or not depending on whether the dir is
the root or not:
php -r ' echo dirname("/Users"),"\n", dirname("/Users/foo"),"\n"; '
/
/Users
which means one cannot blindly say:
include DIR."/somefile";
although that's probably moot because my experience is that extraneous slashes
in a path are, afaik, always ignored. i.e. /foo//foo//foo == /foo/foo/foo,
so really there is nothing to see here.
good idea btw having DIR, it makes sense and rounds off the other magic
constants nicely.
Hi Jochen,
Sebastian Bergmann schreef:
Jochem Maas schrieb:
Output:
C:
Is this intended?
Yes, or what would you expect?
possibly 'C:' ?Is "C:" not the volume whereas "C:" is the root directory on the
volume?this is what I thought, kind of, but I was just proposing what the OP
was expecting.
the OP?
it does make one think a little about the small discrepancy with regard to
whether the slash is 'appended' or not depending on whether the dir is
the root or not:php -r ' echo dirname("/Users"),"\n", dirname("/Users/foo"),"\n"; '
/
/Users
You ask the directory name of a path. In the first case, you ask the
directory name of the path /Users (or /Users/), it is "/". The
directory name of the path "/Users/foo" is "/Users". Everything works
as expected as far as I can see.
which means one cannot blindly say:
include DIR."/somefile";
Little notice: OSes without volumes will work smoothly. For those with
volumes (windows, novell afair) willl use the current volume.
although that's probably moot because my experience is that extraneous slashes
in a path are, afaik, always ignored. i.e. /foo//foo//foo == /foo/foo/foo,
so really there is nothing to see here.
Yes, PHP is very tolerant (and brought us some headaches too in the
pasts :). It is also tolerant with \ or / usages.
Cheers,
Pierre Joye schreef:
Hi Jochen,
Sebastian Bergmann schreef:
Jochem Maas schrieb:
Output:
C:
Is this intended?
Yes, or what would you expect?
possibly 'C:' ?
Is "C:" not the volume whereas "C:" is the root directory on the
volume?
this is what I thought, kind of, but I was just proposing what the OP
was expecting.the OP?
it does make one think a little about the small discrepancy with regard to
whether the slash is 'appended' or not depending on whether the dir is
the root or not:php -r ' echo dirname("/Users"),"\n", dirname("/Users/foo"),"\n"; '
/
/UsersYou ask the directory name of a path. In the first case, you ask the
directory name of the path /Users (or /Users/), it is "/". The
directory name of the path "/Users/foo" is "/Users". Everything works
as expected as far as I can see.
I agree, I was merely pondering out loud, no problems as such.
which means one cannot blindly say:
include DIR."/somefile";
Little notice: OSes without volumes will work smoothly. For those with
volumes (windows, novell afair) willl use the current volume.although that's probably moot because my experience is that extraneous slashes
in a path are, afaik, always ignored. i.e. /foo//foo//foo == /foo/foo/foo,
so really there is nothing to see here.Yes, PHP is very tolerant (and brought us some headaches too in the
pasts :). It is also tolerant with \ or / usages.
I can imagine it has caused headaches for dev's working with the underlying implementation ..
I for one am grateful it's so tolerant ... more than once have I noticed some badly defined
paths working without a problem, months after the code was originally written.
3 cheers for tolerance :-)
Cheers,
Hi,
Hello all, I was documenting the DIR patch, and I ran across some
curious behavior when the PHP file was in the Windows filesystem root:C:\test.php
<?php
echo DIR;
?>Output:
C:\Is this intended?
What else would you expect? For me it looks right.
johannes
Johannes Schlüter wrote:
What else would you expect? For me it looks right.
I talked about this with Steph Fox, and the behavior is correct. Please
disregard GP! :-)
--
Edward Z. Yang GnuPG: 0x869C48DA
HTML Purifier http://htmlpurifier.org Anti-XSS Filter
[[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
Hello Pierre,
yeah nice idea. I am wondering if you might want to add the cvs tag, too?
E.g.: PHP_TAG = 'PHP_5_3'
I'll commit the patch later today, I think PHP_BRANCHE sounds better
than PHP_TAG, or PHP_CVS_TAG (but if we move away from CVS? :-D )
Ilia, I know you see no use of this but is it ok to apply it to 5.2 too?
Cheers,
Hello Pierre,
yeah nice idea. I am wondering if you might want to add the cvs tag, too?
E.g.: PHP_TAG = 'PHP_5_3'I'll commit the patch later today, I think PHP_BRANCHE sounds better
than PHP_TAG, or PHP_CVS_TAG (but if we move away from CVS? :-D )
Typo, I meant PHP_BRANCH
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
Pierre,
Hello Pierre,
yeah nice idea. I am wondering if you might want to add the cvs tag, too?
E.g.: PHP_TAG = 'PHP_5_3'I'll commit the patch later today, I think PHP_BRANCHE sounds better
than PHP_TAG, or PHP_CVS_TAG (but if we move away from CVS? :-D )Typo, I meant PHP_BRANCH
Yes that name is fine, bunt wondering: When/Where do you get this
information and where from? What's the impact for build
snapshots/releases? Afaik the scripts for that work on cvs exports where
that information isn't available anymore.
johannes
Pierre,
Hello Pierre,
yeah nice idea. I am wondering if you might want to add the cvs tag, too?
E.g.: PHP_TAG = 'PHP_5_3'I'll commit the patch later today, I think PHP_BRANCHE sounds better
than PHP_TAG, or PHP_CVS_TAG (but if we move away from CVS? :-D )Typo, I meant PHP_BRANCH
Yes that name is fine, bunt wondering: When/Where do you get this
information and where from? What's the impact for build
snapshots/releases? Afaik the scripts for that work on cvs exports where
Good point, I did not check the CVS doc before and can't find how to
get it in the same way than $Id$. Marcus? :)
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
Yes that name is fine, bunt wondering: When/Where do you get this
information and where from? What's the impact for build
snapshots/releases? Afaik the scripts for that work on cvs exports whereGood point, I did not check the CVS doc before and can't find how to
get it in the same way than $Id$. Marcus? :)
No, there is no such keyword which offers this information. The only way
to get it would be to inject it from the scripts ... but I guess that
just leads to trouble afterward. And I don't see much need for the
branch info anyhow ...
johannes
We spoke about this via IM, but its only fair that the answer be
provided via a mailing list as well.
From my standpoint this is a feature, although a minute one and 5.2
is not in a feature mode right now, we have 5.3 and PHP 6 for that.
Secondly these constants are of dubious value (besides making code
slightly shorter) since nearly everything they offer can already be
done via the existing PHP_VERSION constant and version_compare. Big
version checks like the ones for 5 vs 6 you don't even need version
compare:
if (PHP_VERSION > 6) etc...
Therefor, for these two reasons I do not believe we need these
constants in 5.2 branch.
Hello Pierre,
yeah nice idea. I am wondering if you might want to add the cvs
tag, too?
E.g.: PHP_TAG = 'PHP_5_3'I'll commit the patch later today, I think PHP_BRANCHE sounds better
than PHP_TAG, or PHP_CVS_TAG (but if we move away from CVS? :-D )Ilia, I know you see no use of this but is it ok to apply it to 5.2
too?Cheers,
Ilia Alshanetsky
And for the reasons why they're not needed in 5.2 apply to any other PHP
version. version_compare() is there for a reason, USE IT! No more
constants for same thing, thankyouverymuch.
--Jani
We spoke about this via IM, but its only fair that the answer be
provided via a mailing list as well.From my standpoint this is a feature, although a minute one and 5.2
is not in a feature mode right now, we have 5.3 and PHP 6 for that.
Secondly these constants are of dubious value (besides making code
slightly shorter) since nearly everything they offer can already be
done via the existingPHP_VERSIONconstant and version_compare. Big
version checks like the ones for 5 vs 6 you don't even need version
compare:
if (PHP_VERSION > 6) etc...Therefor, for these two reasons I do not believe we need these
constants in 5.2 branch.Hello Pierre,
yeah nice idea. I am wondering if you might want to add the cvs
tag, too?
E.g.: PHP_TAG = 'PHP_5_3'I'll commit the patch later today, I think PHP_BRANCHE sounds better
than PHP_TAG, or PHP_CVS_TAG (but if we move away from CVS? :-D )Ilia, I know you see no use of this but is it ok to apply it to 5.2
too?Cheers,
Ilia Alshanetsky
--
Patches/Donations: http://pecl.php.net/~jani/
And for the reasons why they're not needed in 5.2 apply to any other PHP
version.version_compare()is there for a reason, USE IT! No more
constants for same thing, thankyouverymuch.
Read:
it is easier, faster handier to use than version_compare. It makes
perfectly sense to have them as other pointed out too, they can even
be used in php.ini when the [if] is available.
Thank you for your feedback :)
And for the reasons why they're not needed in 5.2 apply to any other PHP
version.version_compare()is there for a reason, USE IT! No more
constants for same thing, thankyouverymuch.Read:
it is easier, faster handier to use than version_compare. It makes
perfectly sense to have them as other pointed out too, they can even
be used in php.ini when the [if] is available.
I thought nobody noticed my comment about constants and php.ini usage..
You could still use PHP_VERSION there too. :D But to keep php.ini syntax
simple, it's better to just keep on adding more constants in PHP
side. ;)
.oO(..so this is how it feels like when something comes back and bites
you in the ass..)
--
Patches/Donations: http://pecl.php.net/~jani/