1 files changed, 10 insertions, 4 deletions
diff --git a/faq/foo_max.mdwn b/faq/foo_max.mdwn
index 5f736680..ccd09904 100644
--- a/faq/foo_max.mdwn
+++ b/faq/foo_max.mdwn
@@ -18,7 +18,12 @@ For porting guidelines, see [[hurd/porting/guidelines#PATH_MAX_tt_MAX_PATH_tt_MA
 
 # Is it really standard not to define them?
 
-These macros are indeed optional in Posix, so not defining them remains standard-compliant.
+These macros are indeed optional in Posix, so not defining them remains
+standard-compliant. Quoting the standard:
+
+    A definition of one of the symbolic constants in the following list shall be
+    omitted from <limits.h> on specific implementations where the corresponding
+    value is equal to or greater than the stated minimum, but is unspecified.
 
 Their definition was actually not completely clear, Posix 1990 was ambiguous
 about it including `\0` or not, it was made clear later on that it does include
@@ -30,13 +35,14 @@ even depend on its revision, so to be rather queried at runtime with `pathconf`.
 # But it's really convenient! Isn't allocating dynamically much more complex?
 
 `FOO_MAX` constants are most often used as “reasonable size to allocate a
-path”. On Linux it is typically 4096, which is not that reasonable (a whole
+path”. On Linux `PATH_MAX` is typically 4096, which is not that reasonable (a whole
 memory page, thus a TLB lookup) when manipulating a lot of paths. Allocating
 dynamically would use much less memory.
 
 Most often interfaces can be made to properly allocate dynamically. Notably,
-since Posix 2008 `realpath(path, NULL)` and `getcwd(NULL, 0)` allocate the path
-dynamically.
+since Posix 2008 `realpath(path, NULL)` allocates the path dynamically.
+Posix 2008 does not say that `getcwd(NULL, 0)` allocates the path dynamically,
+but BSD, Linux, and even windows do.
 
 In general, using `FOO_MAX` in source code (with a large value) leads to code
 that is not actually checking against overflows. `PATH_MAX` being 4096 is