Re: KITTEN BOF at IETF 60?

On Saturday, Mar 20, 2004, at 13:09 US/Eastern, Nicolas Williams wrote:
>> - Is an implementation allowed to define any of these functions as
>>   macros as well (a la C '89, which generally allows it but requires
>>   that an addressable function be available as well).
>>
>>   For example:
>>   #define gss_wrap(a,b,c,d,e,f,g)                            \
>>     ({ /* statement expression - gcc extension */            \
>>        gss_ctx_id_t _ctx = (b); /* no multiple evaluation */ \
>>        (_ctx->ops->wrap(a,_ctx,c,d,e,f,g));                  \
>>     })
>
> Why bother?

That would be for the implementor to decide.  Perhaps, like above, it's 
to avoid calling a named function that would just make an indirect 
call.  (Maybe the GOT/PLT processing or inter-segment calls are slow?  
Maybe to save a stack frame?)  Maybe it's to make gss_wrap and gss_seal 
call a common library routine.  Perhaps it's for something neither you 
nor I have thought of.

For an API spec, the question should not be "why would anyone want to 
implement it that way", but "do we have a good reason to prohibit it".

The main reason I can think of to prohibit macro implementations is 
that they'll tend to screw up any attempt to specify an ABI that'll 
work across implementations for a platform.  But if that's all, and if 
ABI compatibility is just an optional extra feature, then the 
restriction belongs in the ABI spec, not the API spec.  (Advice to 
implementors in the API spec, maybe; a requirement, no.)

>>   (And I'd have to research it, but suggesting incomplete struct
>>   pointer types might be a better option.)
>
> We're using pointers to incomplete structs in the upcoming release of
> Solaris.  The use of "void *" for this sort of thing should be avoided
> as it foils compiler/lint type checking.

Yes, Appendix B discourages the use of void*, and says that the handle 
must have the same size as void*, but otherwise doesn't suggest 
anything.  In theory, different pointer types could have different 
representations, and could be passed around differently even if they 
have the same sizes, but I believe all struct pointers wind up having 
to be treated the same.  In practice, it probably doesn't matter much, 
all pointers will be the same on 99% of the platforms we care about.  
(Which is not to say that that's sufficient if you're writing 
specifications.)

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]