On Mon, Feb 22, 2016 at 10:35:21AM +0100, Lukas Slebodnik wrote: > On (22/02/16 10:28), Jakub Hrozek wrote: > >On Mon, Feb 22, 2016 at 10:19:31AM +0100, Lukas Slebodnik wrote: > >> On (22/02/16 10:01), Jakub Hrozek wrote: > >> >Hi, > >> > > >> >during my work on pam_hbac I ran into some issues in libipa_hbac that I > >> >would like to fix. And before doing the work I wanted to check if anyone > >> >is opposed to these changes. > >> > > >> >I would like to: > >> > 1) Stop using C99 in libipa_hbac. pam_hbac can run on old and/or > >> > strange platforms that don't support C99 compilers. > >> > > >> > 2) Stop using sss_utf8_case_eq unconditionally and rather use an > >> > externally-provided function, a bit like we already set the debug > >> > function. I was thinking even about creating hbac_init() that > >> > would accept these functions and return a context which would then > >> > be passed to other libipa_hbac functions, but this would be an API > >> > break. Alternatively, we could just use a function setter, I just > >> > think > >> > the context might be clearer..and IIRC the C libipa_hbac API is used > >> > only by the python bindings at the moment. > >> > > >> what about ifdef? > > > >How would I solve this with ifdef? I mean, the consumer of the library > >has to provide the UTF8 case-matching function one way or another. > The same way as in src/util/sss_utf8.c. > or which (external) function would you like to use on other platforms?
I think this is fine for whoever is implementing the functions, but I'm not sure I like ifdefs in the libipa_hbac itself.. If we don't want to change the API, what about adding "hbac_set_utf8_case_eq_fn()" that SSSD would call with sss_utf8_case_eq() and pam_hbac would call it with something like ph_utf8_case_eq() ? (I didn't like the global function pointer inside libipa_hbac, that's why the context seemed nicer to me..) _______________________________________________ sssd-devel mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected]
