[332] in Kerberos_V5_Development
Re: Mystifying problem with function prototypes....
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue Oct 16 16:07:54 1990
Date: Tue, 16 Oct 90 16:07:31 -0400
From: Theodore Ts'o <tytso@ATHENA.MIT.EDU>
To: Ralph Swick <swick@ATHENA.MIT.EDU>
Cc: tytso@ATHENA.MIT.EDU, krbdev@ATHENA.MIT.EDU
In-Reply-To: [331]
Reply-To: tytso@ATHENA.MIT.EDU
[0331] daemon@ATHENA.MIT.EDU (Ralph Swick) Kerberos_V5_Development 10/16/90 15:54 (29 lines)
Date: Tue, 16 Oct 90 15:53:24 EDT
From: Ralph Swick <swick@ATHENA.MIT.EDU>
Other prototypes in kdb.h reference krb5_boolean with out any problem at
all.
Then something else is bizarre; it should only be possible to use
pointers to narrow types in the prototypes. I had to do some crocky
stuff in the X headers to deal with this. More details if you want
'em.
From the same file (kdb.h)
krb5_error_code krb5_db_set_nonblocking
PROTOTYPE((krb5_boolean,
krb5_boolean * ));
Appearently, it worked here. No, never mind, it didn't; this function
is declared in all of the prototypes, but is never defined anywhere, so
we never noticed the problem. Argh! (It will be disappearing
presently....)
What was the crocky stuff in the X headers? I'm quite willing to just
leave the "int" declaration in function prototype, but there might be
pickier people who would perfer the "right thing" in the header files.
Dunno, but the business of include/krb5/kdb_dbm.h
#define'ing krb5_dbm_db_set_lockmode krb5_db_set_lockmode
seems a tad crocky to me by-the-way. I assume there was
a legitimate reason at one time.
Yes, it is a crock. (And it's all over kdb.h and kdb_dbm.h.) I believe
the original justification was that we didn't want to pay the cost of an
additional indirection through a glue layer, like we're doing with the
keytab and the credentials cache code. So instead, John named the
routines in kdb_dbm.c krb5_dbm_db_*, but used #define's so that the
functions names *really* would be krb5_db_*, which are the names which
are used in the rest of the Kerberos 5 source tree. The idea was that
if we ever wanted to add the indirection, all we would have to do would
be to replace libkdb.a with a version that had the extra code in it, and
relink.
I'm not sure I agree with the above justification, but the resulting
confusion doesn't seem to be harmful enough to go back and try to change
it.
- Ted
