Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80915
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.174 as permitted sender)
Message-ID: <54BEDABB.2040406@gmail.com>
Date: Tue, 20 Jan 2015 14:46:19 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@lerdorf.com>, 
 PHP internals <internals@lists.php.net>
References: <54BECE9E.5050502@lerdorf.com> <54BED307.5010606@lerdorf.com>
In-Reply-To: <54BED307.5010606@lerdorf.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Help - gcc mystery in ext/imap
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> So, I guess the lesson is that we need to be careful when we migrate
> extensions to PHP 7. Passing ints instead of size_t string length params
> to zpp can cause extreme weirdness and we should go through all our
> bundled extensions and make sure things that are still using "s" have
> all been changed to size_t.

Definitely so. I've recently went through intl and fixed a bunch of
int/size_t issues, but judging from how many there were, I assume other
non-trivial extensions would have such things too. We have lots of
places where size_t and int are intermixed - e.g., random try, go to
mysqli extension, do grep int *.c | grep len and see that results of
spprintf - which returns size_t - are put into int. Now, in this case
it's almost 100% not a problem, but illustrates bigger issue of mixing
the types, and in some cases it may be a real problem.
-- 
Stas Malyshev
smalyshev@gmail.com