[PHP-DEV] error git push - You have insufficient Karma for gtk-src.git!
Desire to develop and update the source code of php-gtk (http://git.php.net/?p=php/gtk-src.git;a=summary0 but I can not perform a push. My karma only allows cloning. git returns error: remote: Welcome buhlerax remote: You have insufficient Karma! remote: I'm sorry, I cannot allow you to write to remote: php/gtk-src.git/README remote: Have a nice day. to g...@git.php.net:/php/gtk-src.git How do I have a karma in http://git.php.net/?p=php/gtk-src.git;a=summary allowing the creation of branch and perform push? My profile: https://people.php.net/user.php?username=buhlerax Tank you -- Alexandre Pereira Bühler Linux User: 397.546 Simão Bühler Ltda (Infobrindes) http://www.simaoebuhler.com.br alexan...@simaoebuhler.com.br Telefone: (41) 3039-5428 Infobrindes (Simão Bühler Ltda) Brindes e material promocional. http://www.infobrindes.com.br ka...@infobrindes.com.br Telefone: (41) 3082-8667 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] error git push - You have insufficient Karma for documentantion gtk.git!
I desire to maintain and update the php-gtk documentation (http://git.php.net/?p=doc/gtk.git;a=summary) but I can not perform a push. My karma only allows cloning. git returns error: remote: Welcome buhlerax remote: You have insufficient Karma! remote: I'm sorry, I cannot allow you to write to remote: doc/gtk.git/notes remote: Have a nice day. To g...@git.php.net:/doc/gtk.git How do I have a karma inhttp://git.php.net/?p=doc/gtk.git;a=summary allowing the creation of branch and perform push? My profile: https://people.php.net/user.php?username=buhlerax Tank you -- Alexandre Pereira Bühler Linux User: 397.546 Simão Bühler Ltda (Infobrindes) http://www.simaoebuhler.com.br alexan...@simaoebuhler.com.br Telefone: (41) 3039-5428 Infobrindes (Simão Bühler Ltda) Brindes e material promocional. http://www.infobrindes.com.br ka...@infobrindes.com.br Telefone: (41) 3082-8667 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Big hashes problem in master
Hi Stas, This should be fixed now. As I understood you already fixed the second problem. Thanks for catching this. Dmitry. On Mon, Jun 1, 2015 at 5:38 AM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! Looking into bug #69295 I've noticed the following problem with hashes on master: if we try to create very large hashtable, on 64-bit build (e.g. one with 112662 elements) then _zend_hash_init would set the following: ht-nTableSize = 0x8000 ht-nTableMask = 0xfffe (I'm using hex so that the numbers would be more clear). Then when we come to zend_hash_real_init_ex, we do allocation of HT_SIZE(ht). But then after this line: HT_SET_DATA_ADDR(ht, pemalloc(HT_SIZE(ht), (ht)-u.flags HASH_FLAG_PERSISTENT)); I see this: (gdb) p ht-arData $37 = (Bucket *) 0x0a00 Looks like what happened is that whet HT_HASH_SIZE was calculated, (-(int32_t)(ht)-nTableMask) was calculated as 0x8000 as signed it, and then promoted to size_t to multiply it with sizeof, which produces 0x8000. Of course, adding this to a pointer wouldn't do much good. So the next line, HT_HASH_RESET(ht); crashes because the pointer arData is broken. I think this: #define HT_HASH_SIZE(ht) \ ((uint32_t)(-(int32_t)(ht)-nTableMask) * sizeof(uint32_t)) Should fix it but would like second pair of eyes on this. There's also another problem in the code in zend_hash_real_init_ex - the initialized flag is set before the address is actually set, so if the allocation fails, the dtor may get broken array marked as initialized. This however seems to be easily fixed if flags are moved to be after allocation. -- Stas Malyshev smalys...@gmail.com
Re: [PHP-DEV] JSON unicode escape issue and new constants
Hi Yasuo,
On Mon, Jun 1, 2015 at 1:10 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Any invalid chars as variable/property name should be handled as invalid.
Valid variable name: '[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*'
http://php.net/manual/en/language.variables.basics.php
This violates JSON spec, but if user would like to allow invalid names. It
should be an option rather than the default. IMO.
[yohgaki@dev ~]$ php
?php
$o = new StdClass;
$o-{123} = 11;
var_dump($o);
?
class stdClass#1 (1) {
public $123 =
int(11)
}
[yohgaki@dev ~]$ php
?php
$o = new StdClass;
$o-123;
var_dump($o);
?
PHP Parse error: syntax error, unexpected '123' (T_LNUMBER), expecting
identifier (T_STRING) or variable (T_VARIABLE) or '{' or '$' in - on line 3
As you showed in your example, these names are not invalid, you just need
to enclose them ( $o-{123} ). This is a basic PHP thing and JSON parser
should not worry about users that don't know that.
Since JSON string must be UTF-8/16/32, any invalid UTF sequence
could be treated as invalid.
8.1. Character Encoding
JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32. The default
encoding is UTF-8, and JSON texts that are encoded in UTF-8 are
interoperable in the sense that they will be read successfully by the
maximum number of implementations; there are many implementations
that cannot successfully read texts in other encodings (such as
UTF-16 and UTF-32).
Implementations MUST NOT add a byte order mark to the beginning of a
JSON text. In the interests of interoperability, implementations
that parse JSON texts MAY ignore the presence of a byte order mark
rather than treating it as an error.
https://tools.ietf.org/html/rfc7159#section-8.1
I prefer BOM as invalid sequence and raising error/return NULL.
PHP JSON parser accepts only UTF-8 and this is already correctly validated
so I don't see any issue here either.
JSON_ERROR_UTF16 would be better defined as JSON_ERROR_UTF as
JSON accepts valid UTF sequence.
The thing is that we have already JSON_ERROR_UTF8 error that is raised when
input binary string is invalid. So the JSON_ERROR_UTF16 was meant to
distinguish these two errors. I'm happy for other ideas but not sure about
JSON_ERROR_UTF as it might be confusing with JSON_ERROR_UTF8.
It's also better to reject any invalid UTF sequence, not limited to
Unicode escaped
(\u) string. If it does not validate Unicode sequence, I would add the
validation.
The single surrogate is actually the only case when it can result in
invalid unicode string.
JSON does not forbid object property begins with digits. I'm not sure how
currently handled, but it should result in error like NULL. IMO.
As noted above: see http://3v4l.org/sJo8p
Since OWASP starts advocating Unicode escape for all names and values in
JSON, I would like to have ability to encode all chars as \u by
default.
i.e. Escape all \r, \n, a, b, c, 0, 1, 2, etc as \u by default,
disable \u
encoding as an option.
I think that we are a bit late for such change as it is a bit bigger and
also a BC break which would require RFC.
BTW, any progress on disabling automatic float conversion against float
like
values? This is mandatory, IMHO.
The RFC ( https://wiki.php.net/rfc/json_numeric_as_string ) is under
discussion:
https://www.mail-archive.com/internals@lists.php.net/msg78683.html
Cheers
Jakub
Re: [PHP-DEV] [RFC] Simplified Array API for extensions
\o/ thanks -Hannes On Fri, May 29, 2015 at 3:54 PM, Sara Golemon poll...@php.net wrote: Not thoroughly tested, but it compiles at least. Give the latest commit a shot: https://github.com/sgolemon/php-array-api/commit/1274a2bcbc3eca78dbd35702136b0034b67afc8f -Sara On Fri, May 29, 2015 at 1:25 PM, Sara Golemon poll...@php.net wrote: Ah, well that I'll probably do soonish, but as you already know, it doesn't need to be in the php-src tree to work. :) On Fri, May 29, 2015 at 12:37 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: I was hoping someone had ported that header file to PHP7 too, for easier upgrade path from PHP5 for projects already using it :] -Hannes On Fri, May 29, 2015 at 12:33 PM, Sara Golemon poll...@php.net wrote: Yeah, way too late for PHP 7.0, but on the plus side the zend hash API has changed in ways which make this facade much less necessary. Not redundant, necessarily, but the biggest pain point (getting zval** by reference) is gone (we now get zval* via return). -Sara On Fri, May 29, 2015 at 12:14 PM, Scott Arciszewski sc...@paragonie.com wrote: Naive answer: P(inclusion) = 0, due to the feature freeze. Unless I'm mistaken. If so, you might need to target 7.1 instead of 7.0. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises https://paragonie.com On Fri, May 29, 2015 at 2:56 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: What are the chances anyone updated this to support PHP7 yet? -Hannes On Mon, Aug 11, 2014 at 5:17 PM, Andrea Faulds a...@ajf.me wrote: On 12 Aug 2014, at 01:15, Tjerk Meesters tjerk.meest...@gmail.com wrote: On 12 Aug, 2014, at 5:03 am, Andrea Faulds a...@ajf.me wrote: On 11 Aug 2014, at 22:00, Hannes Magnusson hannes.magnus...@gmail.com wrote: I think it would be fantastic if this would be included in 5.6. Too late for 5.6, but 5.7 perhaps (can we please have this? 7 will break BC and I’d like to get some stuff in next year, not in 2 years). Can this API be retained as is when NG gets merged? I would hate to see developers put in effort to take advantage of this simplified API in 5.x only to have to make changes again for 7. If it can’t, I’d suggest only adding this in ng in the first place. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
