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

David Schultz das at FreeBSD.ORG
Wed May 28 06:03:09 UTC 2008

On Tue, May 27, 2008, Xin LI wrote:
> 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?

ISTR that in prior discussions on symbol versioning, the consensus
was that there's nothing wrong with adding new APIs in -STABLE
branches, but of course apps that use the new features won't be

By the way, one catch is that once you MFC symbols in the FBSD_1.1
namespace, any new symbols in the same library need to go in
FBSD_1.2. We do guarantee that public namespaces do not change
across stable branches. This is important for API-checking tools
like appcert: even if you can't prevent problems like the one
described previously, at least you have some assurance as to which
versions of FreeBSD will run your app.

More information about the cvs-src mailing list