| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
| |
patch from jsg@
ok gnezdo@ miod@ jmc@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we must not reset the recursion counter when moving beyond the end
of the *previous* expansion, but we may only do so when moving
beyond the rightmost position reached by *any* expansion in the
current equation. This matters because definitions can nest;
consider:
.EQ
define inner "content"
define outer "inner outer"
outer
.EN
This endless loop was found by tb@ using afl(1).
Incidentally, GNU eqn(1) also performs an infinite loop in this
situation and then crashes when memory runs out, but that's not an
excuse for nasty behaviour of mandoc(1).
While here, consistently print the expanded content even when the
expansion is finally truncated. While that is not likely to help
end-users, it may help authors of eqn(7) code to understand what's
going on. Besides, it sends a very clear signal that something is
amiss, which was easy to miss in the past unless people
enabled -W error or used -T lint.
|
| |
|
|
|
|
|
|
|
| |
whatsoever and ends with a broken next-line scope. Obviously, this
cannot happen in a real manual page, but mandoc(1) should not die
even when fed absurd input.
This bug was independently reported by both jsg@ and tb@ who both
found it with afl(1).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
beginning of an escape sequence: \, \E, \EE, \EEE, and so on all do
the same outside copy mode, so let them do the same in mandoc(1), too.
This fixes an assertion failure triggered by \EE*X that tb@ found
with afl(1). The first E was consumed by roff_expand(), but that
function failed to recognize the escape sequence as the expansion
of a user-defined string and handed it over to mandoc_escape(),
which consumed the second E and then died on an assertion because
it is not prepared to handle user-defined strings. Fix this by
letting *both* functions handle arbitrary numbers of 'E's correctly.
|
| |
|
|
|
|
|
|
| |
for centering text spanning multiple tbl(7) columns, correctly account
for the spacing between columns instead of wrongly assuming the default
spacing of 3n.
Patch from Simon Branch <simonmbranch at gmail dot com>.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
delete a sentence taking about databases. Having that sentence in
the first place probably was a copy-and-paste mistake when adopting
some text from the makewhatis(8) manual page.
Triggered by a smaller patch sent to discuss@
by Paul A. Patience <paul at apatience dot com>.
|
| |
|
|
|
|
|
|
|
|
| |
two-value syntax "display: inline flow;" instead. In particular, there
is no need to establish a new block formatting context with "flow-root",
and in fact that's detrimental because it appears to introduce spurious
soft-wrap opportunities.
jmc@ reported a bogus line break between the opening angle bracket
generated by .Aq Mt and the following email address.
|
| |
|
|
|
|
|
|
|
|
|
| |
and man(1), without restricting that statement to "man -k".
Suggested by and patch OK'ed by jmc@.
While only apropos(1) and whatis(1) strictly require the database
and while our man(1) implementation can find many manual pages even
when no database is available or when the database is incomplete or
corrupt, it does use the database even without -k whenever possible.
Consequently, this change makes the manual page less confusing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It feels more natural to me to use -a directly when asking mandoc(1)
to use a pager. The reason that "mandoc -l" does exactly the same
as "mandoc -a" is that "mandoc" is essentially "man -lc", so the -a
implied by -l negates the -c and the -l has no effect because it is
already the default for mandoc(1).
The more usual command for doing the same is "man -l foo.1 bar.1 ..."
but that's off-topic for the mandoc(1) manual page.
Patch on tech@ from Anders Damsgaard <anders at adamsgaard dot dk>.
|
| |
|
|
| |
patch from jsg@, ok jmc@ sthen@ millert@
|
| |
|
|
|
|
|
|
|
|
|
| |
because all of the following hold:
* It is an alias for a part of an ancient standard that is no longer important.
* To refer to that old standard, -xpg4.2 is readily available and portable.
* It is unused in OpenBSD, FreeBSD, and NetBSD.
* Groff never supported it.
I agreed with G. Branden Robinson that deleting this from mandoc
is preferable to adding it to groff.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
making the mansearch() function easier to read for human auditors.
No functional change on OpenBSD.
As observed by Mark Millard <marklmi at yahoo dot com>, neither the
latest version of POSIX 2008 nor C11 defines what qsort(3) should do
for base == NULL && nmemb == 0.
My impression is it is indeed undefined behaviour because the
standards say that base shall point to an array, NULL does not point
to an array, and while there is special wording saying that compar()
shall not be called if nmemb == 0, i fail to see any similar wording
stating that base shall not be accessed if nmemb == 0.
Consequently, this patch is also likely to improve standard conformance
and portability.
Minor issue found by Stefan Esser <se at FreeBSD> with UBSAN.
He sent a patch to bugs@, but my patch differs in a minor way.
|
| |
|
|
|
|
|
| |
output. In particular, do not represent "_" as "-", and distinguish "_"
from "\_" and "=" from "\=".
Output tweak following a related question from
Ted Bullock <tbullock at comlore dot com>.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
two character sequence "\_" or "\=", a single or double horizontal
line is supposed to be drawn inside the cell, not joining its
neighbours.
I am not aware of any way to do that with HTML and/or CSS.
Still, it seems closer to the intent of the document author to draw
a horizontal line with <hr/>, even though that line will join the
neighbour cells, rather than printing a literal '_' or '=' character.
Formatting tweak inspired by a related question from
Ted Bullock <tbullock at comlore dot com>.
|
| |
|
|
|
|
|
|
| |
contains a backslash that needs to be escaped, and the
missing escaping resulted in very misleading formatting.
Documentation bug found due to a question from
Ted Bullock <tbullock at comlore dot com>.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
sequence in -T ps and -T pdf output mode, use an appropriate
horizontal distance by correctly using the term_len() utility
function. Output from the -T ascii, -T utf8, and -T html modes
was already correct and remains unchanged.
Lennart Jablonka <hummsmith42 at gmail dot com> found and reported
this unit conversion bug (misinterpreting AFM units as if they were
en units) when rendering scdoc-generated manuals (which is a low
quality generator, but that's no excuse for mandoc misformatting \h)
on Alpine Linux. Lennart also tested this patch.
|
| |
|
|
| |
sytle -> style; adapted from changes by SAITOH masanobu (NetBSD)
|
| |
|
|
|
|
|
|
|
|
|
| |
running with the -M option or with a MANPATH environment variable
that has neither a leading or trailing ":" nor any "::". If -M or
MANPATH override the configuration file rather than adding to it,
just ignore any "manpath" directives while processing the configuration
file.
This fixes a bug reported by Jan Stary <hans at stare dot cz>
on misc@.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
For open/openat, if the flags parameter does not contain O_CREAT, the
3rd (variadic) mode_t parameter is irrelevant. Many developers in the past
have passed mode_t (0, 044, 0644, or such), which might lead future people
to copy this broken idiom, and perhaps even believe this parameter has some
meaning or implication or application. Delete them all.
This comes out of a conversation where tb@ noticed that a strange (but
intentional) pledge behaviour is to always knock-out high-bits from
mode_t on a number of system calls as a safety factor, and his bewilderment
that this appeared to be happening against valid modes (at least visually),
but no sorry, they are all irrelevant junk. They could all be 0xdeafbeef.
ok millert
|
| |
|
|
|
| |
variables that are already present (and used nearby) in the code;
no functional change
|
| |
|
|
|
|
|
|
| |
A comment in the code claimed that the list of spans would be sorted,
but the sorting did not actually work. The layout "LSSS,LLSL" resulted
in the list "0-3, 1-2", whereas the layout "LLSL,LSSS" resulted
in the list "1-2, 0-3". Since sorting serves no purpose, just leave
the list unsorted.
|
| | |
|
| |
|
|
|
| |
that is malloc(3)ed. In addition to being less confusing, the new
code is also shorter by two lines.
|
| |
|
|
|
|
|
|
|
|
| |
after processing each name given on the command line.
Failure to do so resulted in a memory leak of about 50 kilobytes
per name given on the command line. Since man(1) uses a few
Megabytes of memory anyway and people rarely give hundreds of names
on the command line, this leak did not cause practical problems,
but cleaning up properly is better in any case.
|
| |
|
|
|
|
|
|
|
|
| |
and resetting the internal state to the initial state.
Call this function from the proper place in term_free().
With the way the module is currently used, this does not imply any
functional change, but doing proper cleanup is more robust, makes
it easier during code review to understand what is going on, and
makes it explicit that there is no memory leak.
|
| |
|
|
|
|
| |
struct together with similar state date rather than in a function-scope
static variable, such that it can be free(3)d in roff_man_free();
no functional change
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a user-defined macro. Calls of standard mdoc(7) and man(7) macros
were unaffected, so the effect on OpenBSD manual pages was small,
about 80 Kilobytes grand total for a full run of "makewhatis
/usr/share/man".
Argument expansion contexts for user-defined macros are stored on
a stack that grows as needed if calls of user-defined macros are
nested or recursive. Individual stack entries contain dynamically
allocated arrays of pointers to arguments; these argument arrays
also grow as needed if user-defined macros take more than eight
arguments. The mistake was that argument arrays of already
initialized expansion contexts were leaked rather than reused on
subsequent macro calls.
I found this issue in a systematic hunt for memory leaks after
Michael <Stapelberg at Debian> reported memory exhaustion problems
on the production server manpages.debian.org. This sub-Megabyte
leak is not the cause of Michael's trouble, though, where Gigabytes
of memory are being wasted. We are still investigating whether the
original problem may be related to his supervisor process, which is
written in Go, rather than to mandoc.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
reported by Michael <Stapelberg at Debian> in the Linux md(4) manual.
The reason the colwidth[] array is needed is not that it stores widths
different from those in tbl->cols[].width, but that only part of the
columns participate in the comparisons, i.e. only those intersecting
at least one span the still requires width distribution.
|
| | |
|
| |
|
|
| |
He is now busy with the early stages of development of Viewpoint Linux.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
For HTML generation, the "mandoc" prerequisite isn't needed anyway
because ${WWW_MANS} already explicitly depends on mandoc.
Issue reported by Sevan Janiyan and Leah Neukirchen.
This is not critical for release because it is only used for
a maintainer target. While here, i also fixed the associated
shell command to use the freshly built mandoc binary rather
than whatever may be in the $PATH.
|
| | |
|
| |
|
|
| |
suggested by Lukas Epple <sternenseemann at systemli dot org>
|
| |
|
|
|
|
| |
in the "regress" target. That makes manual "cd regress && ./regress.pl"
a bit less fragile.
The idea came up in a conversation with Thomas Klausner <wiz at NetBSD>.
|
| |
|
|
| |
bug reported by Thomas Klausner <wiz at NetBSD>
|
| |
|
|
| |
Thomas Klausner <wiz at NetBSD> reported a compiler warning
|
| | |
|
| | |
|
| |
|
|
| |
in case it is missing; needed for SUN Solaris 10.
|
| |
|
|
|
|
|
| |
1. If mktemp(3) fails, do not overwrite the errno because
all errors mktemp(3) might return are also valid for mkdtemp(3).
2. If mkdir(2) fails, always put back the Xes, even if
the error is fatal and the function is about to return NULL.
|
| |
|
|
| |
issue found on SUN Solaris 10
|
| |
|
|
| |
issue found on Oracle Solaris 11
|
| | |
|
