edw@ius2.cs.cmu.edu (Eddie Wyatt) (07/09/87)
Does the comment "/*VARARGS*/" really work in making "lint" skip argument checking? I've been trying to use it with multiply modules without success. -- Eddie Wyatt e-mail: edw@ius2.cs.cmu.edu terrorist, cryptography, DES, drugs, cipher, secret, decode, NSA, CIA, NROal
rblieva@cs.vu.nl (Roemer b Lievaart) (09/04/87)
In article <712@spar.SPAR.SLB.COM> hunt@spar.UUCP (Neil Hunt) writes: >In article <869@tjalk.cs.vu.nl> I (that's me) wrote: > >Oh yeah? How about the message I get for EVERY casted malloc or realloc: > >:: somefile.c(007): warning: possible pointer alignment problem > >Can't shut lint up about that. ^^^^ >I don't know which compiler you are using, but on the compiler I use, ^^^^^^^^ >this warning is avoided if you make sure that the compiler knows that >malloc returns a pointer by declaring it (char *). Even if you then I was talking about LINT, not the compiler. And as you can see by the warning lint gave, it was NOT because I didn't declare malloc as (char *)(), because I did. >cast it into (something_else *), it accepts it, whereas if the compiler >thinks that [mc]alloc is (int), it will indeed issue this warning. ^^^^^^^^^^^^ If this is true, I would buy another compiler with more apropriate error messages! --Roemer (pronounce "Rumour") PS About the (pretty obvious, I now realise) (void)-thing you were ofcourse right. At last I understand what "void" is good for! :-\
SILVERBERG@CSL.SRI.COM (Brad A. Silverberg) (09/10/87)
Turbo C has a single file LINT built into it with very complete warning checks. There are something like 40 different warnings that can be enabled. Numerous of our users have found problems using the built in checking in code that had been shipping for a few years, and that code had been run through every lint available. Brad Silverberg Borland International -------
henry@utzoo.UUCP (Henry Spencer) (09/13/87)
> Turbo C has a single file LINT built into it with > very complete warning checks. There are something like 40 > different warnings that can be enabled... I for one would be quite interested in knowing what they are, if someone feels like listing them. (Please don't tell me to buy Turbo C, I have no other use for it.) -- "There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry
tada@athena.mit.edu (Michael J Zehr) (11/29/89)
(sorry for posting this -- i've check other sources and couldn't find an answer) are the sources for lint available via ftp from somewhere? i want to use it on a non-unix system so it's not already supplied.... thanks for any information. -michael j zehr
henry@utzoo.uucp (Henry Spencer) (11/29/89)
In article <1989Nov28.161413.28336@athena.mit.edu> tada@athena.mit.edu (Michael J Zehr) writes: >are the sources for lint available via ftp from somewhere? i want to >use it on a non-unix system so it's not already supplied.... The original lint, like all other parts of Unix, is licensed software. I don't know of any redistributable rewrite. -- That's not a joke, that's | Henry Spencer at U of Toronto Zoology NASA. -Nick Szabo | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
tris@alzabo.uucp (Tris Orendorff) (12/04/89)
henry@utzoo.uucp (Henry Spencer) writes: >In article <1989Nov28.161413.28336@athena.mit.edu> tada@athena.mit.edu (Michael J Zehr) writes: >>are the sources for lint available via ftp from somewhere? i want to >>use it on a non-unix system so it's not already supplied.... >The original lint, like all other parts of Unix, is licensed software. >I don't know of any redistributable rewrite. If you have money to spend, try: Gimpel Software 3207 Hogarth Lane Collegeville, PA 19426 (215) 584-4261 They will sell you "unformatted" code for their version of PC-Lint to be compiled on other machines. Apparently the variable names are scrambled so that the code is unreadable but not unusable. -- Sincerely Yours Tris Orendorff -----------------------------------------------------------------------
david.megginson@canremote.uucp (DAVID MEGGINSON) (03/08/90)
Who knows where I can find portable C source for a PD lint? I have a very good ANSI compiler and source-level debugger, but I could use a lint just to check my code from another angle. Thanks. David Megginson, Centre for Medieval Studies BITNET: meggin@vm.epas.utoronto.ca --- * Via ProDoor 3.1R
scs@adam.mit.edu (Steve Summit) (03/22/91)
In article <13584@helios.TAMU.EDU> byron@archone.tamu.edu (Byron Rakitzis) writes: >How many people remember to run lint on their code? How many do >it at the last minute? Well, I've got a number of peculiar habits, but I often make sure code passes lint before even trying to compile it, when I've just typed in a lot of code that I'm sure contains typos, unused variables, missing arguments, etc. It's unfortunately true that "classic" versions of lint tend to require a bit of bondage and discipline to keep them quiet. Nobody said programming was easy. I wouldn't particularly mind it if compilers tended to emit a few more "handholding" messages, as long as it didn't make them bigger and buggier, but I certainly don't mind running lint to catch mistakes that the compilers shouldn't, can't, don't, or won't. I don't understand why it takes anything to "remember" to run lint on your code. (If you can't run it, because your lackadaisical vendor sold you half a compiler, that's another story.) How do you remember to look for bugs at all? Steve Summit scs@adam.mit.edu
byron@archone.tamu.edu (Byron Rakitzis) (03/22/91)
In article <1991Mar22.055335.23091@athena.mit.edu> scs@adam.mit.edu writes: >In article <13584@helios.TAMU.EDU> byron@archone.tamu.edu (Byron Rakitzis) writes: >>How many people remember to run lint on their code? How many do >>it at the last minute? > >It's unfortunately true that "classic" versions of lint tend to >require a bit of bondage and discipline to keep them quiet. >Nobody said programming was easy. I wouldn't particularly mind it >if compilers tended to emit a few more "handholding" messages, as >long as it didn't make them bigger and buggier, but I certainly >don't mind running lint to catch mistakes that the compilers >shouldn't, can't, don't, or won't. > I don't think that a compiler has to be big in order to perform the tasks outlined. You are just prejudiced by the current state of commercial compilers and gcc. The compiler I am working on will operate in two stages, a cpp/parser/ir-generator and a code-generator/ linker, and I am aiming for a factor of 3-5x compile-time speedup over gcc, plus a 3-5x reduction in compiler source code size. Impossible? Hardly. Compilers are in a sad state these days. Really sad. >I don't understand why it takes anything to "remember" to run >lint on your code. (If you can't run it, because your >lackadaisical vendor sold you half a compiler, that's another >story.) How do you remember to look for bugs at all? I don't think that good coding style should depend wholly on receiving enlightenment from Henry Spencer's 10 commandments ("thou shalt run lint.."). I think a newcomer to Unix or to C should be able to depend on the compiler to generate the necessary diagnostics to encourage some semblance of a good coding style. I admit that this compiler will be a hand-holder, but I also think that it can be done with good taste. And Real-Programmers(tm) can always turn the diagnostics off. But I think it's crucial to present these diagnostics by default, since otherwise they are ignored by the user. I guess what I'm trying to say is, why should someone have to run lint on their code to figure out what's wrong with it when it's perfectly reasonable for the compiler to provide a similar service by default? Are there people out there who deliberately WANT to write bad code? I'm not talking about the 5-minute foo.c hack, I'm talking about software development. A good compiler that does C preprocessing in the same pass as lexical analysis should be no slower than lint for this job. Also, if you let compilation proceed to the point where the compiler can do some dataflow analysis, then you can get diagnostics regarding use of unassigned variables, and so on.
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (03/22/91)
In article <13619@helios.TAMU.EDU>, byron@archone.tamu.edu (Byron Rakitzis) writes: > I don't think that a compiler has to be big in order to perform the > tasks outlined. You are just prejudiced by the current state of > commercial compilers and gcc. The compiler I am working on will > operate in two stages, a cpp/parser/ir-generator and a code-generator/ > linker, and I am aiming for a factor of 3-5x compile-time speedup over > gcc, plus a 3-5x reduction in compiler source code size. Impossible? > Hardly. Compilers are in a sad state these days. Really sad. More power to you! While you're at it, how about an _increase_ in comment density? But will your hand-holding compiler check that a *group* of files are consistent? That's what I really depend on lint for. -- Seen from an MVS perspective, UNIX and MS-DOS are hard to tell apart.
byron@archone.tamu.edu (Byron Rakitzis) (03/22/91)
In article <5036@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > >But will your hand-holding compiler check that a *group* of files are >consistent? That's what I really depend on lint for. I don't see what you need over and above good function-prototype checking. I am going to write a compiler strongly biased towards ANSI C; if you don't supply prototypes, you will pay the price of not having the use of unprototyped functions checked for type safety.
scs@adam.mit.edu (Steve Summit) (03/23/91)
In article <13627@helios.TAMU.EDU> byron@archone.tamu.edu (Byron Rakitzis) writes: >In article <5036@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: >>But will your hand-holding compiler check that a *group* of files are >>consistent? That's what I really depend on lint for. > >I don't see what you need over and above good function-prototype checking. >I am going to write a compiler strongly biased towards ANSI C; if you don't >supply prototypes, you will pay the price of not having the use of >unprototyped functions checked for type safety. I don't believe that ANSI C prototypes, as currently defined and commonly implemented, are a sufficient solution to the problem of cross-file declaration mismatches. One could also say, "if you don't supply correct function calls, you will pay the price of not having your code work properly." The analogy is imperfect, but not absurd. Keeping function calls correct across source files is tedious and error-prone. Lint was developed in part as an acknowledgement that even conscientious programmers make mistakes, which an automated tool can catch. Perfect (or infinitely patient) programmers wouldn't need lint. Prototypes catch almost as many errors as lint would (they don't check data declarations), but they can also gloss over other potential errors (by quietly inserting casts to the correct type), and they do their work only when the programmer has gone to the considerable extra work of supplying the prototypes and keeping them up-to-date. I do use full prototypes in some programs, and it's a lot of work. It galls me that I have to do all this work, to get 90% of the checking that a simple invocation of lint would do automatically. (It's also annoying that catching errors with the aid of prototypes is essentially a two-pass affair: first you have to chase down all the "function called with no prototype in scope" warnings, and supply the missing prototypes so that a second pass can use them to check your calls. How would you like it if you had to give a spellchecking program a list of the correctly-spelled words in the document to be checked?) The use of prototypes can also dramatically increase recompilation during development, because prototypes *must* be placed in header files (see below), so you need lots of header files (up to one per C source file), and they must be much more widely #included. (It's true that in a carefully planned and properly managed project, changes or additions to module interfaces, and therefore changes to prototypes and header files, should be infrequent. On the other hand, incremental design and implementation is not without its merits, and new interfaces can be added all the time.) All prototypes (except those for static functions) must be placed in header (.h) files, and *not* in source (.c) files, so that the header file can be #included both by the referencing source files and by the defining source file, so that the prototype (and in particular, the same copy of it) can be checked against the definition. This is reasonably obvious if you think about it. However, I suspect that there are a lot of beginning or incautious programmers who are typing prototypes directly in at the top of the .c files in which they are needed. (Programming textbooks usually talk about functions before they talk about #include, so their early examples suggest and reinforce this habit.) If there is any chance that the function definitions are going to change, decoupled prototypes like these are worse than useless. They would have to be manually kept in sync with the definitions, which is what we agreed, back at square one (talking about manually keeping calls in sync with definitions), is difficult for people to do. I'm not trying to start a lint vs. prototypes flamefest here. Prototypes have their advantages, and they're definitely here to stay. But they're not a panacea. Steve Summit scs@adam.mit.edu
stan@Dixie.Com (Stan Brown) (03/23/91)
scs@adam.mit.edu (Steve Summit) writes: =>In article <13584@helios.TAMU.EDU> byron@archone.tamu.edu (Byron Rakitzis) writes: =>>How many people remember to run lint on their code? How many do =>>it at the last minute? =>Well, I've got a number of peculiar habits, but I often make sure =>code passes lint before even trying to compile it, when I've just =>typed in a lot of code that I'm sure contains typos, unused =>variables, missing arguments, etc. Well maybe, I have diferent progrraming habits too, but whenever I run into a bug thats not imediatly obvious, the firts thing I do is run lint. You will be *amazed* how quickly that will point you to the problem. -- Stan Brown P. c. Design 404-363-2303 Ataant Ga. (emory|gatech|uunet) rsiatl!sdba!stan "vi forever"
darcy@druid.uucp (D'Arcy J.M. Cain) (03/25/91)
In article <1991Mar23.043408.5260@athena.mit.edu> scs@adam.mit.edu writes: >In article <13627@helios.TAMU.EDU> byron@archone.tamu.edu (Byron Rakitzis) writes: >I don't believe that ANSI C prototypes, as currently defined and >commonly implemented, are a sufficient solution to the problem of >cross-file declaration mismatches. As with anything the tool by itself is never a sufficient solution. Lint and prototypes both require intelligent use to get the most from them. I believe that prototypes used properly can enhance the development process. There is a commercial for Pert shampoo (is there such a thing as realpoo?) that shows a woman holding a bottle and easily moving around a locker room while someone in the background who supposedly is using the old style two bottle system that can barely stumble to the shower she is so overloaded with bottles, towels, etc. Somehow that one extra bottle of conditioner translates into an armful of stuff. Your post reminds me of that somewhat. Sure there is some more work required to work with prototypes but it isn't nearly so bad as you make it seem and I think the benefits really make it worhwhile in the long run. I have been using full prototypes for years and it has saved my bacon too many times to even consider going to some other system. First of all, the standard headers will take care of most of your checking. If you use a standard I/O function, #include stdio.h. If you are using any time functions then #include time.h. If you turn on enough warnings the compiler will remind you if you forget a header by pointing out that a function hasn't been prototyped. If you have a number of functions that are shared in a project, create a header file or a few headers where the functions are declared. Make sure to include the header in the file that defines the function. This is a check on the header file as well as the function. The header file can perform double duty if you wish by documenting the project as well as specifying the interfaces to the various routines. I have one header file that runs to ~16 pages with ~90% devoted to comments. It is in effect the functional specification for the sub-system it describes. Now if a change is made to the specification the sub-system as well as those programs that use it are automatically checked. As for the header file, consider the following: /* The foo function performs a framitz function on the string that */ /* is sent as the first argument and returns a pointer to a YABBA */ /* type */ YABBA *foo(char *s); Now we change the specification to this: /* The foo function performs a framitz function on the string that */ /* is sent as the first argument using the second argument sent as */ /* a filbert factor and returns a pointer to a YABBA type */ YABBA *foo(char *s); Note that we forgot to change the prototype. Assuming that we correct the actual function definition we will immediately see a problem when we do the compile and the header file, which is self-documenting, is easily fixed before we re-compile the functions that use the sub-system. >Prototypes catch almost as many errors as lint would (they don't >check data declarations), but they can also gloss over other >potential errors (by quietly inserting casts to the correct type), Exactly. I can do the following: #include <stdio.h> ... int index; ... fseek(fp, index, SEEK_SET); and not have to worry about the conversion. Are you saying that it is better for the programmer to cast noisily rather than have the compiler do it quietly? >and they do their work only when the programmer has gone to the >considerable extra work of supplying the prototypes and keeping >them up-to-date. And I argue that the programmer should be making these design specifications before coding. Sure they may have to be modified as the project goes on but that isn't nearly as difficult as you make it seem. >aid of prototypes is essentially a two-pass affair: first you >have to chase down all the "function called with no prototype in >scope" warnings, and supply the missing prototypes so that a >second pass can use them to check your calls. How would you like >it if you had to give a spellchecking program a list of the >correctly-spelled words in the document to be checked?) But you do have to do this. Of course your vendor gives you a list to start with but you have to add your own from time to time because the list can never be complete. If you mean the list has to be in the actual document, of course that is the wrong place for them. Just as prototypes don't belong in the .c files. They belong in a file that can be included by the module defining the function as well as the one(s) using it. Of course you say essentially the same thing a few paragraphs later so I'm not sure what the above statemet is meant to suggest. >The use of prototypes can also dramatically increase >recompilation during development, because prototypes *must* be >placed in header files (see below), so you need lots of header >files (up to one per C source file), and they must be much more >widely #included. (It's true that in a carefully planned and My experience suggests that the ratio of header files to source files is much lower. Usually a project can be broken up into broadly defined subsections, each with it's own header/specification file. >properly managed project, changes or additions to module >interfaces, and therefore changes to prototypes and header files, >should be infrequent. On the other hand, incremental design and >implementation is not without its merits, and new interfaces can >be added all the time.) And let's not forget clients who change their minds every other day. A properly managed project, even with prototypes and header files, should be able to handle this. > >All prototypes (except those for static functions) must be Just a side note here. I hardly ever prototype static functions. I simply make sure that within a file a function is not used until it has been defined. This in effect makes it a prototype for itself. >or incautious programmers who are typing prototypes directly in >at the top of the .c files in which they are needed. (Programming >textbooks usually talk about functions before they talk about >#include, so their early examples suggest and reinforce this Which means that the methods of teaching C may need some overhaul. >I'm not trying to start a lint vs. prototypes flamefest here. Neither am I. I hope that this doesn't come across as some sort of personal attack. I do agree with a lot of what you say and I have no problem with those who are comfortable with lint using it. I simply happen to believe that there is a lot of value in prototypes and wanted to show that there was another side to the question. >Prototypes have their advantages, and they're definitely here to >stay. But they're not a panacea. And neither is lint. In the end the real issue is the capability of the programmer using the tools. Use the ones that you are comfortable with and get to know them well. -- D'Arcy J.M. Cain (darcy@druid) | D'Arcy Cain Consulting | There's no government Toronto, Ontario, Canada | like no government! +1 416 424 2871 |
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (03/25/91)
In article <13627@helios.TAMU.EDU>, byron@archone.tamu.edu (Byron Rakitzis) writes: > In article <5036@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > >But will your hand-holding compiler check that a *group* of files are > >consistent? That's what I really depend on lint for. > I don't see what you need over and above good function-prototype checking. But how do you check that the prototypes used in file FOO.C agree with the function definitions in file BAZ.C? If the programmer makes a habit of #including the header files with the prototypes _both_ in the files that use things _and_ in the files that provide them, all is well. If not, and there is nothing in ANSI C to require it, we're back in the realm of Pascal, i.e. up the well known creek without a paddle. > I am going to write a compiler strongly biased towards ANSI C; if you don't > supply prototypes, you will pay the price of not having the use of > unprototyped functions checked for type safety. Ah, I _see_. Only people who are willing to rewrite all their old code and make it non-portable to pre-ANSI systems (still in very wide use) will benefit. You know, you _could_ help people who have to maintain old code by adding to your compiler an option to write prototypes inferred from the definitions out to a file. -- Seen from an MVS perspective, UNIX and MS-DOS are hard to tell apart.
bhoughto@pima.intel.com (Blair P. Houghton) (03/25/91)
In article <5043@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: >In article <13627@helios.TAMU.EDU>, byron@archone.tamu.edu (Byron Rakitzis) writes: >> I am going to write a compiler strongly biased towards ANSI C; if you don't >> supply prototypes, you will pay the price of not having the use of >> unprototyped functions checked for type safety. If you did otherwise, your compiler would be nonconforming. >Ah, I _see_. Only people who are willing to rewrite all their old code >and make it non-portable to pre-ANSI systems (still in very wide use) >will benefit. You know, you _could_ help people who have to maintain >old code by adding to your compiler an option to write prototypes >inferred from the definitions out to a file. Bad attitude, and a little misinformed. An ANSI compiler is required to compile functions and function calls that are declared in the old style; however, it is explicitly stated in the standard that the arguments to a function defined in old-style will not be _checked_, even though passing bogus-typed data can still produce bad results. (see ANSI X3.159-1989, sec. 3.5.4.3, p. 69, ll. 10-11 for one version of it, and sec. 3.5.2.2, p. 42, ll. 17-19 for the actual words "the number and types of arguments are not compared with those of the parameters in a function definition that does not include a function prototype declarator.") You never really did have this sort of type-and-number checking in old compilers, and variadic functions depend on this sort of thing. Some things are still the responsibility of the programmer (or code-generating software, as the case may be). --Blair "It's a feature, not a bug."
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (03/26/91)
In article <3433@inews.intel.com>, bhoughto@pima.intel.com (Blair P. Houghton) writes: > In article <5043@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > >Ah, I _see_. Only people who are willing to rewrite all their old code > >and make it non-portable to pre-ANSI systems (still in very wide use) > >will benefit. You know, you _could_ help people who have to maintain > >old code by adding to your compiler an option to write prototypes > >inferred from the definitions out to a file. > Bad attitude, and a little misinformed. No, not a whit misinformed. I know all that stuff about ANSI C. Because *compilation* as such was never the issue, I omit all the points that Blair Houton made, they never were in doubt, and they never were a propos. I didn't say that the compiler wouldn't be able to generate the right code. We were *specifically* talking about Lint and replacements for Lint, and my point was solely concerned with cross-module consistency checks. If the source files are correct, of COURSE an ANSI compiler is going to generate the right object code for them without the aid of prototypes. The point is that the compiler in question is intended to be so good at generating warning messages that it will be an effective replacement for >Lint<, but it is not going to do cross- module consistency checks. To obtain that effect, you are going to have to supply prototypes. (In effect, a "lint-library" as generated by lint _is_ a collection of prototypes. Asking for the compiler to produce a file of prototypes -- which some existing C compilers will do -- is asking for no more than lint will already do. You know, some people *do* have to check the consistency of their C code with source files produced by others. It may not do any good to rewrite those other files, because (a) the original supplier may issue a new version, and then you have it all to do again, and (b) the reason for the original supplier not providing prototypes in the first place may be that the code has to work on a range of machines that still haven't got an ANSI-compliant compiler. -- Seen from an MVS perspective, UNIX and MS-DOS are hard to tell apart.
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (03/26/91)
In article <5043@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > You know, you _could_ help people who have to maintain old code by > adding to your compiler an option to write prototypes inferred from > the definitions out to a file. I would prefer an option to get the old syntax with the new semantics. (Yes, I know the result is no longer quite C. But *I* would certainly use it! (I'd also like the default return type to be void instead of int.)) Hmmm, perhaps this is more appropriate material for comp.lang.d.... der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
enag@ifi.uio.no (Erik Naggum) (03/27/91)
Hi, As long as you're writing a compiler which will be totally ANSI/ISO C conformant, I'd like to request that you supply the relevant chapter and verse for errors you detect in the source. That way, a consci- entious programmer can know where to go look up the Right Thing. This is perhaps what I like most about many good Ada compilers. I see now reason why we couldn't have it for C, as well. -- [Erik Naggum] <enag@ifi.uio.no> Naggum Software, Oslo, Norway <erik@naggum.uu.no>
torek@elf.ee.lbl.gov (Chris Torek) (03/27/91)
In article <5069@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: >... my point was solely concerned with cross-module consistency checks. Of course, a compilation system *could* write all the type information to its intermediate files and have the resolver (`linker'/`binder'/ whatever you want to call it) verify it. It is just a Small Matter of Programming.... :-) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
henry@zoo.toronto.edu (Henry Spencer) (03/28/91)
In article <ENAG.91Mar27025243@holmenkollen.ifi.uio.no> enag@ifi.uio.no (Erik Naggum) writes: >As long as you're writing a compiler which will be totally ANSI/ISO C >conformant, I'd like to request that you supply the relevant chapter >and verse for errors you detect in the source... Which brings to mind the image of the ANSI C compiler Ken Thompson would write: all it prints for an error message is the page number in the standard... :-) :-) :-) :-) -- "[Some people] positively *wish* to | Henry Spencer @ U of Toronto Zoology believe ill of the modern world."-R.Peto| henry@zoo.toronto.edu utzoo!henry
gwyn@smoke.brl.mil (Doug Gwyn) (03/28/91)
In article <1991Mar27.175558.6738@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >Which brings to mind the image of the ANSI C compiler Ken Thompson would >write: all it prints for an error message is the page number in the >standard... :-) :-) :-) :-) I guess that would be so one could tell where the error came from. "?" or "eh?" already belong to other utilities.
lamont@uts.amdahl.com (Duane Richard LaMont) (03/28/91)
In article <1991Mar24.165719.26908@druid.uucp> darcy@druid.uucp (D'Arcy J.M. Cain) writes: >Just a side note here. I hardly ever prototype static functions. I >simply make sure that within a file a function is not used until it >has been defined. This in effect makes it a prototype for itself. I thought this was a good idea too, but it didn't work for me on the first prototyping compiler I ever used (SCO XENIX, forget the version number). It behaved as if I had declared the function without prototyping it (i.e. the return type was known, but not the argument count and types). So I got in the habit of prototyping static functions and haven't tried the "self prototyping" method since. One advantage of prototyping everything is that I'm free to put the functions in the order I'm most comfortable with. Of course, this discussion wouldn't be complete without mentioning mutual recursion. I'm sure that's one case where Mr. Cain does prototype static functions (note he didn't say "never" :-). Are prototyping compilers supposed to treat a function as prototyped following that function's definition? Rick LaMont
scs@adam.mit.edu (Steve Summit) (03/28/91)
In article <c48H01l04bKM00@amdahl.uts.amdahl.com> lamont@amdahl.uts.amdahl.com (Duane Richard LaMont) writes: >In article <1991Mar24.165719.26908@druid.uucp> darcy@druid.uucp (D'Arcy J.M. Cain) writes: >>I simply make sure that within a file a function is not used until it >>has been defined. This in effect makes it a prototype for itself. > >I thought this was a good idea too, but it didn't work for me on the >first prototyping compiler I ever used (SCO XENIX, forget the version >number). It behaved as if I had declared the function without >prototyping it (i.e. the return type was known, but not the argument >count and types). > >Are prototyping compilers supposed to treat a function as prototyped >following that function's definition? Yes. Steve Summit scs@adam.mit.edu
darcy@druid.uucp (D'Arcy J.M. Cain) (03/28/91)
In article <c48H01l04bKM00@amdahl.uts.amdahl.com> Duane Richard LaMont writes: >In article <1991Mar24.165719.26908@druid.uucp> darcy@druid.uucp (D'Arcy J.M. Cain) writes: >>Just a side note here. I hardly ever prototype static functions. I >I thought this was a good idea too, but it didn't work for me on the >first prototyping compiler I ever used (SCO XENIX, forget the version Of course I did mean ANSI compilers. > [...] >comfortable with. Of course, this discussion wouldn't be complete without >mentioning mutual recursion. I'm sure that's one case where Mr. Cain does ^^^^^^^^ You mean my father agrees with me too? ----------------------^ >prototype static functions (note he didn't say "never" :-). > >Are prototyping compilers supposed to treat a function as prototyped >following that function's definition? K&R2 pp 72 says: "The function atof must be declared and defined consistently. If atof itself and the call to it in main have inconsistent types in the same source file, the error will be detected by the compiler. But (as is more likely) atof were compiled separately ..." It goes on to discuss the situation where it has to determine the parameters to atof by other rules when atof is not defined in the current file. This would strongly suggest that the answer is yes. In fact you would almost think that the order of calls and definitions is immaterial except for the following sentence from the paragraph following the one above: "... a function is implicitly declared by its first appearance in an expression ..." ^^^^^ So the following: ... foo(5); ... } void foo(long i) { ... If handled the "right way" i.e. an extra pass to determine the type of argument to foo before compiling the call to it would not be fully conforming. -- D'Arcy J.M. Cain (darcy@druid) | D'Arcy Cain Consulting | There's no government Toronto, Ontario, Canada | like no government! +1 416 424 2871 |
mkahl@world.std.com (Michael Kahl) (03/30/91)
In article <3433@inews.intel.com> bhoughto@pima.intel.com (Blair P. Houghton) writes: > >An ANSI compiler is required to compile functions >and function calls that are declared in the old style; >however, it is explicitly stated in the standard that >the arguments to a function defined in old-style will >not be _checked_, even though passing bogus-typed data >can still produce bad results. > >(see ANSI X3.159-1989, sec. 3.5.4.3, p. 69, ll. 10-11 >for one version of it, and sec. 3.5.2.2, p. 42, >ll. 17-19 for the actual words "the number and types of >arguments are not compared with those of the parameters >in a function definition that does not include a >function prototype declarator.") > However, earlier in the section (p. 42, ll. 3-7), the Standard says that if the number and types of the arguments do *not* agree with those of the parameters, the behavior is undefined. Therefore, a conforming translator can legimitately do whatever it likes, including reporting type mismatches and/or inserting appropriate conversions. The Standard does not forbid a conforming implementation from being helpful in this manner. -- Michael Kahl, Symantec Corporation mkahl@world.std.com -or- 75236.3146@compuserve.com Disclaimer: Keep this quiet; what my employer doesn't know won't get me fired.
jpk@ingres.com (Jon Krueger) (03/30/91)
From article <1991Mar27.175558.6738@zoo.toronto.edu>, by henry@zoo.toronto.edu (Henry Spencer): > Which brings to mind the image of the ANSI C compiler Ken Thompson would > write: all it prints for an error message is the page number in the > standard... :-) :-) :-) :-) Not a bad idea at all. Then one can have an ansi-c-mode in one's favorite editor that pulls up the standard, open to the relevant page, next to an editing window with your cursor on the offending source line. -- Jon -- Jon Krueger, jpk@ingres.com
stan@Dixie.Com (Stan Brown) (04/01/91)
jpk@ingres.com (Jon Krueger) writes:
=>From article <1991Mar27.175558.6738@zoo.toronto.edu>, by henry@zoo.toronto.edu (Henry Spencer):
=>> Which brings to mind the image of the ANSI C compiler Ken Thompson would
=>> write: all it prints for an error message is the page number in the
=>> standard... :-) :-) :-) :-)
=>Not a bad idea at all. Then one can have an ansi-c-mode in one's favorite
=>editor that pulls up the standard, open to the relevant page, next to an
=>editing window with your cursor on the offending source line.
I like it. But what would we don on non X terminal editors ?
--
Stan Brown P. C. Design 404-363-2303 Ataanta Ga.
(emory|gatech|uunet) rsiatl!sdba!stan "vi forever"
"Operating Systems, Like Editors Are Religions" -- Armando Stettnerconor@lion.inmos.co.uk (Conor O'Neill) (04/02/91)
In article <5043@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: >But how do you check that the prototypes used in file FOO.C agree with >the function definitions in file BAZ.C? If the programmer makes a habit >of #including the header files with the prototypes _both_ in the files >that use things _and_ in the files that provide them, all is well. If >not, and there is nothing in ANSI C to require it, we're back in the >realm of Pascal, i.e. up the well known creek without a paddle. The INMOS ANSI C compiler has a command line switch ("software quality policing") which will warn if an externally visible function is detected which was not preceded by a prototype. If prototypes are only ever written in header files, this provides the required security. --- Conor O'Neill, Software Group, INMOS Ltd., UK. UK: conor@inmos.co.uk US: conor@inmos.com "It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".
karl@ima.isc.com (Karl Heuer) (04/04/91)
In article <9001@rsiatl.Dixie.Com> stan@Dixie.Com (Stan Brown) writes: >jpk@ingres.com (Jon Krueger) writes: >>[Given a compiler whose error messages are references to the ANS,] one can >>have an ansi-c-mode in one's favorite editor that pulls up the standard, >>open to the relevant page, next to an editing window with your cursor on the >>offending source line. > >I like it. But what would we don on non X terminal editors ? Real editors can handle multiple files on ASCII terminals. >-- >"vi forever" Oh. Never mind. >"Operating Systems, Like Editors Are Religions" -- Armando Stettner Followups redirected accordingly. Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint