> I think the Sun guys didn't think when they implemented this. I actually
> asked the Sun guys about it when I was writing this part of libpam_misc
> (5 years ago?) and they never gave any response. The first I heard that
> they had implemented it wrongly was actually about a year ago, when a
> commercial module developer emailed me to say that they'd run into this
> problem with their module and had opted to support both meanings of
> 'pam_message **' in what they passed to the conversation function.
> Slightly sick, but quite doable.
I'm probably being dense, I read the documentation as:
"int conv(int num_msg, const struct pam_message **msg,
struct pam_response **resp, void *appdata_ptr);
The num_msg parameter is the number of messages associated with the
call. The parameter msg is a pointer to an array of length num_msg of
the pam_message structure."
Not an array of pam_message structure pointers.
The code implements it as:
msg = (struct pam_message *)calloc(num_msg,
sizeof (struct pam_message));
retcode = (pam_convp->conv)(num_msg, &msg, ret_respp,
conv_apdp);
That seems the same to me as const struct pam_message *msg[]. Though
I agree *msg[] might be clearer. I believe whomever did the prototype
at X/Open followed the main(int argc, char **argv, char **envp)
prototype that was popular at one time. IMO, the X/Open spec has a
number of typos that should be corrected some day. This could be one
of them.
> Nothing. Perhaps file a bug report with the Solaris folk? ;)
Bug reports are always appreciated. Internal testing cannot find
all the bugs. -^<
Gary..
