Paul Eggert <yyyyyy@xxxxxxxxxxx> wrote, on 23 Nov 2006:
>
> > when the getchar() description says:
> >
> > "The getchar() function shall be equivalent to getc(stdin)."
> >
> > one interpretation is that "getc" means whatever that identifier
> > refers to in the code calling getchar(), the other is that "getc"
> > means the getc() function defined by the standard. It doesn't take
> > much of a clue to realise that the latter is the intended meaning.
>
> If it doesn't take much of a clue, then many implementations are
> clueless, since they take the former interpretation, not the latter!
>
> For example, consider this common implementation of getchar:
>
> #define getchar() getc (stdin)
>
> This implementation does not conform to what you are saying is the
> obvious interpretation of the standard. But this approach is used by
> Solaris and by many other POSIX implementations. So there is a real
> problem here.
So far, I've assumed we were talking about the required behaviour
of functions. What you are raising here is a separate issue about
macro versions of functions and whether they behave the same as
the real function.
> In contrast, the problems we've identified for creat and dup2 are not
> real problems in practice. No implementation that I know of has any
> real issue with argument promotion; they all take the obvious
> interpretation. I suppose it wouldn't hurt to fix the wording, but it
> ought to be lower priority than clarifying the spec for getchar(),
> cproj(), and the like, where we _do_ have real problems.
I still don't believe there is a problem with the way getchar(),
cproj(), etc. are defined in the standard.
The getchar() page describes the behaviour of the getchar() *function*.
Thus the arguments I presented earlier still apply (i.e. when the
description refers to getc() it means the standard getc() function).
Elsewhere the standard says that functions can also be implemented as
macros. Obviously if a function is also implemented as a macro, the
macro must behave the same as the function (except for a few special
cases like getc() being allowed to evaluate the stream argument more
than once). Therefore I believe what you have identified here is,
purely and simply, a bug in implementations that have a macro
definition of getchar that uses the getc identifier. There is a
trivial fix: just "expand out" the getc macro in the definition of
getchar. Or perhaps a better fix would be to make the current getc
macro definition be a definition of __getc, and then:
#define getc(x) __getc(x)
#define getchar() __getc(stdin)
Other similar cases should also be trivial to fix (e.g. if getc hadn't
been a macro, the definition of getchar could change from using getc
to _getc).
--
Geoff Clare <yyyyyyy@xxxxxxxxxxxxx>
The Open Group, Thames Tower, Station Road, Reading, RG1 1LX, England
|