News for hackers. Stuff that matters.
Re:How big are PHP arrays (and values) really? by legooolas on Friday December 16, 2011 @05:03AM (#3360209)
> A union is a means to make some value accessible as various types. For example if you do a zvalue_value->lval you’ll get the value interpreted as an integer. If you use zvalue_value->ht on the other hand the value will be interpreted as a pointer to a hashtable (aka array).

This is not valid C usage of unions. They are _only_ for use as a method to save space, not for conversion between types, despite it being a very common usage of unions.

This can cause all manner of problems when compiler optimizations such as type-based alias analysis are used.

EDIT: Turns out I'm completely wrong on this and it's fine from C99 onwards.

Re:How big are PHP arrays (and values) really? by chadaustin on Friday December 16, 2011 @05:16AM (#3360240)
Actually, the upcoming C1X standard makes type punning via union legal. In C99, alias analysis works behaves exactly as you said, but using unions to convert between floats and ints is so common that it's legal in C1X, VC++, and I believe gcc.
Re:How big are PHP arrays (and values) really? by cygx on Friday December 16, 2011 @05:48AM (#3360310)
Type-punning through unions is already legal in C99, but there's a known error in Annex J, listing it incorrectly as unspecified behaviour.

See http://stackoverflow.com/a/8513748/48015

Re:How big are PHP arrays (and values) really? by legooolas on Friday December 16, 2011 @06:10AM (#3360349)
I stand corrected :/
Re:How big are PHP arrays (and values) really? by cygx on Friday December 16, 2011 @06:29AM (#3360386)
Don't feel bad about it - the C standard can be quite subtle, and I've been known to spread lies about it as well.

Things about which I have stumbled somewhat recently:

* restrict-qualified pointer-to-const parameters do not guarantee that the pointed-to object won't be modified as restrict only applies if the pointer is actually used to access the object, which calling code can't know (ie restrict only enables optimizations in the called code and not reordering in calling code)

* functions with differently qualified, but otherwise compatible parameter types have compatible type (which is only mentioned in the last, parenthesized sentence of section 6.7.5.3)

Re:How big are PHP arrays (and values) really? by legooolas on Friday December 16, 2011 @05:24AM (#3360261)
gcc does in some cases but not all (see http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options... but not all).

Still, the current standard says it's not legal so it seems like a bad idea to rely on undefined behaviour...

Re:How big are PHP arrays (and values) really? by cygx on Friday December 16, 2011 @05:55AM (#3360325)
This is not valid C usage of unions. They are _only_ for use as a method to save space, not for conversion between types

That's incorrect. The following footnote was added to section 6.5.2.3 with TC3 in 2007 to clear up this particular misconception:

"If the member used to access the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called "type punning"). This might be a trap representation."

Re:How big are PHP arrays (and values) really? by ars on Friday December 16, 2011 @05:36AM (#3360284)
PHP isn't using it for type punning, they are using it to save space. The article author was a bit unclear here.

When PHP needs to convert a type it does it properly, not through the union.

Re:How big are PHP arrays (and values) really? by jronkone on Friday December 16, 2011 @05:07AM (#3360220)
I don't see how unions could save space, care to explain?
Re:How big are PHP arrays (and values) really? by legooolas on Friday December 16, 2011 @05:08AM (#3360221)
If you have multiple items of which you're only going to store one at a time but want them in the same "structure" then you use a union. (i.e. temporally disjoint)