Move fparseln(3) from libutil to libc

[ngie]

Summary

Move fparseln(3) from libutil to libc, similar to what NetBSD did in 2002

From [e-mail]'s commit message:

• Migrate fparseln(3) from libutil to libc, where it should have been in the first place...
• Bump libutil major (to 7.0) and libc minor (to 12.91).

This improves compatibility with libbsd on Linux and libc on NetBSD.

• Add fparseln to lib/libc/stdio/Symbol.map
• Bump SHLIB_MAJOR in lib/libutil from 9 to 10

MFC after: 1 month
Sponsored by: Dell EMC Isilon

[ngie]

ObsoleteFiles.inc

42

It's in /lib, not /usr/lib...

[ngie]

Add UPDATING entry.

[ngie]

Remove lib/libc/tests/hash/Makefile from the diff -- it was added by accident.

[bdrewery]

lib/libutil/Makefile

10

Bumping the version and breaking packages (hassling users) for this doesn't seem warranted. The move itself is an opinion that we would be copying.

[ngie]

lib/libutil/Makefile

10

If I don't bump the version, then there are 2 copies of the function floating around -- one in libc, the other in libutil. Why bloat libutil like that?

Let me step back a bit and try to explain the justification for the change..

fparseln on FreeBSD requires stdio.h and libutil.h / libutil.so.
fparseln on NetBSD requires stdio.h.

Trying to reduce the diff in contrib/netbsd-tests, I was again reminded of why I polluted tests that use fparseln 2 years ago... hexdump in contrib/netbsd-tests/lib/libc/hash/h_hash.c conflicts with hexdump(3) in libutil. I tried quickly adapting h_hash.c to hexdump(3), but in order to make it work, I'd have to add additional flags to support the output, and even then it wasn't working 100% because of how hexdump in h_hash.c handles string lengths vs hexdump(3) in libutil. Given that fparseln came from NetBSD in the first place, it seems a lot more fitting to follow their lead and move it to libc -- especially because it reduces unnecessary convolution in libutil.h (note that libutil.h exposes fparseln if and only if stdio.h is first included).

I guess this is my "brilliant idea" in trying to get things to work in a way that makes the most sense instead of continuing to hack contrib/netbsd-tests for FreeBSD where it doesn't make sense.

[bdrewery]

lib/libutil/Makefile

10

Yes, I just think the cost should be weighed of maintaining *3* patches in contrib/netbsd-tests vs package grief and an API change for an obscure function. POLA comes to mind as it will make upgrading packages needing libutil painful. I had never heard of this function before. If we're going to do things that bump a version I'd rather see more bundled into the bump to make it worth the cost. There are other functions in libutil that may make more sense in libc. A public discussion on arch@ would be better about this I think. Though, we're 15 years past their move and I don't see a pressing need for it right now when we can just work around it.

[pfg]

Just IMHO, and not meaning to stand in the way ...

I don't like the idea of bringing a new non-standard function to libc just to use it in the testsuite.

[ngie]

lib/libc/stdio/fparseln.3

38

This would need to be updated to use libc instead of libutil.

Going to hold off on this until I get an idea of whether or not people want to move forward with this overall proposed change.

[ngie]

lib/libutil/Makefile

10

It won't really be any more difficult -- it's just that libutil after this change will be a superfluous requirement for things that need fparseln.

[ngie]

I guess I can push for the code to use getdelim upstream, which is POSIX standard... meh. Discarding.