Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend.h zend_ptr_stack.h zend_types.h zend_vm_def.h zend_vm_execute.h
[email protected] ("Nuno Lopes") Fri, 5 Jun 2009 19:57:39 +0100
| Newsgroups | php.zend-engine.cvs |
|---|---|
| Message-ID | <DF20C65D29944A40949411D486A1EA7A@PC3EE1F19287> |
> On Wed, 2009-06-03 at 22:11 +0100, Nuno Lopes wrote: >> >> So I'm not particularly happy this solution. First it relies on gcc: >> >> the >> >> code is still broken for other compilers following C99 strict aliasing >> >> rules. >> >> Second you're using may_alias and restrict at the same time, which >> >> have >> >> opposite meanings. They refer to different pointers, but it's still >> >> confusing. >> > >> > may_alias means a particular type can alias any other type (like char >> > does) >> > restrict means a particular variable cannot be accessed through other >> > variables in the current scope/block. >> > >> > So I used restrict to cancel the performance effect of may_alias on the >> > function's code. >> >> exactly my point: it's very confusing :) >> The interplay of two variables with these two attributes is also tricky. >> >> >> >> As these functions are only called from 2 sites, I think fixing the >> >> function >> >> signature to the right types is the right solution. >> > >> > I agree, however there is some other potential problems that may need >> > to >> > be fixed, and which will not be fixable in this way. >> >> like what? I haven't checked the code, but what are the other potential >> problems? >> >> >> > So this fix is an attempt to do something generic and useable for other >> > cases. I found this solution not too bad as this is still a pointer >> > type >> > which can be assigned to (as opposed to using a char type), and it is >> > compatible with the original type. >> > >> > As you pointed, may_alias is gcc-specific, but is there other compiler >> > with this level of strictness without such attribute ? >> >> I don't know. I know that at least ICC and suncc have strict aliasing >> analysis, but I dunno what's their support for these attributes (or if >> they >> will be detected as gcc by the configure script). >> > > You are right, thanks for having reviewed this. I have reverted this to > something simpler/better. Thank you! Nuno