Even worse than I thought. First, the account functions return an
"int", unlike everything else, which returns "ISC_STATUS" (aka "long").
Second, the miserable functions don't take database handles. I willing
to give the benefit of the doubt to the brain-dead idea that database
accounts are system wide rather than database specific, but an
architecture makes implementation of a more reasonable option is a
little dim.

I propose the following:

ISC_STATUS API_ROUTINE fb_update_account_info (ISC_STATUS* userStatus,
DbHandle *dbHandle,
USHORT apbLength,
UCHAR *apb)

where a null data handle, rather than returning the rightful "bad
handle" exception, gives the sorry packet to the default, sys-wide
security system. Everyone else can give a valid database handle and the
packet will get delivered to their favorite engine for forwarding to
their lovingly crafted and selected database security plugin.

The "account parameter block" is standard clumplet form:

<verb-byte><length-byte><stuff>...

where <stuff>... is either ascii or a binary number, least significant
byte first.

The values are (yes, Virginia, they line up in a fixed font):

/*********************************/
/* Account parameter block stuff */
/*********************************/

#define fb_apb_version1 1
#define fb_apb_uid 2 // user id
#define fb_apb_gid 3 // group id
#define fb_apb_protocol 4
#define fb_apb_account 5
#define fb_apb_password 6
#define fb_apb_group 7
#define fb_apb_first_name 8
#define fb_apb_middle_name 9
#define fb_apb_last_name 10
#define fb_apb_user_name 11
#define fb_apb_password 12
#define fb_create_account 13
#define fb_update_account 14
#define fb_delete_account 15