Ok, I checked Ecore.h and I see what you mean, but that's only useful if
you break the API, the padding is useful for not breaking the API but
keeping the .so ABI-compatible.
For example, if you only add a function to the API, you add the @since in
the docs, and all the software that was linked to your .so will still work
because the other functions are the same and their behavior is the same, so
it's not an API break, but you incremented the API with a new function that
can be used by future apps.
If that new function needs a variable in the structure, then you can just
replace one of the void * paddings and that's it, it works..
If you don't have padding and you add a new field in the struct, the
sizeof(struct whatever) will change, so anything that instanciates your
structure will be allocating wrongly sized memory and that can lead to
memory corruption (since your old API will be compiled with the new
sizeof). Thus breaks the ABI and it forces every app using your library to
get recompiled (no code change, it just needs a recompile) for it to work..
this also means that your .so version will need to change, .so.1.1 instead
of .so.1.0 for example, it basically amounts to the same as breaking the
API even though it's not necessary if you had padding.
Of course, any internal structure doesn't need that, so if you allocate a
structure using a function call and the user of the lib only sees it as an
opaque struct pointer, then you don't need padding, but if the struct
itself is defined in the .h and is public, then it would need the padding
to avoid breaking the ABI/API for compatible+incremental API changes.
@Boris: technically, only one void * could be enough, but that means that
if you need 2 new fields, you'd have to create a substructure and set that
as your void *padding, and add padding in it too in case you still need to
add stuff to your substructure, and it complicates everything.. usually
you'd set 10 or 20 padding pointers or something so you can keep adding
stuff to the struct in the future.
You could also not put any padding, but just have a void *priv; at the end,
then put any additional thing in this priv pointer to a private structure,
but it will limit you in the sense that you won't be able to add new public
fields to the struct, and any additions will have to be private.
As an example, this would be impractical in the case of a MouseEvent
structure, if you wanted to add a new field to it, then it probably needs
to be public, not hidden in a private opaque structure.
What do you think ?
On Mon, Nov 7, 2011 at 4:42 PM, Boris Faure <billiob@...> wrote:
> On Mon, Nov 7, 2011 at 22:37, Youness Alaoui
> <kakaroto@...> wrote:
> > Could you explain what you mean by versioning or give me a link to
> > something that explains it ?
> > padding is useful so you can change your structure (and add new APIs)
> > without breaking the ABI and forcing every app to recompile (changed
> > sizeof).
> You should only need a spare (void *).
> Boris Faure
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> enlightenment-devel mailing list