dbrooks@osf.org (David Brooks) (09/07/90)
(this followup adds comp.lang.c to comp.std.c) In article <13759@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: |> Furthermore, any function need not be declared using prototype ("new- |> style") syntax if its parameters have already-default-widened types |> (as I think all the standard library functions do). And any function |> need not be declared at all if it returns type int and its parameters |> have already-default-widened types. This loses some of the benefits of prototypes. But if your parameters don't have already-widened types, you must beware of the following situations: Define your callee with a narrow parameter or two, and accidentally leave out the prototype from the caller. Your program breaks. We all know this, right? Not necessarily. Build a library using prototypes and narrow parameters, and put the binary out on the streets. Your customers had better use prototypes in their application code, which means you have to insist they build with a prototyping compiler. Reasonable. It gets worse. There are some overly-helpful compilers out there which do the widening anyway, prototype or no. This is quite consistent with the ANSI rules; it works so long as the caller and callee agree about it. So you do all your program development with that compiler, test it up the wazoo, and put the source out on the streets. But you got the prototypes mixed up - either you misspelt the function name in a header file or you left a #include out of a source. A paying customer points a less-helpful compiler at it (or the same compiler, built differently), and it breaks in obscure ways. Of course, such a compiler would produce at least a comment when it encounters a default-declared procedure. But prudence is beginning to suggest that I balance the advantages of decent parameter type checking against handling non-reproducible-in-house parameter-passing bugs. (people who meet me in other newsgroups know what I'm talking about). -- David Brooks dbrooks@osf.org Systems Engineering, OSF uunet!osf.org!dbrooks Experience Hackvergnuegen!
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/08/90)
In article <1990Sep7.114544@osf.org> dbrooks@osf.org (David Brooks) writes: >This loses some of the benefits of prototypes. Well, yes, but there was that mountain of already-written code that was correct by previous (K&R) criteria that we wanted to "grandfather in". >Build a library using prototypes and narrow parameters, ... I don't recommend excessive use of narrow parameter types, but certainly if you're going to use them (or even if not!) there should be an associated header that properly declares them. A conforming compiler will flag any type error in the function implementation if the implementation includes the header. Otherwise, some form of "lint" should be used by the developer.