@kib, sorry about not providing some aspects of the context of this change, I thought this was a good enough draft to get the first few reviews, but in hindsight it looks just lazy of me.

But the summary contains the same phrase twice, seems unintentional.

Please remember to tag the commit as Relnotes: yes.

In D35807#823735, @obiwac_gmail.com wrote:

Where can I find the rules for vertical spacing? I can't find it explicitly in style(9)

In D35807#823358, @obiwac_gmail.com wrote:

I can do it myself this evening, if that doesn't slow you down for anything else. (Aswell as making that post on -hackers that @lwhsu mentioned, if that's still necessary.)

@jilles is this patch in a good shape now?

In D35807#815011, @obiwac_gmail.com wrote:

Hey guys, is there anything here that I still need to do?

I already started looking into adding it to prevent my cat from powering off my system

In D36195#822210, @meka_tilda.center wrote:

To be honest I don't know how the process works. Can you advise, please?

Rename base64.h to b64.h.

Add the missing semicolon in Symbol.map.
Add base64.h to INCS.

Slightly change the approach: each not_fcnumber() check, keep consuming options until we need to jump to the next argptr.
Add a couple of test cases.

In D35960#816654, @hselasky wrote:

I've seen patches where BCPL-style comments are abused to form what we're used to see as block comments. So if we start allowing them, maybe say that they're allowed under some conditions (not sure what to specify here or how).

In D35807#815011, @obiwac_gmail.com wrote:

Hey guys, is there anything here that I still need to do?

@jilles what do you think about this one?

A little unfortunate to have these strange backslash sequences spread out further, but it's nothing that bash doesn't do.

Simplify and add comments.

Handle rare cases the way bash does it.

Remove debugging changes not meant for review.

Place the result of strftime() in the right place instead of always at the beginning of the buffer.
Simplify conditional early exit.

I've made the mistake of assuming that the first token has to be an option, but of course fc -1 must work.

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.