Proposal: shoot vint64 through the head

[Mark Atwood]

Ok.

Eric, I recommend you kill the no-64 nasty code.

If possible and easy, stick an assert or guard in somewhere so that
compilation fails with a useful error message when some poor sap tries to
compile on a C99 without a int64_t/uint64_t

If the day comes that we have to compile on a machine that can't native 64,
we will, as appropriate, steal design and/or code from RTEMs to paper over
it.

..m


On Tue, Dec 1, 2015 at 11:05 AM Joel Sherrill <joel.sherrill at gmail.com>
wrote:

>
> A first step would just to have an NTP specific type derived from a
> standard type.
> Then at least the underlying 64-bit type would be hidden.
>
> Worst case, we can do what RTEMS has had to do for our internal timestamp.
> We
> support multiple underlying data representations and although we default
> to a
> preferred 64-bit type, can use alternate representations. There are inline
> methods
> and macros to provide explicit operations on the timestamp. Native math is
> not
> assumed in this case. It completely encapsulates the type and operations.
>
> This may be heavy handed for this case since there is not a defined
> requirement
> to do something like this but it can hide ugliness when you have
>
> On Tue, Dec 1, 2015 at 12:57 PM, Mark Atwood <fallenpegasus at gmail.com>
> wrote:
>
>> In general yes, ESR and I share the policy of "if we need a hack for an
>> odd case, deal with it when we have to".
>>
>> So, now this is a question for Eric:  You had said "There is some fairly
>> nasty code in NTP's calendaring library to work around the absence of a
>> true 64-bit integral type."  If we ever do have to hack back *in* support
>> for the absence of a true 64bit, can it be done in a way that is less
>> "nasty"?
>>
>> ..m
>>
>> On Tue, Dec 1, 2015 at 10:51 AM Joel Sherrill <joel.sherrill at gmail.com>
>> wrote:
>>
>>> There are many other compilers including Green Hills, IAR, ARM,
>>> Watcom, and a non-GCC from Wind River I can't remember the name of.
>>>
>>> I know the Green Hills and odd Wind River one are C99 with full stdint.h
>>> types.
>>> The others I don't know. IAR is primarily 8/16 bit CPUs.
>>>
>>> I would say we should follow ESR's policy of "it works for everything we
>>> know about and if we need a hack for an odd case, deal with it when we
>>> have to". :)
>>>
>>> --joel
>>> On Tue, Dec 1, 2015 at 10:38 AM, Daniel Poirot <dtpoirot at gmail.com>
>>> wrote:
>>>
>>>> There are lots of 'third tier' compilers and tools.
>>>>
>>>>
>>>>
>>>> GCC has the lion's share with the ARM Ltd. compiler the next nearest.
>>>>
>>>>
>>>>
>>>> For chips-which-aren't-ARM, just about all are GCC.
>>>>
>>>>
>>>>
>>>> -    Dan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From:* devel [mailto:devel-bounces at ntpsec.org] *On Behalf Of *Mark
>>>> Atwood
>>>> *Sent:* Tuesday, December 01, 2015 10:16 AM
>>>> *To:* Eric S. Raymond; devel at ntpsec.org; Joel Sherrill
>>>> *Subject:* Re: Proposal: shoot vint64 through the head
>>>>
>>>>
>>>>
>>>> I think this is actually a question for Joel.
>>>>
>>>>
>>>>
>>>> As in: out in the field, especially in small embedded systems, are
>>>> there any important 32bit targets that are not compiled to with GCC, clang,
>>>> or are ARM?
>>>>
>>>>
>>>>
>>>> ..m
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel at ntpsec.org
>>>> http://lists.ntpsec.org/mailman/listinfo/devel
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20151201/02afde84/attachment.html>