|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Sun, 19 Oct 1997 18:46:05 -0400 From: "Theodore Y. Ts'o" <tytso@MIT.EDU> To: Tom Yu <tlyu@MIT.EDU> Cc: krbdev@MIT.EDU In-Reply-To: Tom Yu's message of Fri, 17 Oct 1997 23:44:52 -0400 (EDT), <199710180344.XAA14228@tess-turbo.mit.edu> Date: Fri, 17 Oct 1997 23:44:52 -0400 (EDT) From: Tom Yu <tlyu@MIT.EDU> So what do people think about getting rid of sized types completely? In particular, krb5_int32 will always be a long, and krb5_int16 will always be an int. Better yet, what about just using long and int where we mean types at least 32 and 16 bits wide, accordingly? I don't think that's inherently a bad thing. It will likely break some binary compatibility, but considering Ken Hornstein's experiences with with Crays and other associated confusion, I am strongly considering it. The major argument against if is if there is some architecture where an int is 32 bits wide and a long is wider but is more expensive to do arithmetic on. I suspect that all architectures that have longs wider than 32 bits actually don't make arithmetic on them expensive, but I may be mistaken. Any compiler gurus want to comment on that? That's my one big reservation with your proposal --- since we'd end up using longs in an awful lot of places, and if there were some platform where longs are not efficiently implemented, the code efficiency would surely suffer. (For example, imagine a compiler for the x86 which decided to make long be 64 bits....) It'd be useful for us to do a survey of the various architectures that Krb5 is likely to be ported to. I suspect the ones likely to cause problems are platforms like the Cray, and the new 64-bit platforms. (Irix6, Ultrasparc, etc.) Anyone want to help gather data points? - Ted
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |