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
