A request was made to reduce the value of {_POSIX_LINK_MAX} from
the value of 8 specified for it in the POSIX.1‐1990 standard to
2. The standard developers decided to deny this request for
several reasons:
* They wanted to avoid making any changes to the standard that
could break conforming applications, and the requested change
could have that effect.
* The use of multiple hard links to a file cannot always be
replaced with use of symbolic links. Symbolic links are
semantically different from hard links in that they associate
a pathname with another pathname rather than a pathname with
a file. This has implications for access control, file
permanence, and transparency.
* The original standard developers had considered the issue of
allowing for implementations that did not in general support
hard links, and decided that this would reduce consensus on
the standard.
Systems that support historical versions of the development
option of the ISO POSIX‐2 standard retain the name
{_POSIX2_RE_DUP_MAX} as an alias for {_POSIX_RE_DUP_MAX}.
{PATH_MAX}
IEEE PASC Interpretation 1003.1 #15 addressed the
inconsistency in the standard with the definition of
pathname and the description of {PATH_MAX}, allowing
application developers to allocate either {PATH_MAX} or
{PATH_MAX}+1 bytes. The inconsistency has been removed by
correction to the {PATH_MAX} definition to include the null
character. With this change, applications that previously
allocated {PATH_MAX} bytes will continue to succeed.
{SYMLINK_MAX}
This symbol refers to space for data that is stored in the
file system, as opposed to {PATH_MAX} which is the length
of a name that can be passed to a function. In some
existing implementations, the pathnames pointed to by
symbolic links are stored in the inodes of the links, so it
is important that {SYMLINK_MAX} not be constrained to be as
large as {PATH_MAX}.
