<feed xmlns='http://www.w3.org/2005/Atom'>
<title>fortify-headers/tests/test_realpath_null.c, branch master</title>
<subtitle>Standalone portable header-based implementation of FORTIFY_SOURCE=3 
</subtitle>
<id>http://git.dustri.org/fortify-headers/atom?h=master</id>
<link rel='self' href='http://git.dustri.org/fortify-headers/atom?h=master'/>
<link rel='alternate' type='text/html' href='http://git.dustri.org/fortify-headers/'/>
<updated>2026-04-01T18:37:02Z</updated>
<entry>
<title>Make do even if PATH_MAX isn't defined</title>
<updated>2026-04-01T18:37:02Z</updated>
<author>
<name>jvoisin</name>
</author>
<published>2026-04-01T18:37:02Z</published>
<link rel='alternate' type='text/html' href='http://git.dustri.org/fortify-headers/commit/?id=60c096eb0433f7573c768a2c8523abd3c11e0720'/>
<id>urn:sha1:60c096eb0433f7573c768a2c8523abd3c11e0720</id>
<content type='text'>
As explained in `man realpath(3)`:

&gt; The POSIX.1-2001 standard version of this function is broken by design,
&gt; since it is impossible  to determine  a  suitable  size  for  the  output
&gt; buffer, resolved_path.  According to POSIX.1-2001 a buffer of size PATH_MAX
&gt; suffices, but PATH_MAX need not be a defined constant, and may have to  be
&gt; obtained  using  pathconf(3).  And asking pathconf(3) does not really help,
&gt; since, on the one hand POSIX warns that the result of pathconf(3) may be huge
&gt; and unsuitable for mallocing memory, and on the other hand pathconf(3) may
&gt; return -1 to  signify  that  PATH_MAX  is  not  bounded.   The  re‐ solved_path
&gt; == NULL  feature,  not standardized in POSIX.1-2001, but standardized in
&gt; POSIX.1-2008, allows this design problem to be avoided.

So we can either not compile, or be pragmatic, and define PATH_MAX to a sane
value, like 4096, which is the one used on Linux and some/most BSD.

This commit also adds two tests to ensure that things aren't catastrophically
broken by this change.
</content>
</entry>
</feed>
