sections multiple times. This started to happen because, pmdoc_Sh(), the handler function
responsible for parsing the Sh macros, used to recursively go through all the child
nodes and then the next nodes starting from top level Sh block node.
Now, once it has processed all the child nodes of the top level block node,
it moves to the next node, which is the top level block node of the next section and
in this way one call to pmdoc_Sh() was causing a complete pass through the
man page. Since, mandoc(3) calls pmdoc_Sh() for each .Sh macro in the man
page, it would result in parsing some of the sections multiple times.
This never happened with the previous versions of mandoc, so we never noticed.
I've fixed this by starting the parse sequence of the Sh macro from its body, which gurantees
that we will stop once that section ends.
ok christos@
flags, we no longer need the custom sppp code to detect if we are
connected or not.
Add commentary on if we really need to handle RTM_DELADDR only when
detached.
and PCI_IOC_DRVNAMEONBUS. the new ones also take a (autoconf) PCI bus
number, which allows lookups for any device on any pci bus node. use this
in pcictl which current reports the wrong values sometimes.
up next: use these in libpciaccess.
The superblock field that distinguishes between 4.2BSD and 4.4BSD
inodes is really only relevant on a UFS1 file system. Make sure that
it is a UFS1 fs before using fs_old_inodefmt.
Note that the NetBSD newfs and mkfs utilities initialize fs_old_inodefmt
even for UFS2, so problems were apparent only on file systems created
by other operating systems, for example, FreeBSD.
than parsing it by hand.
With the latest mandoc(3), the .Nd macro was getting parsed twice. This fixes
that problem and cleans up the code as well.
ok christos@
With the latest API, mdoc_validate()/man_validate() needs to be called before
reading the roff_man.meta field, otherwise it is NULL.
Also, if a man page doesn't specify machine architecture, don't default to '?'
, let it be stored as null in the db. Otherwise, the output of apropos(1) shows
the names of the results as \?/<title>
abhinav