ffix

[thirdparty/man-pages.git] / man3 / realpath.3

diff --git a/man3/realpath.3 b/man3/realpath.3
index 1f3faa4c65cabffb31a6e48198342f73567a5a65..b3ea07e8a91b3710c5b8f246f38b6c0e0778881b 100644 (file)
--- a/man3/realpath.3
+++ b/man3/realpath.3
@@ -99,10 +99,14 @@ On Linux this function appeared in libc 4.5.21.
 .SH "CONFORMING TO"
 4.4BSD, POSIX.1-2001.
 
-In 4.4BSD and Solaris the limit on the pathname length is MAXPATHLEN
+In 4.4BSD and Solaris the limit on the pathname length is
+.B MAXPATHLEN
 (found in \fI<sys/param.h>\fP).
-SUSv2 prescribes PATH_MAX and
-NAME_MAX, as found in \fI<limits.h>\fP or provided by the
+SUSv2 prescribes
+.BR PATH_MAX
+and
+.BR NAME_MAX ,
+as found in \fI<limits.h>\fP or provided by the
 .BR pathconf (3)
 function.
 A typical source fragment would be
@@ -139,8 +143,9 @@ is specified as NULL, then
 .BR realpath ()
 uses
 .BR malloc (3)
-to allocate a buffer of up to PATH_MAX bytes
-to hold the resolved pathname,
+to allocate a buffer of up to
+.B PATH_MAX
+bytes to hold the resolved pathname,
 and returns a pointer to this buffer.
 The caller should deallocate this buffer using
 .BR free (3).
@@ -159,9 +164,11 @@ using the non-standard
 feature) it is
 impossible to determine a suitable size for the output buffer,
 .IR resolved_path .
-According to POSIX a buffer of size PATH_MAX suffices, but
-PATH_MAX need not be a defined constant, and may have to be
-obtained using
+According to POSIX a buffer of size
+.B PATH_MAX
+suffices, but
+.B PATH_MAX
+need not be a defined constant, and may have to be obtained using
 .BR pathconf (3).
 And asking
 .BR pathconf (3)
@@ -172,7 +179,9 @@ may be huge and unsuitable for mallocing memory.
 And on the other
 hand
 .BR pathconf (3)
-may return \-1 to signify that PATH_MAX is not bounded.
+may return \-1 to signify that
+.B PATH_MAX
+is not bounded.
 .LP
 The libc4 and libc5 implementation contains a buffer overflow
 (fixed in libc-5.4.13).