Re: Undefined variables undefined order

On Wed, Jun 10, 2015 at 7:50 AM, Sara Golemon <pollita@php.net> wrote: > On Wed, Jun 10, 2015 at 7:42 AM, Sara Golemon <pollita@php.net> wrote: >> Dmitry, what's the reasoning behind this diff in the first place? >> Doesn't the compiler fold (<const-string> . <const-string>) already >> anyhow? How would we wind up with CONCAT_CONST_CONST at runtime? >> > Derp. Looked again, and it's (const *OR* string) && (const *OR* > string). I read those as ANDs initially. > > But now I'm confused again, because that makes it look like we can > reach this with an expression like "1 . 2" 1 and 2 are consts, but not > strings, so then we get to: > > zend_string *op1_str = Z_STR_P(op1); > > Which will lead to op1_str pointing at 0x00000001 and a segfault. > > What am I missing here? > Okay, answered my own question (I need to be gentler with the [Send] button). Zend/zend_compile.c sets up an assumption: if (left_node.op_type == IS_CONST) { convert_to_string(&left_node.u.constant); } if (right_node.op_type == IS_CONST) { convert_to_string(&right_node.u.constant); } So any const nodes passed to CONCAT will always be strings (having been preconverted), and the if check using an OR make sense, because if it's CONST, then we KNOW it's a string, and there's no point testing for it. We won't ever reach CONCAT_CONST_CONST (since that would be folded in the compiler), but we might reach CONCAT_CONST_CV or CONCAT_TMPVAR_CONST or some other combination thereof for which this case is set to handle. TL;DR - Never mind me. I just didn't think it all the way through. -Sara P.S. - An assert(Z_TYPE_P(op1) == IS_STRING); and assert(Z_TYPE_P(op2) == IS_STRING); does seem reasonable though... Maybe even with a comment referencing that we can make that assumption because the compiler fixes up the types.