Examining structures exposed in the API

[Sam Hartman]

>>>>> "Theodore" == Theodore Ts'o <tytso at MIT.EDU> writes:

    Theodore> I'd strongly suggest switching everything over to using
    Theodore> accessor functions, and deprecate direct structure
    Theodore> access.  Especially given these days of fast computers
    Theodore> are the desire to maintain stable ABI's to avoid shared
    Theodore> library compatibility problems, there's no excuse for
    Theodore> allowing direct structure accesses for all but the most
    Theodore> basic data structures.  (i.e., krb5_data, but probably
    Theodore> little else)


I think structures are also sometimes a win for a named collection of
arguments to a function.  For example, I think it is correct that
krb5_get_credentials takes a structure for its search arguments.

In such cases you need to be prepared to support old versions of your
structure to maintain ABI compatibility.  I.E. having a
krb5_search_creds structure would have been fine, but using this same
structure as the krb5_credentials structure elsewhere in the code is
not fine at all.

Note that you have rather more options for fixing these sorts of
problems if you want to maintain ABI compatability but are willing to
break API compatibility.