Proposed resolution:

This wording is relative to the FDIS.

1. In [c.files] add "stderr", "stdin", and "stdout" to a new Values section in Table 134 — Header <cstdio> synopsis:

   134 — Header <cstdio> synopsis

   Type Name(s)
   Macros:
   BUFSIZ	FOPEN_MAX	SEEK_CUR	TMP_MAX	_IONBF	stdout
   EOF	L_tmpnam	SEEK_END	_IOFBF	stderr
   FILENAME_MAX	NULL <cstdio>	SEEK_SET	_IOLBF	stdin
   Types:	FILE	fpos_t	size_t <cstdio>
   Functions:
   …
   Values:
   stderr	stdin	stdout

2. Add a new paragraph after paragraph 2 as indicated:

   2 Calls to the function tmpnam with an argument of NULL may introduce a data race (17.6.5.9) with other calls to tmpnam with an argument of NULL.
   See also: ISO C 7.9, Amendment 1 4.6.2.

   ? The macros stderr, stdin, and stdout shall expand to stderr, stdin, and stdout, respectively. [Note: This allows uses of #ifdef to detect their presence, while allowing code in other scopes to use them as identifiers. — end note]

3. In [diff.library] add "stderr", "stdin", and "stdout" to Table 150 — Standard values:

   Table 150 — Standard values

   CHAR_BIT	FLT_DIG	INT_MIN	MB_LEN_MAX
   …
   …	…	…	SHRT_MIN
   …	…	…	stderr
   …	…	…	stdin
   …	…	…	stdout
   …	…	…	UCHAR_MAX
   …

[ 2011 Bloomington ]

Closed as NAD. This is an extension request that has been an issue for over 20 years. Supporting the extension would place a burden on the underlying C library that we may not be in a position to influence.

People often define structs and classes with fields named stdin, stdout, or stderr. According to [c.files], though, these are macros.

glibc defines them to themselves, allowing their non-portable use as field names, while the Mac OS X libc defines them to either __stdoutp or (&__sF[1]), etc depending on __DARWIN_UNIX03. It's possible to allow their use while, as far as I can see, only requiring minor changes to various libc's, so C++1x should allow it.