libmsrpc feedback

[Gerald (Jerry) Carter]

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

Copied back to the list for posterity.

Chris Nicholls wrote:
> Hi Jerry,
> 
> Whenever you get a chance to look at the libmsrpc code, I wouldn't mind
> hearing your comments on cac_SamGetNamesFromRids(), which calls
> cli_samr_lookup_rids().  Basically what I've done is return return 2
> arrays, one has the names that were looked up, and the other has the
> RIDs that couldnt be found.  However, in order to preserve a mapping
> between RIDs and names, it also has to return another array that
> contains the RIDs that were found.

Why not deal with an array of a structure like

struct cac_LookupRidsRecord {
	char *name;
	uint32 rid;
	NTSTATUS status;
};

?

Then a developer would know whether a given name was mapped by
checking NT_STATUS_IS_OK( array[i].status ).

> At first, it seemed like a good idea but as I was writing it, I started
> questioning it.  On one hand it will make it a little easier for a
> developer since they don't have to check that a name was actually found
> for an RID or sift through the list to find out which ones were not
> found, but on the other hand it's a little expensive in terms of
> overhead and memory usage.  But, when I try to 'picture' typical usage
> of this function, I think most of the time it will successfully return
> names for all of the RIDs that are looked up, so this may not be a big
> issue.

Trying to coordinate entries between 3 arrays is a little hairy IMO.
Memory usage is probably not that big a deal here.





cheers, jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDAe91IR7qMdg1EfYRAt/zAKCBRyKpuIk01fEabRLe7vHrXqzGMQCgocNq
ZTglaw1ONpJLsSwXSMT3fP0=
=XBoz
-----END PGP SIGNATURE-----