I disagree about SPIChar, I don't think that's a sensible solution because
clients will want/need to use other string API with the at-spi strings. 

As for SPI_true and SPI_false, again we have multiple kinds of TRUE and FALSE
already, this seems like overkill.  That said, putting SPI_TRUE and SPI_FALSE in
the spi.h header seems reasonable.

Let's consider the next 2 pieces of code:

  gchar *name = Accessible_getName (acc)
  SPI_freeString (name)

and

  AccessibleRelation **acc_relation;
  acc_relation = Accessible_getRelationSet (acc);
  for (i = 0; acc_relation[i]; i++)
    AccessibleRelation_unref (acc_relation[i]);
  g_free (acc_relation);

As it can be seen here, user has to free 2 different pointers obtained by a call
to an at-spi function by calling an at-spi function (SPI_freeString) and a glib
function (g_free).

This may be very confussing for user. Why there is not an uniform way to deal
with all kind of pointers?

There is no uniform way, because the strings (while technically the same type)
are allocated from different storage.

The g_free (acc_relation) above looks wrong to me, in fact - since the
AccessibleRelation was not allocated via g_new or malloc, the relation set
should be freed with cspi-specific API.  So we should add
AccessibleRelationSet_free to the list of prototypes/macros we need.

It's quite common for client libraries to require that clients use something
other than free() or g_free() to free data structures.  In general, it's wrong
for a client to call g_free() on anything that the client did not explicitly
g_new or g_alloc(), unless the client API documentation clearly states that the
result "should be free with g_free()".

So the right solution is for clients to make no assumptions about how to free
data structures, relying on the API docs and libraries to either provide
specific 'free' API calls, or indicate which API calls should be used to free
structures.  In cases where cspi fails to do this, we should either fix the
documentation or provide appropriate ..._free() API, or both.  Using typedefs to
hint this to the user is unnecessary and is, in its own way, cumbersome and
confusing, and can lead to errors.

My example of code is inspired from at-spi/simple-at.c file. Around line 500 is
(almost) same example of processing the returned value from
Accessible_getRelationSet function.

the relationset and string discussion above is irrelevant to the bug (which is
concerned with the boolean return types).