> Dmitrij Tejblum wrote:
> >
> > Marcel Moolenaar wrote:
> > > > I suggest to try to avoid the version bump. NetBSD-like way to do it:
> > > > Give new implementations another names in object files, so that they
> > > > don't conflict with old implementations, and preserve old
> > > > implementations in the library too. To make the compiler generate calls
> > > > to new implementations, one can add appropriate #define s in .h files.
> > > > For GCC, __asm__ attribute also can be used.
> >
> > No, when new functions are added into the library, and binaries linked
> > with the old library will continue to work with new library, version bump
> > is not required.
> >
> > This is a standard rule. It was also recently discussed on -committers
> > on Aug 20 in the thread
> > Re: cvs commit: src/include histedit.h src/lib/libedit Makefile editline.3 el.c
>el.h
>
> In that discussion it has been said that datatype changes require a version
> change. Now you're telling me that we should implement datatype changes as
> new functions which consequently don't require a version change. So now the
> policy is "version bump avoidance at all cost"?
I am not setting any policy - I am not core. I am just suggesting it
(strongly :-)
Then, I believe that the cost here is relatively low compared to the
benefit. libc is used by all programs, and version bumps would have
quite severe impact. OTOH, you touch only half-dozen of functions, and
they are not that popular, so why the change should affect all programs?
Other OSes started to avoid version bumps. Linux promises to not bump
the libc version since glibc2. NetBSD avoid version bumps too. (Linux
use "symbol versioning", that isn't supported by our rtld.)
> > > How else
> > > do I know wich version x library has the new implementations (besides the
> > > larger one :-)?
> >
> > Linker knows it. If some function ("new implementation") is missing, linker print
> > an error message. This is all you need.
>
> I strongly disagree. Spitting "unresolved references" is *not* a way to
> tell the user that he doesn't have the right libraries.
I strongly disagree. This is much better than version bump. After all,
we can add suggestion to upgrade libraries to the "unresolved references"
message. Then, if an user don't have right libraries, it is his mistake.
It should not impact another people.
Also, we are not discussing _this_. A lot of functions were added to libc
without a version bump, and it is a standard accepted practice (Just from
top of my head: strlcpy, strlcat, mkstemps, strsignal, fseeko, ftello,
poll, nanosleep, pread, pwrite, kld*, ... ouch, there is a lot of
other functions).
My suggestion have more serious disadvantages. For one, it add more
work to you (the person who change an interface). But it save some work
to everyone who will ever upgrade FreeBSD or deal with a 3rd party
software. Then, say, dlsym(,"setjmp") will give probably incorrect result.
But "you cannot have everything" and noone, I hope, will use such dlsym.
Dima
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
