cvs commit: src/include string.h src/lib/libc/string memchr.3 memrchr.c src/sys/sys param.h

Xin LI delphij at
Tue May 27 23:21:46 UTC 2008

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
|> 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?

- --
** Help China's quake relief at
Xin LI <delphij at>
FreeBSD - The Power to Serve!
Version: GnuPG v2.0.9 (FreeBSD)


More information about the cvs-src mailing list