sw@smds.UUCP (Stephen E. Witham) (11/02/90)
In article <PDS.90Oct10093245@lemming.webo.dg.com>, pds@lemming.webo.dg.com (Paul D. Smith) writes: > [People] 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... I agree. "Common, non-K&R features" are illusions and traps! > IMHO, if you're going to go whole-hog with interoperability, then you > have to have a definition of what you are interoperable with... > > 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. Yes, mostly, to all of that. It's either ANSI C or Least Common Denominator (LCD) C. But even K&R is not a reference to LCD C, for two reasons: 1) K&R is unclear at times. 2) Even when K&R is clear, implementations get it wrong. The closest thing to a reference to LCD C is _C: A Reference Manual_, by Harbison and Steele. The whole point of the project that led to the book was to seek out the fuzzy edge of C, see what was really happening there, and FIGURE OUT HOW TO AVOID IT. The book is full of advice like, "Don't use this feature," or, "Sometimes this doesn't work, sometimes this doesn't work, so the most conservative and portable way to do it seems to be this..." Stephen Clamage tried to make this same point to Dan Bernstein, but slipped up by talking about "portable" and "enums" in the same sentence. That was a real disservice to Mr. Bernstein's understanding the value of H&S, viz: > You don't understand. I don't *want* to have to wade through all that > stuff about newer C. The language described by the original K&R isn't > defined precisely---but it's the language I use, and the language that > compilers understand. And that's exactly what I want. I can't speak for how hard it is for Mr. Bernstein to flip past the few sections that describe features not in K&R. But H&S DOES describe K&R C-- CLEARLY. Earlier, Mr. Bernstein had said: > ...K&R (the real one) can be used as a > reference. If you recognize its ambiguities as true ambiguities, you'll > write much more portable code. Then, later, > Maybe I would agree with Chris that H&S is the best reference if I ever > needed more precise interpretations than there are in K&R. But I don't. If you have an intuitive understanding of where the ambiguities are, and somehow just know that you will never find yourself in a grey area, then by all means stick with K&R. If, you want to be explicitly warned about the ambiguities in K&R, and about where some implementations don't live up to K&R, and given good advice about what to do about it, then get H&S. Mr. Bernstein says: > Your code is likely to be even more portable if you use K&R as your > reference. That's all I'm saying. and IMHO that's exactly wrong. The final reference for portability, of course, is experience. Don't use features that have bitten you in the past on any machine. That's why I'm surprised by Paul Smith's comment: > 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! What kind of insulated environments do these people work in, anyway? Steve Witham, The Squeaky Wheel (who doesn't know his own net address) VoiceNet: (617)625-2856 "The Tao that can be dialed is not a working Tao."
chris@mimsy.umd.edu (Chris Torek) (11/02/90)
In article <222@smds.UUCP> sw@smds.UUCP (Stephen E. Witham) writes: >The whole point of the project that led to the [H&S] book was to >seek out the fuzzy edge of C, see what was really happening there, >and FIGURE OUT HOW TO AVOID IT. The book is full of advice like, "Don't >use this feature," or, "Sometimes this doesn't work, sometimes this doesn't >work, so the most conservative and portable way to do it seems to be this..." > >Stephen Clamage tried to make this same point to Dan Bernstein, but slipped >up by talking about "portable" and "enums" in the same sentence. ... Or, to put it another way, if all you have read is K&R I, you might be tempted to write the following fragment for counting vowels: #include <stdio.h> main() { char *p, *getword(); int anum, enum, inum, onum, unum, wnum, ynum; anum = enum = inum = onum = unum = wnum = ynum = 0; while ((p = getword()) != NULL) { if (*p == 'c' && strcmp(p, "cwm") == 0) { /* * This English word was imported from Welsh. * It is probably the only one in which w is * a vowel. */ wnum++; continue; } for (;;) { switch (*p++) { case '\0': break; case 'a': anum++; continue; case 'e': enum++; continue; case 'i': inum++; continue; case 'o': onum++; continue; case 'u': unum++; continue; case 'y': ynum++; /* could be a consonant... */ continue; default: continue; } break; } } /* print out results */ . . . This code will compile on some systems, and not on others, because `enum' is only sometimes a keyword. >"The Tao that can be dialed is not a working Tao." ... but if you call this 1-900 number today, at only $1235917/minute ... :-) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
pds@lemming.webo.dg.com (Paul D. Smith) (11/03/90)
[] The final reference for portability, of course, is experience.
[] Don't use features that have bitten you in the past on any machine.
[] That's why I'm surprised by Paul Smith's comment:
[]
[] > 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!
[]
[] What kind of insulated environments do these people work in,
[] anyway?
Until somewhat recently I've been working on a proprietary system;
what good is it to make your C code portable when you have much larger
portability issues (DG's proprietary AOS/VS operating system had
OS-supported multi-tasking and other goodies) which will cause your
code to not work on any other system without major re-working?
Recently, on DG's new UNIX 88k RISC platform, we've been cuddled in
the warm and fuzzy insulation of the GNU C Compiler; it's almost
universally available on modern UNIX systems, and since I'm in
networking it's kinda hard to write code where you don't have close
ties to the OS.
I have strong feelings about the enhancements to C that ANSI provides,
mainly in the strong-typing (moderate-typing? :-) and data abstraction
areas. I'm not willing to give up these badly needed enhancements to
the language when I have a solid leg to stand on (the ANSI standard)
and a widely available, free (!!) compiler which implements those
enhancements. Sorry, but I'm stubborn and the "well, there's always
some poor guy with a card punch reader -- what about him?" argument
just doesn't cut any butter with me. All the more reason for him to
get a new AViiON, IMO! :-) :-) :-) :-) <--Note smileys!!!
I don't consider any program "LCD C" which uses external identifiers
not unique in 6 monocase characters or internal identifiers not unique
in 8 characters, and which doesn't *come with* a scheme for shortening
them to acceptable levels, whether a seperate "compacter" program or
the good old standby #define scheme.
Saying it's easy to do if you need it is a cop-out, IMHO. I can't
compile it as-is, so what's the point of all that pain and torture and
sacrifice to make it super-portable?
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. (thank you, thank you! <bow, wave, bow> I now return the
soapbox to the K&R I proponents for their equal time rebuttal...:-)
--
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) (11/03/90)
In article <PDS.90Nov2141442@lemming.webo.dg.com> 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.)
rns@se-sd.SanDiego.NCR.COM (Rick Schubert) (11/07/90)
In <222@smds.UUCP> sw@smds.UUCP (Stephen E. Witham) writes: > That's why I'm >surprised by Paul Smith's comment: >> 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! >What kind of insulated environments do these people work in, anyway? Paul already responded to this, but I don't think he caught the fact that Stephen was confused by the triple negative: >> 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! What he is saying (and I think this is what he meant, too) is that each of the C programs he has seen in the last 8 years has used some feature not found in K&R I. -- Rick Schubert (rns@se-sd.sandiego.NCR.COM)
pds@lemming.webo.dg.com (Paul D. Smith) (11/10/90)
[] >> 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!
[] What he is saying (and I think this is what he meant, too) is that
[] each of the C programs he has seen in the last 8 years has used
[] some feature not found in K&R I.
Yes, this is what I meant; my junior-year English teacher would have a
fit! :-(
However, I think Stephen _did_ understand me; at least my response was
based on the fact that he was implying that `our' programming
environments (whoever "we" are: DG programmers? CMU graduates?
People named Paul? Anyone named Smith? Left handed people? :-) were
sufficiently insulated that we don't need to guard against any crafty,
non-K&R I features creeping into our code.
--
paul
-----
------------------------------------------------------------------
| Paul D. Smith | pds@lemming.webo.dg.com |
| Data General Corp. | |
| Network Services Development | "Pretty Damn S..." |
| Open Network Applications Department | |
------------------------------------------------------------------