[PHP-DEV] Resolution of static variables in the function scope not using forwarded calling information?
Hello all,
I ran into some very strange behavior while experimenting with static
function variables. It looks like a bug to me, but I couldn't find any
previous reports or discussions about the subject, so I wanted to gather
your input before submitting it as such.
Static variables in the function scope appear to be resolved using late
static binding: the content of the variable in that function is shared
amongst all instances of a class, though each subclass gets its own
separate variable space.
This is pretty logical and works fine. As an example, let's create
classes Base => Animal => {Cat,Dog}. Base has a function that describes
the class, and caches the result in a static function variable
$description. Calling describe() on the three different classes
correctly gives us three different results: http://3v4l.org/Qldve
However, once you override the describe function in Animal and call
parent::describe() from within, it looks like all calling information is
lost: the resolution of $description in Base's function scope now always
points to Animal's variable space. For example: http://3v4l.org/qWrvf
Overriding the function in one of the childmost classes like Dog gives
an even stranger result: $description is now correctly a separate value
in Cat vs Dog, but calling Animal::describe() now uses the value left by
its child class Cat?! See: http://3v4l.org/61P72
Any thoughts?
Thanks,
Laszlo
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Resolution of static variables in the function scope not using forwarded calling information?
> This last is the only one that seems to be a bug to me; I think if you > step through the others you'll see why they are fine. Maybe the last > isn't a bug either; I'll try to think about this more but it does > appear to be a bug. FWIW, an example that makes the second situation slightly more clear: http://3v4l.org/CcrL8 I would have expected the static function variable and get_called_class() to always refer to the same class/variable space, parent:: or not. Oddly enough, referring to static class variables with "static::" never seems to use late static binding at all? http://3v4l.org/G9nCE Thanks, Laszlo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: Traits for PHP
Hi, during last six months I've studied a language construct called Traits. It is a construct to allow fine-grained code reuse and in my opinon this would be a nice feature for PHP, which I did like to propose here. The following RFC deals with the questions what Traits are, how they are used, why they are usefull and how they do look like in PHP. A patch implementing this new language construct is available, too. Thank you for your attention and I'm looking forward to hear your comments :) Kind Regards Stefan Request for Comments: Traits for PHP :HTML: http://www.stefan-marr.de/artikel/rfc-traits-for-php.html ... contents:: This RFC will discuss at first the motivation for Traits describing the rationals and presenting a short real world use case. The main part will describe the concept of Traits in detail using the syntax for Traits implemented in a patch which is part of this proposal. In the end, the URL of the patch and additional resources about Traits are given. Introduction *Traits* is a mechanism for code reuse in single inheritance languages such as PHP. A Trait is intended to reduce some limitations of single inheritance by enabeling a developer to reuse sets of methods freely in several independent classes living in different class hierarchies. The semantics of the combination of Traits and classes is defined in a way, which reduces complexity and avoids the typical problems associated with multiple inheritance and Mixins. They are recognized for their potential in supporting better composition and reuse, hence their integration in newer versions of languages such as Perl 6, Squeak, Scala, Slate and Fortress. Traits have also been ported to Java and C#. Why do we need Traits? -- Code reuse is one of the main goals that object-oriented languages try to achieve with inheritance. Unfortunately, single inheritance often forces the developer to take a decision in favor for either code reuse *or* conceptual clean class hierarchies. To achieve code reuse, methods have either to be duplicated or to be moved near the root of the class hierarchy, but this hampers understandability and maintainability of code. To circumvent this problems multiple inheritance and Mixins have been invented. But both of them are complex and hard to understand. PHP5 has been explicitly designed with the clean and successful model of Java in mind: single inheritance, but multiple interfaces. This decision has been taken to avoid the known problems of for example C++. Traits have been invented to avoid those problems, too. They enable designer to build conceptually clean class hierarchies without the need to consider code reuse or complexity problems, but focusing on the real problem domain and maintainability instead. Traits: A Mechanism for Fine-grained Reuse == A Trait is a unit of reuse much like a class, but only intended to group functionality in a fine-grained and consistent way. It is not possible to instantiate a Trait on its own. It is an addition to traditional inheritance and enables horizontal composition of behavior. The following code illustrates the current implementation of an extended version of the PHP reflection API which provides detailed access to doc comment blocks. ReflectionMethod and ReflectionFunction are classes from the reflection API and have to be extended with exactly the same code. In some situations it would be possible to add a common base class, but in this case it is impossible, because the extended classes are not under our control, i.e., they are implemented in third party code or even in C, like it is the case here. :: With Traits it is possible to refactor this redundant code out. :: This is just a small example of what Traits are useful for. The next sections will discuss on more advanced techniques and describe how the current implementation of Traits for PHP works. The Flattening Property --- As already mentioned, multiple inheritance and Mixins are complex mechanisms. Traits are an alternative which have been designed to impose no additional semantics on classes. Traits are only entities of the literal code written in your source files. There is no notion about Traits at runtime. They are used to group methods and reuse code and are totally flattened into the classes composed from them. It is almost like a language supported and failsafe copy'n'paste mechanism to build classes. Precedence Order """""""""""""""" Flattening is achieved by applying some simple rules on the composition mechanism. Instead of implementing a fancy and awkward algorithm to solve problems, the entire control about the composition is left in the hand of the developer and fits nicely into the known inheritance model of PHP. The following example
[PHP-DEV] Re: [PECL-DEV] Re: [PDO] Breaking the PDO API
On Wed, 22 Apr 2009 00:33:18 +0200, Johannes Schlüter wrote: > On Thu, 2009-04-16 at 01:58 +0200, Matteo Beccati wrote: >> Wez Furlong ha scritto: >> > Any objection to fixing this in the drivers themselves (as I >> > suggested)? >> > It seems like the easiest fix, and doesn't introduce a massive change >> > to >> > the code. >> >> Fine to me. I'll try and get back with a smaller patch soon-ish. > > Any update on this? Is there a good fix without API break? I'd like to > roll RC2 next Thursday. I confirm there's no need for API changes. I will commit the fix as soon as is't thoroughly tested, hopefully by the end of tomorrow. Sorry for the delay, but luck isn't on my side lately. I've lost all my uncommitted changes because of a silly mistake and I had to restart from scrach. Not to mention a few other hardware failures slowing me down even more. Cheers -- M. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] using $this-> implicitly inside same class
Hi all.
I'm using php 5.1.2 compiled from source, with Apache 2.2.0
and MySQL 5.0.18 on SuSE Linux 9.2 pro.
I really do not see the need to keep telling php I'm
refering to the properties and method of the class I'm
already in, when php 5 should be able to deduce this from
the context of the class I'm coding in.
I was wondering if it would be possible in future versions
of php to provide a PHP_INI_CLASS constant and a
this.use_implicit TRUE|FALSE option please, valid only
within a class's definition? I guess it could be moved to
php.ini later, if it became popular, and was required there.
This would allow a programmer to set the default value of
whether to use $this-> as a prefix to class properties and
methods, or not. (Similar to the way php 5.1.2 handles
methods without a visibility declaration - i.e. they default
to public)
This option to select default implicit referencing could
also apply to inherited properties and methods.
This would save ALOT of repetitive typing, and make the code
alot more concise. This would be similar to & being made
implicit when passing object references to method calls.
this.use_implicit could default to FALSE, so it would not
interfere with current code compatibility.
Developers could then choose to enable this.use_implicit
on a class by class basis. This would allow a developer to
do a gradual upgrade of their classes, without breaking any
code.
The only problem I can see, is that the parameters passed to
the __construct() function would have to use different names
to avoid any ambiguity conflicts - see example below.
As the parameters are only usually passed into a class once,
when the object is instantiated, this would cut down on a
lot of coding once the parameters are inside the class.
So, instead of coding something like:
(From chapter 19 example 25 of the manual)
server = $server;
$this->username = $username;
$this->password = $password;
$this->db = $db;
$this->connect();
}
private function connect()
{
$this->link = mysql_connect($this->server, $this->username,
$this->password);
mysql_select_db($this->db, $this->link);
}
public function __sleep()
{
mysql_close($this->link);
}
public function __wakeup()
{
$this->connect();
}
}
?>
I was thinking of something more like this:
implicitly within this class only
ini_set('this.use_implicit', ON);
protected $link;
private $server, $username, $password, $db;
public function __construct($server_p, $username_p, $password_p, $db_p)
{
$server= $server_p;
$username = $username_p;
$password = $password_p;
$db= $db_p;
connect();
}
private function connect()
{
$link = mysql_connect($server, $username, $password);
mysql_select_db($db, $link);
}
public function __sleep()
{
mysql_close($link);
}
public function __wakeup()
{
connect();
}
}
?>
Any comments or suggestions would be welcomed.
Keith Roberts
In theory, theory and practice are the same;
In practice they are not.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] using $this-> implicitly inside same class
Thanks to Marcus and everyone else for their comments. I note the valid points you raised. Keith On Fri, 24 Feb 2006, Marcus Boerger wrote: > To: [EMAIL PROTECTED] > From: Marcus Boerger <[EMAIL PROTECTED]> > Subject: Re: [PHP-DEV] using $this-> implicitly inside same class > > Hello php, > > Friday, February 24, 2006, 3:05:11 PM, you wrote: > > > Hi all. > > > I'm using php 5.1.2 compiled from source, with Apache 2.2.0 > > and MySQL 5.0.18 on SuSE Linux 9.2 pro. > > > I really do not see the need to keep telling php I'm > > refering to the properties and method of the class I'm > > already in, when php 5 should be able to deduce this from > > the context of the class I'm coding in. > > While we could do this we decided against this years ago for a good reason. > It is faster the way we do it and the code is clearer and much easier > toread. Also introducing this now would be a major BC break. > > > This would save ALOT of repetitive typing, and make the code > > alot more concise. > > WOW, do your fingers hurt when typing "$this->" - wow 7 strokes. > > > this.use_implicit could default to FALSE, so it would not > > interfere with current code compatibility. > > No chance for an ini option because that would make writing protable > code impossible. > > [...] > > > Best regards, > Marcus > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Internals Standards
Hey, Could anyone point me to the current document for the internal PHP coding standards? (eg. Naming conventions, argument priorities...) . Thanks, Brad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #67383 exec() leaks file and socket descriptors to called program
Hi all, Am 27.01.2016 um 15:01 schrieb Julien Pauli: > On Wed, Jan 27, 2016 at 1:03 PM, Yasuo Ohgaki wrote: >> Hi all, >> >> This bug comes to my attention. >> https://bugs.php.net/bug.php?id=67383 >> >> This report includes patch that prevents file descriptor leaks. >> https://bugs.php.net/patch-display.php?bug_id=67383&patch=SOCK_CLOEXEC-and-FD_CLOEXEC&revision=latest >> >> There may be cases that CLOEXEC cannot be applied blindly, but it >> seems this fixes lots of bugs including very old bugs. >> Why this patch is not merged and closed? >> >> Regards, >> >> -- >> Yasuo Ohgaki >> yohg...@ohgaki.net >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > Hi, > > Great catch. > > We already have many CLOEXEC, but we seem to be missing lots of them. > > There is a note however, in bug ticket 67383, about a problem in FPM > with CLOEXEC, which should be qualified and addressed. > Just don't apply blindly the patch. I think this patch is going to far. I agree any socket that is created by the sapi should be opened with SOCK_CLOEXEC. But in userland it must be possible to keep a socket open when forking, otherwise it is a big BC issue. At least the changes in ext/socket/socket.c, main/streams/plain_wrapper.c and main/fopen_wrappers.c change userland socket behavior in a not-compatible way. Maybe a fcntl wrapper which allows to enable/disable the SOCK_CLOEXEC flag should be introduced (in the next minor) and later (maybe in 8) userland sockets could be opened with SOCK_CLOEXEC set (as a security thing) with a workaround available for manual forking and keeping the sockets open. Greets Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] path_join function
Hey,
I have created on GitHub a feature request for a path_join function
(https://github.com/php/php-src/issues/11258) and got the label that this
requires a RFC. So I am here now :)
The idea is to provide in PHP itself a function to join filesystem paths (idea:
path_join) like in other languages, node as example
(https://nodejs.org/api/path.html#pathjoinpaths). For me this function is some
kind of base filesystem functionality like basename, realpath.
Example usage:
path_join('/base', 'my', 'path'); // /base/my/path
path_join('/base', 'my', 'path', 'test', '..'); // /base/my/path
Why not just string concatenation?
When you concat just the paths you have to think about:
- normalize string part to strip ending slash
- for windows compatibility you have to use DIRECTORY_SEPERATOR
I think this can improve the developer experience when working with filesystems
a lot and people can delete their implementation.
I am really looking for your feedback, right now I have no “karma points” to
create a RFC in the wiki :)
Thanks,
Soner
Re: [PHP-DEV] [RFC] path_join function
No stripping would be needed at the end :) Yes I would like to work on an proper RFC and make thoughts on the already given feedback here :) My wiki name is: shyim Thanks! > On 17. May 2023, at 17:36, Tim Düsterhus wrote: > > Hi > > On 5/17/23 16:54, p...@shyim.de wrote: >> When you concat just the paths you have to think about: >> - normalize string part to strip ending slash > > Why is it necessary to strip the ending slash? > >> - for windows compatibility you have to use DIRECTORY_SEPERATOR > > I don't use Windows, but to the best of my knowledge, using the '/' is > equivalent to the backslash. Is there a case where the difference matters? > >> I am really looking for your feedback, right now I have no “karma points” to >> create a RFC in the wiki :) > > If you want to proceed with an actual RFC, the folks handing out the RFC > karma would need your Wiki name. > > Best regards > Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] `PDO::FETCH_CONSTRUCTOR` fetch mode proposal
On 2024-01-18 21:23, Niels Dossche wrote: Hi Frederik Just putting the link here so people find it more easily :-) https://github.com/php/php-src/issues/13174 Cheers Niels Thank you, the link was originally on the text "on GitHub" but it seems to have been stripped. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] `PDO::FETCH_CONSTRUCTOR` fetch mode proposal
Hi Saki,
Welcome to the internal mailing list! I had looked the pull request,
and I'm pleased to have received your email promptly.
Thank you!
Now, I agree that it is often not possible to use `PDO::FETCH_CLASS`
because DB column names are typically snake case and variables and
properties are camel case.
IMHO, passing arguments to the constructor in order is a good
approach, but I think another option would be to give attributes to
properties and map data appropriately when using PDO::FETCH_CLASS.
e.g.
```
#[ColumnName('user_name')]
private string $userName;
```
The main motivation for this new fetch mode is the fact that it is now
infeasible to use the constructor. You would expect to use
`PDO::FETCH_CLASS` for it, as you're trying to create a class, but that
is impossible entirely. You need to resort to a hacky usage of
`PDO::FETCH_FUNC`, which in my view is unwanted. A nice consequence of
using the constructor is that the casings need not match. I like the
idea of using annotations, but they solve a different problem I think.
In addition to the concerns mentioned in the pull request, I'm also
concerned that more modes with similar functionality will confuse
users.
That is a valid concern. When I first starting looking into this I was
also a bit overwhelmed by the amount of possibilities one has. I think
giving an appropriate name to this new fetch mode is therefore
important. I thought of `PDO::FETCH_CONSTRUCTOR`, but I'm happy to hear
other ideas.
Kind regards,
Frederik van der Els
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] `PDO::FETCH_CONSTRUCTOR` fetch mode proposal
Hi Alexander,
I would also suggest supporting readonly classes and creating special
attributes to help map data fields to constructor arguments. Something
like
this:
readonly class User {
public function __construct(
#[PDOField('user_id')]
public string $userId,
#[PDOField('user_name')]
public string $userName,
#[PDOField('user_address')]
public ?string $userAddress = '', // Optional field with
default
value
);
}
When the constructor is used to create the class, readonly classes
should be
automatically supported by this new fetch mode right? And indeed, it
would be
useful to use named parameters if available. I overlooked this
possibility in
my response to Saki.
Kind regards,
Frederik van der Els
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Symbol clash between Recode and MySQL extensions
On FreeBSD, I was gettting the following error message when PHP exits: Php in free(): junk pointer, too high to make sense Further investigation showed that it stops showing when the MySQL module is disabled. I rebuilt my MySQL client libraries with debugging symbols, and forced a crash on invalid frees. Here is a backtrace: (gdb) bt #0 0x283fb404 in kill () from /usr/lib/libc.so.4 #1 0x28440810 in abort () from /usr/lib/libc.so.4 #2 0x2843f18a in isatty () from /usr/lib/libc.so.4 #3 0x2843f1bf in isatty () from /usr/lib/libc.so.4 #4 0x28440208 in isatty () from /usr/lib/libc.so.4 #5 0x28440485 in free () from /usr/lib/libc.so.4 #6 0x28487962 in my_no_flags_free (ptr=0x28d365e8 "U\211å\203ì\024Sèðÿÿÿ\201ÃXo\017") at my_malloc.c:60 #7 0x2848c7a6 in delete_dynamic (array=0x824b798) at array.c:236 #8 0x2848ddad in hash_free (hash=0x824b780) at hash.c:116 #9 0x28d38b74 in recode_delete_outer () from /usr/local/lib/librecode.so.3 #10 0x28ceed88 in zm_shutdown_recode () from /usr/local/lib/php/20041030/recode.so #11 0x81145be in module_destructor () #12 0x81170d7 in zend_hash_apply_deleter () #13 0x8117246 in zend_hash_graceful_reverse_destroy () #14 0x810faa2 in zend_shutdown () #15 0x80d8a10 in php_module_shutdown () #16 0x8157eea in main () #17 0x80632a1 in _start () It looks like the MySQL hash_free function is being called as the recode extension shuts down. I confirmed this by disabling the recode module and noting that the problem went away (it also goes away if the MySQL module is disabled). Any thoughts on how to scope the libraries to avoid this conflict? I was thinking dlfunc could be used to only import the functions we want, but I don't really have time to play with this myself. -- Alastair D'Silva mob: 0413 485 733 Networking Consultant fax: 0413 181 661 New Millennium Networking web: http://www.newmillennium.net.au -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Symbol clash between Recode and MySQL extensions
> -Original Message- > From: Jani Taskinen [mailto:[EMAIL PROTECTED] > Sent: Sunday, 13 February 2005 5:25 PM > To: [EMAIL PROTECTED] > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] Symbol clash between Recode and MySQL > extensions > > > > Also documented in the manual: > >http://www.php.net/recode Got it, thanks. > Just blame recode and mysql. They both should namespace > protect their > functions. :) Agreed. However, if a workaround is available, it would benefit everyone to implement it. I was thinking that rather than linking against the recode library (and implicitly importing all symbols within it), we could instead dlopen() it, and use dlsym() to import only symbols we want. Looking at the recode extension, theres only a handful of entrypoints that need to be imported, so it should be a relatively easy task for someone familiar with the PHP API. -- Alastair D'Silva mob: 0413 485 733 Networking Consultant fax: 0413 181 661 New Millennium Networking web: http://www.newmillennium.net.au -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Symbol clash between Tidy and ImageMagick
OK, heres another clash: (gdb) bt #0 0x28691f16 in GetToken () from /usr/local/lib/libMagick.so.7 #1 0x299c6198 in ParseDocument () from /usr/local/lib/libtidy-0.99.so.0 #2 0x299e1362 in tidyDocParseStream () from /usr/local/lib/libtidy-0.99.so.0 #3 0x299e0cbb in tidyDocParseString () from /usr/local/lib/libtidy-0.99.so.0 #4 0x299e09c4 in tidyParseString () from /usr/local/lib/libtidy-0.99.so.0 #5 0x299a4b61 in zif_tidy_parse_string () from /usr/local/lib/php/20041030/tidy.so #6 0x08161db3 in zend_do_fcall_common_helper () #7 0x0816210e in zend_do_fcall_handler () #8 0x0814fe7e in execute () #9 0x08128064 in zend_execute_scripts () #10 0x080e8411 in php_execute_script () #11 0x in ?? () #12 0x0003 in ?? () #13 0x in ?? () #14 0xbfbfe7b4 in ?? () #15 0x in ?? () #16 0x0002 in ?? () #17 0x284d976c in ?? () from /lib/libc.so.6 #18 0x0828d700 in ?? () #19 0x0080 in ?? () #20 0x0828d780 in ?? () #21 0x0812f5cd in _zend_hash_add_or_update () #22 0xbfbfe3d0 in ?? () #23 0x0080 in ?? () #24 0x28467e4f in _UTF8_wcsnrtombs () from /lib/libc.so.6 Previous frame inner to this frame (corrupt stack?) Disabling ImageMagick allows Tidy to work properly. I really think that rather than sitting around pointing fingers at the developers of the libraries (and yes, I understand that they really should be decorating all exported symbols), the PHP team should take steps to prevent these problems from happening by not loading all third party libraries (I count over 30 on my installation) into the same namespace. I still think that dlopen() and friends is the best way to tackle this on platforms that support it - does anybody know of any PHP supported platforms that don't support dlopen()? Other than the effort of converting the current extensions (or at least, the ones with known clashes), is there any reason not to try and work around these problems? -- Alastair D'Silva mob: 0413 485 733 Networking Consultant fax: 0413 181 661 New Millennium Networking web: http://www.newmillennium.net.au -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] . period for Class Syntax references
Hi all. I don't know if this has been implemented yet. Is it possible to make the '.' period character act place of the '->' character pair in class references, without conflicting with the '.' concatenation character? Possibly would have to implement the two styles of referencing to allow for backward compatibility? So, instead of writing: $this->my_var, one could then write $this.my_var, which would be alot more in common with other OOP languages. Maybe it's me, but I find it alot easier to read and pronounce '$this.my_var' == $this dot my_var, than something like '$this->my_var' == $this right-arrow my_var Or, even some other single character that may be used instead of the '->' pair. Any suggestions please? Regards - Keith Roberts http://www.karsites.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] . period for Class Syntax references
Thankyou for your quick replies Derick and Jason. I've taken a look at the link below - but I don't want to make any non-standard changes to the php engine - If it's working, don't 'fix' it! I want my code to be portable as well! I agree with Andrei Zmievski's point of view though. It's a shame it could not be implemented as a standard feature of php zend engine. Regards - Keith Roberts On Sun, 20 Mar 2005, Jason Sweat wrote: > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > From: Jason Sweat <[EMAIL PROTECTED]> > Subject: Re: [PHP-DEV] . period for Class Syntax references > > On Sun, 20 Mar 2005 22:09:54 + (GMT), [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: > > > > Hi all. > > > > I don't know if this has been implemented yet. > > > > Is it possible to make the '.' period character act > > place of the '->' character pair in class references, > > without conflicting with the '.' concatenation character? > > > > Possibly would have to implement the two styles of > > referencing to allow for backward compatibility? > > > > So, instead of writing: $this->my_var, one could then write > > $this.my_var, which would be alot more in common with other > > OOP languages. > > > > Maybe it's me, but I find it alot easier to read and > > pronounce '$this.my_var' == $this dot my_var, > > > > than something like > > > > '$this->my_var' == $this right-arrow my_var > > > > Or, even some other single character that may be used > > instead of the '->' pair. Any suggestions please? > > > > Regards - Keith Roberts > > Very dangerous to the long term maintainability of your code, but you > could look at: > http://www.gravitonic.com/software/php/ (near the bottom of the page) > which links to > http://www.gravitonic.com/software/php/patches/ze2_concat_obj_op.diff.gz > > Regards, > Jason > http://blog.casey-sweat.us/ > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #23580 ETA
I'm just trying to get a possible ETA on when and if somebody is going to look into the bug #23580 (detail below) a bit more. This bug is beginning to cause me a whole lot of pain, and if nobody else was looking at this maybe I could take a stab at it? --- Bug #23580 - 23580 Open Random values for include_path Thanks, Daniel S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #23580 ETA
I guess I can take a peek, but to get ramped up on the entire php engine might take longer than just waiting for a fix to become available. Maybe, because this is the only bug that seems to be causing problems on my server(s) at this time it is the most important :) This bug seems to have been open for a while, and since many hosting companies use php on the server they might have there own fixes (run in cgi mode only?) Anyway, thanks for the information, and I will try and make time today and later this weekend to look into learning more about the internal working of php and this one bug. Daniel S On Fri, 2003-08-15 at 01:13, Marcus Börger wrote: > Hello php, > > Friday, August 15, 2003, 9:02:28 AM, you wrote: > > p> I'm just trying to get a possible ETA on when and if somebody is going > p> to look into the bug #23580 (detail below) a bit more. This bug is > p> beginning to cause me a whole lot of pain, and if nobody else was > p> looking at this maybe I could take a stab at it? > > p> --- Bug #23580 - > p> 23580 Open Random values for include_path > > If a bug isn't assigned that means nobody is found guilty for the bug and > nobody has a real clue or enough time to analyze the bug. If the bug is > assigned you can always contact the person to whom the bug is assigned to > query whether any not listed progress in fixing was made. However you can > always invest time in fixing the bug. If you do you should post the news of > your investigations on the bug so the others know about your progress. And > we of course appreciate that :-) > > > -- > Best regards, > Marcusmailto:[EMAIL PROTECTED]
Re: [PHP-DEV] Scope of zend_alter_ini_entry in Apache module?
No I have not been able to isolate it, but I will try to set up a script to force the bug out of hiding on a regular basis... Give me a while though thanks, Daniel S On Fri, 2003-08-15 at 17:01, Zeev Suraski wrote: > At 01:46 16/08/2003, php wrote: > >Zeev, > > > >If you needed I could give you access to one of our servers so that you > >could see this with your own eyes :) It doesn't take long to run into the > >error in the log files and to just hit a few webpages on two domains until > >the error pops up, but I'm wondering now if it has something to do with > >auto_prepend? > > Did you ever manage to reproduce it in a fairly isolated manner? If you > could find the steps necessary to reproduce this problem this bug's life is > going to be VERY short! > > Off hand, I can't see how auto_prepend is related but to be honest, I'm not > sure what it is related to at all... > > Zeev
Re: [PHP-DEV] PHP Benchmark
Quoting Sebastian Bergmann <[EMAIL PROTECTED]>: > A while ago I posted [1] a script that performed some micro-benchmarks > on PHP. > > I have now refined this benchmark by splitting the monolithic script > into one script per micro-benchmark thus performing each benchmark with > a fresh PHP interpreter. > > The benchmark "suite" is available at > > http://www.sebastian-bergmann.de/PHP_Benchmark/ > > Any comments, feedback, corrections and additions are welcome, > Sebastian > > -- > [1] > http://www.sebastian-bergmann.de/blog/archives/104_PHP_MicroBenchmarkSuite.html > > -- > Sebastian Bergmann > http://sebastian-bergmann.de/ http://phpOpenTracker.de/ > > Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > PHP 5.0.0b3-dev (12 Nov 2003) Object Creation: 516997 objects created per second Member Access: 743309 member accesses per second Method Calls: 665755 method calls per second Array Creation: 821922 arrays created per second Array Index Access: 590843 array elements accessed by index per second Array Key Access: 1504844 array elements accessed by key per second Basic FP: 2759838 basic FP operations per second Complex FP: 1530908 complex FP operations per second Nested Loops (FP): 814283 nested loops per second Nested Loops (Int): 807857 nested loops per second processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 6 model name : AMD Athlon(tm) XP 1700+ stepping : 2 cpu MHz : 1463.275 cache size : 256 KB bogomips: 2916.35 Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
Quoting Andi Gutmans <[EMAIL PROTECTED]>: > I can nuke E_STRICT altogether if u guys want. > It's kind of a shame because I thought it might be nice for purists. I > don't understand why it bothers ppl so much when they don't have to use it. > I am with Derick, it should be in. The non-purist won't use it! The non-purists even now doesn't use E_ALL, they don't have E_NOTICEs enabled. Andrey Just my 0.046BGL :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Additional param for debug_print_backtrace() ?
Hi internals, I have created a small patch for debug_print_backtrace() that adds the possibility the string representation of the backtrace in printed form to be returned as string (as it is with print_r() currently). The patch is available at : http://andrey.hristov.com/projects/php_stuff/patches/debug_print_backtrace_ret_string.diff.txt Ideas or comments? I would like to see it applied since it's faster (to type) to pass true value to the function than using output buffering in userland which needs 3 additional lines of code. Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: desty
VCS Account Rejected: desty rejected by rasmus /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: ocramius
VCS Account Approved: ocramius approved by tyrael \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: cmb
VCS Account Approved: cmb approved by bjori \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: dustin
VCS Account Rejected: dustin rejected by bjori /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: ivangabriele
VCS Account Rejected: ivangabriele rejected by bjori /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: tgdice
VCS Account Rejected: tgdice rejected by bjori /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: buhlerax
VCS Account Approved: buhlerax approved by rasmus \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: mcmic
VCS Account Approved: mcmic approved by rasmus \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: matttait
VCS Account Rejected: matttait rejected by bjori /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: trowski
VCS Account Approved: trowski approved by salathe \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: matttait
VCS Account Approved: matttait approved by rasmus \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Rejected: test rejected by bjori
Nuked test -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Rejected: luballomuyoyo rejected by bjori
Nuked luballomuyoyo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: michaelhood
rasmus approved michaelhood account request \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Rejected: bspim rejected by bjori
Nuked bspim -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Rejected: flmommens rejected by bjori
Nuked flmommens -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Rejected: riad rejected by bjori
Nuked riad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VC6 Win32 Build
Hi, I'm using the VC6 GUI usnder Windows XP and I'm Building PHP 5.0.4 The entire Build works but it comes up with these errors at the end. "Linking... Creating library ..\Release_TSDbg/php5ts.lib and object ..\Release_TSDbg/php5ts.exp network.obj : error LNK2001: unresolved external symbol _in6addr_any simplexml.obj : error LNK2001: unresolved external symbol _zm_startup_spl_sxe basic_functions.obj : error LNK2001: unresolved external symbol _php_win32_core_globals_id pwd.obj : error LNK2001: unresolved external symbol _php_win32_core_globals_id time.obj : error LNK2001: unresolved external symbol _php_win32_core_globals_id wsyslog.obj : error LNK2001: unresolved external symbol _php_win32_core_globals_id basic_functions.obj : error LNK2001: unresolved external symbol _php_win32_core_globals_ctor basic_functions.obj : error LNK2001: unresolved external symbol _zm_deactivate_win32_core_globals ..\Release_TSDbg\php5ts.dll : fatal error LNK1120: 5 unresolved externals Error executing link.exe." The php_win32_core_globals are defined in globals.c and defined externally in the file php_win32_globals.h My guess is that I need to compile globals.c with ZTS defined. I haven't found which project that's in yet. Any suggestions would be greatly appreciated? Thanks! Terry -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Build issues with Mac OSX 10.4
--- "D. Walsh" <[EMAIL PROTECTED]> wrote: > I've been trying to build PHP in Mac OS X Server > 10.4.0 > > The OS is a fresh install with the appropriate > graphic libs installed > > It fails to configure with the switch '--with-gd' > citing the > following error. Hmm... I was able to configure and make 5.0.4 with GD without problems. What version of PHP are you building? Can you provide the entire ./configure line? Have you installed the new version of Xcode from the 10.4 DVD? - Gabriel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: ilovephp
I'm testing the cvs account request system to make sure it works, because someone insists it's not. Ignore me. --philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: yuanyuqiang
VCS Account Approved: yuanyuqiang approved by tyrael \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: hywan
VCS Account Approved: hywan approved by tyrael \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: bdrsuh
VCS Account Rejected: bdrsuh rejected by rasmus /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: jslingerland
VCS Account Rejected: jslingerland rejected by bjori /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: joelm
VCS Account Approved: joelm approved by bjori \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: fredemmott
VCS Account Approved: fredemmott approved by bjori \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: drew
VCS Account Approved: drew approved by bjori \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: eliw
VCS Account Approved: eliw approved by bjori \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: cpusavage5150
VCS Account Rejected: cpusavage5150 rejected by rasmus /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: demo
VCS Account Rejected: demo rejected by rasmus /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: kalesi
VCS Account Rejected: kalesi rejected by rasmus /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: royopa
VCS Account Rejected: royopa rejected by rasmus /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: nishantcbse
VCS Account Rejected: nishantcbse rejected by rasmus /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: hehexianshi
VCS Account Rejected: hehexianshi rejected by rasmus /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: fmargaine
VCS Account Approved: fmargaine approved by tyrael \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: leigh
VCS Account Approved: leigh approved by tyrael \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: hellosys
VCS Account Rejected: hellosys rejected by bjori /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: covibe
VCS Account Rejected: covibe rejected by bjori /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: itsmedinesh31
VCS Account Rejected: itsmedinesh31 rejected by bjori /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: jacob
VCS Account Approved: jacob approved by bjori \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Rejected: dr0id rejected by bjori
Nuked dr0id -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Rejected: nickl rejected by rasmus
Nuked nickl -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Rejected: sajith rejected by bjori
Nuked sajith -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Rejected: demoking8 rejected by bjori
Nuked demoking8 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Rejected: heavenfactory rejected by bjori
Nuked heavenfactory -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: ardbiesheuvel
rasmus approved ardbiesheuvel account request \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: cpriest
rasmus approved cpriest account request \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Approved: tyraeltest10 approved by bjori
Approved tyraeltest10 \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Rejected: tyraeltest10 rejected by bjori
Nuked tyraeltest10 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] echo new SplFileObject(__FILE__);
This feels like a bug to me. Why would SplFileObject::__toString return the current line while SplFileInfo::__toString returns file path? On Tue, Jan 29, 2013 at 5:51 PM, Ferenc Kovacs wrote: > On Tue, Jan 29, 2013 at 11:29 PM, hakre wrote: > > > Can somebody shed some light why: > > > > > > > echo new SplFileObject(__FILE__); > > > > returns the first line of the file (in that case ` > > > SplFileInfo has the path and SplFileObject extends from it but it will > > return the current line. I do not really understand why and I tend to > > report this as a bug but I'm not sure. > > > > > > --hakre > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > SplFileObject->__toString() is an alias for current() which will return the > current line of file > http://lxr.php.net/xref/PHP_5_3/ext/spl/spl_directory.c#2954 > http://www.php.net/manual/en/splfileobject.tostring.php > it seems that the class synopsis at > http://www.php.net/manual/en/class.splfileobject.php is missing this > method > so it is easy to think that it isn't provided by the SplFileObject so the > parent't method will be used, which isn't the case. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu >
[PHP-DEV] Re: VCS Account Request: alejosimon
VCS Account Rejected: alejosimon rejected by rasmus /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: gabrielwu84
VCS Account Approved: gabrielwu84 approved by rasmus \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: mschuster91
VCS Account Approved: mschuster91 approved by rasmus \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: mschuster91
VCS Account Deleted: mschuster91 deleted by rasmus /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: marco
VCS Account Approved: marco approved by rasmus \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: dlsniper
VCS Account Approved: dlsniper approved by rasmus \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: mehdone
VCS Account Rejected: mehdone rejected by bjori /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: sverbeek
VCS Account Rejected: sverbeek rejected by bjori /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: rajivgadda
VCS Account Rejected: rajivgadda rejected by bjori /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: jas
VCS Account Approved: jas approved by pajoye \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: baronth
VCS Account Rejected: baronth rejected by rasmus /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: jenkins
VCS Account Rejected: jenkins rejected by rasmus /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: kaplan
VCS Account Approved: kaplan approved by rasmus \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: requinix
VCS Account Approved: requinix approved by bjori \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Help w/ Parser
I'm having trouble getting some changes to the parser to recognize some new
syntax. I've attached a patch of what I've done.
Here is the syntax I am trying to get to be parsed properly:
Seconds = $Seconds;
}
// Getters/Setters
public $Hours {
get { return $this->Seconds / 3600; }
set { $this->Seconds = $value * 3600; } // The variable $value
holds the incoming value to be "set"
}
};
?>
After compiling and attempting to execute the above PHP file, I'm getting
this parse error:
Parse error: syntax error, unexpected 'get' (T_STRING), expecting get
(T_GET) or set (T_SET) in /mnt/hgfs/svn/php-src-test/test.php on line 13
Why is the parse recognizing the 'get' as T_STRING rather than get (T_GET)?
Thanks,
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: marcio
VCS Account Rejected: marcio rejected by tyrael /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: marcio
VCS Account Approved: marcio approved by tyrael \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: edgarsandi
VCS Account Rejected: edgarsandi rejected by rasmus /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: ericmann
VCS Account Approved: ericmann approved by kalle \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: shivam
VCS Account Approved: shivam approved by derick \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: saki
VCS Account Approved: saki approved by derick \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Mitigate “Magellan vulnerabilitites” in PHP 7.2?
Thanks Christoph!
Just to be clear, this patch doesn't prevent security issues if you
don't update your SQLite3 library, it just implements a new option
available in newer SQLite versions which will prevent arbitrary changes
to the internals of a SQLite database only if you SQLite3 library is
3.26+. Changing the internals of a SQLite database is something that
should be quite rare in the real world I think.
This addresses potential security issues for PHP applications allowing
end-users to run arbitrary SQL queries.
But please note that if your application does allow end-users to run
arbitrary SQL queries, I advise that you limit them to read-only by
either:
* opening the database as readonly (available in PDO since PHP 7.3: use
open attribute: PDO::SQLITE_ATTR_OPEN_FLAGS => PDO::SQLITE_READONLY)
* using the SQLite3Stmt::readOnly method (will tell you if a prepared
statement will write to the database)
* or using the equivalent for PDO:
$st = $pdo->prepare('SELECT * FROM table;');
var_dump($st->getAttribute(PDO::SQLITE_ATTR_READONLY_STATEMENT));
This last one should be available in PHP 7.4 I hope? See
https://github.com/php/php-src/pull/2760
Both PDO features are currently undocumented but it's on my TODO list as
well.
If your users are performing custom SELECT queries, this is the best
thing to do.
I am now working on bringing support for a userland custom callback to
the SQLite3 authorizer API, this will allow PHP code to restrict access
to specific tables, columns and operations, that should also improve
security in the future.
As a side note, although my time is quite limited, I have worked for the
last two years to improve features support and security of the SQLite3
extension and try to match features of the SQLite3 extension in PDO as
well.
I have to give a warm thank you to Christoph and everyone else who
helped me in this :)
And if anyone is interested in helping me improve SQLite support in PHP
you are more than welcome :)
Cheers.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: sjon
VCS Account Approved: sjon approved by salathe \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] open_basedir?
Kia ora, I'm against deprecating it or removing it. As said earlier, it has some security value, especially with mass hosting. If I'm hosting thousands of websites for thousands of users, using chroot is not doable, and open_basedir is a good alternative (at least it's better than nothing). That's why it's used by ISPconfig and other panels: there is no other solution that I know of. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: profforg
VCS Account Rejected: profforg rejected by rasmus /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: mgage
VCS Account Rejected: mgage rejected by rasmus /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
