Is this varargs error a VS2003 limitation?

[Danny Mayer]

Jeffrey Altman wrote:
> Danny Mayer wrote:
>> Sam Hartman wrote:
>>> So, we certainly do not plan to ship both versions of the ccapi.  It
>>> may make development more challenging if Kevin has to drop the old
>>> ccapi code to develop the new code, but such is life.
>>>
>>> I'm somewhat more concerned about dropping the krb4 libraries.  Do we
>>> know they fail with vs2005 or do we simply suspect they will fail?
>> I suspect some changes will be needed based on past experience but most
>> of the should be of the form of changing a type.
>>
> Danny:
> 
> The issues are not simply whether or not the code compiles.  There is a
> need to maintain the ABI.  Some of the exported functions use time_t as
> a type.  Therefore, it is crucial that the 32-bit version of time_t be
> used and not the 64-bit.

If you absolutely have to use 32-bit time_t you can just define the
following macro:

#define _USE_32BIT_TIME_T 1

This will only get used by the VS 2005 compiler and will be ignored by
previous versions. I did this initially in NTP until I figured out all
the issues. I'm not talking about compiling, I'm talking about running
code. NTP has had this in its Windows config file until I fixed the
problem code. There's nothing more sensitive to time_t sizes than NTP!

I still have that definition in BIND 9 as I haven't had time to revisit
the code.

>>> I know we don't expect them to work in 64-bit vs2005.
>>>
>> Sorry, but why not? If you run on 64-bit platforms the code should be
>> there to get the types correct.
> Kerberos v4 has been deprecated.  As part of every announcement for KFW
> over the last two years MIT has stated that Kerberos v4 support is no
> longer being developed and that other than security fixes there will be
> no routine bug fixes or feature enhancements.  As part of this policy,
> Kerberos v4 is not being ported to new platforms.  64-bit Windows is a
> new platform.  Kerberos v4 will continue to be available as 32-bit
> libraries that can be used under WOW64 but no native 64-bit libraries
> will be produced.
> 

Well Kerberos v4 would have been built on 64-bit Alphas so you shouldn't
have a lot of issues here. If the API arguments are going to be variable
in size you have even bigger problems since they need to be well defined.

> In my opinion, porting Kerberos v4 to VS.2005 even if all it requires is
> replacing time_t and other types with types that are known to be 32-bit
> would be a violation of the policy intended to assist in the removal of
> Kerberos v4 entirely at some point in the near future.
> 

I could do this but it's not worth the effort.

> No new work is being performed on Kerberos v4 and many organizations
> that I am aware of intentionally disable its use via MSI Transforms.  In
> my opinion, it makes sense that Kerberos v4 be broken out into a
> separate supplemental installer.
> 

I'd just dump it (yes I know it's not that easy). Keeping it separate
makes a lot of sense.

Danny