Re: [E-devel] Improving Elementary for the release

[Youness A. <kak...@ka...>]

On Tue, Nov 8, 2011 at 9:18 AM, Gustavo Sverzut Barbieri <
bar...@pr...> wrote:

> On Mon, Nov 7, 2011 at 10:40 PM, Youness Alaoui
> <kak...@ka...> wrote:
> > 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.
>
> This is a stupid workaround used in Gtk world. With version you can do
> that and even more, you can even reorder fields, like below:
>
yes it's a workaround in gtk world, doesn't make it stupid though.
And no, you missed my point completely, you can't do that with version.


>
> if (st->version == 1) {
>    Old_St *s = (Old_St *)st;
>    code_accessing_the_old_way(s);
> } else if (st->version == 2) {
>    code_accessing_the_new_way(st);
> }
>
> In other words, you can know exactly what to do, and not just assume
> you won't break because there is enough allocated memory to access.
>

yes, that is *only* valid if you write your app after both version 1 and 2
have been released, and it means that the structure needs to be renamed
between both versions so it doesn't conflict, and mostly it means that your
version 2 breaks the API from version 1. If you read what I wrote, you'd
understand that the purpose is to release a new version without breaking
the API, without forcing every app to recompile itself or to change its
code... you cannot do that with version.



>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --------------------------------------
> MSN: bar...@gm...
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> enlightenment-devel mailing list
> enl...@li...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>