🚀 go-pugleaf

From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>


mod.std.c Digest            Fri, 11 Oct 85       Volume 11 : Issue   2

Today's Topics:
                                #elif
                         Function prototypes
----------------------------------------------------------------------

Date: Mon, 7 Oct 85 21:24:27 EDT
From: Doug Gwyn (VLD/VMB) <gwyn@BRL.ARPA>
Subject: #elif
To: cbosgd!std-c@LOCAL.Berkeley.EDU

In the April 30, 1985 X3J11/85-045, section C.8, the #elif
directive is not explained and the term "control condition"
is used but not defined (presumably it means "controlling
constant expression").  I think the paragraph that mentions
"control condition" is attempting to include #elif, but
that is not clear.

Also, when skipping, "directives are verified for
correctness, but processed only to keep track of the level
of nested conditionals"; what does this mean?  (Lines
starting with # checked for a known preprocessing keyword
after the # ?  There is a limit to what can be checked in
the code being skipped.)

------------------------------

Date: Thu, 10 Oct 85 15:59:29 mdt
From: ihnp4!alberta!myrias!cg (Chris Gray)
Subject: Function prototypes
To: alberta!ihnp4!cbosgd!std-c

A question of interpretation about function prototypes:

Does the use of the new style function headers in a function definition
qualify as a 'function prototype being in scope' for that function?

For example:

void f(float p) {
    if (p >= 0.0)
        f(p - 1.0);
}

Is 'p - 1.0' passed to the recursive call as a 'float' or as a 'double'?
Both cases are self-consistent, but which is in effect will affect what
other callers of 'f' are supposed to do. If this style of header doesn't
constitute a function prototype, do I really have to do this:

extern void f(float p);
static void f(float p)
{
    ...
}

The sentence reading "The following equivalent definition uses the prototype
form for the parameter declarations:" from the end of the second paragraph
on page 60 of the April 30 ANSI draft seems to imply that I really do have
to use the second form. I would suggest that the use of the prototype form
constitute an actual prototype. The alternative is that new-style functions
must ALWAYS have a prototype in scope in the file they are defined in.
This seems unnecessarily ugly. Allowing the prototype form to BE a prototype
won't break any existing programs since they won't be using it.

			Chris Gray {...,ihnp4}!alberta!myrias!cg

------------------------------

End of mod.std.c Digest - Fri, 11 Oct 85 07:43:53 EDT
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.