e...@thyrsus.com said:
> Checking...oh, that's interesting. Since 2.6, Linux puts a struct timespec
> there, with some backward-compatibility macros. Your creation/mod/stat bits
> can have nanosecond resolution; who knew?
Neat. Thanks.
>From the fstat man page:
struct stat {
...
dfoxfra...@gmail.com said:
> I question this prediction. I expect there to be plenty of
> *newly-manufactured* 32-bit embedded systems for the
> indefinite future, well beyond 2038.
> Nobody needs or wants 64 bits to control a coffee pot.
The question in not whether the CPU is 32 or 64 bits, but
On 3/13/17, Eric S. Raymond wrote:
> Daniel Franke :
>> I question this prediction. I expect there to be plenty of
>> *newly-manufactured* 32-bit embedded systems for the indefinite
>> future, well beyond 2038. Nobody needs or wants 64 bits to control a
>> coffee pot.
>
> Yes, but how many of thos
Daniel Franke :
> I question this prediction. I expect there to be plenty of
> *newly-manufactured* 32-bit embedded systems for the indefinite
> future, well beyond 2038. Nobody needs or wants 64 bits to control a
> coffee pot.
Yes, but how many of those will want NTP?
Also, it may be the case th
Hal Murray :
> I think the main issue is code simplification and clarity.
>
> Plan A: get rid of time64_t
> Plan B: convert all internal use of time_t to time64_t
>
> If the world is going to shift to a 64 bit time_t soon enough, then Plan A
> make sense. We get clean code and it will just keep
On 3/13/17, Eric S. Raymond wrote:
> I think so. I'd worry about this more if I thought we were going to be
> running
> on a lot of legacy embedded systems in the *near* future, but by 21 years
> from
> now I seriously doubt a significant fraction of our potential targets will
> be
> 32-bit.
I q
Hal Murray :
> What happens for read/write times in disk metadata? Are they just assuming
> it's unsigned so it will last another 68 years?
No. There's nothing special about disk-metadata timestamps on any Unix I've
ever seen; they're just the local time_t type, whatever that is.
Checking...oh
Hal Murray :
> Is the world going to shift to 64 bit time_t soon enough?
I think so. I'd worry about this more if I thought we were going to be running
on a lot of legacy embedded systems in the *near* future, but by 21 years from
now I seriously doubt a significant fraction of our potential targ
> We will have to figure out how to handle %ld vs %d in printf format strings.
I just tried my code on a 32 bit system. I didn't get any warnings about
extra l in %ld.
Does the compiler copy over the variable?
-
I should have added that my initial message was just thinking about the
fallenpega...@gmail.com said:
> Are there any worrisome performance or conformance issues with time64_t on
> any of our 32bit targets?
I can't think of any performance issues.
I'm assuming we will avoid any conformance issues.
I think the main issue is code simplification and clarity.
Plan A:
Are there any worrisome performance or conformance issues with time64_t on
any of our 32bit targets?
..m
On Mon, Mar 13, 2017 at 5:03 PM Hal Murray wrote:
>
> I have the leap second code mostly cleaned up. It builds but the tests
> still
> get several errors. There is no reference to ntpcal_x
I have the leap second code mostly cleaned up. It builds but the tests still
get several errors. There is no reference to ntpcal_xxx.
The general idea is that the file format uses NTP epoch, but as soon as dates
are read in, they are converted to time_t. All processing is done using
time_t.
Mark Atwood writes:
> Which GPS receiver puck are you going to use?
>
> You and your audience can buy GPS receiver pucks at
> https://www.etsy.com/shop/Fallenpegasus
The NaviSys works fine even over USB on the rasPi. There's a ublox-8
based one that you could mod for PPS out. They don't actually
Sanjeev,
You can see a video of Susan's recent talk at
https://www.oreilly.com/ideas/the-internet-is-going-to-fall-down-if-i-dont-fix-this-susan-sons?imm_mid=0eb1c1&cmp=em-webops-na-na-newsltr_security_20161129
and her slide deck is at
http://slides.com/hedgemage/savingtime
Which GPS receiver pu
Yo Ertic!
cp = buffer;
cq = tag;
- while (*cq != '\0')
+ while (*cq != '\0' && cp < buffer + sizeof(buffer) - 1)
*cp++ = *cq++;
Why not just use strlcpy? NTPsec has its own copy if the OS does
not provide it. This sort of bit-picky C code is where p
Sorry. I was complaining about the printout being misleading rather than the
tests not working.
I'm working on the leap second stuff. My world builds, but the tests are
failing. I expected it to say so loud and clear.
It actually says
tests that fail 1/2
but then it says
'check' finis
Hal Murray :
> Waf: Entering directory `/home/murray/ntpsec/play/hgm/main'
> [148/167] Processing hgm/main/tests/test_libntp
> [156/167] Processing hgm/main/tests/test_ntpd
> Waf: Leaving directory `/home/murray/ntpsec/play/hgm/main'
> Wrote test log to: /home/murray/ntpsec/play/hgm/main/test.log
Waf: Entering directory `/home/murray/ntpsec/play/hgm/main'
[148/167] Processing hgm/main/tests/test_libntp
[156/167] Processing hgm/main/tests/test_ntpd
Waf: Leaving directory `/home/murray/ntpsec/play/hgm/main'
Wrote test log to: /home/murray/ntpsec/play/hgm/main/test.log
execution summary
te
18 matches
Mail list logo
