jdm5548@diamond.tamu.edu (James Darrell McCauley) (09/09/90)
How do you professionals deal with insignificant(?) ravings from lint (or other high quality C program verifiers) such as the following: >test.c(x): warning: possible pointer alignment problem which was caused by the malloc in: >double **dmatrix(nr,nc) >int nr,nc; >{ > double **m = NULL; > > m = (double **) malloc( (unsigned) nr * sizeof(double *) ); > if (!m) ... From what netlanders tell me, this warning is explanined as: (by Conor P. Cahill) |> The problem is that malloc is defined |> as returning a pointer to char which has looser alignment requirements than |> pointer to pointer. Since malloc guarrantees that the result is suitably |> alligned for all data types, you can ignore this message. Well, I can just ignore warnings like this, but those who review my code (professors, employers, clients) are not likely to. It makes an bad impression and frankly, I find it a little embarrassing. (I'm embarrassed for those who publish code in which lint detects things like unused arguments, etc). I could just: #ifndef lint m = (double *) malloc(... #endif but before long, the code looks disgusting. Do you just ignore warnings like this and remain confident in your code, or do you do your best to work around them? By the way, I got this error while using a Sparc under Sun OS 4.0.3c, but not under 4.0.3 (which perplexes me). --- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - James Darrell McCauley jdm5548@diamond.tamu.edu Dept of Ag. Engineering (409) 845-6484 Texas A&M University, College Station, Texas 77843-2117, USA - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ik@laic.UUCP (Ik Su Yoo) (09/10/90)
> > Well, I can just ignore warnings like this, but those who review > my code (professors, employers, clients) are not likely to. It makes > an bad impression and frankly, I find it a little embarrassing. > (I'm embarrassed for those who publish code in which lint detects > things like unused arguments, etc). I could just: > #ifndef lint > m = (double *) malloc(... > #endif > but before long, the code looks disgusting. Do you just ignore > warnings like this and remain confident in your code, or do you > do your best to work around them? > Actually, I'm not at all embarrassed by getting lint errors like unused arguments etc., although I'm not sure why you'd want to show lint output to your customers. Sometimes, I find it necessary to specify unused arguments to achieve proper abstraction, consistent argument specification, etc. There is a rather simple solution (which I picked up from the net) to your code getting messy from using `ifndef' with each `malloc': #ifndef lint #define MALLOC(size) (malloc(size)) #else #define MALLOC(size) (0) #endif -- | Ik Su Yoo | Office: (415) 354-5584 | | Scientist @ Lockheed AI Center | Fax: (415) 354-5235 | | Orgn. 96-20, Bldg. 259, 3251 Hanover St. | E-mail: ik@laic.lockheed.com | | Palo Alto, CA 94304-1191 | |
moraes@cs.toronto.edu (Mark Moraes) (09/12/90)
ik@laic.UUCP (Ik Su Yoo) writes: >#ifndef lint >#define MALLOC(size) (malloc(size)) >#else >#define MALLOC(size) (0) >#endif With the unfortunate side effect that you now don't let lint check the argument to malloc/calloc/realloc/free. I much prefer the lint noise to this -- the lint noise doesn't hurt, but a missing argument to realloc may. If you create functions to allocate the different types you need, and stick them in a file, you get the lint noise in a single well-known place (or a few well-known places) and can easily ignore it. Mark.