[ntp:hackers] Recent C99-isms

Danny Mayer mayer at ntp.org
Mon Jan 5 21:24:00 UTC 2015


On 1/5/2015 4:20 PM, Danny Mayer wrote:
> On 1/5/2015 12:18 PM, Martin Burnicki wrote:
>> Harlan Stenn wrote:
>>> Martin and Danny specifically, and everybody else in general,
>>>
>>> I am shooting for a non-public pre-release of 4.2.8p1 for late on
>>> Monday the
>>> 5th, with a public release late on Monday the 12th.
>>>
>>> The recent addition of a bunch of code cleanup from the NetBSD folks
>>> have introduced some C99-isms and I want to be sure that's OK.
>>>
>>> While the // comments should not be an issue for anybody because libopts
>>> (from Autogen) has been using them for a while, one of their other
>>> changes
>>> was to update the initialization of the VDC structure in ntpq-subs.c,
>>> to use
>>> C99's designated initializers.
>>>
>>> This seems to be a problem for VS2008 builds.  Is it an issue for anybody
>>> else?  I'm wondering about older Solaris machines in particular.
>>>
>>> Danny says that it looks to him that  HAVE_DNSREGISTRATION has been
>>> #defined, and he's having trouble building with that option with VS2008.
>>> He's also seeing a *lot* of refclocks being built by default now.
>>>
>>> While it won't be a huge problem if these issues are not resolved by
>>> Monday
>>> the 5th, the sooner they can be resolved the better, certainly before the
>>> 11th.
>>
>> I've just tried to build the current bk -stable version under Windows
>> with VS2008, and there is the problem with undefined __func__ which
>> David Taylor has still reported. I've already a fix for this which David
>> has also already tested successfully.
>>
>> Beside this, there are the problems with the new structure
>> initialization code which doesn't work for VS2008.
>>
>> I'd really love to stick with VS2008 as default compiler for the Windows
>> port since actually most Windows versions are shipped with the VS2008
>> runtime, whereas the VS2013 runtime is only in less cases, AFAIK, and
>> thus users of the precompiled binaries would have to install it first.
>>
>> There are 2 different cases where the new structure initialization code
>> is used.
>>
>> One case is where only single members of a structure are set to 0 where
>> a structure is instantiated. I've found 2 places:
>>
>> in sntp/libopts/enum.c:
>> tOptDesc od = { .optIndex = NULL };
>>
>> in sntp/libopts/autoopts.h:
>> arg_types_t argTypes = { .pzStr = NULL };
>>
>> I suggest using more compatible code here which zeroes out the whole
>> structure instead of the specific fields only, i.e.:
>>
>> tOptDesc od = { 0 };
>> arg_types_t argTypes = { 0 };
>>
>>
>> The second way where C99-style initialization is used is in
>> ntpq/ntpq-subs.c, where the local macro VDC_INIT is used to initialize
>> structures of type vdc:
>>
>> #define VDC_INIT(a, b, c) { .tag = a, .display = b, .type = c }
>>
>> Since the fields tag, display, and type are the first 3 fields in vdc,
>> in this order, we could
>>
>> #define VDC_INIT(a, b, c) { a, b, c }
>>
>> for compilers which don't accept the C99 style. This results in the same
>> code as implemented earlier.
>>
>> The question is if we should make the decision depending on a global
>> define which has to be set, like
>>
>> #if HAVE_C99_INIT_STYLE
>> # define VDC_INIT(a, b, c) { .tag = a, .display = b, .type = c }
>> #else
>> # define VDC_INIT(a, b, c) { a, b, c }
>> #endif
>>
>> and take care that HAVE_C99_INIT_STYLE or whatever it is called is set
>> up appropriately, or if we should check a specific compiler version here
>> like
>>
>> #if defined( _MSC_VER ) && ( _MSC_VER < xy )
>> # define VDC_INIT(a, b, c) { a, b, c }
>> #else
>> # define VDC_INIT(a, b, c) { .tag = a, .display = b, .type = c }
>> #endif
>>
>> Personally I find the first way (HAVE_..., or MISSING_...) cleaner since
>> it can easily be used in different places, and you can grep for it.
>> However, eventually it requires more changes to determine the condition
>> properly (by automake?).
>>
>> If someone thinks it's more appropriate to zero out only specific fields
>> of a structure then this could also be used there similarly.
>>
>> Harlan, if you let me know what you prefer I can provide a patchset.
>>
>> With either of these changes and a define for __func__ we can build both
>> with VS2008 and VS2013.
>>
>>
>> Martin
> 
> I generally agree with this. HAVE or MISSING is the way to go. If we
> want to compile in jupiter the __func__ should be mapped to __FUNCTION__
> on VS20xx.
> 
> Danny

I forgot to mention that I tried to build using VS2010 and got the same
errors as VS2008. I have VS2012 as well but why bother?

Danny



More information about the hackers mailing list