Subject: Re: libpam build problems
To: Emmanuel Dreyfus <firstname.lastname@example.org>
From: John Nemeth <email@example.com>
Date: 02/19/2005 13:34:24
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)
Since sizeof is supposed to return size_t, it sounds like lint is
} 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