Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!ucbcad!ucbvax!ulysses!hector!jss From: jss@hector.UUCP (Jerry Schwarz) Newsgroups: comp.lang.c Subject: Re: Another thing broken in ANSI C Message-ID: <3334@ulysses.homer.nj.att.com> Date: 8 Jan 88 15:03:44 GMT References: <3726@hoptoad.uucp> <6922@brl-smoke.ARPA> <1178@wjvax.UUCP> Sender: daemon@ulysses.homer.nj.att.com Reply-To: jss@hector (Jerry Schwarz) Organization: AT&T Bell Labs, Murray Hill Lines: 37 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 . I can see why the semantics of 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 it will continue to work if your compilation system continues to provide . You can't mix and 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 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