[SSSD] [PATCH] ELAPI sinks and providers

Jakub Hrozek jhrozek at redhat.com
Thu Aug 27 17:15:43 UTC 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/25/2009 11:00 PM, Dmitri Pal wrote:
> Please see the patch comment.
>  
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel

Couple of comments:
* Instead of putting libprovider.la into _SOURCES, maybe you wanted to
add it to libelapi_la_LIBADD?

* in elapi_print_sink_ctx() instead of casting pointer to uint32_t and
printing with %X, you should use %p without casting the pointer

* why are elapi_sink_cfg.required and elapi_sink_cfg.synch defined as
uint32_t? They seem to have bool semantics, maybe bool would be more
appropriate. Anyhow, using uint32_t to store unsigned int (or unsigned
char in case of get_bool_config_value() even though it should not matter
here as unsigned char will be smaller than 32 bits) return value might
not be correct on all platforms.
** the same applies to struct file_prvdr_cfg in file_provider.h, I don't
understand using uint32_t to store bool values
** Not strictly related to the patch but why does
get_bool_config_value() return char and not bool?

* in elapi_load_lib() why not use snprintf instead of checking the
length and then using sprintf() ?

* in elapi_sink_loader() instead of using array of names and a switch
just to assign the callback, maybe it would be cleaner to use array of {
name, ability } tuples  - that way you would just update on one place

* in elapi_sink_create(), if the intent is to have the structure zeroed,
why not use calloc()? Or zero the structure out with memset?

	Jakub
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkqWvz8ACgkQHsardTLnvCW5vACeOXVIgOUTtZfEE0E7zBBbWfom
NCgAmwT6f8a9ozCcBeTo1wfl445L2wVC
=sXR5
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list