Justus Winter, le Tue 13 May 2014 12:50:54 +0200, a écrit : > Quoting Samuel Thibault (2014-05-13 01:04:13) > > Justus Winter, le Mon 12 May 2014 12:05:41 +0200, a écrit : > > > +/* An opaque type. You must not access these values directly. */ > > > +typedef uint64_t refcounts_t; > > > + > > > +/* Instead, the functions manipulating refcounts_t values write the > > > + results into this kind of objects. */ > > > +struct references { > > > + uint32_t hard; > > > + uint32_t weak; > > > +}; > > > + > > > +union _references { > > > + struct references refs; > > > + refcounts_t rc; > > > +}; > > > + > > > +/* Initialize REF with HARD and WEAK references. */ > > > +static inline void > > > +refcounts_init (refcounts_t *ref, uint32_t hard, uint32_t weak) > > > +{ > > > + ((union _references *) ref)->refs = > > > > AIUI this cast is a case of type-puning. Why not making refcounts_t the > > union itself? That way would be clearly safe with gcc's extension. > > As stated in the comment for refcounts_t, I like the idea of using the > type system to enforce the use of the accessor functions.
I understand, but type-puning will break with smart compilers. We do have had bugs like that in the past. Samuel