The one in wcwidth.c actually came up in one of my valgrind runs: if you passed it a non-null-terminated wide string (specifically, one that reaches invalid memory exactly when the length parameter runs out), it would illegally load the character beyond the end of the string before noticing that the length parameter said it shouldn't. The one in bk_man.c may well not be able to come up at all, but I spotted it in passing and I thought I might as well fix it - it makes me twitch on general principles to see any use of buf[len-1] without having checked len>0 first.
this a couple of times in Halibut markup recently (in particular, it's handy to have a typographical distinction between 'this term is emphasised because it's new' and 'this term is emphasised because I want you to pay attention to it'), so here's an implementation, basically parallel to \e. One slight oddity is that strong text in headings will not be distinguished in some output formats, since they already use bolded text for their headings. [originally from svn r9772]
I'm not quite sure why I ever thought it was a good idea to have a central variadic error() function taking an integer error code followed by some list of arguments that depend on that code. It now seems obvious to me that it's a much more sensible idea to have a separate function per error, so that we can check at compile time that the arguments to each error call are of the right number and type! So I've done that instead. A side effect is that the errors are no longer formatted into a fixed-size buffer before going to stderr, so I can remove all the %.200s precautions in the format strings. [originally from svn r9639]
"-" as a special file name meaning standard output. I've restricted it to just those output formats which can predictably output only one file, just for the sake of not having to faff too much with the others. Probably what I should have done for all of this would have been to write a set of wrappers around fopen, fclose and everything in between, and use them everywhere. Those wrappers would uniformly detect "-" and convert it into stdin or stdout as appropriate, would avoid fclosing those files for real when told to close them, and would also be able to handle reading a little bit of data from the start of a file and then pushing it all back even if the file were not seekable (which would allow input.c to lose the ugly special case whereby it can't currently read font files from standard input). [originally from svn r8729]
apparently this is preferred (it's what pod2man uses); cf Debian #496063, #159872. [originally from svn r8641] [r8309 == 73e8c7d1b4ac77ec1b5acc700cb3af277a150bcf]
(via Colin in Debian bug#496063). [originally from svn r8640] [r8321 == 5e7a3a5b1bbaccb7ce7d61bb9bc4654924135dfb]
contexts get output usefully in the face of UTF-8 *roff implementations. Works on Debian-derived distributions (and hence along with r8309 should fix #496063), but I'm slightly worried about portability as I've used a named character "\(aq" which doesn't appear in the "classic" reference CS TR #54. [originally from svn r8321] [r8309 == 73e8c7d1b4ac77ec1b5acc700cb3af277a150bcf]
because otherwise UTF-8 versions of man(1) tend to turn them into Unicode hyphen characters, with the result that if you cut and paste sample command lines out of man pages in the obvious way then the things that look like hyphens are not in fact the character that the program in question would recognise as an option introducer. [originally from svn r8309]
a period specially _even_ if there's an \fB or similar escape sequence before the period. Therefore, man_rdaddctrl() now doesn't clear the QUOTE_INITCTRL flag just because it generated some text; instead, its call sites clear the flag when the _type_ of generated text is appropriate for this. This should remove an error from the `lns' man page (utils/lns/lns.but), which was where I noticed the problem. [originally from svn r6871]
string to the output. This incidentally fixes a bug whereby font changes at the start of a line weren't resetting QUOTE_INITCTRL. [originally from svn r6660]