pds@lemming.webo.dg.com (Paul D. Smith) (10/08/90)
(comp.std.c readers please ignore this first section ...)
Thanks to everyone who pointed out my brain damage re my "efficiency"
example; obviously I was not completely sane when I posted last. :-)
The example I mentioned quite obviously depends on the sparseness of
the array: if the array is sparse, then doing the check before the
function call saves you much overhead; if the array is full, then
(maybe) you win by not doing the check (if your library is ANSI
compliant and does the check for you).
I apologize to everyone for taking up their time with this nonsense,
anyway; obviously this is a "personal style" question, whether you
think free() should handle all cases graciously (including NULL), or
think free() should to continue to crap out on NULL, presumably to
locate logic errors.
-----
I do, however, have a new point I'd like to take up some bandwidth
on: basically, I got a lot of responses stating that free(NULL) should
not be used because, although it *is* ANSI compliant, it is not
backward portable.
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?
I understand that many people do not as yet have an ANSI-compliant
compiler, but is really a valid reason for those of us who do to
continue to eschew important enhancements to the language in order to
continue to interoperate with the "lowest common denominator" C
implementations?
Some people mentioned that ANSI compilers are not in widespread use
"yet" (but hey, grab & port GCC and there you go!), and we should wait
until they are -- I ask, when will this be and how will we know it's
time?
Replies via e-mail welcome; I'll post a summary of "net" opinions...
--
paul
-----
------------------------------------------------------------------
| Paul D. Smith | pds@lemming.webo.dg.com |
| Data General Corp. | |
| Network Services Development | "Pretty Damn S..." |
| Open Network Applications Department | |
------------------------------------------------------------------cpcahil@virtech.uucp (Conor P. Cahill) (10/09/90)
In article <PDS.90Oct8101336@lemming.webo.dg.com> pds@lemming.webo.dg.com (Paul D. Smith) writes: >I do, however, have a new point I'd like to take up some bandwidth >on: basically, I got a lot of responses stating that free(NULL) should >not be used because, although it *is* ANSI compliant, it is not >backward portable. > >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? Since non-ANSI compilers are somewhat prevalent at this time you must take that into consideration. Not calling free(ptr) when ptr==NULL by checking the ptr with an if, will: 1. probably improve performance in most cases 2. be just as reliable as just calling free() with a null ptr 3. be just as readable. So IMHO you shouldn't use this feature. However, this is not a blanket statement that should be conscrued to mean that you shouldn't use any ANSI enhancements. For example, using function prototypes will: 1. have no effect on performance. 2. be more reliable. 3. be just as readable. So use them and add an #ifdef to conditionally use them if you have an ANSI compliant compiler. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
flaps@dgp.toronto.edu (Alan J Rosenthal) (10/09/90)
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? Reality! "Portability" is (hopefully) not merely a buzzword nor merely a political concept. It refers to the quantity of C compilers which will accept your program and give it the intended semantics. When most compilers accept all the new Ansi-C constructs, then programs using them will be portable, but not before. I eagerly embrace the Ansi C standard. I would not write any code incompatible with it, even if that code runs on all the machines I know of. But I eagerly embrace reality too, and want my C code to work now, not just later. ajr -- "Anytime there are electronic systems there are usually complications of electronic failure," he said.
henry@zoo.toronto.edu (Henry Spencer) (10/10/90)
In article <PDS.90Oct8101336@lemming.webo.dg.com> pds@lemming.webo.dg.com (Paul D. Smith) writes: >I understand that many people do not as yet have an ANSI-compliant >compiler, but is really a valid reason for those of us who do to >continue to eschew important enhancements to the language in order to >continue to interoperate with the "lowest common denominator" C >implementations? This depends entirely on how much you care about portability. Achieving real portability today requires acknowledging that pre-ANSI compilers are still in wide use and will not disappear overnight. This situation is a fact; wishing, e.g. arguing about whether it is "valid", will not change it. You either live in the real world or you don't. Refusing to live in the real world will substantially reduce the portability of your code. -- Imagine life with OS/360 the standard | Henry Spencer at U of Toronto Zoology operating system. Now think about X. | henry@zoo.toronto.edu utzoo!henry
paul@u02.svl.cdc.com (Paul Kohlmiller) (10/10/90)
pds@lemming.webo.dg.com (Paul D. Smith) writes: >Some people mentioned that ANSI compilers are not in widespread use >"yet" (but hey, grab & port GCC and there you go!), and we should wait >until they are -- I ask, when will this be and how will we know it's >time? I don't know when but I think we know how we will know that it is time. It will be after NIST approves a validation suite and then the phrase ANSI- conforming might mean something. -- // Paul H. Kohlmiller // "Cybers, Macs and Mips" // // Control Data Corporation // Internet: paul@u02.svl.cdc.com // // All comments are strictly // America Online: Paul CDC // // my own. // Compuserve: 71170,2064 //
pds@lemming.webo.dg.com (Paul D. Smith) (10/10/90)
[] In article <PDS.90Oct8101336@lemming.webo.dg.com> 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 <<add a list of your own favourite "add on" C features>> ... 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 | | ------------------------------------------------------------------
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/11/90)
In article <26738@shamash.cdc.com> paul@u02.svl.cdc.com (Paul Kohlmiller) writes: >I don't know when but I think we know how we will know that it is time. It >will be after NIST approves a validation suite and then the phrase ANSI- >conforming might mean something. "NIST's validation suite conforming" is not at all guaranteed to mean "ANSI standard conforming", and in fact two of the three major bidders for the suite dropped out, largely due to concerns over the way NIST was going about the acquisition. They essentially were insisting on a suite being contributed free, plus NIST being allowed to make any changes they felt like, which given their record with POSIX would very likely mean that they would add requirements counter to the intent of the ANSI standard.