On Jul 12, 10:11am, Emmanuel Dreyfus wrote:
} 
} In order to cross-compile libpam from amd64 to macppc, I had to apply the
} attached patches to the source. Does that need to be committed and propagated to
} OpenPAM, or is there a lint flag that needs to get rid of in our build system?

     I see that Christos has already answered, but I've done some digging.

} There are two distincts problems: sizeof's result is not of type size_t, and

     Christos says it is, and I don't have my C references handy at the
moment in order to double check, so I'm going to accept his answer.

} lint will complain about that when sizeof is used as an argument for a function
} that wants size_t (e.g.: calloc and friends). Lint shuts up if I add a (size_t)
} cast.

     Since sizeof is supposed to return size_t, it sounds like lint is
broken.

} Second problem: *data = (void *)(intptr_t)dp->data; bugs because converting a
} pointer to int may loose bits. Indeed, but where is the conversion? Removing the
} (intptr_t) cast cause lint to shut up.

     This one I find curious.  I checked it out.  dp->data is of type
'void *'.  intptr_t is a machine dependent type, on sparc64 it is 'long
int'.  *data is of type 'void *'.  Basically, it is taking a 'void *',
casting it to 'long int' (depending on platform), casting it back to
'void *', and finally assigning it to 'void *'?  Why all the casts when
the value is already of the proper type?  What happens if you take out
both casts?  Does that break anything?

}-- End of excerpt from Emmanuel Dreyfus