[52] in GSSAPI Development
Re: Use of void *
daemon@ATHENA.MIT.EDU (John Wray, Secure Systems Developm)
Tue Jun 4 09:23:30 1991
Date: Tue, 4 Jun 91 06:23:10 PDT
From: "John Wray, Secure Systems Development, DTN 226-6106 04-Jun-1991 0907" <wray@ultra.enet.dec.com>
To: gssapi-dev@Pa.dec.com
>I suggest that we change references to "void *" to "gss_pointer", where
>"gss_pointer" can be defined to void * for compilers which support it,
>and char * for compilers that don't. (Like the cc that comes with
>Ultrix 3.1, for example....)
Sounds reasonable.
>The C Bindings Spec should also specifically say that the programmer
>must assume that gss_pointer might be a void *, so that things like
>
> input_chan_bindings->acceptor_address.value[0] = ((to_addr & 0xff000000) >> 24);
> (from fcmd.c, approximately line 270)
>
>are explicitly disallowed. (Arithmetic using void pointers is extremely
>bad form.)
Where's the pointer arithmetic in the SPX code? Is to_addr a pointer? I don't
have the current code in front of me, but I'd have thought that to_addr should
be a 32-bit integer. Not that that's important - I agree that the spec should
say that gss_pointers may be implemented as void *.
One other point. gss_init_sec_context and gss_accept_sec_context return a flag
saying whether confidentiality services will be available from the context via
the seal and unseal services. I'd like to propose that we add an additional
flag saying whether per-message integrity services are available too. I'd
propose calling this flag GSS_C_INTEG_FLAG, and adding it to the ret_flags
parameter of both context establishment calls.
John
