On Aug 29, 2012, at 12:28 PM, Mark Kettenis <[email protected]> wrote:
>> Date: Wed, 29 Aug 2012 08:09:14 -0700 >> From: Alan Coopersmith <[email protected]> >> >> On 08/28/12 11:59 PM, Jeremy Sequoia wrote: >>> On 08/28/12, *Peter Hutterer * <[email protected]> wrote: >>>>> -#define __container_of(ptr, sample, member) \ >>>>> - (void *)((char *)(ptr) \ >>>>> - - ((char *)&(sample)->member - (char *)(sample))) >>>>> +#define __container_of(ptr, sample, member) \ >>>>> + container_of(ptr, typeof(*sample), member) >>>> >>>> typeof is a gcc extension/c99 and I don't think we support that yet, do we? >>> I thought we were expecting C99 nowadays. CCing Alan since I think he >>> knows the >>> answer to that and can chime in re: SunCC. >>> >>> In any event, typeof is in *a* standard whereas the previous implementation >>> is >>> undefined (and can lead to crashes on startup). I'd vote for doing >>> something >>> that is in a 13 year old standard over something that has undefined >>> behavior. >> >> Actually, as best I can tell, typeof is not in any standard, just a >> gcc extension that's been picked up by compilers that want to be gcc >> compatible. (And yes, for my sins, I do have a copy of the C11 >> standard in front of me.) >> >> If AC_C_TYPEOF works, then I'm happy with that, otherwise a little >> quick testing shows it seems to work with Sun compilers matching an >> #if test of: (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590)) >> (i.e. Studio 12.0 or later - latest release is 12.3). > > Well, AC_C_TYPEOF doesn't really work. It will define HAVE_TYPEOF if > typeof() (or an equivalent) is available. But you'll still have to > provde an alternative implementation. Yeah, see my v2. > Jeremy, did clang actually complain about __container_of() as well, or > was the change to that function just an optimization? It doesn't complain (no warning, no error). If run with -O1 or higher, it just produces code which results in a segfault when the server launches. __container_of is the cause of the segfault because __container_of is used by xorg_list_for_each_entry. I've filed a bug report about the missing warning. --Jeremy _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
