fopen path-length failure: ENAMETOOLONG reliance on libc implementation

The C standard library function fopen specifies a NULL return when a file cannot be opened, but leaves errno population unspecified for many failure conditions. On POSIX-conformant systems, a filename whose length exceeds PATH_MAX typically results in a NULL return and errno set to ENAMETOOLONG, yet the standard imposes no such guarantee, and non-POSIX libc implementations may return NULL without modifying errno or may employ alternative error indicators. This inconsistency creates ambiguity for portable software that seeks to differentiate path-length rejections from other open failures through errno inspection. A precise goal would clarify the conditions under which fopen reliably populates errno for path-length violations, and whether programmer guards such as pre-checking string length against system constants constitute universally portable practice.

• Under what conditions does fopen set errno versus returning NULL alone when a filename exceeds implementation-defined length limits?
• In what ways do major C library implementations differ in ENAMETOOLONG reporting for paths exceeding PATH_MAX?
• Is the absence of errno after a path-length fopen failure strictly conforming to the C standard?