The description is below, but I believe its not quite correct. C11 adds the "x" mode, so its not a glibc thing anymore. See, for example, https://www.securecoding.cert.org/confluence/display/seccode/FIO03-C.+Do+not+make+assumptions+about+fopen%28%29+and+file+creation. I understand uClibc may not be C11 compliant (and may not even desire it). But "x" mode has security implications, and claiming its a compat option may not be doing it justice. ───── Support an fopen() 'x' flag for exclusive mode (glibc-compat) ─────┐ │ UCLIBC_HAS_FOPEN_EXCLUSIVE_MODE: │ │ │ │ Answer Y to support a glibc extension to allow passing │ │ additional 'x' flag in the mode string for fopen() to specify that │ │ the file should be open()ed with the O_EXCL flag set. │ │ │ │ Most people will answer N. │ │ │ │ Symbol: UCLIBC_HAS_FOPEN_EXCLUSIVE_MODE [=y] │ │ Prompt: Support an fopen() 'x' flag for exclusive mode (glibc-compat) │ │ Defined at extra/Configs/Config.in:1728 │ │ Location: │ │ -> String and Stdio Support
This library aims to implement SUSv4 (aka POSIX-2008 aka IEEE Std 1003.1-2008). $ grep "through SUSv4" TODO *) Go through SUSv4 So yes, SUSv4 compliants is on the TODO list. Please do not file bugs about those but send proper and complete patches to handle SUSv4. Regarding this issue here. There is no 'x' mode in http://pubs.opengroup.org/onlinepubs/9699919799/functions/fopen.html so we rightfully have it as an extension. You may want to send a patch that adds ...glibc extension (and C11 requirement).. to the help-text, sure. TIA,