gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/14/85)
> /* Open a file, aborting on failure */ > > /* Written by Bernie Roehl, June 1985 */ > > #include <stdio.h> > #include <sys.h> ^^^^^ NONSTANDARD INCLUDE FILE ^^^^^ > > efopen(fn, mode) ^^^^^ WRONG RESULT TYPE; should be (FILE *) ^^^^^ > char *fn, *mode; > { > FILE *unit; > if ((unit = fopen(fn, mode)) == NULL) > error("Cannot open file %s", fn); ^^^^^ IMPLICITLY DECLARES error() AN (int)-VALUED FUNCTION ^^^^^ > else > return unit; > } > > extern char *progname; ^^^^^ NONSTANDARD GLOBAL DATUM; this package should allocate it and provide a function to set it ^^^^^ > > error(s1, s2) ^^^^^ WRONG RESULT TYPE; should be (void) ^^^^^ ^^^^^ INSUFFICIENTLY GENERAL TO BE GLOBAL; should be changed to use varargs or else be made file-static ^^^^^ > char *s1, *s2; > { > fprintf(stderr, "%s: ", progname); > fprintf(stderr, s1, s2); > exit(1); ^^^^^ IMPLICITLY DECLARES exit() AN (int)-VALUED FUNCTION ^^^^^ > } Nice try, but no cigar. Please, folks, de-lint your code before posting!
peter@graffiti.UUCP (Peter da Silva) (10/16/85)
> > /* Open a file, aborting on failure */ > > ...whole bunch of comments about non-standard things... > > Nice try, but no cigar. > Please, folks, de-lint your code before posting! Please folks, think about the program before flaming! This program (as I understand it) is: 1. Specific to a particular machine (IBM-PC). 2. Not a complete distribution (it's a "missing function"). 3. Written for a non-UNIX compiler (Lattice or something). 4. Written for a compiler without (void) type. So who cares if you can't compile it on UNIX. It's just there to cover up a crummy runtime library anyway!
peter@rlgvax.UUCP (Peter Klosky) (10/17/85)
XXX > ^^^^^ WRONG RESULT TYPE; should be (void) ^^^^^ There is a certain confusion about how well documented and supported the void() feature is in various versions of the language support systems. > Nice try, but ... Is this pedantic tone really needed here?
levy@ttrdc.UUCP (Daniel R. Levy) (10/19/85)
In article <796@rlgvax.UUCP>, peter@rlgvax.UUCP (Peter Klosky) writes: > >> ^^^^^ WRONG RESULT TYPE; should be (void) ^^^^^ >There is a certain confusion about how well documented and >supported the void() feature is in various versions of the >language support systems. > Yessir. F'rinstance... (void)whatever is not supported at all under VAX/VMS C. It will barf severely on (originally) Unix C programs which have been heavily larded with (void)'s for the sake of lint. Not the entire C world is Unix. -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!ihnp4!ttrdc!levy
laura@l5.uucp (Laura Creighton) (10/22/85)
I've had it. I'm going to write a book, called *HOW TO WRITE PORTABLE C PROGRAMS*. I wonder if Prentice Hall will take it. It is not going to say anything that I don't think you should know already, but I am getting more and more convinced that there are only 50 people or so who know how to write good C code in the world. Please send me your favourite things that you wish people would know about C, so it can make it into the book. **WARNING** If it turns out that the problem is that you don't know C, I WILL TELL YOU THAT TOO. People who want to remain in ignorance about their decrepid coding practices should AVOID ME LIKE THE PLAGUE. Ahem. efopen is a great idea. I have one. This means that you can take your average piece of putrid slime and fix all the ``doesn't check if fopen succeeds'' bugs by globally changing all occurrances of fopen with efopen. The posted efopen does not pass lint. This sucks dead worms through a straw. What good is it to fix the sloppy and vile practices of the people who don't check fopen by adding more slime? The complaint that void is not well understood by compilers on micros is LOUSY. If your compiler does not understand void, then you can usually add a line to your makefile which reads: DEFINES= -Dvoid=int spiffo. add one line and your code works. *That's* portable. You don't have make? Well maybe you can type it in on a command line. You can't do that? Okay, hack either your source files, or (better) a header file that is included by all of them (if the program comes in modules -- you do write your programs in modules, don't you) to say: #define void int /* remove this line if your compiler knows about void */ which can probably go inside something appropriate like: #ifdef IBMPC mumblefrotz #endif What? You don't have a preprocessor? Hmm, I have my doubts as to whether you really have C. I'll bet you have lots of problems. I'll bet that globally changing all occurrances of void to int with your editor is the easiest job you get porting code. I'll bet you would pay real hard cash to only have to port code that passes lint and which checks the returns of its system calls, even if you had to use your editor to convert void into int every day. I'll bet you will buy lots of copies of my book... I am serious folks. Help beautify the world. Send me what you wish more C programmers did or stopped doing. -- Laura Creighton sun!l5!laura (that is ell-five, not fifteen) l5!laura@lll-crg.arpa
john@frog.UUCP (John Woods) (10/24/85)
> I've had it. I'm going to write a book, called *HOW TO WRITE PORTABLE C > PROGRAMS*. > > #define void int /* remove this line if your compiler knows about void */ > Although I am sure that someone has a compiler for which the following will not make sense, in general the construct #ifndef lint #define void int #endif allows one to have one's cake and eat it too. -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA Out of my way, I'm a scientist! War of the Worlds
lasse@daab.UUCP (Lars Hammarstrand) (10/26/85)
In article <210@l5.uucp> laura@l5.UUCP (Laura Creighton) writes: >I've had it. I'm going to write a book, called *HOW TO WRITE PORTABLE C >PROGRAMS*.... > . . . > That's the damn best thing I ever heard this year!! It's going to be a best seller. Good luck! Lars Hammarstrand. Datorisering AB, Stockholm, SWEDEN. PS.. I hope you will take up the difference between SysV,4.[0-4]BSD,V7,..,..,..,..
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/26/85)
> Although I am sure that someone has a compiler for which the following will > not make sense, in general the construct > > #ifndef lint > #define void int > #endif > > allows one to have one's cake and eat it too. Not always, since this introduces a mismatch between the application code and the C library. There may also be compilers that get unhappy when your int-valued functions don't return a value, etc. The #define void int kludge should really only be applied when the compiler doesn't know about void.
brooks@lll-crg.ARpA (Eugene D. Brooks III) (10/27/85)
In article <170@daab.UUCP> lasse@daab.UUCP (Lars Hammarstrand) writes: >In article <210@l5.uucp> laura@l5.UUCP (Laura Creighton) writes: >>I've had it. I'm going to write a book, called *HOW TO WRITE PORTABLE C Harbison and Steel take quite a good look at some of the issues. >PS.. >I hope you will take up the difference between SysV,4.[0-4]BSD,V7,..,..,..,.. Sounds like a very long book. Are you sure we readers have the endurance? :-)
seifert@hammer.UUCP (Snoopy) (10/29/85)
In article <267@frog.UUCP> john@frog.UUCP (John Woods) writes: >Although I am sure that someone has a compiler for which the following will >not make sense, in general the construct > >#ifndef lint >#define void int >#endif > >allows one to have one's cake and eat it too. What doesn't make sense is having a combination of compiler and lint where one knows about void and the other doesn't. (Sure it's *possible*, but WHY?) Snoopy tektronix!tekecs!doghouse.TEK!snoopy
campbell@maynard.UUCP (Larry Campbell) (11/02/85)
> What doesn't make sense is having a combination of compiler and lint > where one knows about void and the other doesn't. > > (Sure it's *possible*, but WHY?) > > Snoopy > tektronix!tekecs!doghouse.TEK!snoopy Not only is it possible, it's been done, in VENIX. (Although the #ifdef lint #define void int #endif hack seems to work well...) -- Larry Campbell decvax!genrad The Boston Software Works, Inc. \ 120 Fulton St. seismo!harvard!wjh12!maynard!campbell Boston MA 02109 / / ihnp4 cbosgd ARPA: maynard.UUCP:campbell@harvard.ARPA