gnu@hoptoad.uucp (John Gilmore) (12/24/87)
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.
However, most existing compilers will continue to accept the old way,
"as an extension", or will go deaf from screaming customers.
[The things I mentioned before can't be fixed, or are unlikely to be fixed,
by common extensions to the standard. Is that more what people were looking
for?]
--
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com
I forsee a day when there are two kinds of C compilers: standard ones and
useful ones ... just like Pascal and Fortran. Are we making progress yet?
-- ASC:GUTHERY%slb-test.csnetkanner@apple.UUCP (Herbert Kanner) (12/25/87)
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. > >However, most existing compilers will continue to accept the old way, >"as an extension", or will go deaf from screaming customers. > >[The things I mentioned before can't be fixed, or are unlikely to be fixed, >by common extensions to the standard. Is that more what people were looking >for?] >-- >{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com > I forsee a day when there are two kinds of C compilers: standard ones and > useful ones ... just like Pascal and Fortran. Are we making progress yet? > -- ASC:GUTHERY%slb-test.csnet Not quite. Take printf for example. True, it has to be defined with the (format, ...) notation, but it is a library function and not your problem. Declarations of the form int printf(); are completely acceptable; see Section 3.5.3.3, which states: "... an empty list in a function declaratorthat is not part of a function definition specifies that no information about the number or types of the parameters is supplied." -- Herb Kanner Apple Computer, Inc. {idi, ios, nsc}!apple!kanner
rbutterworth@watmath.waterloo.edu (Ray Butterworth) (12/29/87)
In article <7109@apple.UUCP>, kanner@apple.UUCP (Herbert Kanner) writes: > Not quite. Take printf for example. True, it has to be defined with > the (format, ...) notation, but it is a library function and not your > problem. Declarations of the form int printf(); are completely > acceptable; see Section 3.5.3.3, which states: "... an empty list in a > function declaratorthat is not part of a function definition specifies > that no information about the number or types of the parameters is > supplied." Not quite. Declarations of the form "int printf();" are not completely acceptable. What is acceptable is #undef printf int printf(); I already ran into this problem trying to compile something on an ANSI (or as close as one can get to a moving target) C compiler. The program contained the declaration "extern int istty();". This didn't work too well when the <stdio.h> file had a #define for isatty(s). It is perfectly acceptable for the header file to have a #define for almost any library function. If you want them to be real functions you have to #undef them before you use them.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/06/88)
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.)
brett@wjvax.UUCP (Brett Galloway) (01/07/88)
In article <6922@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >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.. Actually, it is not quite fair to dismiss all code that currently uses UNIX-style varargs by saying "mighty few users of <varargs.h> have done it right." As you might already have inferred from my interest in the matter, I have made great use of <varargs.h> on a UNIX 4.2BSD system, and I believe that I have done so correctly, at least consistent with varargs(3). The fact is that the current form of the standard breaks the programs in which I have used <varargs.h>. I can see why the semantics of <stdarg.h> might have to change to accommodate more architectures. What I can't see is why it was necessary to break code which works on architectures in which varargs(3) is adequate. I am not convinced why variable arguments should require function prototyping (actually, the ... notation). It seems to me that the va_alist macro could be defined to supply that if required. In that case, the argument that name conflicts between <varargs.h> and <stdarg.h> are excusable because the user would have to re-code anyhow become less compelling. Could an expert explain to me why it was not possible to define <stdarg.h> with different names and to *permit* <varargs.h> to be defined *in addition* on architectures on which its semantics could be supported, either based on top of <stdarg.h> or independent of it? I can hardly expect my existing code to port to architectures on which the semantics of <varargs.h> are unsupportable (not that I am convinced that that is an exceptionally important limitation). However, I think I can expect my existing code to work on architectures on which it currently works. -- ------------- Brett D. Galloway {ac6,calma,cerebus,isi,isieng,pyramid,tymix}!wjvax!brett
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/08/88)
In article <1178@wjvax.UUCP> brett@wjvax.UUCP (Brett Galloway) writes: >The fact is that the current form of the standard breaks the programs in >which I have used <varargs.h>. People bandy the term "breaks code" around too freely. It is highly likely that when your system vendor switches over to an ANSI conforming C compiler, it will also provide <varargs.h> which will continue to work the same way it currently does. Only a few special architectures really had trouble with implementing <varargs.h>, and only they are likely to use a different calling sequence for variadic functions. Even some of these can still whip up a <varargs.h> that will work, although in a different manner from before. The only constraint will be that you cannot readily mix use of <stdarg.h> and <varargs.h> in the same translation unit (source file). Since you're not currently doing this, it is not an issue until you have to modify your code to use <stdarg.h>, for example in order to get it to run on an architecture that doesn't support <varargs.h>. When that situation arises, you'll have to fix all your uses of <varargs.h> anyway, which means there still won't be a conflict. I use <varargs.h> a lot and have started using <stdarg.h> under control of #if __STDC__, although I don't yet have an ANSI C compiler. I don't have any problems with this.
jss@hector.UUCP (Jerry Schwarz) (01/08/88)
In article <1178@wjvax.UUCP> brett@wjvax.UUCP (Brett Galloway) writes: > >The fact is that the current form of the standard breaks the programs in >which I have used <varargs.h>. I can see why the semantics of <stdarg.h> might >have to change to accommodate more architectures. What I can't see is why it >was necessary to break code which works on architectures in which varargs(3) > Nothing in the Standard breaks anything. Only implementations break code. This is an important distinction that the committee seems to have taken into account by providing for a new header file to contain the new varargs stuff. If you have old code that includes <varargs.h> it will continue to work if your compilation system continues to provide <varargs.h>. You can't mix <vararg.h> and <stdargs.h> in a single file, but it seems to me unlikely that you would want to. >I can hardly expect my existing code to port to architectures on which the >semantics of <varargs.h> are unsupportable (not that I am convinced that that >is an exceptionally important limitation). However, I think I can expect my >existing code to work on architectures on which it currently works. I agree and since I would expect compiler vendors to continue to supply varargs.h on systems where they do so now I would expect your code to continue to work. I expect compiler vendors to attempt to satisfy their customers (as any other vendor would) and to make conversion from older C to any new ANSI C systems easy. What this will mean in individual cases will depend on individual situations. For example, I would not expect a compiler vendor who currently supplies a compiler that put strings in writable memory to suddenly switch to making them unwritable. Nor would I expect a compiler vendor that currently accepts long identifiers to suddenly cut back because the standard only requires a smaller number. Jerry Schwarz
brett@wjvax.UUCP (Brett Galloway) (01/11/88)
In article <6979@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <1178@wjvax.UUCP> brett@wjvax.UUCP I wrote: >>The fact is that the current form of the standard breaks the programs in >>which I have used <varargs.h>. >People bandy the term "breaks code" around too freely. Hmmm. <stdarg.h> is not compatible with <varargs.h>. Further, I understood that I had no guarantee of <varargs.h> semantics being provided; in fact, the name spaces of <stdarg.h> and <varargs.h> conflict. >It is highly likely that when your system vendor switches over to an >ANSI conforming C compiler, it will also provide <varargs.h> which >will continue to work the same way it currently does. Only a few >special architectures really had trouble with implementing <varargs.h>, >and only they are likely to use a different calling sequence for >variadic functions. Even some of these can still whip up a <varargs.h> >that will work, although in a different manner from before. >The only constraint will be that you cannot readily mix use of ><stdarg.h> and <varargs.h> in the same translation unit (source file). >Since you're not currently doing this, it is not an issue until you >have to modify your code to use <stdarg.h>, for example in order to >get it to run on an architecture that doesn't support <varargs.h>. >When that situation arises, you'll have to fix all your uses of ><varargs.h> anyway, which means there still won't be a conflict. That's what I was asking. I understood that <stdarg.h> was to *replace* <varargs.h>; <varargs.h> would no longer be supported because of the name conflicts between it and <stdarg.h>. I thought one of the goals of ANSI C was to regularize the name space. If a vendor provides a <varargs.h> which retains its semantics but conflicts with <stdarg.h> (as it must, as <stdarg.h> names conflict with <varargs.h>), then neither that include file nor my code which uses it is ANSI C conformant. Worse, it is a kludge. All I asked was to take this one teeny step further -- change the names in <stdarg.h> and require <varargs.h> also to be defined with its current semantics where possible. No conflict. Maximum portability. Everybody's happy. -- ------------- Brett D. Galloway {ac6,calma,cerebus,isi,isieng,pyramid,tymix}!wjvax!brett
gwyn@brl-smoke.UUCP (01/12/88)
In article <1183@wjvax.UUCP> brett@wjvax.UUCP (Brett Galloway) writes: >All I asked was to take this one teeny step further -- change the names >in <stdarg.h> and require <varargs.h> also to be defined with its >current semantics where possible. We cannot reasonably do the latter. ANSI C must cater to architectures and efficient C implementations where <varargs.h> is problematic. As to the former, I've explained why this isn't a problem about as well as I can..
mjy@sdti.UUCP (Michael J. Young) (01/15/88)
In article <3334@ulysses.homer.nj.att.com> jss@hector (Jerry Schwarz) writes: >Nothing in the Standard breaks anything. Only implementations break >code. Seen on a bumper sticker on the car of an X3J11 member: "Standards don't break code. Implementations do." -- Mike Young - Software Development Technologies, Inc., Sudbury MA 01776 UUCP : {decvax,harvard,linus,mit-eddie}!necntc!necis!mrst!sdti!mjy Internet : mjy%sdti.uucp@harvard.harvard.edu Tel: +1 617 443 5779 "Are we having fun yet?" -- Zippy