Re: [d-i] libdebian-installer2
[Michael Cardenas] Isn't it true that you can only safely add onto the end of a struct on i386? Since the stack is allocated backwards on ppc, wouldn't adding to the end of the struct still break old clients? No. If the library clients never allocates or uses the struct content directly, and all access to the struct is done using the library, there are no limits on how you can restructure the content of a struct. Think encapsulation. :-) IF the client allocates the struct on the stack, there is no way you can safely modify the struct content. The Practice of Programming by Brian Kernighan and Rob Pike is a nice book to read about interface design. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] libdebian-installer2
On Tue, Nov 19, 2002 at 11:51:35PM +0100, Petter Reinholdtsen wrote: [Junichi Uekawa] You can add members at the end of struct if and only if any other application does not try to malloc it. Both malloc and static variables will be a problem. Examples of bad interface: Isn't it true that you can only safely add onto the end of a struct on i386? Since the stack is allocated backwards on ppc, wouldn't adding to the end of the struct still break old clients? Also, if you don't have it now, you should reserve a little bit of struct for future changes, usually a few longs will do for a long time. -- michael cardenas | lead software engineer, lindows.com hyperpoem.net | GNU/Linux software developer people.debian.org/~mbc | encrypted email preferred There is a morality of reason, a morality proper to man, and Man's Life is its standard of value. - Ayn Rand, Atlas Shrugged msg24296/pgp0.pgp Description: PGP signature
Re: [d-i] libdebian-installer2
[Junichi Uekawa]
You can add members at the end of struct if and only if any other
application does not try to malloc it.
Both malloc and static variables will be a problem. Examples of bad
interface:
/* library */
typedef struct { int a; } foo;
void use_foo(foo *f) { ... }
/* client code */
int bar() { foo b; use_foo(b); }
int baz() { foo *b = malloc(sizeof(*b)); use_foo(b); }
Example of good interface:
/* library */
struct f { int a; };
typedef struct f *foo;
foo foo_alloc() { return malloc(sizeof(*foo)); }
void use_foo(foo f) { ... }
/* client code */
int bar() { foo b = foo_alloc(); use_foo(b); }
The good API can be made harder to misuse by moving the struct f
definition into a private header file, not exposed to the clients.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] libdebian-installer2
tis 2002-11-05 klockan 03.18 skrev Junichi Uekawa: But surely adding stuff to a data structure is a backward-incompatible change? It depends on the way you do it. You can add stuff to a data structure without breaking backwards compatibility. I'm considering adding more stuff to struct package_t, do you have any hints or pointers on how I should do it, then? /Martin signature.asc Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signeradmeddelandedel
Re: [d-i] libdebian-installer2
At 14 Nov 2002 00:10:32 +0100, Martin Sj�gren wrote: [1 text/plain (quoted-printable)] tis 2002-11-05 klockan 03.18 skrev Junichi Uekawa: But surely adding stuff to a data structure is a backward-incompatible change? It depends on the way you do it. You can add stuff to a data structure without breaking backwards compatibility. I'm considering adding more stuff to struct package_t, do you have any hints or pointers on how I should do it, then? You can add members at the end of struct if and only if any other application does not try to malloc it. Otherwise, interface probably needs to be bumped up. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] libdebian-installer2
we don't need to bump soversion at all, unless we make backward-incompatible changes. just bump minor (and don't change the packaging name). Also, fix shlibs to depend on that version or later. But surely adding stuff to a data structure is a backward-incompatible change? It depends on the way you do it. You can add stuff to a data structure without breaking backwards compatibility. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] libdebian-installer2
* Martin Sjögren | I've added priority parsing to libd-i, which is yet another | interface-changing addition, but since libd-i2 hasn't been uploaded yet, | and neither have the packages that depend on it, I haven't increased the | soversion. | | This will probably break some things, but I intend to have as policy not | to increase soversion more than once per version! Since we release | often, the soversion will increase rapidly anyway, and it's only | CVS-users who will have problems with this. we don't need to bump soversion at all, unless we make backward-incompatible changes. just bump minor (and don't change the packaging name). Also, fix shlibs to depend on that version or later. | Is my thinking flawed? If so, please back out my commits and do | something different. I committed it because I'm going to a convention | and wanted this up and running in the next upload of libd-i. I'll run through a few installs and check if things are holding together. If they are, you're going to see a few uploads in a couple of hours. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] libdebian-installer2
sön 2002-11-03 klockan 15.36 skrev Tollef Fog Heen: we don't need to bump soversion at all, unless we make backward-incompatible changes. just bump minor (and don't change the packaging name). Also, fix shlibs to depend on that version or later. But surely adding stuff to a data structure is a backward-incompatible change? /Martin signature.asc Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signeradmeddelandedel
[d-i] libdebian-installer2
I've added priority parsing to libd-i, which is yet another interface-changing addition, but since libd-i2 hasn't been uploaded yet, and neither have the packages that depend on it, I haven't increased the soversion. This will probably break some things, but I intend to have as policy not to increase soversion more than once per version! Since we release often, the soversion will increase rapidly anyway, and it's only CVS-users who will have problems with this. Is my thinking flawed? If so, please back out my commits and do something different. I committed it because I'm going to a convention and wanted this up and running in the next upload of libd-i. /Martin signature.asc Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signeradmeddelandedel
