Path: utzoo!utgpu!watserv1!watmath!att!att!bu.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn From: gwyn@smoke.brl.mil (Doug Gwyn) Newsgroups: comp.std.c Subject: Re: ANSI, K&R, H&S (was: Re: Just a minor new twist on free()) Message-ID: <14323@smoke.brl.mil> Date: 3 Nov 90 02:55:02 GMT References: <222@smds.UUCP> Organization: U.S. Army Ballistic Research Laboratory, APG, MD. Lines: 37 In article pds@lemming.webo.dg.com (Paul D. Smith) writes: >what good is it to make your C code portable when you have much larger >portability issues ... which will cause your code to not work on any >other system without major re-working? Only a fraction of your application would be system-specific; if good code modularization is practiced, probably the majority of your code would be usable in other applications and in other environments. It is that generally-useful code that should be made portable. In the huge software project ("MUVES") that I have been involved in for the past four years, the application itself (even though designed with a large measure of generality) is of little interest in non-military environments; however, it needed a large amount of support code that is quite useful for other applications. Indeed, there were several unrelated applications that utilized the MUVES support packages before the MUVES application itself was working. I've maintained a general C programming support library for local use, to which I intend to add all the generally useful MUVES support packages. Such libraries have been extremely valuable at other places that I have worked, and I expect them to be of value almost anywhere that they are tried (assuming that proper care is used in designing the functionality and interfaces). >Portability is very important to me; I'm going to make all my code >rigorously portable under the ANSI standard for the C programming >language. Portability is also very important to me. However, at present there are too many systems that I have to port applications to that do not provide an implementation of standard C. In fact our Crays are just about the only ones that do. Therefore, I've chosen a subset of the UNIX System V Release 2 C library as the "portable interface", and for the C language proper and the preprocessor, provide both Reiser/ PCC compatible and standard conforming code, using a configuration parameter to determine what code is compiled. (I have a configuration header "std.h" that sets this parameter and provides other system- dependent definitions.)