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

[David Schultz]

On Tue, May 27, 2008, 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?

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
backwards-compatible.

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.