From f08a132cc7e22f6ac2625f3b2bd93574a12fa92d Mon Sep 17 00:00:00 2001
From: Denis Ovsienko <denis@ovsienko.info>
Date: Mon, 27 Feb 2023 19:53:37 +0000
Subject: man: Format more C types using bold font. [skip ci]

---
 cbpf-savefile.manfile.in | 27 ++++++++++++++++++++-------
 pcap_loop.3pcap          | 12 ++++++------
 pcap_next_ex.3pcap       |  8 ++++----
 3 files changed, 30 insertions(+), 17 deletions(-)

diff --git a/cbpf-savefile.manfile.in b/cbpf-savefile.manfile.in
index 2a52aaa4..af3ea8da 100644
--- a/cbpf-savefile.manfile.in
+++ b/cbpf-savefile.manfile.in
@@ -94,15 +94,27 @@ part of the header up to and including MinorVer identical.
 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 .fi
 
-MOD, XOR, COP and CPX: if set to 1, in this BPF dialect BPF_MOD, BPF_XOR,
-BPF_COP and BPF_COPX respectively are valid instructions.  For the current
-list of OSes that support BPF_MOD and BPF_XOR in the kernel see the
+MOD, XOR, COP and CPX: if set to 1, in this BPF dialect
+.BR BPF_MOD ,
+.BR BPF_XOR ,
+.B BPF_COP
+and
+.B BPF_COPX
+respectively are valid instructions.  For the current list of OSes that
+support
+.B BPF_MOD
+and
+.B BPF_XOR
+in the kernel see the
 .B %
 and
 .B ^
 binary operators in
 .BR \%pcap-filter (7).
-BPF_COP and BPF_COPX are implemented in NetBSD kernel.
+.B BPF_COP
+and
+.B BPF_COPX
+are implemented in NetBSD kernel.
 .LP
 Note that the fact an instruction is valid in a BPF dialect does not always
 mean the compiled bytecode in the savefile contains the instruction.  In other
@@ -134,14 +146,15 @@ or the value(s) returned by
 and
 .BR pcap_list_datalinks (3PCAP).
 Although these functions take and return link-layer header type values via the
-.I int
+.B int
 C type, by convention only the low 16 bits are in use.
 
 .SS InstructionCount
 This is the last field of the fixed header in major version 1, it contains the
 number of bytecode instructions following the header.  By convention, valid
-BPF bytecode always ends with a "ret" instruction, so in a valid savefile this
-field value is at least 1.
+BPF bytecode always ends with a
+.B ret
+instruction, so in a valid savefile this field value is at least 1.
 
 .PP
 The file format thus far minimizes the overhead for software that uses the BPF
diff --git a/pcap_loop.3pcap b/pcap_loop.3pcap
index 0c595262..f8ca59b7 100644
--- a/pcap_loop.3pcap
+++ b/pcap_loop.3pcap
@@ -94,10 +94,10 @@ but must not rely on it happening.
 .PP
 .I callback
 specifies a
-.I pcap_handler
+.B pcap_handler
 routine to be called with three arguments:
 a
-.I u_char
+.B u_char
 pointer which is passed in the
 .I user
 argument to
@@ -105,16 +105,16 @@ argument to
 or
 .BR pcap_dispatch (),
 a
-.I const struct pcap_pkthdr
+.B const struct pcap_pkthdr
 pointer pointing to the packet time stamp and lengths, and a
-.I const u_char
+.B const u_char
 pointer to the first
 .B caplen
 (as given in the
-.I struct pcap_pkthdr
+.BR "struct pcap_pkthdr" ,
 a pointer to which is passed to the callback routine)
 bytes of data from the packet.  The
-.I struct pcap_pkthdr
+.B struct pcap_pkthdr
 and the packet data are not to be freed by the callback routine, and are
 not guaranteed to be valid after the callback routine returns; if the
 code needs them to be valid after the callback, it must make a copy of
diff --git a/pcap_next_ex.3pcap b/pcap_next_ex.3pcap
index 4d2c43e8..d07f55e3 100644
--- a/pcap_next_ex.3pcap
+++ b/pcap_next_ex.3pcap
@@ -39,12 +39,12 @@ reads the next packet and returns a success/failure indication.
 If the packet was read without problems, the pointer pointed to by the
 .I pkt_header
 argument is set to point to the
-.I pcap_pkthdr
+.B pcap_pkthdr
 struct for the packet, and the
 pointer pointed to by the
 .I pkt_data
 argument is set to point to the data in the packet.  The
-.I struct pcap_pkthdr
+.B struct pcap_pkthdr
 and the packet data are not to be freed by the caller, and are not
 guaranteed to be valid after the next call to
 .BR pcap_next_ex (),
@@ -60,7 +60,7 @@ reads the next packet (by calling
 with a
 .I cnt
 of 1) and returns a
-.I u_char
+.B u_char
 pointer to the data in that packet.  The
 packet data is not to be freed by the caller, and is not
 guaranteed to be valid after the next call to
@@ -71,7 +71,7 @@ or
 .BR pcap_dispatch ();
 if the code needs it to remain valid, it must make a copy of it.
 The
-.I pcap_pkthdr
+.B pcap_pkthdr
 structure pointed to by
 .I h
 is filled in with the appropriate values for the packet.
-- 
cgit v1.2.1