From: daveg@synaptics.com (Dave Gillespie)
Newsgroups: comp.lang.c++
Subject: Re: Standard library functions and macros
Date: 25 Dec 92 03:38:47 GMT
	<BzFM01.CD@frumious.uucp> <1992Dec23.214139.24948@microsoft.com>
Organization: Synaptics, Inc., San Jose, CA
In-reply-to: jimad@microsoft.com's message of 23 Dec 92 21:41:39 GMT

In article <1992Dec23.214139.24948@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
> In article <BzFM01.CD@frumious.uucp> uunet.ca!frumious!pat writes:
> |Suppose the C++ standard said that standard library functions must
> |have external linkage, and prohibited implementing them as macros.
> |Would this change the meaning of any C programs if compiled as C++?

> 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.

I have to disagree here.  Usually when language standards talk about
the "meaning" of a program, they are referring only to whether or not
it is correct, and what its behavior will be if it is correct.  As I
understand it, all the talk about macros in the C standard is there
purely to reserve to implementors the right to provide fast macro
implementations of library functions.

If the only effect of `#undef putchar' is to change whether or not
a fast macro or a slow equivalent function is used, i.e., if it only
affects performance and not results, then I'd say it's improper for
a standard to legislate it one way or another, or for a portable
program to depend on it.

Even if `putchar' were a function instead of a macro, don't compilers
sometimes inline-expand functions anyway?  A good optimizing compiler
ought to be able to do this, whether or not there are "inline"
declarations in the language.  As far as I know, there is no way in
C to require that a function be compiled out-of-line.  The only
language I can think of offhand that does provide for this is Common
Lisp.

I don't have a copy of the standard handy, but my K&R II uses language
like "if it is a macro" in its description of "putchar".  Doesn't that
imply that it is perfectly legal for a compiler to implement `putchar'
as a function, not a macro?

In fact, is there anything preventing a C implementation from putting

    static int putchar(int c) { return putc(c, stdout); }

in its <stdio.h> header?  Is there anything preventing a compiler
from expanding a call to "putchar" inline, given this definition?
(Urgh, I wish I had a copy of the standard around...)

> 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.

Well, yes, but can a conforming, i.e., portable program depend on this?
My K&R says `int putchar(int c)'.  I have to assume that this is what
I have when I write a call to `putchar'.  Even if I have a whiz-bang
extended C compiler that allows me to pass other things to `putchar',
I have to assume any code that uses this will break when I move to
another compiler, be it a C++ compiler or just another vendor's C.

> Thus, requiring that a macro *not* be
> used for implementation requires that some possible conforming programs
> will no longer be accepted.

As I understand it, even if it's required for `putchar' and to `putc'
to be macros, it is still legal for their definitions to be

    #define putc(c,f) fputc(c,f)
    #define putchar(c) putc(c,stdout)

which means that a conforming program couldn't possibly pass anything
to `putchar' which it couldn't also pass to `fputc', which is certainly
allowed to be a function.

What other properties of `putchar' being a macro or not could a
conforming program depend on?

> 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.

Could you please provide a quotation?

> So then the next person has to somehow magically discover that the "meaning"
> of these "standard" functions have been changed from the C++ standard have
> been changed from the C standard....

What has actually changed, that this next maintainer could perceive?
Okay, the performance has changed some, but performance can change even
when you install a new rev of the "same" compiler.

								-- Dave
--
Dave Gillespie
  daveg@synaptics.com, uunet!synaptx!daveg
  or: daveg@csvax.cs.caltech.edu
Newsgroups: comp.lang.c++