Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!bbn!aoa!chuckles
From: chuckles@aoa.UUCP (Charles Stern)
Newsgroups: comp.unix.questions
Subject: Re: Shutting lint up about malloc (missing /*NOSTRICT*/)
Message-ID: <262@aoa.UUCP>
Date: Tue, 19-May-87 11:44:45 EDT
Article-I.D.: aoa.262
Posted: Tue May 19 11:44:45 1987
Date-Received: Sat, 23-May-87 04:23:11 EDT
References: <61@amanue.UUCP>
Reply-To: chuckles@aoa.UUCP (Charles Stern)
Followup-To: <61@amanue.UUCP>
Organization: Adaptive Optics Assoc., Cambridge, Mass. USA
Lines: 94
Keywords: lint malloc NOSTRICT
Summary: NOISY lint

In article <61@amanue.UUCP> jr@amanue.UUCP (Jim Rosenberg) writes:
>This is driving me nuts.  I can't get lint on my system to shut up about
>malloc.  In response to the following code:
>
>#include <stdio.h>
>
>struct foo {
>	int foo1;
>	char foo2;
>};
>
>extern char *malloc();
>
>struct foo *goo()
>{
>	struct foo *p;
>
>	/*NOSTRICT*/
>	if ((p = (struct foo*) malloc(sizeof(struct foo))) == NULL) {
>		(void) fprintf(stderr, "Out er memory, turkey\n");
>		return NULL;
>	}
>	return p;
>}
>
>the command lint -u prints:
>
>warning: possible pointer alignment problem
>    (15)  	
>
>Aargh!!  The man page for malloc() sayeth:  "malloc returns a pointer to
>a block of at least _size_ bytes suitably aligned for any use".  Right.
>lint apparently doesn't capiche that malloc() strains itself most mightly
>to achieve this.  Well, OK, so my lint is too dumb to know about malloc(),
>which arguably it should, what about /*NOSTRICT*/ -- isn't this supposed
>to turn off this kind of message??  The tutorial for lint says:
>
>"If it is desired to turn off strict type checking for an expression, the
>comment
>
>	/* NOSTRICT */
>
>should be added to the program immediately before the expression."
>
>Right.  Well it didn't tell lint to please unsquawk.  My system is VENIX
>System V, which is a pretty straight V.2 except for implementing its own
>shared memory calls and the /usr/group locking standard -- one would think
>it would be an off-the-tape lint.  It can't be *that* ancient since it does
>seem to know about void.  strings run on the file /usr/lib/lint1 produces
>the following: (line numbers added)
>
>	57:123456789
>	58:VARARGS
>	59:LINTLIBRARY
>	60:ARGSUSED
>	61:NOTREACHED
>	62:yylex error, character %03o (octal)
>
>Hmm.  No NOSTRICT.  grepping for STRICT in the strings listing yields
>nothing.  Same for /usr/lib/lint2.  So it sort of looks as though /*NOSTRCT*/
>got dumped from my version of lint.
>
>(1) Did /*NOSTRICT*/ get dropped somewhere?  If so, was this a mistake?  If
>not, can someone tell me **WHY**??  (2) Absent /*NOSTRICT*/ how the devil
>am I supposed to get lint to shut up about casting the value returned by
>malloc() to a struct <whatever> *?  The cast makes it clear what I mean and
>the man page says I can do it.
>
>I have some code that would completely pass lint but for this annoyance.


This may be a rather simplistic answer to your question, but I suggest 
taking your assignment of p OUT of the conditional statement.  For some
reason, if I am writing shell scripts or C code, and I do something more
complex than comparing two objects, the compiler throws up (Vax 8650
running Ultrix 2.1).  This is the easiest answer I can give you, since I
*DON'T* write device drivers using cat>. :-#) (See an article a couple of
weeks ago defining various user levels.)

Chuckles
-- 
                    |                                     \  |  /
         /\      -------      /\                           \ | /
        /  \    |   |   |    /  \                           \|/
------ /----\---|---|---|---/----\---------------------------|---
      /      \  |   |   |  /      \                         /|\
     /        \  -------  /        \                       / | \
                    |                                     /  |  \
             
	Charles Stern
	...!{decvax,linus,ima,ihnp4}!bbncca!aoa!chuckles
	...!{wjh12,mit-vax}!biomed!aoa!chuckles

Quantum Mechanics - "Where constants aren't, and variables de ae ae