[17494] in Kerberos_V5_Development
Re: Proposed platform assumption changes
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Tue Jan 31 17:28:14 2012
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Ken Raeburn <raeburn@mit.edu>
In-Reply-To: <201201272355.q0RNt2pE007805@outgoing.mit.edu>
Date: Tue, 31 Jan 2012 17:28:10 -0500
Message-Id: <4BF36536-0950-4FA3-AC45-B78884F24B75@mit.edu>
To: ghudson@mit.edu
Cc: krbdev@mit.edu
Content-Type: multipart/mixed; boundary="===============1085661282=="
Errors-To: krbdev-bounces@mit.edu
--===============1085661282==
Content-Type: multipart/signed;
boundary="Apple-Mail=_DA617F16-D01A-4D57-ABED-10014697E0E0";
protocol="application/pkcs7-signature"; micalg=sha1
--Apple-Mail=_DA617F16-D01A-4D57-ABED-10014697E0E0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On Jan 27, 2012, at 18:55, ghudson@MIT.EDU wrote:
> I'd like to propose some changes to the platform assumptions we make
> for the krb5 code base. In short:
>=20
> * Assume POSIX signal support
> * Assume IPv6 support
> * Assume C99 variadic macro support
All look good (and overdue) to me.
> * Assume threading support (POSIX or Windows)
This opens up the option of eventually shipping (unconditionally) =
multithreaded programs, if desired. (Test programs for multithreaded =
performance, built unconditionally, if nothing else.)
> * Assume mutex unlocking can't fail
> * Assume mutex locking can't fail
I'd suggest wrapping the calls in assert() rather than completely =
ignoring the low-level return values, but yeah, the main Kerberos =
library code probably doesn't need to be checking all those return =
values.
Ken=
--Apple-Mail=_DA617F16-D01A-4D57-ABED-10014697E0E0--
--===============1085661282==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
--===============1085661282==--
