NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/lang/cplus/18521

Text File | 1992-12-29 | 5.6 KB | 117 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!microsoft!hexnut!jimad
From: [e-mail] (Jim Adcock)
Subject: Re: Standard library functions and macros
Message-ID: <[e-mail]>
Date: 29 Dec 92 21:35:48 GMT
Organization: Microsoft Corporation
References: <[e-mail]> <[e-mail]> <[e-mail]>
Lines: 106

In article <[e-mail]> [e-mail] (Jerry Schwarz) writes:
|In article <[e-mail]>, [e-mail] (Jim Adcock) writes:
|
||> Yes, assuming by "the meaning" of a C program you mean "the intent
||> of the original C author."  For example, the original author can
||> do a '#undef putchar' with "the meaning" that in this compilation his/her
||> intent is that putchar be implemented out-of-line.  Under the proposed
||> required changes to C++ implementations, "the meaning" of the original
||> C author would be silently changed.  Thus someone porting this C program
||> to C++ finds [or worse, DOESN'T FIND!] that C++ silently changes the
||> intent of the original author.
||>
|
|There is no such guarantee in standard C.  If there is a #include <stdio.h>
|present, a compiler is free to inline putchar whether or not the user
|does #undef putchar.  The constraint is in the other direction.  A
|programmer can't use "putchar" in specific ways unless an #undef appears.

On the contrary, standard C DOES guarantee implementors the right
to implement standard functions as macros, DOES guarantee that
programmers can get to a guaranteed underlying actual function
call implementation of the standard functions, and DOES guarantee that the
#undef will get the programmer to the function call implementation.

See ANSI X3.159-1989 4.1.6

The fact that macro implementations are allowed under ANSI reserves the
entirety of the name space of a standard function to the library if
the header is included.  If the programmer doesn't like this, then
the programmer is permitted to simply declare the function required
out of the standard library, and just use that.  Which your changes
will also break.

It seems pretty silly to think that ANSI-C++ can at this late
date attempt to take the largest portion of the standard functions
name space back away from the implementors without having negative
consequences to conforming programs.

|If Jim is saying that in a particular implementation the #undef has
|this effect and believes that effect should be preserved, then nothing
|stops an implementation from giving the #undef the same effect in C++,
|although I suspect he will have to lobby his vendors very hard to
|convince them to implement such a feature.

If this is possible, then show me how to do it, because the solution
is not obvious to me.

||> Also, note that a conforming C implementation of these standard library
||> functions using macros can accept a superset of the parm types that a
||> C++ extern implementation or inline implementation can accept.  A macro
||> implementation is somewhat analogous to the C++ situation where a
||> templated function is used.  Thus, requiring that a macro *not* be
||> used for implementation requires that some possible conforming programs
||> will no longer be accepted.  Still, breaking such a program is a MUCH better
||> situation that silently accepting a program while changing "the meaning"
||> of that program.
||>
|
|I'm not sure I understand this.  Is the intented example that
|there might be something like
|
|    #define putchar __myputchar
|
|And __myputchar would then be callable in different ways?

No, the intended example would be if a macro-defined putchar were
called with a parm not of char [actually int] type.  My claim is that
a conforming implementation can have a macro-definition that accepts
a superset of the parms that are strictly required to be accepted.

This might argue that it would be good to allow implementors to
use multiple inlines for some standard C library calls, such that
those inlines are optimal for a given parm type.  Or that templated
versions of some of the C standard functions could be appropriate.
But in these cases the entirety of the name space would remain to
the implementor, not to the programmer.  The problem lies with
the fact that now, at this late date, you guys are trying to take
part of the name space back from the implementor returning it to the
programmer to do with as they will.  This is certain to break things.

||> The other side of the coin is that it then becomes impossible for
||> programmers to specify *whether or not* they want an inline implementation,
||> which is a stated intent of the original ANSI-C standard library
||> macro/function implementations.
||>
|
|I've never seen such an intent expressed.  Where is it stated?

See ANSI X3.159-1989 4.1.6

|Contrary to the way Jim uses the word, I don't consider
|whether a compiler inlines calls to a library function
|part of the "meaning" of that function.  And neither
|as far as I can tell does the standard.

I said the "meaning" of a programmer's PROGRAM would be silently changed,
not that the "meaning" of the function would be silently changed.  You
guys are REQUIRING implementors to break existing contracts between
implementations and conforming programs expecting those implementations.
Making these silent changes are not a trivial matter, and needed to be
reconsidered in a serious manner.

Again, I suggest that unless you have a very serious reason for requiring
changes to existing standard C libraries, leave well enough alone.  There is
no reason why you have to mess with the historically reserved C name
space and its implementation.