![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to lint.ms CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ps1 / 09.lint|
Return to lint.ms CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ps1 / 09.lint |
1.1 ! root 1: .\" @(#)lint 6.1 (Berkeley) 5/7/86 ! 2: .\" ! 3: .EH 'PS1:9-%''Lint, a C Program Checker' ! 4: .OH 'Lint, a C Program Checker''PS1:9-%' ! 5: .\".RP ! 6: .ND "July 26, 1978" ! 7: .OK ! 8: .\"Program Portability ! 9: .\"Strong Type Checking ! 10: .TL ! 11: Lint, a C Program Checker ! 12: .AU "MH 2C-559" 3968 ! 13: S. C. Johnson ! 14: .AI ! 15: .MH ! 16: .AB ! 17: .PP ! 18: .I Lint ! 19: is a command which examines C source programs, ! 20: detecting ! 21: a number of bugs and obscurities. ! 22: It enforces the type rules of C more strictly than ! 23: the C compilers. ! 24: It may also be used to enforce a number of portability ! 25: restrictions involved in moving ! 26: programs between different machines and/or operating systems. ! 27: Another option detects a number of wasteful, or error prone, constructions ! 28: which nevertheless are, strictly speaking, legal. ! 29: .PP ! 30: .I Lint ! 31: accepts multiple input files and library specifications, and checks them for consistency. ! 32: .PP ! 33: The separation of function between ! 34: .I lint ! 35: and the C compilers has both historical and practical ! 36: rationale. ! 37: The compilers turn C programs into executable files rapidly ! 38: and efficiently. ! 39: This is possible in part because the ! 40: compilers do not do sophisticated ! 41: type checking, especially between ! 42: separately compiled programs. ! 43: .I Lint ! 44: takes a more global, leisurely view of the program, ! 45: looking much more carefully at the compatibilities. ! 46: .PP ! 47: This document discusses the use of ! 48: .I lint , ! 49: gives an overview of the implementation, and gives some hints on the ! 50: writing of machine independent C code. ! 51: .AE ! 52: .CS 10 2 12 0 0 5 ! 53: .SH ! 54: Introduction and Usage ! 55: .PP ! 56: Suppose there are two C ! 57: .[ ! 58: Kernighan Ritchie Programming Prentice 1978 ! 59: .] ! 60: source files, ! 61: .I file1. c ! 62: and ! 63: .I file2.c , ! 64: which are ordinarily compiled and loaded together. ! 65: Then the command ! 66: .DS ! 67: lint file1.c file2.c ! 68: .DE ! 69: produces messages describing inconsistencies and inefficiencies ! 70: in the programs. ! 71: The program enforces the typing rules of C ! 72: more strictly than the C compilers ! 73: (for both historical and practical reasons) ! 74: enforce them. ! 75: The command ! 76: .DS ! 77: lint \-p file1.c file2.c ! 78: .DE ! 79: will produce, in addition to the above messages, additional messages ! 80: which relate to the portability of the programs to other operating ! 81: systems and machines. ! 82: Replacing the ! 83: .B \-p ! 84: by ! 85: .B \-h ! 86: will produce messages about various error-prone or wasteful constructions ! 87: which, strictly speaking, are not bugs. ! 88: Saying ! 89: .B \-hp ! 90: gets the whole works. ! 91: .PP ! 92: The next several sections describe the major messages; ! 93: the document closes with sections ! 94: discussing the implementation and giving suggestions ! 95: for writing portable C. ! 96: An appendix gives a summary of the ! 97: .I lint ! 98: options. ! 99: .SH ! 100: A Word About Philosophy ! 101: .PP ! 102: Many of the facts which ! 103: .I lint ! 104: needs may be impossible to ! 105: discover. ! 106: For example, whether a given function in a program ever gets called ! 107: may depend on the input data. ! 108: Deciding whether ! 109: .I exit ! 110: is ever called is equivalent to solving the famous ``halting problem,'' known to be ! 111: recursively undecidable. ! 112: .PP ! 113: Thus, most of the ! 114: .I lint ! 115: algorithms are a compromise. ! 116: If a function is never mentioned, it can never be called. ! 117: If a function is mentioned, ! 118: .I lint ! 119: assumes it can be called; this is not necessarily so, but in practice is quite reasonable. ! 120: .PP ! 121: .I Lint ! 122: tries to give information with a high degree of relevance. ! 123: Messages of the form ``\fIxxx\fR might be a bug'' ! 124: are easy to generate, but are acceptable only in proportion ! 125: to the fraction of real bugs they uncover. ! 126: If this fraction of real bugs is too small, the messages lose their credibility ! 127: and serve merely to clutter up the output, ! 128: obscuring the more important messages. ! 129: .PP ! 130: Keeping these issues in mind, we now consider in more detail ! 131: the classes of messages which ! 132: .I lint ! 133: produces. ! 134: .SH ! 135: Unused Variables and Functions ! 136: .PP ! 137: As sets of programs evolve and develop, ! 138: previously used variables and arguments to ! 139: functions may become unused; ! 140: it is not uncommon for external variables, or even entire ! 141: functions, to become unnecessary, and yet ! 142: not be removed from the source. ! 143: These ``errors of commission'' rarely cause working programs to fail, but they are a source ! 144: of inefficiency, and make programs harder to understand ! 145: and change. ! 146: Moreover, information about such unused variables and functions can occasionally ! 147: serve to discover bugs; if a function does a necessary job, and ! 148: is never called, something is wrong! ! 149: .PP ! 150: .I Lint ! 151: complains about variables and functions which are defined but not otherwise ! 152: mentioned. ! 153: An exception is variables which are declared through explicit ! 154: .B extern ! 155: statements but are never referenced; thus the statement ! 156: .DS ! 157: extern float sin(\|); ! 158: .DE ! 159: will evoke no comment if ! 160: .I sin ! 161: is never used. ! 162: Note that this agrees with the semantics of the C compiler. ! 163: In some cases, these unused external declarations might be of some interest; they ! 164: can be discovered by adding the ! 165: .B \-x ! 166: flag to the ! 167: .I lint ! 168: invocation. ! 169: .PP ! 170: Certain styles of programming ! 171: require many functions to be written with similar interfaces; ! 172: frequently, some of the arguments may be unused ! 173: in many of the calls. ! 174: The ! 175: .B \-v ! 176: option is available to suppress the printing of ! 177: complaints about unused arguments. ! 178: When ! 179: .B \-v ! 180: is in effect, no messages are produced about unused ! 181: arguments except for those ! 182: arguments which are unused and also declared as ! 183: register arguments; this can be considered ! 184: an active (and preventable) waste of the register ! 185: resources of the machine. ! 186: .PP ! 187: There is one case where information about unused, or ! 188: undefined, variables is more distracting ! 189: than helpful. ! 190: This is when ! 191: .I lint ! 192: is applied to some, but not all, files out of a collection ! 193: which are to be loaded together. ! 194: In this case, many of the functions and variables defined ! 195: may not be used, and, conversely, ! 196: many functions and variables defined elsewhere may be used. ! 197: The ! 198: .B \-u ! 199: flag may be used to suppress the spurious messages which might otherwise appear. ! 200: .SH ! 201: Set/Used Information ! 202: .PP ! 203: .I Lint ! 204: attempts to detect cases where a variable is used before it is set. ! 205: This is very difficult to do well; ! 206: many algorithms take a good deal of time and space, ! 207: and still produce messages about perfectly valid programs. ! 208: .I Lint ! 209: detects local variables (automatic and register storage classes) ! 210: whose first use appears physically earlier in the input file than the first assignment to the variable. ! 211: It assumes that taking the address of a variable constitutes a ``use,'' since the actual use ! 212: may occur at any later time, in a data dependent fashion. ! 213: .PP ! 214: The restriction to the physical appearance of variables in the file makes the ! 215: algorithm very simple and quick to implement, ! 216: since the true flow of control need not be discovered. ! 217: It does mean that ! 218: .I lint ! 219: can complain about some programs which are legal, ! 220: but these programs would probably be considered bad on stylistic grounds (e.g. might ! 221: contain at least two \fBgoto\fR's). ! 222: Because static and external variables are initialized to 0, ! 223: no meaningful information can be discovered about their uses. ! 224: The algorithm deals correctly, however, with initialized automatic variables, and variables ! 225: which are used in the expression which first sets them. ! 226: .PP ! 227: The set/used information also permits recognition of those local variables which are set ! 228: and never used; these form a frequent source of inefficiencies, and may also be symptomatic of bugs. ! 229: .SH ! 230: Flow of Control ! 231: .PP ! 232: .I Lint ! 233: attempts to detect unreachable portions of the programs which it processes. ! 234: It will complain about unlabeled statements immediately following ! 235: \fBgoto\fR, \fBbreak\fR, \fBcontinue\fR, or \fBreturn\fR statements. ! 236: An attempt is made to detect loops which can never be left at the bottom, detecting the ! 237: special cases ! 238: \fBwhile\fR( 1 ) and \fBfor\fR(;;) as infinite loops. ! 239: .I Lint ! 240: also complains about loops which cannot be entered at the top; ! 241: some valid programs may have such loops, but at best they are bad style, ! 242: at worst bugs. ! 243: .PP ! 244: .I Lint ! 245: has an important area of blindness in the flow of control algorithm: ! 246: it has no way of detecting functions which are called and never return. ! 247: Thus, a call to ! 248: .I exit ! 249: may cause unreachable code which ! 250: .I lint ! 251: does not detect; the most serious effects of this are in the ! 252: determination of returned function values (see the next section). ! 253: .PP ! 254: One form of unreachable statement is not usually complained about by ! 255: .I lint; ! 256: a ! 257: .B break ! 258: statement that cannot be reached causes no message. ! 259: Programs generated by ! 260: .I yacc , ! 261: .[ ! 262: Johnson Yacc 1975 ! 263: .] ! 264: and especially ! 265: .I lex , ! 266: .[ ! 267: Lesk Lex ! 268: .] ! 269: may have literally hundreds of unreachable ! 270: .B break ! 271: statements. ! 272: The ! 273: .B \-O ! 274: flag in the C compiler will often eliminate the resulting object code inefficiency. ! 275: Thus, these unreached statements are of little importance, ! 276: there is typically nothing the user can do about them, and the ! 277: resulting messages would clutter up the ! 278: .I lint ! 279: output. ! 280: If these messages are desired, ! 281: .I lint ! 282: can be invoked with the ! 283: .B \-b ! 284: option. ! 285: .SH ! 286: Function Values ! 287: .PP ! 288: Sometimes functions return values which are never used; ! 289: sometimes programs incorrectly use function ``values'' ! 290: which have never been returned. ! 291: .I Lint ! 292: addresses this problem in a number of ways. ! 293: .PP ! 294: Locally, within a function definition, ! 295: the appearance of both ! 296: .DS ! 297: return( \fIexpr\fR ); ! 298: .DE ! 299: and ! 300: .DS ! 301: return ; ! 302: .DE ! 303: statements is cause for alarm; ! 304: .I lint ! 305: will give the message ! 306: .DS ! 307: function \fIname\fR contains return(e) and return ! 308: .DE ! 309: The most serious difficulty with this is detecting when a function return is implied ! 310: by flow of control reaching the end of the function. ! 311: This can be seen with a simple example: ! 312: .DS ! 313: .ta .5i 1i 1.5i ! 314: \fRf ( a ) { ! 315: if ( a ) return ( 3 ); ! 316: g (\|); ! 317: } ! 318: .DE ! 319: Notice that, if \fIa\fR tests false, \fIf\fR will call \fIg\fR and then return ! 320: with no defined return value; this will trigger a complaint from ! 321: .I lint . ! 322: If \fIg\fR, like \fIexit\fR, never returns, ! 323: the message will still be produced when in fact nothing is wrong. ! 324: .PP ! 325: In practice, some potentially serious bugs have been discovered by this feature; ! 326: it also accounts for a substantial fraction of the ``noise'' messages produced ! 327: by ! 328: .I lint . ! 329: .PP ! 330: On a global scale, ! 331: .I lint ! 332: detects cases where a function returns a value, but this value is sometimes, ! 333: or always, unused. ! 334: When the value is always unused, it may constitute an inefficiency in the function definition. ! 335: When the value is sometimes unused, it may represent bad style (e.g., not testing for ! 336: error conditions). ! 337: .PP ! 338: The dual problem, using a function value when the function does not return one, ! 339: is also detected. ! 340: This is a serious problem. ! 341: Amazingly, this bug has been observed on a couple of occasions ! 342: in ``working'' programs; the desired function value just happened to have been computed ! 343: in the function return register! ! 344: .SH ! 345: Type Checking ! 346: .PP ! 347: .I Lint ! 348: enforces the type checking rules of C more strictly than the compilers do. ! 349: The additional checking is in four major areas: ! 350: across certain binary operators and implied assignments, ! 351: at the structure selection operators, ! 352: between the definition and uses of functions, ! 353: and in the use of enumerations. ! 354: .PP ! 355: There are a number of operators which have an implied balancing between types of the operands. ! 356: The assignment, conditional ( ?\|: ), and relational operators ! 357: have this property; the argument ! 358: of a \fBreturn\fR statement, ! 359: and expressions used in initialization also suffer similar conversions. ! 360: In these operations, ! 361: \fBchar\fR, \fBshort\fR, \fBint\fR, \fBlong\fR, \fBunsigned\fR, \fBfloat\fR, and \fBdouble\fR types may be freely intermixed. ! 362: The types of pointers must agree exactly, ! 363: except that arrays of \fIx\fR's can, of course, be intermixed with pointers to \fIx\fR's. ! 364: .PP ! 365: The type checking rules also require that, in structure references, the ! 366: left operand of the \(em> be a pointer to structure, the left operand of the \fB.\fR ! 367: be a structure, and the right operand of these operators be a member ! 368: of the structure implied by the left operand. ! 369: Similar checking is done for references to unions. ! 370: .PP ! 371: Strict rules apply to function argument and return value ! 372: matching. ! 373: The types \fBfloat\fR and \fBdouble\fR may be freely matched, ! 374: as may the types \fBchar\fR, \fBshort\fR, \fBint\fR, and \fBunsigned\fR. ! 375: Also, pointers can be matched with the associated arrays. ! 376: Aside from this, all actual arguments must agree in type with their declared counterparts. ! 377: .PP ! 378: With enumerations, checks are made that enumeration variables or members are not mixed ! 379: with other types, or other enumerations, ! 380: and that the only operations applied are =, initialization, ==, !=, and function arguments and return values. ! 381: .SH ! 382: Type Casts ! 383: .PP ! 384: The type cast feature in C was introduced largely as an aid ! 385: to producing more portable programs. ! 386: Consider the assignment ! 387: .DS ! 388: p = 1 ; ! 389: .DE ! 390: where ! 391: .I p ! 392: is a character pointer. ! 393: .I Lint ! 394: will quite rightly complain. ! 395: Now, consider the assignment ! 396: .DS ! 397: p = (char \(**)1 ; ! 398: .DE ! 399: in which a cast has been used to ! 400: convert the integer to a character pointer. ! 401: The programmer obviously had a strong motivation ! 402: for doing this, and has clearly signaled his intentions. ! 403: It seems harsh for ! 404: .I lint ! 405: to continue to complain about this. ! 406: On the other hand, if this code is moved to another ! 407: machine, such code should be looked at carefully. ! 408: The ! 409: .B \-c ! 410: flag controls the printing of comments about casts. ! 411: When ! 412: .B \-c ! 413: is in effect, casts are treated as though they were assignments ! 414: subject to complaint; otherwise, all legal casts are passed without comment, ! 415: no matter how strange the type mixing seems to be. ! 416: .SH ! 417: Nonportable Character Use ! 418: .PP ! 419: On the PDP-11, characters are signed quantities, with a range ! 420: from \-128 to 127. ! 421: On most of the other C implementations, characters take on only positive ! 422: values. ! 423: Thus, ! 424: .I lint ! 425: will flag certain comparisons and assignments as being ! 426: illegal or nonportable. ! 427: For example, the fragment ! 428: .DS ! 429: char c; ! 430: ... ! 431: if( (c = getchar(\|)) < 0 ) .... ! 432: .DE ! 433: works on the PDP-11, but ! 434: will fail on machines where characters always take ! 435: on positive values. ! 436: The real solution is to declare ! 437: .I c ! 438: an integer, since ! 439: .I getchar ! 440: is actually returning ! 441: integer values. ! 442: In any case, ! 443: .I lint ! 444: will say ! 445: ``nonportable character comparison''. ! 446: .PP ! 447: A similar issue arises with bitfields; when assignments ! 448: of constant values are made to bitfields, the field may ! 449: be too small to hold the value. ! 450: This is especially true because ! 451: on some machines bitfields are considered as signed ! 452: quantities. ! 453: While it may seem unintuitive to consider ! 454: that a two bit field declared of type ! 455: .B int ! 456: cannot hold the value 3, the problem disappears ! 457: if the bitfield is declared to have type ! 458: .B unsigned . ! 459: .SH ! 460: Assignments of longs to ints ! 461: .PP ! 462: Bugs may arise from the assignment of ! 463: .B long ! 464: to ! 465: an ! 466: .B int , ! 467: which loses accuracy. ! 468: This may happen in programs ! 469: which have been incompletely converted to use ! 470: .B typedefs . ! 471: When a ! 472: .B typedef ! 473: variable ! 474: is changed from \fBint\fR to \fBlong\fR, ! 475: the program can stop working because ! 476: some intermediate results may be assigned ! 477: to \fBints\fR, losing accuracy. ! 478: Since there are a number of legitimate reasons for ! 479: assigning \fBlongs\fR to \fBints\fR, the detection ! 480: of these assignments is enabled ! 481: by the ! 482: .B \-a ! 483: flag. ! 484: .SH ! 485: Strange Constructions ! 486: .PP ! 487: Several perfectly legal, but somewhat strange, constructions ! 488: are flagged by ! 489: .I lint; ! 490: the messages hopefully encourage better code quality, clearer style, and ! 491: may even point out bugs. ! 492: The ! 493: .B \-h ! 494: flag is used to enable these checks. ! 495: For example, in the statement ! 496: .DS ! 497: \(**p++ ; ! 498: .DE ! 499: the \(** does nothing; this provokes the message ``null effect'' from ! 500: .I lint . ! 501: The program fragment ! 502: .DS ! 503: unsigned x ; ! 504: if( x < 0 ) ... ! 505: .DE ! 506: is clearly somewhat strange; the ! 507: test will never succeed. ! 508: Similarly, the test ! 509: .DS ! 510: if( x > 0 ) ... ! 511: .DE ! 512: is equivalent to ! 513: .DS ! 514: if( x != 0 ) ! 515: .DE ! 516: which may not be the intended action. ! 517: .I Lint ! 518: will say ``degenerate unsigned comparison'' in these cases. ! 519: If one says ! 520: .DS ! 521: if( 1 != 0 ) .... ! 522: .DE ! 523: .I lint ! 524: will report ! 525: ``constant in conditional context'', since the comparison ! 526: of 1 with 0 gives a constant result. ! 527: .PP ! 528: Another construction ! 529: detected by ! 530: .I lint ! 531: involves ! 532: operator precedence. ! 533: Bugs which arise from misunderstandings about the precedence ! 534: of operators can be accentuated by spacing and formatting, ! 535: making such bugs extremely hard to find. ! 536: For example, the statements ! 537: .DS ! 538: if( x&077 == 0 ) ... ! 539: .DE ! 540: or ! 541: .DS ! 542: x<\h'-.3m'<2 + 40 ! 543: .DE ! 544: probably do not do what was intended. ! 545: The best solution is to parenthesize such expressions, ! 546: and ! 547: .I lint ! 548: encourages this by an appropriate message. ! 549: .PP ! 550: Finally, when the ! 551: .B \-h ! 552: flag is in force ! 553: .I lint ! 554: complains about variables which are redeclared in inner blocks ! 555: in a way that conflicts with their use in outer blocks. ! 556: This is legal, but is considered by many (including the author) to ! 557: be bad style, usually unnecessary, and frequently a bug. ! 558: .SH ! 559: Ancient History ! 560: .PP ! 561: There are several forms of older syntax which are being officially ! 562: discouraged. ! 563: These fall into two classes, assignment operators and initialization. ! 564: .PP ! 565: The older forms of assignment operators (e.g., =+, =\-, . . . ) ! 566: could cause ambiguous expressions, such as ! 567: .DS ! 568: a =\-1 ; ! 569: .DE ! 570: which could be taken as either ! 571: .DS ! 572: a =\- 1 ; ! 573: .DE ! 574: or ! 575: .DS ! 576: a = \-1 ; ! 577: .DE ! 578: The situation is especially perplexing if this ! 579: kind of ambiguity arises as the result of a macro substitution. ! 580: The newer, and preferred operators (+=, \-=, etc. ) ! 581: have no such ambiguities. ! 582: To spur the abandonment of the older forms, ! 583: .I lint ! 584: complains about these old fashioned operators. ! 585: .PP ! 586: A similar issue arises with initialization. ! 587: The older language allowed ! 588: .DS ! 589: int x \fR1 ; ! 590: .DE ! 591: to initialize ! 592: .I x ! 593: to 1. ! 594: This also caused syntactic difficulties: for example, ! 595: .DS ! 596: int x ( \-1 ) ; ! 597: .DE ! 598: looks somewhat like the beginning of a function declaration: ! 599: .DS ! 600: int x ( y ) { . . . ! 601: .DE ! 602: and the compiler must read a fair ways past ! 603: .I x ! 604: in order to sure what the declaration really is.. ! 605: Again, the problem is even more perplexing when the ! 606: initializer involves a macro. ! 607: The current syntax places an equals sign between the ! 608: variable and the initializer: ! 609: .DS ! 610: int x = \-1 ; ! 611: .DE ! 612: This is free of any possible syntactic ambiguity. ! 613: .SH ! 614: Pointer Alignment ! 615: .PP ! 616: Certain pointer assignments may be reasonable on some machines, ! 617: and illegal on others, due entirely to ! 618: alignment restrictions. ! 619: For example, on the PDP-11, it is reasonable ! 620: to assign integer pointers to double pointers, since ! 621: double precision values may begin on any integer boundary. ! 622: On the Honeywell 6000, double precision values must begin ! 623: on even word boundaries; ! 624: thus, not all such assignments make sense. ! 625: .I Lint ! 626: tries to detect cases where pointers are assigned to other ! 627: pointers, and such alignment problems might arise. ! 628: The message ``possible pointer alignment problem'' ! 629: results from this situation whenever either the ! 630: .B \-p ! 631: or ! 632: .B \-h ! 633: flags are in effect. ! 634: .SH ! 635: Multiple Uses and Side Effects ! 636: .PP ! 637: In complicated expressions, the best order in which to evaluate ! 638: subexpressions may be highly machine dependent. ! 639: For example, on machines (like the PDP-11) in which the stack ! 640: runs backwards, function arguments will probably be best evaluated ! 641: from right-to-left; on machines with a stack running forward, ! 642: left-to-right seems most attractive. ! 643: Function calls embedded as arguments of other functions ! 644: may or may not be treated similarly to ordinary arguments. ! 645: Similar issues arise with other operators which have side effects, ! 646: such as the assignment operators and the increment and decrement operators. ! 647: .PP ! 648: In order that the efficiency of C on a particular machine not be ! 649: unduly compromised, the C language leaves the order ! 650: of evaluation of complicated expressions up to the ! 651: local compiler, and, in fact, the various C compilers have considerable ! 652: differences in the order in which they will evaluate complicated ! 653: expressions. ! 654: In particular, if any variable is changed by a side effect, and ! 655: also used elsewhere in the same expression, the result is explicitly undefined. ! 656: .PP ! 657: .I Lint ! 658: checks for the important special case where ! 659: a simple scalar variable is affected. ! 660: For example, the statement ! 661: .DS ! 662: \fIa\fR[\fIi\|\fR] = \fIb\fR[\fIi\fR++] ; ! 663: .DE ! 664: will draw the complaint: ! 665: .DS ! 666: warning: \fIi\fR evaluation order undefined ! 667: .DE ! 668: .SH ! 669: Implementation ! 670: .PP ! 671: .I Lint ! 672: consists of two programs and a driver. ! 673: The first program is a version of the ! 674: Portable C Compiler ! 675: .[ ! 676: Johnson Ritchie BSTJ Portability Programs System ! 677: .] ! 678: .[ ! 679: Johnson portable compiler 1978 ! 680: .] ! 681: which is the basis of the ! 682: IBM 370, Honeywell 6000, and Interdata 8/32 C compilers. ! 683: This compiler does lexical and syntax analysis on the input text, ! 684: constructs and maintains symbol tables, and builds trees for expressions. ! 685: Instead of writing an intermediate file which is passed to ! 686: a code generator, as the other compilers ! 687: do, ! 688: .I lint ! 689: produces an intermediate file which consists of lines of ascii text. ! 690: Each line contains an external variable name, ! 691: an encoding of the context in which it was seen (use, definition, declaration, etc.), ! 692: a type specifier, and a source file name and line number. ! 693: The information about variables local to a function or file ! 694: is collected ! 695: by accessing the symbol table, and examining the expression trees. ! 696: .PP ! 697: Comments about local problems are produced as detected. ! 698: The information about external names is collected ! 699: onto an intermediate file. ! 700: After all the source files and library descriptions have ! 701: been collected, the intermediate file is sorted ! 702: to bring all information collected about a given external ! 703: name together. ! 704: The second, rather small, program then reads the lines ! 705: from the intermediate file and compares all of the ! 706: definitions, declarations, and uses for consistency. ! 707: .PP ! 708: The driver controls this ! 709: process, and is also responsible for making the options available ! 710: to both passes of ! 711: .I lint . ! 712: .SH ! 713: Portability ! 714: .PP ! 715: C on the Honeywell and IBM systems is used, in part, to write system code for the host operating system. ! 716: This means that the implementation of C tends to follow local conventions rather than ! 717: adhere strictly to ! 718: .UX ! 719: system conventions. ! 720: Despite these differences, many C programs have been successfully moved to GCOS and the various IBM ! 721: installations with little effort. ! 722: This section describes some of the differences between the implementations, and ! 723: discusses the ! 724: .I lint ! 725: features which encourage portability. ! 726: .PP ! 727: Uninitialized external variables are treated differently in different ! 728: implementations of C. ! 729: Suppose two files both contain a declaration without initialization, such as ! 730: .DS ! 731: int a ; ! 732: .DE ! 733: outside of any function. ! 734: The ! 735: .UX ! 736: loader will resolve these declarations, and cause only a single word of storage ! 737: to be set aside for \fIa\fR. ! 738: Under the GCOS and IBM implementations, this is not feasible (for various stupid reasons!) ! 739: so each such declaration causes a word of storage to be set aside and called \fIa\fR. ! 740: When loading or library editing takes place, this causes fatal conflicts which prevent ! 741: the proper operation of the program. ! 742: If ! 743: .I lint ! 744: is invoked with the \fB\-p\fR flag, ! 745: it will detect such multiple definitions. ! 746: .PP ! 747: A related difficulty comes from the amount of information retained about external names during the ! 748: loading process. ! 749: On the ! 750: .UX ! 751: system, externally known names have seven significant characters, with the upper/lower ! 752: case distinction kept. ! 753: On the IBM systems, there are eight significant characters, but the case distinction ! 754: is lost. ! 755: On GCOS, there are only six characters, of a single case. ! 756: This leads to situations where programs run on the ! 757: .UX ! 758: system, but encounter loader ! 759: problems on the IBM or GCOS systems. ! 760: .I Lint ! 761: .B \-p ! 762: causes all external symbols to be mapped to one case and truncated to six characters, ! 763: providing a worst-case analysis. ! 764: .PP ! 765: A number of differences arise in the area of character handling: characters in the ! 766: .UX ! 767: system are eight bit ascii, while they are eight bit ebcdic on the IBM, and ! 768: nine bit ascii on GCOS. ! 769: Moreover, character strings go from high to low bit positions (``left to right'') ! 770: on GCOS and IBM, and low to high (``right to left'') on the PDP-11. ! 771: This means that code attempting to construct strings ! 772: out of character constants, or attempting to use characters as indices ! 773: into arrays, must be looked at with great suspicion. ! 774: .I Lint ! 775: is of little help here, except to flag multi-character character constants. ! 776: .PP ! 777: Of course, the word sizes are different! ! 778: This causes less trouble than might be expected, at least when ! 779: moving from the ! 780: .UX ! 781: system (16 bit words) to the IBM (32 bits) or GCOS (36 bits). ! 782: The main problems are likely to arise in shifting or masking. ! 783: C now supports a bit-field facility, which can be used to write much of ! 784: this code in a reasonably portable way. ! 785: Frequently, portability of such code can be enhanced by ! 786: slight rearrangements in coding style. ! 787: Many of the incompatibilities seem to have the flavor of writing ! 788: .DS ! 789: x &= 0177700 ; ! 790: .DE ! 791: to clear the low order six bits of \fIx\fR. ! 792: This suffices on the PDP-11, but fails badly on GCOS and IBM. ! 793: If the bit field feature cannot be used, the same effect can be obtained by ! 794: writing ! 795: .DS ! 796: x &= \(ap 077 ; ! 797: .DE ! 798: which will work on all these machines. ! 799: .PP ! 800: The right shift operator is arithmetic shift on the PDP-11, and logical shift on most ! 801: other machines. ! 802: To obtain a logical shift on all machines, the left operand can be ! 803: typed \fBunsigned\fR. ! 804: Characters are considered signed integers on the PDP-11, and unsigned on the other machines. ! 805: This persistence of the sign bit may be reasonably considered a bug in the PDP-11 hardware ! 806: which has infiltrated itself into the C language. ! 807: If there were a good way to discover the programs which would be affected, C could be changed; ! 808: in any case, ! 809: .I lint ! 810: is no help here. ! 811: .PP ! 812: The above discussion may have made the problem of portability seem ! 813: bigger than it in fact is. ! 814: The issues involved here are rarely subtle or mysterious, at least to the ! 815: implementor of the program, although they can involve some work to straighten out. ! 816: The most serious bar to the portability of ! 817: .UX ! 818: system utilities has been the inability to mimic ! 819: essential ! 820: .UX ! 821: system functions on the other systems. ! 822: The inability to seek to a random character position in a text file, or to establish a pipe ! 823: between processes, has involved far more rewriting ! 824: and debugging than any of the differences in C compilers. ! 825: On the other hand, ! 826: .I lint ! 827: has been very helpful ! 828: in moving the ! 829: .UX ! 830: operating system and associated ! 831: utility programs to other machines. ! 832: .SH ! 833: Shutting Lint Up ! 834: .PP ! 835: There are occasions when ! 836: the programmer is smarter than ! 837: .I lint . ! 838: There may be valid reasons for ``illegal'' type casts, ! 839: functions with a variable number of arguments, etc. ! 840: Moreover, as specified above, the flow of control information ! 841: produced by ! 842: .I lint ! 843: often has blind spots, causing occasional spurious ! 844: messages about perfectly reasonable programs. ! 845: Thus, some way of communicating with ! 846: .I lint , ! 847: typically to shut it up, is desirable. ! 848: .PP ! 849: The form which this mechanism should take is not at all clear. ! 850: New keywords would require current and old compilers to ! 851: recognize these keywords, if only to ignore them. ! 852: This has both philosophical and practical problems. ! 853: New preprocessor syntax suffers from similar problems. ! 854: .PP ! 855: What was finally done was to cause a number of words ! 856: to be recognized by ! 857: .I lint ! 858: when they were embedded in comments. ! 859: This required minimal preprocessor changes; ! 860: the preprocessor just had to agree to pass comments ! 861: through to its output, instead of deleting them ! 862: as had been previously done. ! 863: Thus, ! 864: .I lint ! 865: directives are invisible to the compilers, and ! 866: the effect on systems with the older preprocessors ! 867: is merely that the ! 868: .I lint ! 869: directives don't work. ! 870: .PP ! 871: The first directive is concerned with flow of control information; ! 872: if a particular place in the program cannot be reached, ! 873: but this is not apparent to ! 874: .I lint , ! 875: this can be asserted by the directive ! 876: .DS ! 877: /* NOTREACHED */ ! 878: .DE ! 879: at the appropriate spot in the program. ! 880: Similarly, if it is desired to turn off ! 881: strict type checking for ! 882: the next expression, the directive ! 883: .DS ! 884: /* NOSTRICT */ ! 885: .DE ! 886: can be used; the situation reverts to the ! 887: previous default after the next expression. ! 888: The ! 889: .B \-v ! 890: flag can be turned on for one function by the directive ! 891: .DS ! 892: /* ARGSUSED */ ! 893: .DE ! 894: Complaints about variable number of arguments in calls to a function ! 895: can be turned off by the directive ! 896: .DS ! 897: /* VARARGS */ ! 898: .DE ! 899: preceding the function definition. ! 900: In some cases, it is desirable to check the ! 901: first several arguments, and leave the later arguments unchecked. ! 902: This can be done by following the VARARGS keyword immediately ! 903: with a digit giving the number of arguments which should be checked; thus, ! 904: .DS ! 905: /* VARARGS2 */ ! 906: .DE ! 907: will cause the first two arguments to be checked, the others unchecked. ! 908: Finally, the directive ! 909: .DS ! 910: /* LINTLIBRARY */ ! 911: .DE ! 912: at the head of a file identifies this file as ! 913: a library declaration file; this topic is worth a ! 914: section by itself. ! 915: .SH ! 916: Library Declaration Files ! 917: .PP ! 918: .I Lint ! 919: accepts certain library directives, such as ! 920: .DS ! 921: \-ly ! 922: .DE ! 923: and tests the source files for compatibility with these libraries. ! 924: This is done by accessing library description files whose ! 925: names are constructed from the library directives. ! 926: These files all begin with the directive ! 927: .DS ! 928: /* LINTLIBRARY */ ! 929: .DE ! 930: which is followed by a series of dummy function ! 931: definitions. ! 932: The critical parts of these definitions ! 933: are the declaration of the function return type, ! 934: whether the dummy function returns a value, and ! 935: the number and types of arguments to the function. ! 936: The VARARGS and ARGSUSED directives can ! 937: be used to specify features of the library functions. ! 938: .PP ! 939: .I Lint ! 940: library files are processed almost exactly like ordinary ! 941: source files. ! 942: The only difference is that functions which are defined on a library file, ! 943: but are not used on a source file, draw no complaints. ! 944: .I Lint ! 945: does not simulate a full library search algorithm, ! 946: and complains if the source files contain a redefinition of ! 947: a library routine (this is a feature!). ! 948: .PP ! 949: By default, ! 950: .I lint ! 951: checks the programs it is given against a standard library ! 952: file, which contains descriptions of the programs which ! 953: are normally loaded when ! 954: a C program ! 955: is run. ! 956: When the ! 957: .B -p ! 958: flag is in effect, another file is checked containing ! 959: descriptions of the standard I/O library routines ! 960: which are expected to be portable across various machines. ! 961: The ! 962: .B -n ! 963: flag can be used to suppress all library checking. ! 964: .SH ! 965: Bugs, etc. ! 966: .PP ! 967: .I Lint ! 968: was a difficult program to write, partially ! 969: because it is closely connected with matters of programming style, ! 970: and partially because users usually don't notice bugs which cause ! 971: .I lint ! 972: to miss errors which it should have caught. ! 973: (By contrast, if ! 974: .I lint ! 975: incorrectly complains about something that is correct, the ! 976: programmer reports that immediately!) ! 977: .PP ! 978: A number of areas remain to be further developed. ! 979: The checking of structures and arrays is rather inadequate; ! 980: size ! 981: incompatibilities go unchecked, ! 982: and no attempt is made to match up structure and union ! 983: declarations across files. ! 984: Some stricter checking of the use of the ! 985: .B typedef ! 986: is clearly desirable, but what checking is appropriate, and how ! 987: to carry it out, is still to be determined. ! 988: .PP ! 989: .I Lint ! 990: shares the preprocessor with the C compiler. ! 991: At some point it may be appropriate for a ! 992: special version of the preprocessor to be constructed ! 993: which checks for things such as unused macro definitions, ! 994: macro arguments which have side effects which are ! 995: not expanded at all, or are expanded more than once, etc. ! 996: .PP ! 997: The central problem with ! 998: .I lint ! 999: is the packaging of the information which it collects. ! 1000: There are many options which ! 1001: serve only to turn off, or slightly modify, ! 1002: certain features. ! 1003: There are pressures to add even more of these options. ! 1004: .PP ! 1005: In conclusion, it appears that the general notion of having two ! 1006: programs is a good one. ! 1007: The compiler concentrates on quickly and accurately turning the ! 1008: program text into bits which can be run; ! 1009: .I lint ! 1010: concentrates on issues ! 1011: of portability, style, and efficiency. ! 1012: .I Lint ! 1013: can afford to be wrong, since incorrectness and over-conservatism ! 1014: are merely annoying, not fatal. ! 1015: The compiler can be fast since it knows that ! 1016: .I lint ! 1017: will cover its flanks. ! 1018: Finally, the programmer can ! 1019: concentrate at one stage ! 1020: of the programming process solely on the algorithms, ! 1021: data structures, and correctness of the ! 1022: program, and then later retrofit, ! 1023: with the aid of ! 1024: .I lint , ! 1025: the desirable properties of universality and portability. ! 1026: .SG MH-1273-SCJ-unix ! 1027: .\".bp ! 1028: .[ ! 1029: $LIST$ ! 1030: .] ! 1031: .bp ! 1032: .SH ! 1033: Appendix: Current Lint Options ! 1034: .PP ! 1035: The command currently has the form ! 1036: .DS ! 1037: lint\fR [\fB\-\fRoptions ] files... library-descriptors... ! 1038: .DE ! 1039: The options are ! 1040: .IP \fBh\fR ! 1041: Perform heuristic checks ! 1042: .IP \fBp\fR ! 1043: Perform portability checks ! 1044: .IP \fBv\fR ! 1045: Don't report unused arguments ! 1046: .IP \fBu\fR ! 1047: Don't report unused or undefined externals ! 1048: .IP \fBb\fR ! 1049: Report unreachable ! 1050: .B break ! 1051: statements. ! 1052: .IP \fBx\fR ! 1053: Report unused external declarations ! 1054: .IP \fBa\fR ! 1055: Report assignments of ! 1056: .B long ! 1057: to ! 1058: .B int ! 1059: or shorter. ! 1060: .IP \fBc\fR ! 1061: Complain about questionable casts ! 1062: .IP \fBn\fR ! 1063: No library checking is done ! 1064: .IP \fBs\fR ! 1065: Same as ! 1066: .B h ! 1067: (for historical reasons)
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.