cvs commit: src/include string.h src/lib/libc/string
Makefile.inc memchr.3 memrchr.c src/sys/sys param.h
kensmith at cse.Buffalo.EDU
Wed May 28 14:32:48 UTC 2008
On Tue, 2008-05-27 at 16:21 -0700, Xin LI wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Maxim Sobolev wrote:
> | Xin LI wrote:
> |> delphij 2008-05-27 20:04:27 UTC
> |> FreeBSD src repository
> |> Modified files: (Branch: RELENG_6)
> |> include string.h lib/libc/string
> |> Makefile.inc memchr.3 sys/sys param.h Added
> |> files: (Branch: RELENG_6)
> |> lib/libc/string memrchr.c Log:
> |> MFC: Add memrchr(3).
> | I think this is not very good idea to MFC that into stable releases 6.x
> | and 7.x. The reason is that configure scripts for some packages might
> | detect up this API and enable it. Which means that some binary-only
> | packages build for say 6.4 won't work on 6.3 and down. AFAIK, both
> | forward and backward compatibility is required (or at least desired?)
> | for stable branches.
> | While it's "nice-to-have" feature, I see no pressing need to MFC this
> | interface.
> I don't think so, perhaps I am wrong, but do we really want absolutely
> no *new* features on -STABLE branches? I think this case is different
> from ctype(3) fix which is widely used API and a change of existing
> interface by adding new dependency to a symbol that is not exist in the
> older FreeBSD releases. It will really scare me away from any new
> features if we can not add an new interface in RELENG_* trees even if
> they have no outside dependencies, if that's the policy of ABI
> compatibility guidelines then I'd be happy to revert these MFC's, but
> having something can only run on -CURRENT does not sound like a good
> idea, and maintaining in-tree alternative patches for different branches
> for such things is really painful and will likely reduce the lifespan of
> given -STABLE branches, is these our goal and should be kept in mind
> when maintaining code in RELENG_* branches?
I'm inclined towards letting this stay in. The ctype(3) fix altered an
existing interface in a way that made it incompatible with older stuff.
This is adding new stuff.
The "forwards compatibility" is a good thing for people trying to use
pre-built packages on older systems but this one is a case of us trying
to avoid breakage that, if it were to occur, would be at the whims of
the configure script for the packages. I think that's pushing the
notion of forwards compatibility a tiny bit too far.
- From there to here, from here to | kensmith at cse.buffalo.edu
there, funny things are everywhere. |
- Theodore Geisel |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/cvs-all/attachments/20080528/0a9b6797/attachment.pgp
More information about the cvs-all