Style cleanup.

Use the BSD house style, in which, in

    foobar() returns 17 on success and 137 on failure.

"foobar" is boldfaced but "()" isn't.

1 files changed, 13 insertions, 13 deletions

diff --git a/pcap_breakloop.3pcap b/pcap_breakloop.3pcap
index 75560187..996290f9 100644
--- a/pcap_breakloop.3pcap
+++ b/pcap_breakloop.3pcap
@@ -31,7 +31,7 @@ void pcap_breakloop(pcap_t *);
 .ft
 .fi
 .SH DESCRIPTION
-.B pcap_breakloop()
+.BR pcap_breakloop ()
 sets a flag that will force
 .BR pcap_dispatch (3PCAP)
 or
@@ -69,9 +69,9 @@ You will need to use whatever mechanism the OS provides for
 breaking a thread out of blocking calls in order to unblock the thread,
 such as thread cancellation or thread signalling in systems that support
 POSIX threads, or
-.B SetEvent()
+.BR SetEvent ()
 on the result of
-.B pcap_getevent()
+.BR pcap_getevent ()
 on a
 .B pcap_t
 on which the thread is blocked on Windows.  Asynchronous procedure calls
@@ -81,31 +81,31 @@ will not be in an alertable state.
 .ft R
 .PP
 Note that
-.B pcap_next()
+.BR pcap_next ()
 and
-.B pcap_next_ex()
+.BR pcap_next_ex ()
 will, on some platforms, loop reading packets from the OS; that loop
 will not necessarily be terminated by a signal, so
-.B pcap_breakloop()
+.BR pcap_breakloop ()
 should be used to terminate packet processing even if
-.B pcap_next()
+.BR pcap_next ()
 or
-.B pcap_next_ex()
+.BR pcap_next_ex ()
 is being used.
 .PP
-.B pcap_breakloop()
+.BR pcap_breakloop ()
 does not guarantee that no further packets will be processed by
-.B pcap_dispatch()
+.BR pcap_dispatch ()
 or
-.B pcap_loop()
+.BR pcap_loop ()
 after it is called; at most one more packet might be processed.
 .PP
 If
 .B PCAP_ERROR_BREAK
 is returned from
-.B pcap_dispatch()
+.BR pcap_dispatch ()
 or
-.BR pcap_loop() ,
+.BR pcap_loop (),
 the flag is cleared, so a subsequent call will resume reading packets.
 If a positive number is returned, the flag is not cleared, so a
 subsequent call will return