Re: [Vala] Can adding new virtual method break ABI?
>If you need to do these things manually, then what's the point in using >vala? It's the job of compilers.I got a proposed solution, please say if you >agree. First, make a new attribute called "ClassStruct" with the field virtual_methods_total, which is the total virtual methods(used + unused). This can't be decided automatically, since it doesn't know how many virtual methods the developer think of. Secondly, use a half human half machine file called by default vala_abi_doc, which keeps the position of any generated virtual method. The developer can do this manually before the compiler choose position, or let the compiler do this autocratically. The next compiler will respect the offsets that has been chose. This file of course must be shipped with the library. The first one solve the padding issue, the second solve the ordering issue. Please share your opinion, Tal Date: Sat, 17 Dec 2011 12:01:45 +0800 From: pcman...@gmail.com To: mikkel.kamst...@gmail.com CC: vala-list@gnome.org Subject: Re: [Vala] Can adding new virtual method break ABI? If you need to do these things manually, then what's the point in using vala? It's the job of compilers. People who like to do the job of compilers manually should use GObject/C instead. Manually filling a virtual function table and calculate offset of pointers are really of fun. lol Creating some empty functions for padding is even easier and more readable IMO. On Wed, Dec 14, 2011 at 6:15 PM, Mikkel Kamstrup Erlandsen < mikkel.kamst...@gmail.com> wrote: > On 12 December 2011 12:15, Jürg Billeter wrote: > > On Mon, 2011-12-12 at 12:12 +0100, Luca Bruno wrote: > >> > >> On Mon, Dec 12, 2011 at 12:01 PM, Jürg Billeter wrote: > >> On Sun, 2011-12-11 at 11:34 +0100, Luca Bruno wrote: > >> > 2011/12/11 Tal Hadad > >> > > >> > > This idea is based on the assumption that the size of > >> XClass struct > >> > > doesn't matter and can be changed(Am I right?). > >> > > Also, how does the virtual method order is currently done > >> by Vala? Is it > >> > > alphabetic or by the order of the decelerations? > >> > > > >> > > >> > The ordering does not matter, the padding does. > >> > >> Ordering matters as well. Vala uses declaration order. > >> > >> We're talking about virtual methods, aren't we? There's no ABI break > >> if the order of N pointers is exchanged. > > > > When a subclass overrides a virtual method, the class_init function uses > > the offset of the virtual function pointer. If that offset changes, the > > subclass will need to be recompiled to work again. > > Indeed. > > Would it make sense to a [CCode (vfunc_padding = "8")] to class > declarations? This could then be decremented when new virtual > functions are added (to the end of the class!). > > Cheers, > Mikkel > ___ > vala-list mailing list > vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list > ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Can adding new virtual method break ABI?
If you need to do these things manually, then what's the point in using vala? It's the job of compilers. People who like to do the job of compilers manually should use GObject/C instead. Manually filling a virtual function table and calculate offset of pointers are really of fun. lol Creating some empty functions for padding is even easier and more readable IMO. On Wed, Dec 14, 2011 at 6:15 PM, Mikkel Kamstrup Erlandsen < mikkel.kamst...@gmail.com> wrote: > On 12 December 2011 12:15, Jürg Billeter wrote: > > On Mon, 2011-12-12 at 12:12 +0100, Luca Bruno wrote: > >> > >> On Mon, Dec 12, 2011 at 12:01 PM, Jürg Billeter wrote: > >> On Sun, 2011-12-11 at 11:34 +0100, Luca Bruno wrote: > >> > 2011/12/11 Tal Hadad > >> > > >> > > This idea is based on the assumption that the size of > >> XClass struct > >> > > doesn't matter and can be changed(Am I right?). > >> > > Also, how does the virtual method order is currently done > >> by Vala? Is it > >> > > alphabetic or by the order of the decelerations? > >> > > > >> > > >> > The ordering does not matter, the padding does. > >> > >> Ordering matters as well. Vala uses declaration order. > >> > >> We're talking about virtual methods, aren't we? There's no ABI break > >> if the order of N pointers is exchanged. > > > > When a subclass overrides a virtual method, the class_init function uses > > the offset of the virtual function pointer. If that offset changes, the > > subclass will need to be recompiled to work again. > > Indeed. > > Would it make sense to a [CCode (vfunc_padding = "8")] to class > declarations? This could then be decremented when new virtual > functions are added (to the end of the class!). > > Cheers, > Mikkel > ___ > vala-list mailing list > vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list > ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Can adding new virtual method break ABI?
On Wed, Dec 14, 2011 at 11:15 AM, Mikkel Kamstrup Erlandsen < mikkel.kamst...@gmail.com> wrote: > Indeed. > > Would it make sense to a [CCode (vfunc_padding = "8")] to class > declarations? This could then be decremented when new virtual > functions are added (to the end of the class!). > I'd expect that to be done automatically. -- www.debian.org - The Universal Operating System ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Can adding new virtual method break ABI?
On 12 December 2011 12:15, Jürg Billeter wrote: > On Mon, 2011-12-12 at 12:12 +0100, Luca Bruno wrote: >> >> On Mon, Dec 12, 2011 at 12:01 PM, Jürg Billeter wrote: >> On Sun, 2011-12-11 at 11:34 +0100, Luca Bruno wrote: >> > 2011/12/11 Tal Hadad >> > >> > > This idea is based on the assumption that the size of >> XClass struct >> > > doesn't matter and can be changed(Am I right?). >> > > Also, how does the virtual method order is currently done >> by Vala? Is it >> > > alphabetic or by the order of the decelerations? >> > > >> > >> > The ordering does not matter, the padding does. >> >> Ordering matters as well. Vala uses declaration order. >> >> We're talking about virtual methods, aren't we? There's no ABI break >> if the order of N pointers is exchanged. > > When a subclass overrides a virtual method, the class_init function uses > the offset of the virtual function pointer. If that offset changes, the > subclass will need to be recompiled to work again. Indeed. Would it make sense to a [CCode (vfunc_padding = "8")] to class declarations? This could then be decremented when new virtual functions are added (to the end of the class!). Cheers, Mikkel ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Can adding new virtual method break ABI?
On Mon, 2011-12-12 at 12:12 +0100, Luca Bruno wrote: > > On Mon, Dec 12, 2011 at 12:01 PM, Jürg Billeter wrote: > On Sun, 2011-12-11 at 11:34 +0100, Luca Bruno wrote: > > 2011/12/11 Tal Hadad > > > > > This idea is based on the assumption that the size of > XClass struct > > > doesn't matter and can be changed(Am I right?). > > > Also, how does the virtual method order is currently done > by Vala? Is it > > > alphabetic or by the order of the decelerations? > > > > > > > The ordering does not matter, the padding does. > > Ordering matters as well. Vala uses declaration order. > > We're talking about virtual methods, aren't we? There's no ABI break > if the order of N pointers is exchanged. When a subclass overrides a virtual method, the class_init function uses the offset of the virtual function pointer. If that offset changes, the subclass will need to be recompiled to work again. Jürg ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Can adding new virtual method break ABI?
On Mon, Dec 12, 2011 at 12:01 PM, Jürg Billeter wrote: > On Sun, 2011-12-11 at 11:34 +0100, Luca Bruno wrote: > > 2011/12/11 Tal Hadad > > > > > This idea is based on the assumption that the size of XClass struct > > > doesn't matter and can be changed(Am I right?). > > > Also, how does the virtual method order is currently done by Vala? Is > it > > > alphabetic or by the order of the decelerations? > > > > > > > The ordering does not matter, the padding does. > > Ordering matters as well. Vala uses declaration order. > We're talking about virtual methods, aren't we? There's no ABI break if the order of N pointers is exchanged. -- www.debian.org - The Universal Operating System ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Can adding new virtual method break ABI?
On Sun, 2011-12-11 at 11:34 +0100, Luca Bruno wrote: > 2011/12/11 Tal Hadad > > > This idea is based on the assumption that the size of XClass struct > > doesn't matter and can be changed(Am I right?). > > Also, how does the virtual method order is currently done by Vala? Is it > > alphabetic or by the order of the decelerations? > > > > The ordering does not matter, the padding does. Ordering matters as well. Vala uses declaration order. Jürg ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Can adding new virtual method break ABI?
2011/12/11 Tal Hadad > > Yes it does. What C programmers often do is adding unused vfuncs as > padding for future extension of the class. From this perspective Vala could > theoretically add some kind of padding to avoid abi breakage. > So what about this idea for fix it: > Create a new attribute property in [CCode], named binary_position, that is > used for virtual methods, but can be used for another things(such as > fields, etc.). > It can be used by the developer to avoid this risk, by doing so: > Every time the developer create a new virtual method, he shell pick the > smallest number available for virtual method position, and put it in > binary_position in [CCode]. > On every planned ABI(&API) break, he can minimize those binary_position(s) > for virtual methods. > > This idea is based on the assumption that the size of XClass struct > doesn't matter and can be changed(Am I right?). > Also, how does the virtual method order is currently done by Vala? Is it > alphabetic or by the order of the decelerations? > The ordering does not matter, the padding does. -- www.debian.org - The Universal Operating System ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Can adding new virtual method break ABI?
> Yes it does. What C programmers often do is adding unused vfuncs as
padding for future extension of the class. From this perspective Vala
could theoretically add some kind of padding to avoid abi breakage.
So what about this idea for fix it:
Create a new attribute property in [CCode], named binary_position, that is used
for virtual methods, but can be used for another things(such as fields, etc.).
It can be used by the developer to avoid this risk, by doing so:
Every time the developer create a new virtual method, he shell pick the
smallest number available for virtual method position, and put it in
binary_position in [CCode].
On every planned ABI(&API) break, he can minimize those binary_position(s) for
virtual methods.
This idea is based on the assumption that the size of XClass struct doesn't
matter and can be changed(Am I right?).
Also, how does the virtual method order is currently done by Vala? Is it
alphabetic or by the order of the decelerations?
Thanks
Tal
Date: Sun, 11 Dec 2011 10:48:21 +0100
Subject: Re: [Vala] Can adding new virtual method break ABI?
From: lethalma...@gmail.com
To: tal...@hotmail.com
CC: vala-list@gnome.org
2011/12/11 Tal Hadad
I've read how GObject define virtual methods, in the XClass struct, and
I'm afraid defining new virtual method can break ABI. Am I right?
Before:
struct _XClass
{
GObjectClass parent_class;
/* stuff */
void (*do_action) (X *self, /* parameters */);
};
After:
struct _XClass
{
GObjectClass parent_class;
/* stuff */
void (*another_action) (X *self, /* parameters */);
void (*do_action) (X *self, /* parameters */);
};
Can this case break ABI?
Yes it does. What C programmers often do is adding unused vfuncs as padding
for future extension of the class. From this perspective Vala could
theoretically add some kind of padding to avoid abi breakage.
--
www.debian.org - The Universal Operating System
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Can adding new virtual method break ABI?
2011/12/11 Tal Hadad
>
> I've read how GObject define virtual methods, in the XClass struct, and
> I'm afraid defining new virtual method can break ABI. Am I right?
> Before:
> struct _XClass
> {
> GObjectClass parent_class;
>
> /* stuff */
> void (*do_action) (X *self, /* parameters */);
> };
>
> After:
> struct _XClass
> {
>
> GObjectClass parent_class;
>
>
> /* stuff */
>
>
> void (*another_action) (X *self, /* parameters */);
>
> void (*do_action) (X *self, /* parameters */);
>
> };
>
> Can this case break ABI?
>
>
Yes it does. What C programmers often do is adding unused vfuncs as padding
for future extension of the class. From this perspective Vala could
theoretically add some kind of padding to avoid abi breakage.
--
www.debian.org - The Universal Operating System
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
