Must stdin, stdout, and stderr be macros?
Keith Thompson
I think the answer is yes, but there's an oddity in the wording in the
standard (and I make no claim that it's anything more than that).
C99 7.19.1 says:
The header <stdio.h> declares three types, several macros, and
many functions for performing input and output.
...
The macros are
...
stderr
stdin
stdout
which are expressions of type "pointer to FILE" that point to the
FILE objects associated, respectively, with the standard error,
input, and output streams.
In context, this says they're macros -- but the descriptions of all
the other macros use the phrase "which expands to". For stderr,
stdin, and stdout, it says they *are* expressions (which, if they're
macros, isn't strictly correct).
If they're allowed to be, say, declared objects rather than macros,
then 7.19.1p1 should be changed to allow for these declarations, and
the description of stderr, stdin, and stdout shouldn't be part of the
page-long run-on sentence.
More plausibly, if they *are* required to be macros, the phrase "which
are expressions" should be changed to "which expand to expressions".
Is there any good reason why they're required to be macros?
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Douglas A. Gwyn
> stderr
> stdin
> stdout
> In context, this says they're macros -- but the descriptions of all
> the other macros use the phrase "which expands to". For stderr,
> stdin, and stdout, it says they *are* expressions (which, if they're
> macros, isn't strictly correct).
Probably we should also have used "expand to" instead of "are"
here also. It's pretty clear from context that that is what
was meant.
> Is there any good reason why they're required to be macros?
#define stderr (&__iob[2])
Tony Finch
>Keith Thompson wrote:
>
>> Is there any good reason why they're required to be macros?
>
>#define stderr (&__iob[2])
Although that's a common implementation, it's a really bad idea because it
locks sizeof(FILE) into your ABI. This hurt FreeBSD when they added locking
to stdio...
Tony.
--
f.a.n.finch <d...@dotat.at> http://dotat.at/
SHETLAND ISLES: SOUTHWEST BECOMING VARIABLE 3 OR 4. RAIN AT FIRST. MODERATE OR
GOOD, OCCASIONALLY POOR AT FIRST. SLIGHT OR MODERATE.
Jordan Abel
Tony Finch wrote:
> "Douglas A. Gwyn" <DAG...@null.net> wrote:
>>Keith Thompson wrote:
>>
>>> Is there any good reason why they're required to be macros?
>>
>>#define stderr (&__iob[2])
>
> Although that's a common implementation, it's a really bad idea because it
> locks sizeof(FILE) into your ABI. This hurt FreeBSD when they added locking
> to stdio...
Weren't they gonna fix that for 6?
And didn't they end up... not doing so?
Keith Thompson
That's a good reason why they should be *allowed* to be macros. But
if they were allowed to be either macros or declared objects, would it
have introduced any real problems?
It's not a big deal either way; at worst, it's a minor and harmless
overspecification. An implementation could easily meet the
requirement by declaring objects and macros:
extern FILE *__stderr;
...
#define stderr __stderr
...
Roland Illig
DragonFly BSD has fixed this problem, although they first weren't sure
if the standard permits FILE to be defined as an incomplete type.
Roland
Jordan Abel
Even if it's not, that doesn't mean you can't be careful with it. (It
might even be useful to let your macros use members of the struct
directly without doing any array indexing on FILEs)
Douglas A. Gwyn
> That's a good reason why they should be *allowed* to be macros. But
> if they were allowed to be either macros or declared objects, would it
> have introduced any real problems?
I can't seem to find it in the current spec, but in C89 I think
we had wording to the effect that in the Library section "macro"
meant "may be an actual macro or might not be".
Keith Thompson
I just looked in my copy of the C90 standard (search for the word
"macro" starting at the beginning of section 7), and I didn't see
anything along those lines. There is the usual stuff saying that
functions may also be defined as macros, of course.
So as far as I can tell, this:
#include <stdio.h>
int main(void)
{
#ifdef stdin
printf("stdin is a macro\n");
#else
printf("stdin is not a macro\n");
#endif
return 0;
}
must print "stdin is a macro" in any conforming implementation.
The standard *could* have been written to allow it to print "stdin is
not a macro", but it wasn't -- which is fine with me (the increased
flexibility for implementers would have been trivial).
lawrenc...@ugs.com
>
> The standard *could* have been written to allow it to print "stdin is
> not a macro", but it wasn't -- which is fine with me (the increased
> flexibility for implementers would have been trivial).
I think that they actually were macros in all known implementations, so
there didn't seem to be much point in allowing that trivial flexibility.
-Larry Jones
That gives me a FABULOUS idea. -- Calvin