[ntp:hackers] Re: Anybody object to requiring AnsiC for building NTP?

Brian Utterback brian.utterback at sun.com
Fri May 27 07:24:41 PDT 2005


mayer wrote:
> ----- Original Message Follows -----
> 
>>Harlan Stenn wrote:
>>
>>>Dave,
>>>
>>>Folks with Old boxes may care, if they don't have either a working
>>>gcc or a way to cross-compile (gcc can be built as a cross-compiler
>>>and it's not terribly hard to do).
>>>
>>>As for other definitions of "rarity", I'll note that after many
>>>years of groundwork, C89 was standardized.  This standard was no
>>>surprise to anybody back then, so compilers for it existed way back
>>>then. 
>>>For this to bite people, they'd have to be running OSes that are,
>>>therefore, at least 16 years old (and this is way before Y2K
>>>issues). 
>>>Finally, I'll point out that if there are indeed folks who need this
>>>they need to speak up and provide funding to maintain the code in
>>>the way they want it.  Other than the funding you get for your
>>>efforts, nobody is getting paid to work on this stuff and there is
>>>definitely a cost to us to try and keep the code buildable by K&R (I
>>>don't think we have any K&R systems at UDel anymore so we have no
>>
>>way to be sure anymore).
>>
>>I have to disagree with Danny and agree with Harlan here. The question
>>of what compilers we support is not in the realm of the IETF WG.
>>The IETF WG is dealing with the standardization of the protocols
>>regarding NTP, while we are discussing a specific open source
>>implementation thereof. As such, the maintainers (us!) can choose
>>whatever specs we like regarding what we choose to support. We could
>>even choose to disagree with one another and have different sets
>>of criteria by forking the project (heavens!). Now, on the other
>>hand, we are reasonable people and want to do the best we can with
>>the time and resources available and at the same time want to
>>provide the best code to the largest number of people, particularly
>>our supporters.
>>
> 
> 
> Sorry, you misunderstood me, maybe because the original message was
> a whole mixture of issues. Compiler specifics do belong right here
> but Todd was really asking questions which belong more in the IETF WG
> domain. I think we are all in agreement on this.
> 
> 
>>So, to that end, is the savings in time and effort and the improved
>>maintenance capability justify the abandonment of some subset of our
>>constituents? And if so, what process do we use to abandon them?
>>I suspect that it is only reasonable that we cut a decent milestone,
>>place it in archive like xntpd is, and then rev the code and
>>state that henceforth, AnsiC is required.
>>
> 
> 
> I agree. We can make the 4.2.1 release the final non-Ansi C standard
> release.
> 
> Danny

So, next question, which AnsiC do we want to standardize on? That
is to say, require? The reason I ask, the Solaris build procedures
by default do not allow C99 extensions and flag them as an error.
Consequently, I filed bug 437 "ntp_config.c has trailing comma in 
enumeration on line 364" which has now been fixed. I subsequently
found out how to allow the C99 extensions, making all of the errors
go away.

So, if we want to require C89, then I would be happy to turn the
extensions off again and file bugs against all of the errors. On
the other hand, if we want to require C99 extensions, I could just
as easily (actually, easier) leave the extensions on and continue
my efforts from there.

While filing bugs and patches would be more time consuming, I am
willing to do that if we want to only require C89. But there is no
point if C99 is the requirement.

Any thoughts?

-- 
blu

Due to heavy processing demand, we are currently using some of your
unused brain capacity for backup processing. Please ignore any
hallucinations, voices or unusual dreams you may experience. Please
avoid concentration-intensive tasks until further notice. Thank you.
----------------------------------------------------------------------
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom



More information about the hackers mailing list