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
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 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 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
No objections here either.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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:
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
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
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 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
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
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 08/08/13 20:56, Michael Wallner wrote:
As I have no Zend karma, is anybody kind enough to merge the bison
blacklist patch?
https://github.com/php/php-src/pull/402
Maybe it should be bison_version_exclude=none so that the error
message is nicer?
--
PHP Internals - PHP Runtime Development
On 07/08/13 13:00, Leigh wrote:
On 7 August 2013 11:18, Yasuo Ohgakiyohg...@ohgaki.net wrote:
A user requested that crypt() should raise error without 2nd(slat)
parameter.
https://bugs.php.net/bug.php?id=55036
crypt() without salt generates extremely weak password hash.
The docs seem to
On 31/03/13 23:18, ALeX wrote:
JSON and serialize() are (inherently) different serialization formats with
different use-cases [...]
Yes, and json requires that all strings (including the keys) has to be
valid utf-8, and I'm sure that's not always the case (serialize can
use binary data in
On 18/03/13 14:04, Julien Pauli wrote:
Also, AFAIR, call_user_func() doesn't work with functions using
references in args. Julien.Pauli
AFAIK it does.
Do you have an example where it doesn't?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On 15/03/13 15:19, Steve Clay wrote:
I'm sure this question has been discussed before, so if anyone can
point to me to links or briefly recap I'd appreciate it.
Why can't we make $someCallable() always work? E.g. http://3v4l.org/FLpAq
I understand the problem of $obj-foo() where -foo is a
On 12/03/13 17:30, Derick Rethans wrote:
On Tue, 12 Mar 2013, Jonathan Sundquist wrote:
Why would the result not preserve the time?
Because tomorrow starts at midnight. You want +1 day.
cheers,
Derick
Alternatively, $d-add(new DateInterval('P1D'));
--
PHP Internals - PHP Runtime
On 11/03/13 12:19, Eric James Michael Ritz wrote:
Hello everyone,
I have a question about the internals of PHP, but this is not about
advancing the development of the language, so I apologize if this is
on the wrong list. I am choosing to post to this list because I
believe the people here
On 11/03/13 12:36, Christian Stoller wrote:
Hi Stas.
I'm afraid it is not a good idea. allow_url_fopen is meant to protect
file functions (fopen and friends) from being injected with
user-controlled data - i.e. if you control the filesystem and you do
fopen() under allow_url_fopen then it is
On 15/02/13 10:25, Paul Dragoonis wrote:
On Fri, Feb 15, 2013 at 9:23 AM, Damien Tournoud d...@damz.org wrote:
On Fri, Feb 15, 2013 at 9:54 AM, Pierre Joye pierre@gmail.com wrote:
no, MediaWiki caching modules only support APC or Wincache so far.
As far as I understand, O+ doesn't have
On 05/02/13 21:16, Karoly Negyesi wrote:
new keywords is an interesting discussion to have -- it's actually the
first real thing to discuss as far as I can see. For example that is
something that version strings would tremendously help. You do not
need to maintain the whole lot of behaviors
Hans-Jürgen Petrich wrote:
Hi Terry and all
thank you very much for your response.
The only thing that confused me about what you say that the second
*doesn't* grow
Yes, about that i was [and am still :-)] also confused... why the 2nd
one won't grow *non-stop*
so I checked and it does --
On 03/02/13 16:27, Hans-Juergen Petrich wrote:
The only different in the second example is the fixed body length of
the eval()-created anoymous function.
I wondering why the memory in the second code-example will be freed at
some point while in the first example not.
I don't think it's a
On 29/01/13 15:21, Pierre Joye wrote:
On Tue, Jan 29, 2013 at 3:16 PM, Zeev Suraski z...@zend.com wrote:
On Windows with impersonation you're actually in a better situation than
you are in Linux. You could hold a small pool of processes and handle as
many different users as you'd like.
Works
On 14/01/13 05:10, Paulo Henrique Torrens wrote:
Hi,
I'm currently interested in two features I'd like to see in PHP; how do I
proceed to request/propose them? I'd be glad to help implementing them as
well, if necessary.
You should propose it here and then create a rfc about it in the php
On 18/12/12 15:43, Victor Berchet wrote:
Dear all:
I would like to get your feedback on implementing some more data
structure in the PHP core.
(...)
I think this could be summarised as allow objects as keys for arrays.
Which would give the Map behavior.
Implementing Set from that is
On 12/12/12 17:29, Amir wrote:
Hi
I searched in php.net and did not find any link that contain php none
thread safe source code for windows.
I have a php source that encoded with Zend Guard 5.5 and have to decode
with Zend Guard Loader.
note: Zend Guard Loader is NTS and didn't read TS code.
On 10/12/12 16:18, Nikita Nefedov wrote:
So there had been at least two or three messages (subjects) about
DateTime object and everytime there was this problem - people tend to
take DateTime object as mutable object and it really is.
As long as we know, it's not so good - date is immutable by
On 10/12/12 13:35, Christian Stoller wrote:
Hm... I know '$date-add(new DateInterval('P15D'));' is possible, but it has
the same problem.
I have to write:
$date = new DateTime()
$date-add(new DateInterval('P' . getDaysToAddMethod() . 'D'));
I think it is very hard to read. Or is it just
On 06/12/12 09:49, Pierre Joye wrote:
hi!
While looking at the bug #63073, I was wondering if we could simply do
not pass open handles to the newly created child process.
Looking at proc_open, where there is an explicit CreateProcess (we seem
to be using the library popen for the exec()...)
On 06/12/12 13:52, Pierre Joye wrote:
hi,
On Thu, Dec 6, 2012 at 12:40 PM, Ángel González keis...@gmail.com wrote:
On 06/12/12 09:49, Pierre Joye wrote:
hi!
While looking at the bug #63073, I was wondering if we could simply do
not pass open handles to the newly created child process
David Muir wrote:
On 29/11/12 05:09, Ángel González wrote:
I see it as simple to show E_DEPRECATED but not when installed from
PECL.
1) Add a
int mysql_extension_triggers_deprecated_warning = 1;
And use it as a conditional for triggering the warning.
2) Copy the extension code to PECL
On 29/11/12 18:17, Anthony Ferrara wrote:
Just pointing this out: that's NOT what this RFC recommends, and is
NOT what's being voted on. This RFC is talking about ONLY adding
E_DEPRECATED to core. And the way it's proposed to be done, the
moves-to-PECL couldn't happen, since it's hard-coded
I see it as simple to show E_DEPRECATED but not when installed from PECL.
1) Add a
int mysql_extension_triggers_deprecated_warning = 1;
And use it as a conditional for triggering the warning.
2) Copy the extension code to PECL
3) Add these changes in PECL
- If the mysql functions are not
On 26/11/12 22:21, Sara Golemon wrote:
https://wiki.php.net/rfc/request-tempnam
Just a bit of hand-holding for those who don't remember to clean up
their messes.
I like it.
Also note that it's not always that people “don't
remember to clean up their messes” since there are
several tricky
On 16/11/12 17:03, Rasmus Lerdorf wrote:
So, I am curious, why are you waiting on us for this? Is it because
ext/mysql does everything you need and you simply have no need for any
of the new and obviously better features in mysqli? I would have thought
you would have switched to mysqli years
On 17/11/12 17:24, Rasmus Lerdorf wrote:
Right, that is what I meant by focusing more on the carrot than the
stick. Many people, yourself included, don't realize the things they
would gain switching to mysqli. We need to do a better job with that and
perhaps even consider if there are other
Am 14/11/12 03:26, schrieb Michael Kliewe:
Am 14.11.2012 00:23, schrieb Ángel González:
So the problem really moves onto the CMS providers, do they support
new php versions and drop customers in shared hosting, do they delay
supporting the new php versions, or do they reimplement mysql_
I see several problems with deprecating ext/mysql:
- The extension is not broken. The problem is the bad usage.
It can be used safely, and good developers have been doing
so for ages, by creating php wrappers.
In magic quotes, the work has been the opposite. The developers
had been detecting the
On 17/10/12 11:43, Pierre Joye wrote:
It is about hi jacking discussions with totally irrelevant topics,
repetitive, nonconstructive posts in rows, in all possible ways.
The issue is that the proposed solution (a forum) does not solve
irrelevant topics being mixed into a discussion about a
El 18/09/12 13:30, Pádraic Brady escribió:
Hi all,
I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper.
The RFC is a proposal to implement a standardised means of escaping
data which is being output into XML/HTML.
Cross-Site Scripting remains one of the most common
On 18/09/12 21:06, Pádraic Brady wrote:
Hi Ángel,
The methods all refer to literal strings, values or digits. We can't
reasonably escape data while allowing valid markup for the current
context since that's a contradiction by its very nature. If you needed
to let user values drive CSS names,
On 25/08/12 00:50, Rasmus Lerdorf wrote:
In 8859-1 no chars are invalid so anything that doesn't get encoded will
get passed through as-is. For example the byte 0xE0 is a perfectly valid
8859-1 character (à), but if the page is actually UTF-8 then this
becomes the first byte of a 3-byte UTF-8
El 23/08/12 18:06, Rasmus Lerdorf escribió:
htmlspecialchars(), htmlentities(), html_entity_decode() and
get_html_translation_table() all take an encoding parameter that used to
default to iso-8859-1. We changed the default in PHP 5.4 to UTF-8. This
is a much more sensible default and in the
On 20/08/12 02:01, Rasmus Lerdorf wrote:
I would still like to understand what this generator keyword would
actually do. I don't see how it would work. Would a function marked
generator somehow not be allowed to return normally or to finish and not
return anything? How could this be enforced?
On 20/08/12 15:12, Nikita Popov wrote:
You could not decorate it and rely instead on the presence of the yield
keyword, but parsers will thank knowing about it from the start rather
than realising at mid-parsing that the function is a completely
different beast.
No, parsers don't care about
On 17/08/12 23:41, Sebastian Krebs wrote:
Hi,
Don't know, how complicated this is (and also someone (not me) must
implement it, because I can't :X), but to be in sync with the
operators the short ternary operator should be usable in conjunction
with the assignment like the other binary
On 03/08/12 01:22, Sara Golemon wrote:
In all seriousness, I'd love to hear how you'd do Sandboxing without
using the tsrm context hack I used in runkit. That approach had
nothing to do with being in PECL, it had to do with that being the
only mechanism available to swap globals in and out at
On 31/07/12 22:20, Peter Lind wrote:
On 31 July 2012 22:02, Anthony Ferrara ircmax...@gmail.com wrote:
Peter,
On Tue, Jul 31, 2012 at 3:46 PM, Peter Lind peter.e.l...@gmail.com wrote:
On 31 July 2012 18:21, Anthony Ferrara ircmax...@gmail.com wrote:
*snip*
Also, be aware that BCrypt only
On 01/08/12 20:02, Kris Craig wrote:
On Wed, Aug 1, 2012 at 6:13 AM, hakre hanskren...@yahoo.de wrote:
I have some simple questions about PHP 5.x End Of Life (EOL) dates:
PHP 5.0 - Is there some official news-item or changelog entry on php.netthat
says at which date PHP 5.0 went End Of
On 31/07/12 18:21, Anthony Ferrara wrote:
Jonathan,
On Tue, Jul 31, 2012 at 12:01 PM, Jonathan Bond-Caron
jbo...@openmv.comwrote:
Sure managing keys properly can be hard, simple cases:
$secret = MY_KEY;
$secret = file_get_contents('/security/key.pem');
Actually, that's not properly
On 22/07/12 04:08, Kris Craig wrote:
On Sat, Jul 21, 2012 at 3:09 AM, Andrew Faulds ajf...@googlemail.comwrote:
If you think 1.1 =/= 1.01 you're sure using some weird version numbers.
Only 1.0.1 would be smaller.
Has anyone seen these weird version ordering schemes in practise? On any
major
On 21/07/12 11:32, Pierre Joye wrote:
hi,
No, I mean version with 1.0 and not 1.0.0 are not. They are just not
correct and confusing, as you noticed.
Then Linux 2.6.39 shouldn't have been followed by Linux 3.0
For me, 1.0 and 1.0.0 are the same thing.
It's fine if x.y is not a valid
On 17/07/12 13:34, Alex Aulbach wrote:
That's more or less what I have thought.
If it's a string surrounded by square brackets, it's a character class,
else
treat as a literal list of characters.
] and - can be provided with the old trick of provide ] as first
character,
make - the first or
On 16/07/12 08:04, Galen Wright-Watson wrote:
What about an approach like PDO, where the password functions would
generate errors by default, but could be configured to throw exceptions?
The ugliest aspects of this idea are the requirement for another function
(password_set_option?) and hidden
On 16/07/12 16:21, Anthony Ferrara wrote:
If this is something that's desired, I can update the password
implementation to include this change (since it depends on a function like
this internally)...
Anthony
Looks good.
--
PHP Internals - PHP Runtime Development Mailing List
To
On 16/07/12 17:32, Alex Aulbach wrote:
I like it. I've looked in some code and found about 8
password-generation-functions. 4 of them have more or less the same
idea behind.
The rest generates more complicated password. E.g. minimum one
digit, First letter must be alphabetic. This is easy to
On 15/07/12 22:07, Alex Aulbach wrote:
2012/7/14 Andrew Faulds ajf...@googlemail.com:
Well... if people have poorly configured servers spitting out debug
info in production mode, I don't think it is our problem. It is
theirs.
Do you want to make it secure or do you want to discuss?
Seems
On 13/07/12 12:28, Ryan McCue wrote:
Somewhat off-topic, but is there a reason why not? It seems to me that
introducing a new API without using PHP's best method of error handling
(IMHO) is a little silly.
I don't really trust exception throwing near password-managing functions.
Consider the
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
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 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 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 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 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 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 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 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 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 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 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
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 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
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
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 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
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 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 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 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
1 - 100 of 197 matches
Mail list logo
