From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3069.199.98.17.55.1082737250.squirrel@wish> In-Reply-To: References: <20040423152948.GA23473@lst.de> Subject: Re: [9fans] acme, rio workalike available in plan 9 ports From: "Joel Salomon" To: 9fans@cse.psu.edu User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Date: Fri, 23 Apr 2004 12:20:50 -0400 Content-Transfer-Encoding: quoted-printable Topicbox-Message-UUID: 6b335dc4-eacd-11e9-9e20-41e7f4b1d025 ron minnich said: > I think unless I'm wrong that you've actually demonstrated the problem = I'm > trying to show -- an old binary, using a broken interface, doesn't get > fixed just because you update the library. What happens is that the old > binary retains the broken interface. This is not what people think of w= ith > shared libraries -- they naively think you upgrade the library and good > things happen, bugs are fixed, angels sing. glibc retains old broken > interfaces as time moves forward -- is this really a good idea? > Is it a broken interface or implementation that's getting fixed? What I'm understanding (and correct me if I'm wrong) is that so long as the function definition is compatible (the same?) the interface stays the same. E.g. void print_msg(void) {printf("hello wrold\n");} can be replaced in a newer version of the library by: void print_msg(void) {printf("hello world\n");} without changing the interface, but not with: void print_msg(char *mgs) {printf(msg);} If it's an interface that's being changed, your program needs a source code update to use the new function, and versioning can keep the old interface available. (And fix the spelling, too...) Have I completely misunderstood the problem? --Joel