Merge lp://staging/~smspillaz/compiz-libcompizconfig/ccs-object into lp://staging/~compiz-team/compiz-libcompizconfig/0.9.8

I know it is common (and may be a project style) but there is no advantage to having different names to refer to the same thing in different namespaces. That is not:

    typedef struct _CCSObject CCSObject;

    struct _CCSObject
    {
    ...
    };

but:

    typedef struct CCSObject
    {
    ...
    } CCSObject;

> I know it is common (and may be a project style) but there is no advantage to
> having different names to refer to the same thing in different namespaces.
> That is not:
>
> typedef struct _CCSObject CCSObject;
>
> struct _CCSObject
> {
> ...
> };
>
> but:
>
> typedef struct CCSObject
> {
> ...
> } CCSObject;

Actually, it doesn't seem that client code should be interested in the members of [_]CCSObject, so why not a completely opaque type? Vis:

    typedef struct CCSObject CCSObject;

in the header. And move the definition to the .c file.

I don't like the style of coding in ccsObjectAddInterface() - if either realloc fails then the object is hosed. Admittedly FALSE is returned to inform the caller, but I'd prefer the object to remain viable and just the call to fail. Anything else can cause nasty surprises in client code. (Admittedly, if realloc fails there are probably worse problems to deal with.)

> I don't like the style of coding in ccsObjectAddInterface() - if either
> realloc fails then the object is hosed. Admittedly FALSE is returned to
> inform the caller, but I'd prefer the object to remain viable and just the
> call to fail. Anything else can cause nasty surprises in client code.
> (Admittedly, if realloc fails there are probably worse problems to deal with.)

Forgot to mention: the cost of calling realloc in ccsObjectRemoveInterface probably outweighs any saving of memory that results.

> > I know it is common (and may be a project style) but there is no advantage
> to
> > having different names to refer to the same thing in different namespaces.
> > That is not:
> >
> > typedef struct _CCSObject CCSObject;
> >
> > struct _CCSObject
> > {
> > ...
> > };
> >
> > but:
> >
> > typedef struct CCSObject
> > {
> > ...
> > } CCSObject;
>
> Actually, it doesn't seem that client code should be interested in the members
> of [_]CCSObject, so why not a completely opaque type? Vis:
>
> typedef struct CCSObject CCSObject;
>
> in the header. And move the definition to the .c file.

I think the struct can't be opaque because of the way that we actually access the object data (eg, casting it to a CCSObject * and accessing the data in the CCSObject in the first part of the struct).

As for realloc - I agree and had similar concerns, and will change that.

ccsObjectInit is only used by the test harness which ignores the return code, so the intended use is unclear. Surely a better return value would be a pointer to the initialised object?

ccsObjectRemoveInterface assigns pointers "interfaces" and "interface_types" to NULL without first freeing the memory referenced.

ccsObjectAddInterface assigns pointers "interfaces" and "interface_types" without first freeing the memory referenced.

struct _CCSObjectAllocationInterface (again, no need for the "_") has members realloc, malloc, calloc - these are reserved names.

Actually, talking of reserved names: names that begin with an underscore and a capital are reserved, which is another reason for not using these names in the struct namespace. (I still see no point in having different names (e.g. _CCSObject) in the struct namespace.)

The tests imply that the intended usage is to cast a pointer to some other structure (represented by "TestingObjectWrapper") to CCSObject* before passing that to ccsObjectXXX. If this is not the intended usage the tests are inappropriate. If it is intended there's negative value in these taking a pointer to the CCSObject as a parameter, they may as well take void* in the same way as ccsObjectInit does. It's a waste of the type-safety features of C.

Let me suggest a way that the client code could be eg "ccsObjectRef(to);"...
...
Bool ccsObjectRef_(CCSObject *object);
#define ccsObjectRef(obj) ccsObjectRef_(&obj->object)
...
No nasty casts, and type safe. At the cost of requiring a member named "object" of CCSObject type.

> ccsObjectInit is only used by the test harness which ignores the return code,
> so the intended use is unclear. Surely a better return value would be a
> pointer to the initialised object?

Indeed, future merges will introduce proper constructors (but this is not trivial right now).

>
> ccsObjectRemoveInterface assigns pointers "interfaces" and "interface_types"
> to NULL without first freeing the memory referenced.
>
> ccsObjectAddInterface assigns pointers "interfaces" and "interface_types"
> without first freeing the memory referenced.

They use realloc, so I don't see why this is a problem ?

>
> struct _CCSObjectAllocationInterface (again, no need for the "_") has members
> realloc, malloc, calloc - these are reserved names.

ack.

>
> Actually, talking of reserved names: names that begin with an underscore and a
> capital are reserved, which is another reason for not using these names in the
> struct namespace. (I still see no point in having different names (e.g.
> _CCSObject) in the struct namespace.)

Right, we should evaluate this elsewhere

>
> The tests imply that the intended usage is to cast a pointer to some other
> structure (represented by "TestingObjectWrapper") to CCSObject* before passing
> that to ccsObjectXXX. If this is not the intended usage the tests are
> inappropriate. If it is intended there's negative value in these taking a
> pointer to the CCSObject as a parameter, they may as well take void* in the
> same way as ccsObjectInit does. It's a waste of the type-safety features of
> C.

Right, this sucks, but we're introspecting the state of the object. Mabye we can get rid of the casts and just do to->object.foo

ccsObjectRemoveInterface_ doesn't use realloc, so it just overwrites the pointer. I think that will leak.

ccsObjectAddInterface does use realloc (I was wrongly assuming that you'd addressed the earlier discussion of invalidating the object on failed operation). Invalidating the object and returning FALSE will cause nasty surprises in client code.

Is there really value in CCSObjectAllocationInterface?

These macros can lead to surprising results in user code:

86 +#define ccsObjectRef(o) \
87 + ((o)->object).refcnt++;
88 +
89 +#define ccsObjectUnref(o, freeFunc) \
90 + ((o)->object).refcnt--; \
91 + if (!((o)->object).refcnt) \
92 + freeFunc (o)

Example of problem:

  if (false) ccsObjectUnref(o, f);

will call f(o).

Rewrite as:
86 +#define ccsObjectRef(o) \
87 + do { ((o)->object).refcnt++ } while(false)
88 +
89 +#define ccsObjectUnref(o, freeFunc) \
90 + do { ((o)->object).refcnt--; \
91 + if (!((o)->object).refcnt) \
92 + freeFunc (o) } while(false)

PS It feels awkward to require freeFunc as a parameter, but I don't have a cleaner alternative suggestion just now.

Bad example.

  if (false) ccsObjectUnref(o, f);

is OK.

But...

  if (true) ccsObjectUnref(o, f);
  else printf("surprise");

is a good example (i.e. broken).