In D11288#233844, @cem wrote:

Wouldn't it be easier to just endnetconfig() in both return paths? Avoid a bunch of unused strdup calls too.

Use endnetconfig() instead of previous approach.

Thanks for the work! (I thought this was already landed last year :)

LGTM. Could you please also send this to upstream?

style(9) fixes for new code.

In D10945#226591, @pfg wrote:

In D10945#226586, @delphij wrote:

What do we gain from the change?

Performance.. if we do them a lot it may be noticeable.

What do we gain from the change?

In D10814#224949, @emaste wrote:

So this is just compiling to an empty qsort.o today, and the removal is to prevent it from being discovered in grep -r etc.?

Certainly removing it from the Makefile makes sense. I'm indifferent to deleting the contrib-like copy of the file itself.

This is related to bugs.freebsd.org/213922

Need to address issues raised (plus some changes were not correct, need to re-do the dynamic buffer related code).

In D10544#218799, @pfg wrote:

OK, it may be worth breaking the ABI but, for now, given that we will
have to carry the old datum for compatibility anyways, how about being
one bit more efficient?

In D10544#218741, @pfg wrote:

In D10544#218740, @delphij wrote:

In D10544#218736, @pfg wrote:

In D10544#218735, @delphij wrote:

In D10544#218590, @pfg wrote:

Take 2: Comply with POSIX.

This can't be MFC'd.

No, libc ABI must NOT be broken regardless if it's MFC'ed, you should implement versioned compatibility shims.

That's just not feasible: the datum struct touches everything in dbm(3).

I might be missing something, but can't you just create wrappers around the new dbm(3) APIs to implement old binary interfaces, and __sym_compat these FBSD_1.0 symbols?

Yes but maybe I am the one missing something: I can't wrap a structure. I would have to copy the library with the old struct and provide both implementations.
The struct is only used on libc/db/hash/ndbm.c but it still seems too much bloat to copy the old version for such a "minor" change.

In D10544#218736, @pfg wrote:

In D10544#218735, @delphij wrote:

In D10544#218590, @pfg wrote:

Take 2: Comply with POSIX.

This can't be MFC'd.

No, libc ABI must NOT be broken regardless if it's MFC'ed, you should implement versioned compatibility shims.

That's just not feasible: the datum struct touches everything in dbm(3).

In D10544#218590, @pfg wrote:

Take 2: Comply with POSIX.

This can't be MFC'd.

No objection from secteam@ (if we were blocking).

Manual pages should be updated too.

I guess George would have interest on this one.

Looks good to me (in general).