I accept this revision. I don't mind declarations after statements, but others might.

Fix the Symbols.map part of this diff.

In D35783#812077, @obiwac_gmail.com wrote:

Looks interesting. However, personally I would like to see these two ideas (the new libc function and the new ls(1) option) have their separate reviews and ultimately commits. See also my inline comments.

Less buggy and visibly less invasive.

What the port does is:
$ file /usr/local/lib/libedit.so.0
/usr/local/lib/libedit.so.0: symbolic link to libedit.so.0.0.68
The port turns out to be a Debian-made repackaging of the NetBSD library.

Huh, as it is, it cannot pick up the base editline at all. It's looking for /lib/libedit.so.0 and ours (well, mine) is /lib/libedit.so.8.

I think I'll need to drop the "editline (ports)" option, there's no way to choose one or the other when both are installed.

Minor nit.

Maybe if the file was mmapped and the r->fromth line found via memchr() or similar, that would be faster.

I think I'm the one to blame for this, but I've never understood ATF and from other usage across our repo it wasn't clear to me how to properly do this.

To be honest, if I need to quote someone to make my argument stronger, it would be Chris: https://ramblings.implicit.net/c/2014/05/02/c-functions-that-should-be-avoided-part-2.html

In D34896#790958, @danfe wrote:

Playing devil's advocate, I can't help but not include (one of many) famous Ulrich's quotes:

Dammit, it is not safe. It hides bugs in programs. If a string is too long for an allocated memory block the copying must not simply silently stop. Instead the program must reallocate or signal an error. I can construct you cases where the use of these stupid functions is creating new security problem.

Admittedly, his canonical way to handle these situations uses unportable mempcpy() function, a GNU extension which returns adjusted destination, but still, all-caps scary warning might be a bit too much for the manpage, despite the almost modifier. IMHO it should be either toned down, or better elaborated.

Thanks again for reviewing this!

Address some of the comments made by delphij.

Address comments by rpokala.
I decided to choose the word "period" over "dot" because the former was already here.

Rebase.

Rebase.

Rename bin2text2bin to bintrans. Update the manual page.

Remove uudecode remnants from Makefile.inc1, etc/mtree/BSD.tests.dist, targets/pseudo/tests/Makefile.depend, and targets/pseudo/userland/Makefile.depend

Address delphij's comments.

Address mistakes, describe the magic buffer length.

Rebase.

Hi, thanks for this review!

Hi, thanks for this review!

Hi, thanks for the review!

Don't leak memory.

Fortunately, the tilde-expanding function from libedit is nicely exported. Too bad this code is duplicated between sh and libedit.

I don't use etcupdate yet, but this change looks reasonable to me.

In D19548#783853, @emaste wrote:

Note this was committed to the tree a couple of years ago.

I missed histedit.c in the previous git add.

Drop the flags argument from tilde_expand().

There doesn't seem to be any specification of the diff3 behavior, so I spent some time looking for some test cases. GNU doesn't provide much directly in the source (https://git.savannah.gnu.org/cgit/diffutils.git/plain/tests/diff3) and also the mailing list isn't rich in corner cases relating to diff3. I've found some test cases for git's implementation (https://github.com/git/git/search?l=Shell&q=diff3) but I only skimmed that so I don't know how useful they are.