[2538] in Kerberos_V5_Development
Re: Prototype hell
daemon@ATHENA.MIT.EDU (Ken Hornstein)
Thu Oct 9 23:51:33 1997
To: Ken Raeburn <raeburn@cygnus.com>
Cc: krbdev@MIT.EDU
In-Reply-To: Your message of "09 Oct 1997 19:56:43 EDT."
<tx1vhz6trr8.fsf@cygnus.com>
Date: Thu, 09 Oct 1997 23:50:27 -0400
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
>So the prototype and definition above do *not* describe compatible
>types for "foo", and the code violates the constraints of section 3.5
>(6.5). The correct prototype should list "int"; the value gets passed
>as an "int", and is "assigned" to the parameter which is of type
>"short" or "char".
Okay, that sounds authoratative enough to me, and I'm willing to accept
it as gospel (and it sounds like everyone else does, too :-) ).
>Actually, I think that's where the problem lies. It's nice to not
>have to use "long" if "int" is big enough and "long" is even bigger
>(e.g., on Alpha, where "long" will bloat your structures). But having
>it be an unwidened type leads to trouble. Maybe it should be "int" if
>that has at least 32 bits, and "long" otherwise? That may be the
>simplest fix for Ken that still provides prototype-based type
>checking.
Perhaps it would be useful to explain what the heck I'm trying to do ...
I'm trying to port Kerberos to Cray/Unicos. (Before you ask, DCE
is _not_ an option, for various technical/sundry reasons). Now, if
you're not familiar with the "Cray" architecture, it has _no_ true
32-bit type -- sizeof(char) == 1, sizeof(everything else) == 8.
This makes it really fun to port the DES library, BTW :-)
However ... there is a catch. If you use a short, it takes up 8 bytes ...
but only has 32 bits of integer precision. So, that seems like the
closest thing I'm going to get, so I made krb5_int32 == short. As you
can see, this breaks things :-/
And before anyone else asks ... AFAIK, gcc is not supported on the
Cray architecture (I think it is on the Cray alpha-based machines such
as the T3E, but I'm not using those).
>Or go Jeff's second suggestion -- eliminate the non-prototype forms.
>Most new platforms ship with ANSI compilers, and most older ones will
>run gcc. I like that solution best. Are there any platforms we care
>about which don't have any ANSI C compiler, even gcc, available?
I'd be willing to go with this. It be a heck of a job, but since I have
to do it anyway ... I could donate a patch for it.
--Ken
