Re: KITTEN BOF at IETF 60?

Nicolas Williams <[email protected]> writes:
>> If it's implementation-specific, then as far as writers of portable 
>> applications are concerned, it might as well be "no".
>
> Agreed.  The question in mind is: can we just add mt requirements to the
> C-bindings?

I don't know.

Can a compliant GSS-API implementation do things that make it unsafe
to use in any multithreaded program even with application-level
locking (e.g., watching stack addresses, on a system with a linear
stack)?  I'm not sure about that either.

With a spec that ignores some areas like this, there are assumptions
about the environment in which the implementation is required to work.
If those assumptions aren't written down, then we have to guess, or
ask.

Of course, we can't specify absolutely everything.  I don't think the
C bindings should go so far as to tell you whether a GSSAPI
implementation must be compatible with the GNU Emacs "unexec"
techniques, for example.  But I think thread systems are pervasive
enough these days that they should be addressed, somehow.

> And doesn't the foregoing apply to the base spec also?

I'm not sure.

It could probably be argued that multithreaded environments are
outside the scope of the base spec, and possibly the basic C bindings,
and that a new spec is needed for constraining the C bindings to the
needs of such an environment, and writers of multithreaded
applications in such environments should be looking for GSSAPI
implementations conformant to the new spec, not just RFC 2744.

But even if that's the approach to take, I think namespace and
extension issues still need to be considered for a possible update to
the C bindings.

>> No, what's implicit in the name is that both should be unsigned 
>> integral types of at least 32 bits.  On an ILP32 system, one could be 
>> unsigned int and the other unsigned long.  Mostly compatible in C, but 
>> could trigger diagnostics if you use pointers or multiple declarations. 
>
> Gross.

Yeah, well...

>  Also, I just noticed that rfc2744 section 3.1 says that
> OM_uint32 is at least 32 bits, not exactly.

Yes.  C exists on non-32-bit machines, and the GSS-API C bindings do
support that, as far as I can tell.

If the C bindings were being developed now, I would recommend using
uint_least32_t or unsigned long for gss_uint32, and dropping the
OM_uint32 stuff.  (A C99 implementation is required to define uint32_t
*if* a type with exactly 32 bits is available, but all C99
implementations must supply uint_least32_t.)  But there's a bunch of
existing code, which is unfortunately tied to this "if you have xom.h
available" stuff.

Ken
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email protected]