On 26/02/12 05:11, Arvids Godjuks wrote:
Kris Craig
I usually just read the list, sometimes add if I have something to say and
I had voiced my opinion on typehinting before. And you know, just from the
stand of a userland developer who has 7-8 years of experience and devoting
myself to the
I just realised that if it were going to add magic casting, it could as well
be done with a spl_autocast_register(), so that you could either cast things
when they match, throw an exception, etc. (there should be some default
value dynamic typing, so the perfomance wouldn't hurt) .
I don't think
On 27/02/12 16:12, Richard Lynch wrote:
Oh, and string is a reserved word, so this won't work as-is, though
that's obviously picuyane.
It's not, you can perfectly define your own class called 'string'. I'd
be much easier if it were, though.
--
PHP Internals - PHP Runtime Development Mailing
On 27/02/12 01:33, Kris Craig wrote:
Exactly, hence why I'm still on the fence with that. I was hoping for some
further discussion though to see if anyone can think of a way around that,
though admittedly nothing comes to my mind.
--Kris
That's why I mentioned the possibility of having such
On 27/02/12 02:44, John Crenshaw wrote:
If we can agree on some basic terminology I think it would move things
forward considerably. I propose these terms:
- Strict Typing means the super strict old C style typing that has been
proven to be ridiculous in this environment because of the
On 27/02/12 17:19, Richard Lynch wrote:
PRESUMPTION:
*ANY* strict datatype could also be NULL, to represent a failure
condition...
Otherwise, when you are out of RAM:
strict $o = new Object(); //violates strict, because Object HAS to be
NULL, as there is no RAM left for it to be an object.
On 27/02/12 16:47, Paul Dragoonis wrote:
2012/2/27 Johannes Schlüter johan...@schlueters.de
Hi,
PHP is no strickt-typed language. Changing this is a massive change, if
you want to go there: There are plenty of other languages.
If you want this to be an optional feature:
a) It's not
On 27/02/12 20:05, Richard Lynch wrote:
You are correct.
I'd have to come up with some OTHER scenario not involving fatal
error, such as:
strict $db = new DB();
and your database being down, unavailable, or connection parameters
being wrong.
The principle remains.
You probably still
On 27/02/12 19:22, Richard Lynch wrote:
I'm not so sure about that. In a well-written web application, you
would
typically convert them on the first layer, when receiving from the
web.
On next usages, your int variables are usually ints already.
Afraid not.
It turns out that PHP, on 32-bit
On 27/02/12 22:52, Anthony Ferrara wrote:
Ferenc,
Thanks for the comments!
Thanks from me, too.
And thanks to you, Anthony if you get to summarise that.
There were ideas, but they didn't have enough traction.
IMO we can't have a proper solution without changing the existing behavior
for
Kris, go out for a walk. We don't need fake
stress after the real one :)
Yes, it's midnight here, but who cares?
That you are afraid of going out at night? Because
you had a bad experience with a serial killer?
Oh, well...
PS: This is what I called 'sane weak typing' in the other
thread before
On 02/03/12 01:00, Simon Schick wrote:
Hi, all
When will the documentation be ready?
For example you wrote that something has changed to the keywords *continue
*and
*break *- but I dont get what and it's not defined in here:
http://www.php.net/manual/en/control-structures.continue.php
On 02/03/12 02:56, Philip Olson wrote:
Hello!
Please clarify whether or not get_magic_quotes_gpc() and
get_magic_quotes_runtime()
are deprecated, because I do not think they are. Deprecated means people
should not
use them while writing new code, but they are perfectly sensible
On 06/03/12 14:04, Adam Jon Richardson wrote:
The sandbox I'm considering would only impact the ability to directly call
internal functions. The idea rests on the hope that the framework or CMS
provides a security model that protects the integrity of their own
environment. The framework can
On 06/03/12 17:08, Alan Knowles wrote:
I just got caught on a production server with the 5.4 upgrade on
debian, pretty much everything works fine, except the E_ALL change.
I have to admit I missed the discussion where it was added, and
searching for E_ALL or E_STRICT on marc is pretty
On 06/03/12 19:36, Kris Craig wrote:
nitpicking mode=on
FIRST:
do NOT top post after get a reply below your text
or how do you imagine that anybody can follow a
thread where answers randomly before and after
the quotet text?
Sorry. Sometimes I forget that there are some people out there
On 06/03/12 15:45, Michael Morris wrote:
I have made a wiki account with user name MichaelMorris - I don't
think I have permissions to submit an RFC as of yet. I'll post this
here for now. I've brought this up before, but can now simplify the
original proposal since the decision to always
On 06/03/12 23:08, Michael Morris wrote:
2012/3/6 Ángel González keis...@gmail.com:
Tagless files interpreted as php is the wrong way to go.
I think you should instead propose it as:
* A file included in that mode MUST begin with ?php.
* ? is forbidden in such mode unless followed by EOF
On 07/03/12 00:04, Adam Jon Richardson wrote:
It would be the responsibility of the framework or CMS or application
to protect against this type of attack (which they do quite well.)
When you can force a plugin to work through your API, you can take
appropriate measures. When the plugin can
El 07/03/12 00:15, Kris Craig wrote:
To clarify again, I was under the mistaken impression that ?=
was a new
alias for short_open_tag. My argument was (and still is) against
short_open_tag. I do see some use in this new echo alias for
templating
purposes.
On 09/03/12 02:05, Adam Harvey wrote:
On 9 March 2012 00:11, Remi Collet r...@fedoraproject.org wrote:
Le 08/03/2012 09:03, Michael Wallner a écrit :
Sorry for the delay, but I already explained the issue in
the bug report: https://bugs.php.net/bug.php?id=61291
Thanks, for the explanation.
On 11/03/12 22:55, Michael Wallner wrote:
wat?
The new hashes are correct. I'm awfully sorry that there has been so much
trouble with the tiger hashes, but it happened and cannot be undone.
Whops, sorry. I got confused on this thread.
Change the order of what I said, then. Let the correct
On 12/03/12 20:51, Stas Malyshev wrote:
Hi!
But you can't necessarily hardcode the encoding if you are writing
portable code. That's a bit like hardcoding a timezone. In order to
write portable code you need to give people the ability to localize it.
No, it's not like timezone at all. I
On 12/03/12 20:36, Richard Lynch wrote:
On Sun, March 11, 2012 6:29 pm, Stas Malyshev wrote:
This doesn't look good. Documentation does say the @ prefix exists,
but
it has very high potential of creating security holes for unsuspecting
people. open_basedir would help limit the impact, but
On 12/03/12 22:30, Stas Malyshev wrote:
Hi!
If you are a framework developer, and really want to shield against a
bad php.ini setting, you could ini_set() to your prefered charset at the
beginning of the request.
That assuming the request is completely processed by your framework
and you
On 14/03/12 20:42, Rasmus Lerdorf wrote:
It is somewhat unintuitive that parse_str() is subject to the
max_input_vars limitation and there are sites that use parse_str() to
parse things that aren't directly coming from user query args.
There arr two ways to solve this. We could add an optional
On 13/03/12 00:25, Stas Malyshev wrote:
Hi!
Still, that API is likely wrong: a library function written by someone
completely unrelated to the main application shouldn't be echoing
anything through the output. And if it's not generating the html, the
htmlspecialchars is better done from the
On 16/03/12 18:45, Lütfi Altın wrote:
I want to read PHP source and help PHP for further development.
You don't need a svn account to read the php source. You can just
download the source from http://php.net/downloads.php#v5 view the
development version at
On 18/03/12 06:56, Tjerk Anne Meesters wrote:
On Sun, Mar 18, 2012 at 8:12 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Obvious solution would be to use a salt for the hash, which prevents blind
pre-computing of hash collisions. However, due to the fact that PHP hash
values can be reused in
El 20/03/12 21:45, David Soria Parra escribió:
On 03/20/2012 09:48 PM, Ángel González wrote:
El 19/03/12 21:29, David Soria Parra escribió:
On 2012-03-19, Kris Craig kris.cr...@gmail.com wrote:
The workflow page currently recommends the git: one for
cloning (which doesn't work for me
El 19/03/12 21:29, David Soria Parra escribió:
On 2012-03-19, Kris Craig kris.cr...@gmail.com wrote:
The workflow page currently recommends the git: one for cloning (which
doesn't work for me, either).
git:// is recommended when you can use it. The access is limited due to
port limiations,
On 01/04/12 14:19, Florian Anderiasch wrote:
I'd appreciate any hints on how to tackle this serious concern.
You should launch a new thread to tackle them. You could then buy
foreign slaves to schedule them on their cores.
Btw, in the spirit of x for hex and b for binary I thought about using
On 07/04/12 16:06, Reindl Harald wrote:
Am 07.04.2012 16:00, schrieb Tom Boutell:
That's a good point too.
I think this is a better proposal:
include_code, require_code, and require_code_once would work just like
include, require and require_once, except that the parser would start
out in
On 07/04/12 17:22, John Bafford wrote:
On Apr 7, 2012, at 10:53, John Crenshaw wrote:
What if you have just ONE function with a variety of options? Something like:
execute_file('path/to/foo.php', array(
'require'=true,
'once'=true,
'begin_code'='?php ',
On 07/04/12 16:56, John Bafford wrote:
On Apr 7, 2012, at 10:00, Tom Boutell wrote:
.phpc is then just a convention for naming PHP files that start out
with code - a convention that autoloaders should respect, just as they
now respect the .php convention. The user asked for the Monkey class,
On 07/04/12 19:29, Rasmus Lerdorf wrote:
On 04/07/2012 10:23 AM, Ángel González wrote:
And I like the idea of providing a function for auto escaping ?= echos.
Turn on your default input filter and all data that comes from the user
will automatically be escaped.
-Rasmus
I'm not interested
On 07/04/12 22:48, Yasuo Ohgaki wrote:
Hi,
The only valid reason for removing ?php from PHP script would be
security.
Since the null byte detection for fopen, remote/local script inclusion
became much harder than before. However, it's still possible and very
easy compare to other
2012/4/8, Yasuo Ohgaki:
2012/4/8 Ángel González keis...@gmail.com:
How does it help security?
If any, requiring '?php' before executable code makes easier to filter
out malicious files on apps with uploads in case there's a local
inclusion vulnerability somewhere.
Attackers may inject PHP
On 08/04/12 14:31, Tom Boutell wrote:
This is an attempt to protect people who have written inherently insecure
code anyway. One should never do a dynamic require to any untrusted location,
if ever at all, yes?
Obviously. But that include vulnerabilty seems a precondition to the
scenario
On 09/04/12 13:29, Tom Boutell wrote:
I would like to clarify what this RFC actually says. Let's try to keep
this thread to the pros and cons of this specific proposal.
The following new keyword would be introduced:
require_path
I don't like the keyword name. Too confusing with the
On 09/04/12 20:23, Chris Stockton wrote:
Hello,
Although I am not very interested in this feature, if it is
implemented I like the idea of flags instead of introducing new
keywords. Maintaining backwards compatibility would be great
considering the benefit to the feature to be completely
On 09/04/12 19:36, Luke Scott wrote:
On Apr 9, 2012, at 10:23 AM, Tom Boutell t...@punkave.com wrote:
Also, your objection - that 'require_code' is confusing - would most
likely be an issue for a handful of people who write autoloaders.
Those clean PHP class files are almost always autoloaded.
On 09/04/12 21:17, Yasuo Ohgaki wrote:
Please do not tell me that programmer should
learn not to, since it's not a protection but education.
Hire a more competent programmer? If he writes such code,
he will be completely unaware of the subtleties of XSS, or how
SQL should be escaped, and his
On 24/04/12 18:11, Paul Dragoonis wrote:
Happy to patch this once someone confirms this is a bug and not
changed behaviour in 5.4.
- Paul.
Why would such behavior change be desired?
get_magic_quotes_gpc() is kept only for compatibility with scripts which
did magic quote detection.
As such, it
On 05/05/12 20:08, Sanford Whiteman wrote:
This presupposes that your users don't expect embedded metadata to be
preserved when people redownload the images.
Not only do photo professionals/hobbyists expect you to keep the
metadata, you also should leave it in for reasons of legality. Hosting
On 06/06/12 12:20, Ivan Enderlin @ Hoa wrote:
On 05/06/12 19:35, Nikita Popov wrote:
Hi internals!
Hi Nikita,
Before going any further I'd like to get some comments about what you
think of adding generator support to PHP.
I have always hoped to see the “yield” keywork introduced in PHP.
Me
On 11/06/12 23:12, Tom Boutell wrote:
Can you really use setjmp and longjmp in that way safely? I thought it
was only safe to longjmp back, not forward - you can use them to
fake exception support but that's it because you'll smash the stack
otherwise. Something like that...
My first reaction
On 14/06/12 16:26, Peter Lind wrote:
I would say it really depends upon the project. The salt can not only
protect against rainbow tables and password hash collisions, if it is
unknown to an attacker then it essentially acts to further strengthen
the hash by vastly expanding the keyspace.
On 13/06/12 05:26, Morgan L. Owens wrote:
After reading the performance improvements RFC about interned strings,
and its passing mention of a special data structure (e.g.
zend_string) instead of char*, I've been thinking a little bit about
this and what such a structure could be.
But rather
On 14/06/12 00:58, Michael Felt wrote:
Hi.
I am trying to compile php against httpd 2.4.2 - but before it gets
interesting I think I am having a different problem.
The sqlite3 embedded in ./ext/sqlite3 returns a syntax error against vac.C
v11 compiler.
On 16/06/12 15:39, Pierre Joye wrote:
However the point here is not the implementation but the APIs.
To be honest I am not a big fan of providing such an API in the core
as no matter the default implementation, it will become obsolete soon
or later. And changing the default brings its lot of
On 18/06/12 18:54, Anthony Ferrara wrote:
Pierre,
There is sadly only state-of-art-right-now password hashing methods.
We have to keep that in mind :)
That's why the crypt() return format was designed. All of the options
that are needed to validate the hash (algorithm, cost parameter, salt,
On 27/06/12 18:13, Pierre Joye wrote:
Changing default value forces code change if you have to keep a given
hash, for one obvious side effect.
If you disagree or does not like the idea, that's all fine, but you
can't really say that it is not an argument (nothing to justify, this
is a draft
On 29/06/12 14:43, Nikita Popov wrote:
Hi internals!
Anthony and me have been looking a lot at the crypt() code recently
and noticed that there are some strange things going on in the buffer
allocations for the sha algorithms.
We did two commits to fix them up a bit:
On 03/07/12 18:21, Anthony Ferrara wrote:
2) I'd like to be able to check wether a stored password uses an outdated
algorithm and update the hash in that case. For that I'd need either a
function to extract the salt from a hash to pass it to password_hash() and
compare the result with the old
On 12/07/12 17:30, Johannes Schlüter wrote:
Hi,
On Thu, 2012-07-12 at 17:09 +0200, Jille Timmermans wrote:
An implementation is quite simple:
https://github.com/Jille/php-src/commit/31a1aa384c29487e077ccf3fd067eca188cf1201
Without looking at the functional change itself a comment: The patch
Jérôme Loyet wrote:
Hi guys,
I'm sure when FPM should call extensions MINIT and MSHUTDOWN functions.
MINIT is called once by the master process after it forks any
children. It's done by calling php_module_startup() in
cgi_sapi_module.startup().
MSHUTDOWN is also called by the master
Derick Rethans wrote:
On Sat, 27 Nov 2010, Johannes Schlüter wrote:
RFC: http://wiki.php.net/rfc/optional-t-function
Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff
I'm -1 on this one. Besides this being confusing for people who want to
run newer code on older PHP
Dallas Gutauckis wrote:
Just to be clear, this works on the assumption that we don't know the class
name that the function resides in?
I understand the search argument, but to me it only applies to functions,
not methods. Is anyone arguing for removing the T_FUNCTION requirement on
Richard Quadling wrote:
I'd really like this feature to be part of PHP.
I don't particularly like the use of what looks like a closure for the
set/get.
I used to code in Delphi and I always like the way in which their
properties were defined.
Essentially, the setter and getter are normal
Richard Quadling wrote:
As for reading $seconds directly ...
Well.
If you think of the element that follows read as $this-, then if
the parser can handle both ...
read $seconds
read getSeconds
then yes for both.
If not, then I'd guess that the getSeconds version should be the one
Richard Quadling wrote:
(I assume the variable has to be part of the current class or one of its
parents?)
Yes. I don't think it makes sense to have a class property actually read
a global.
If a project really need it (eg. some migration from procedural style to
classes), then
use the verbose
presid...@basnetworks.net wrote:
I feel that the downfall of this syntax, is that the get and set methods
can easily be scattered at either end of a class definition. With the
syntaxes I provided, it is easy to tell which of the methods a property
has defined at a quick glance, because
Andrey Hristov wrote:
I am not against global variables, I'm against usage of $GLOBALS and
global.
So how do you support global variables by banning the two ways they can
be accessed?
-1
From a Framework point of view, they should save all of the
(super)global variables from the global
Andrey Hristov wrote:
Ángel González wrote:
So how do you support global variables by banning the two ways they can
be accessed?
very easy, by using them by name. Global variables are those outside
of a classes, methods and functions.
If they can only be used outside functions they would
On Thu, Dec 9, 2010 at 11:42, Michael Shadle wrote:
Not to mention, I have had issues (and I can't reproduce it properly
or I would report it) where sometimes i will have a variable in global
scope in one file, and I have to reference it as $GLOBALS['variable']
in another include, or I have
Gustavo Lopes wrote:
I know you're responding to Pierre's proposed addition of a way to
disable POST data handling altogether possibly via an ini option, but
since the objection also applies to the ini option I've added to
trunk, I'd like to address it.
Yes, it sucks that the option cannot
Gustavo Lopes wrote:
I've committed to trunk the patch with the name of the ini option changed
from disable_post_data_processing to enable_post_data_reading.
Pierre Joye wrote:
hi,
The more I look at this option the more I think it is confusing. I'm
not sure the gain is worth this
Have you taken a look at Runkit_Sandbox? It may provide useful tips.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 19/01/11 23:10, Sam Vilain wrote:
On 20/01/11 10:17, Ángel González wrote:
Have you taken a look at Runkit_Sandbox? It may provide useful tips.
*headdesk*
No, I hadn't seen that. Thanks for pointing this out, it looks like
exactly what I was trying to reinvent...
Cheers,
Sam.
You may
Moriyoshi Koizumi wrote:
Hi,
Just to let you know that I wrote a RFC about built-in web server
feature with which PHP can serve contents without a help of web
servers. That would be handy for development purpose.
If interested, have a look at http://wiki.php.net/rfc/builtinwebserver .
Stas Malyshev wrote:
Hi!
http://volnitsky.com/project/str_search/
I'm not sure it'd be easy to integrate this into PHP codebase as-is,
provided it relies on C++ standard libraries which PHP makes no use of
(and thus potentially introduces a world of dependencies and
complexities into the
Moriyoshi Koizumi wrote:
Regarding the patch (https://gist.github.com/835698):
I don't see a switch to disable the internal parse on configure.
I don't see any obvious reason it should be able to be turned off
through the build option. The only problem is binary size increase,
which I guess
Olivier Hoareau wrote:
I don't think that people are gonna like that kind of approach, having two
binaries with one of them coming from custom source should raise some
concerns and you won't like the prospects of maintaining PHP for older
Debian/Ubuntu versions.
My users currently does not
Alec wrote:
I actually wrote that. I never imagined someone would actually find
that useful!
If you don't mind having a few external dlls, you can use dl (ick!) to
load the extensions.
I gave up supporting that because compiling the custom lightweight
stubs took more work than I cared for.
Sanford Whiteman wrote:
Same here.
Here's my take:
[1] I don't like ?? / ? because it is disjunctive with === / ==.. The
extra equals sign strengthens equality comparison, while the extra
question mark essentially _weakens_ the ternary operator (making it
more forgiving). (Sure, a
Ben Schmidt wrote:
$var = $arr['key'] ?? : 'empty';
Also note this is possible with the recent proposal Hannes and I were
discussing. It simply looks like
$var = $arr?['key'] ?: 'empty';
The ?[ avoids notices and the ?: works as it always has.
Ben.
If it was going to be ?[, I'd much
reeze wrote:
Hi,
I am not sure it's the right place to discuss this. someday I found I call a
static method _instancely_.
the method is just a helper method when reviewing my code. I know I do the
wrong thing, but PHP doesn't
complain about it. then I do some tests like below:
A few
Lars Schultz wrote:
Hi internals,
Jani told me to ask the list about this. I tried commenting on the bug
but I guess since it's closed, no one cares about it anymore.
http://bugs.php.net/bug.php?id=49189
This Change prevents us to move to anything beyond this bugfix with
our codebase and
Pascal COURTOIS wrote:
Hi,
Is there any way that a variable can be changed within a function without
passing it by reference ?
I have a code like that:
function myfunction($var)
{
some code
print_r($var); = prints $var which is an object
anotherfunction($var); // call by value
Derick Rethans wrote:
Raise E_DEPRECATED when running the CGI or any web server SAPI and a
php.ini file does not contain “magic_quotes_gpc = Off”.
and
Raise E_ERROR when running the CGI or any web server SAPI and a php.ini
file does not contain “magic_quotes_gpc = Off”.
Doesn't that mean that
Marc Bennewitz wrote:
Idea for an RFC for a more powerful (and backward compatible) API of
random number generator functions.
The following psaudocode is self explained (hopfully)
const RAND_ALGO_LIBC
const RAND_ALGO_MERSENNE_TWISTER
const RAND_ALGO_OPENSSL
const RAND_ALGO_GMP
(...)
What do
On 13/09/13 22:10, Lazy wrote:
Hello internals,
I'm trying to fix deadlock in an ancient php 5.2.17, php hangs on
internal libc lock.
From my understanding free is not safe to use in a signal handler, and
this seems to be the issue here.
No, it's not.
On 16/09/13 15:58, Daniel Lowrey wrote:
More generally, PHP's stream encryption aspects are quite poorly
documented. For example, https:// streams disable peer verification by
default. While I understand that this is necessary to provide the easiest
possible user experience for things like
On 19/09/13 23:41, Adam Harvey wrote:
As for the CA bundle side of things, I wonder if this is one of those
rare times where an ini setting might make sense, as opposed to actual
bundling — that would allow distros to point to their packaged bundles
without needing to patch php-src, and we could
Anatol Belski wrote:
Hi,
this is a long spoken topic which is now embodied in
https://wiki.php.net/rfc/native-tls . A preliminary implementation is
there as well, thus we can discuss it.
Regards
Anatol
Great!
I remember myself already wondering about that years ago.
+1
--
PHP Internals -
On 03/12/14 10:22, Anatol Belski wrote:
I meant that as well, to the time it's merged all the TSRMLS_* thingies
should be removed. I kept them only while developed and now for the RFC so
the diff shows the only change done, otherwise it would sink in the
unrelevant stuff.
Therefore I'd rather
On 11/12/14 20:44, Leigh wrote:
I actually think a generic random bytes function outside of any
cryptographic extensions would be a good idea. Even mcrypt seems like
overkill if all you want is random strings.
mcrypt_create_iv should be left as an alias to that function, even if no mcrypt
I wonder how many people use ternary operators in an associative context.
My suspicion is that little of those that do really intend PHP
associativity.
But it'd need quite a parser to detect the affected usage.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
No objections here either.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 30/04/15 00:41, Christoph Becker wrote:
Hi everybody!
I've noticed that the Reserve Even More Types in PHP 7 RFC[1] has been
moved to Process and Policy with the comment needs no impl.
However, the RFC states:
| This RFC does not fully reserve them as keywords; it only prohibits
| their
On 22/06/15 23:40, Anatol Belski wrote:
Hi,
Actually I was relying on that page as well. While it would be great if 5.4
branch were blocked, as we would branch 7.0 ... disregarding were it wrong or
not, IMHO 14th September should be the date. Even if the page is wrong, the
info is public,
On 15/09/15 18:23, Anthony Ferrara wrote:
Third, it ignores context. This is related to the first two, but I
think is a separate concern. An example from the taint RFC
(https://wiki.php.net/rfc/taint) is the shell-execution. If the
variable is used in the context of command, one escape function
On 31/05/16 02:33, Sammy Kaye Powers wrote:
BOM's should not be treated as characters and should not be sent to
the output. Is there any reason this should be considered the expected
behavior? If not, I'd like to create an RFC to change it. :)
What about
«Hello Foo!
Today is » ?
If there's a
I don't think more than a direct SMTP transport will be needed (LMTP
perhaps?), but it seems a good idea that #29629 can finally be fixed.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 21/02/16 11:42, Anatol Belski wrote:
Were you putting the snippets into a file or testing on the console? I
had an issue while testing this on the console, that some chars was
partially swallowed by terminal (which was a utf-8 terminal). When
putting into a file, the output is same for both
On 19/02/16 09:20, Anatol Belski wrote:
Could you please write back, what is the out difference between those
two commands? Thanks. Anatol
In the first case, it correctly outputs «x°11» (78 c2 b0 7a). With jit
enabled it produces «x�z» (78 c2 7a). That is, it is only outputting the
lower byte
101 - 197 of 197 matches
Mail list logo
