ries@trwrb.UUCP (03/11/87)
In article <5347@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: [... discussions on dynamically allocating arrays deleted ...] >> >> fnames = (char (*)[16][32])malloc(16*32*sizeof(char)); >> [.. more deletions ...] >Of course, proper paranoia also includes checking the return >value from malloc(): > > if ((fnames = (char (*)[32]) malloc(16 * sizeof (char [32))) == NULL) > ... /* handle out of memory error */ > >Another annoying nit is that malloc() takes an unsigned argument, >while sizeof has type `size_t', which is not necessarily unsigned >(it is signed in 4BSD), requiring yet more casts. (I would rather >have an unsigned `size_t'.) >-- >In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept I have followed the discussion because of the comments on de- linting and portability. Maybe one of the linting experts can comment on the following case. I noticed that while practicing de-linting the "filter" code in the latest release of Dave Taylor's "ELM" mailer, the "parse.c" code has several lines of the type: if ((cond = (struct condition_rec *) malloc(sizeof(struct condition_rec))) == NULL) { (void) fprintf(stderr,"couldn't malloc first condition rec!\n"); return(-1); } where: char *malloc(); struct condition_rec *cond; lint (Pyramid 98X, 3.1 DualOSx, BSD Universe): "warning: possible pointer alignment problem" llib-lc: char * malloc(n) unsigned n; {static char c; return(&c);} Summary: Several gyrations of trying to get lint to shut up hasn't. I there a way to get lint to pass this, make this "more" portable, or ?. Marc A. Ries sdcrdcf!---\ ihnp4!------\----- trwrb! --- ries -- Marc A. Ries sdcrdcf!---\ ihnp4!------\----- trwrb! --- ries
guy@gorodish.UUCP (03/14/87)
> char *malloc(); > struct condition_rec *cond; > >lint (Pyramid 98X, 3.1 DualOSx, BSD Universe): > "warning: possible pointer alignment problem" > ... > hasn't. I there a way to get lint to pass this, make > this "more" portable ...? No, short of waiting for ANSI C, where there is a "void *" data type for "generic" pointers, and "malloc" returns a pointer of that type. Presumably pointers of this type could be converted to and from pointers of other types, in implementations that support "void *", without this "lint" warning. (Yes, there is still a possible alignment problem, but "lint" should assume that somebody writing a routine that constructs a "void *" value and returns it knows this already and has dealt with it.)
karl@haddock.UUCP (Karl Heuer) (03/17/87)
In article <15040@sun.uucp> guy@sun.UUCP (Guy Harris) writes: [In response to a query about silencing the lint warning on malloc] >No [solution], short of waiting for ANSI C, where there is a "void *" data >type for "generic" pointers, and "malloc" returns a pointer of that type. >Presumably pointers of this type could be converted to and from pointers of >other types, in implementations that support "void *", without this "lint" >warning. (Yes, there is still a possible alignment problem, but "lint" >should assume that somebody writing a routine that constructs a "void *" >value and returns it knows this already and has dealt with it.) I would prefer that lint *not* make this assumption, and continue to give the warning; however, there should be a new lint-pragma /*ALIGNED*/ to handle the malloc-like functions. (This need not wait for ANSI C. Somebody should write this and post it to mod.sources.) Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint (Relevant section of X3J11, as of the May86 Draft: (5.5) Common Warnings: An implicit narrowing conversion is encountered, such as the assignment of a pointer to void to [some other pointer].