Is this varargs error a VS2003 limitation?

[Danny Mayer]

Jeffrey Altman wrote:
> Paul B. Hill wrote:
>> http://msdn2.microsoft.com/en-us/library/ms177415.aspx  and 
>> http://msdn2.microsoft.com/en-us/library/ms177415(vs.80).aspx appear to 
>> indicate that it is supported by VS2005 and the upcoming Orcas version 
>> but I don't see anything about vs2003 support.
>>
>> Paul
> We are required to stick with .NET 2003 in order to compile the existing
> credential cache code and to doubly ensure that we don't have any 64-bit
> time_t conflicts within the KFW 3.x series.

Can you explain this further? I have no problems at all implementing
64-bit time_t in both BIND 9 and NTP. There were a couple of changes
that I needed to make in the config file and fix a couple of bugs where
it was using long instead of using time_t. VS 2005 works fine with KfW
and in fact I built KfW 3.0 using it, though with a lot of gnashing of
teeth because a lot of files were missing as well as some of the make
files needed to get fixed and I found myself making changes on Unix to
get the required files and pulling the resultant zip and then finding
additional fixes to the makes.

Can you explain why you require VS 2003? I see no obstacle to using VS
2005 except time fixing all the bugs that show up as a result.

I haven't built anything since last summer, mainly due to lack of time.

> 
> I am going to guess that this macro is being used for the new credential
> cache code.  Switching to VS2005 as the required compiler for 32-bit KFW
> would be fine provided that we are getting rid of the old credential
> cache and the Kerberos v4 libraries.  At that point we should increment
> the major version number to 4.
> 

We use code in both BIND 9 and NTP that uses variable arguments for
logging errors and I can't imagine that it would be too hard to come up
with a solution, include looking at what __VA_ARGS__ translates to in VS
2005 and retrofiting it to VS 2003. A well-known technique.

> Does WIN.MIT.EDU have a requirement that KFW continue to be compiled
> with .NET 2003?  
> 
> Note that Kerberos v4 libraries could be packaged as a separate
> installer and be supported by NIM as a plug-in.  The Kerberos v4
> libraries could therefore still be built with .NET 2003.  In fact, they
> could be built once now and never changed again since no further work is
> being done on them.
> 

Why is Kerberos V4 being maintained in upgrades like this especially for
the above reasons?

Danny

> Jeffrey Altman
> Secure Endpoints Inc.
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> kfwdev mailing list
> kfwdev at mit.edu
> http://mailman.mit.edu/mailman/listinfo/kfwdev