[comp.lang.c++] Ansi C compatibility

dld@F.GP.CS.CMU.EDU (David Detlefs) (01/06/88)

I'm trying to modify our include files here at CMU so that we can use
them directly from C++.  I would like to make any modifications in
such a way that the declarations may also be used by any ANSI-standard
C compilers we eventually get.  I have two questions:

1) First of all, is there any sort of movement towards standardization
of preprocessor variables that are defined by various compilers?
We're operating under the assumption that any ANSI-C compiler will
define "_ansi_c_", and will modify any of those (as well as CC)
locally to do this.  Does anyone have a better idea?

2) I thought there was a problem when I read that the ANSI standard
requires functions of no arguments to be declared using the syntax

  extern int foo(void);

until I discovered that The Book allows this syntax in C++ as well.
A similar situation exists with regard to ellipses.  The ANSI standard
requires that printf be declared as in

  extern int printf(const char*,...);

whereas a C++ version would be (as per The Book)

  extern int printf(const char* ...);

Note the missing comma.  Now, it turns out that the version of cfront
I'm using (1.1 -- don't ask why) accepts the ANSI-style syntax without
difficulty.  Is this just a quirk, or is there some guarantee that
this will continue to be the case in the future?

P.S.  Can someone explain to me the rationale behind the ANSI
decision?  I understand that it has something to do with varargs, but
I don't know what.  The ANSI restriction that there must be at least
one fixed argument seems obviously artificial.

Thanks.

Dave

gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/06/88)

In article <590@PT.CS.CMU.EDU> dld@F.GP.CS.CMU.EDU (David Detlefs) writes:
>We're operating under the assumption that any ANSI-C compiler will
>define "_ansi_c_", and will modify any of those (as well as CC)
>locally to do this.  Does anyone have a better idea?

Yes, how about using the symbol __STDC__ that an ANSI C implementation
is required to provide a predefinition for?

>P.S.  Can someone explain to me the rationale behind the ANSI
>decision?  I understand that it has something to do with varargs, but
>I don't know what.  The ANSI restriction that there must be at least
>one fixed argument seems obviously artificial.

Some implementations would much prefer to pass "normal" non-variadic
arguments in a different, more efficient way than what they would have
to use for variadic arguments.  The fixed argument is for an "anchor"
to help va_start locate the first variadic argument; this could be
done with the help of compiler intrinsics, but it was felt that many
implementations would not need such kludges if an anchor were present.