Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Another thing broken in ANSI C
Message-ID: <6922@brl-smoke.ARPA>
Date: 6 Jan 88 00:28:15 GMT
References: <3726@hoptoad.uucp>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 34

In article <3726@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>Another thing that ANSI C disallows is ALL prior uses of functions
>with variable numbers of arguments.  All such functions must be declared
>and defined with ", ..." notation, which did not exist before ANSI C.

I think that's overstating the situation.  Certainly the primary use of
variadic (variable number and/or type of arguments) functions is the
*printf*() family, which have declarations in <stdio.h>.  Although the
ANSI C implementation may need to patch up the <stdio.h> declarations,
the application is unaffected -- unless it assumed that *printf*()
could be called without including <stdio.h>, as was unfortunately done
in the original K&R C book.  I started including <stdio.h> before any
use of *printf*() several years ago, before the ANSI variadic stuff, as
a matter of safe style, but I realize that not everyone was so cautious.

In fact, many implementations will probably have the same interface for
variadic functions as they have been using to date for all functions,
so this is a non-issue for those implementations.  The ones that really
needed the variadic indicator assist will probably be glad to have it.

My experience has been that mighty few users of <varargs.h> have done
it right (i.e. strictly according to the rules) anyway..

Also note that in the UNIX (System V) world, open(), ioctl(), and
fcntl() are variadic functions.  I have seen several approaches for
dealing with this in application code, none of them universal.  If
the function specifications are revised to use official ANSI C
variadic arguments, it would undoubtedly be an improvement, but this
too conflicts with current code that contains its own declarations
for these functions.  The real problem seems to be, how can existing
code be considered "right" according to standards that assure
portability when it wasn't fully portable in the first place?  (Yes,
I know we didn't have any choice at the time.  It's unfortunate, but
just another one of those unavoidable facts of life.)