On Sat, Mar 03, 2001 at 04:14:32PM -0800, Andrew Morgan wrote:
> I firmly believe this is a Solaris implementation bug.

Indeed.

> Consider the similarity with the common practice definition:
>
> main(int argc, char **argv)
> {
> /* .. */
> }
>
> If we look at what Sun implements, its this:
>
> conv(...., x, ....);
>
> where x = &y; y = &m[0]; and m[0]....m[n] is there message array. By
> what logic can one possibly justify the indirection introduced by using
> 'y'?

My guess? x is (struct pam_message **) and so matches the prototype,
even if it's dead wrong. This bug is not noticeable until n > 1.

I believe n == 1, always, with stock Solaris PAM modules. So Sun could
fix this without breaking any of their modules or applications, but
customers' modules/apps would require fixes if any customer or 3rd party
module can have n > 1.

> If the prototype had been this:
>
> int (*conv)(int num_msg, const struct pam_message *msg,
> struct pam_response **resp, void *appdata_ptr);
>
> this issue would not have arisen.

Why? Compiler warnings are easy to ignore :) :)

> We can define conversations more flexibly using the Linux-PAM
> definition, it thus it seems like the right one to me.

Linux-PAM does it right.

> Cheers
>
> Andrew
>

Nico

--
_______________________________________________
Pam-list mailing list
Pam-listredhat.com
https://listman.redhat.com/mailman/listinfo/pam-list

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]