Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!seismo!mimsy!cvl!umd5!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.UUCP Newsgroups: comp.lang.c Subject: Re: impossible problem for find(1)? Message-ID: <5832@brl-smoke.ARPA> Date: Tue, 5-May-87 17:36:55 EDT Article-I.D.: brl-smok.5832 Posted: Tue May 5 17:36:55 1987 Date-Received: Thu, 7-May-87 04:08:24 EDT References: <2645@phri.UUCP> <6454@mimsy.UUCP> <5797@brl-smoke.ARPA> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 25 In article <477@haddock.UUCP> karl@haddock.ISC.COM.UUCP (Karl Heuer) writes: >... For example, "int nullf() {}" is acceptable to the lint I just >tried, and is still legitimate in X3J11 unless they've changed recently. What X3J11 says is that any use by the caller of the return value of such a function produces undefined behavior (as, logically, it should). If the caller doesn't use the value, then it's legal portable C. There are several versions of "lint", with different ideas of what should be checked by default. The one I usually use doesn't complain about the above example (nor the original newer.c with /*NOTREACHED*/ after the last exit() call), but I would consider such a complaint legitimate and therefore took defensive measures in advance. Perhaps someone (even I) may change "lint" to complain about such usage. "Lint" is permitted, nay, encouraged to check for possible problems that are nonetheless legal C usage. It is almost always an error in MY code for a function to be declared to return a value but to fail to do so, just as it's almost always an error for MY code to not use the value returned by a function. This is a consequence of a coding style that tries to be as type-correct as possible. To the extent that "lint" supports such a style, it can help find coding errors. Actually all #ifdef lint stuff is ugly, and I would have removed it before posting the code had I guessed that a discussion was imminent.