AT&T C compilers

Guy Harris guy at auspex.UUCP
Mon Feb 27 07:30:46 AEST 1989


>Yes, it's legal, but it explicitly amounts to an "old style" declaration
>of the "bob" function, with all the consequences thereof.

That's what I figured.

>That's right.  Old C++ did not use func(void) but rather just func().
>This may be changing toward ANSI C style, but I don't know for sure.

S ("S", by analogy to "K&R") says in "15.3 Anachronisms":

	The extensions presented here may be provided to make it easier
	to use C programs as C++ programs.  Note that each of these
	features has undesirable aspects.  An implementation providing
	them should also provide a way for the user to ensure that they
	did not occur in a source file.

	...

	The keyword 'void' may be used to indicat that a function takes
	no arguments, thus '(void)' is equivalent to '()'.

Assuming this is still the case, then 1) ANSI C style is *supported*,
but 2) it's deprecated.  I don't know what the "undesirable aspect" of
the extension in question is; perhaps it's the mismatch between
declaration and use - you call a no-arguments function as "foo()", but
declare it as "foo(void)".

I do consider that mismatch undesirable, although eliminating it in C89
(or C90?) is impractical, given the volume of old code out there. 
Assuming a new version of the C standard comes out sometime in the
future, I would like to see "int foo()" mean "'foo' is a function that
takes no arguments and returns 'int'" in that new version; by that time,
presumably, all the old-style non-prototype function declarations and
definitions would have gone away.  (The May 13, 1988 draft indicates
that old-style function declarators and definitions are "obsolescent
features".)

I would also like to see compilers at least have an option to warn about
1) old-style function declarators and definitions, 2) functions not
declared as "void" that return no value, and 3) functions declared
"implicitly", in order to encourage the use of prototype declarations
and definitions and the improved type-checking that would result.  (As I
remember, "cfront" produces some or all of those warnings if it detects
any of the above items in C++ programs fed to it.)



More information about the Comp.lang.c mailing list