Client localization design issues

ghudson@MIT.EDU ghudson at MIT.EDU
Fri Jun 3 08:09:50 EDT 2011


> I'd suggest keeping the domain attached to the specific error
> tables.
[...]
> that's probably an argument for passing the name in with the
> initialization call, so it can be maintained in one place.

I agree.

> There's currently no versioning of the internal data structures, so
> altering the existing error table format would be a
> backward-incompatible change, though it's not clear that that's
> broken -- do the binary error tables used on a system have to be in
> sync with the system com_err library and associated tools, or not?

At a minimum, we can't rule out version skew within an implementation.
Updating libcom_err on a system doesn't magically re-run compile_et
and rebuild libkrb5 or other binaries containing error table code.

Backward-compatible extensibility seems easy enough for
add_error_table().  e2fsprogs and our built-in com_err separate
_et_list (which might be directly modified by older generated source
code) from the internally maintained dynamic list.  The structure of
the dynamic list can be changed to include a text domain alongside the
error table structure.

(Actually, I don't see the point of _et_list in our built-in com_err
library.  In r16183, you made it always static, which means older
generated source code won't link, but nothing ever adds anything to it
internally, so it's always an empty list.)

There's also initialize_error_table_r(), introduced by Heimdal and
adopted by e2fsprogs for compatibility.  That function accepts a state
argument of type "struct et_list **" whose internal structure is fully
specified in com_right.h.  If one were to add a with-text-domain
variant of that function, it would have to use a new variant of struct
et_list and you wouldn't be able to mix initialize_error_table_r()
calls with invocations of the new variant on the same list.  This
isn't necessarily our problem anyway.

> #pragma weak initialize_foo_error_table_l

I'd prefer an autoconf test to weak-refs magic, and I don't see any
obvious obstacles there.



More information about the krbdev mailing list