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

[Ken Smith]

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.

-- 
                                                Ken Smith
- 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
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20080528/0a9b6797/attachment.pgp