Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80967
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.44 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <54BEE31B.3020403@lerdorf.com>
References: <54BECE9E.5050502@lerdorf.com> <54BED307.5010606@lerdorf.com>
 <54BEDABB.2040406@gmail.com> <54BEE31B.3020403@lerdorf.com>
Date: Thu, 22 Jan 2015 19:13:22 +0900
Message-ID: <CAGa2bXYzvjaZ=ORK9WCdVfSfWzOLddh2TrAViqj8X0n31V9wNQ@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c1257e6f2584050d3aee56
Subject: Re: [PHP-DEV] Re: Help - gcc mystery in ext/imap
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c1257e6f2584050d3aee56
Content-Type: text/plain; charset=UTF-8

Hi all,

On Wed, Jan 21, 2015 at 8:22 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> On 01/20/2015 02:46 PM, Stanislav Malyshev wrote:
> > 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.
>
> Yeah, I was quite surprised by the weirdness it caused. I don't think I
> have ever seen something that breaks under -O2 start working again
> compiled with -O3. That's what had me chasing my tail into assembly
> world for a bit there.
>
> I have fixed up ext/imap now. Hopefully I caught them all.


I'm observing somewhat similar behavior. I don't have clue why it does...

gcc version 4.9.2 20141101 (Red Hat 4.9.2-1) (GCC)

Should we use size_t/ptrdiff_t everywhere applicable?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c1257e6f2584050d3aee56--