Xref: utzoo comp.lang.c:32778 comp.std.c:3742 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!dg!fs06!pds From: pds@lemming.webo.dg.com (Paul D. Smith) Newsgroups: comp.lang.c,comp.std.c Subject: Re: To ANSI or not to ANSI (was: Re: Just a minor new twist on free()) Message-ID: Date: 10 Oct 90 13:32:45 GMT References: <1990Oct09.132005.8435@virtech.uucp> Sender: root@dg.dg.com Organization: NSDD/ONAD, Data General Corp., Westboro, MA Lines: 56 In-reply-to: cpcahil@virtech.uucp's message of 9 Oct 90 13:20:05 GMT [] In article pds@lemming.webo.dg.com (Paul D. Smith) writes: [] >My question is: since we now have a standard (whatever you may think [] >of it, it is an internationally accepted definition of the C [] >programming language), why do we have so much reluctance to [] >embrace it? In particular, how can you justify labelling a [] >program "non-portable" if it follows the ANSI standard? [] [] The big question is: [] [] How does it effect the performance, reliability, and/or [] readability of your code to make it "portable" to non-ANSI [] compilers? These are good questions; another very important, and (to me) central question is: What does it mean for a program to be "portable to non-ANSI compilers"? By this I mean, if we want to be back-portable, what features should we not use and which are we allowed to use? Most of the replies I got said things like: In general the ANSI features added are not hard to avoid using, except for things like enums and <> ... so go ahead and use the common (but non-K&R I) features, but avoid the uncommon ones; they're not portable. This seems to me to be inherently unportable. Sure, most compilers support some kind of enum statement, but what are the semantics? I've seen compilers which do not treat enum's as int's without casts, I've even seen one which warns you about improper casts if you do them! IMHO, if you're going to go whole-hog with interoperability, then you have to have a definition of what you are interoperable with, and that definition has to be very widely accepted; in my mind, significantly *more* widely than the current availability of ANSI compliant compilers, or else why bother? The only definition I know of is K&R I, which, while I agree it's a great book, just does not do the job as far as nitty-gritty specifications of the entire language. In addition, I don't think I've seen a C program in the last 8 years which does not use any language features except those found in K&R I! -- paul ----- ------------------------------------------------------------------ | Paul D. Smith | pds@lemming.webo.dg.com | | Data General Corp. | | | Network Services Development | "Pretty Damn S..." | | Open Network Applications Department | | ------------------------------------------------------------------