All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sami Kerola <kerolasa@iki.fi>
To: J William Piggott <elseifthen@gmx.com>
Cc: util-linux@vger.kernel.org
Subject: Re: pull: hwclock 27 changes
Date: Sat, 14 Jan 2017 09:34:16 +0000 (GMT)	[thread overview]
Message-ID: <alpine.LNX.2.20.1701140930380.2049@imuri> (raw)
In-Reply-To: <ede34a46-7290-c68b-1dd8-e4fc356e5caf@gmx.com>

On Thu, 12 Jan 2017, J William Piggott wrote:
> On 01/11/2017 04:44 PM, Sami Kerola wrote:
> > On Sun, 8 Jan 2017, J William Piggott wrote:
> >>> @@ -1031,9 +1032,7 @@ calculate_adjustment(const struct hwclock_control *ctl,
> >>>  	exact_adjustment =
> >>>  	    ((double)(systime - last_time)) * factor / (24 * 60 * 60)
> >>>  	    + not_adjusted;
> >>> -	tdrift_p->tv_sec = (int) exact_adjustment;
> >>> -	if (exact_adjustment < 0)
> >>> -		tdrift_p->tv_sec--;
> >>> +	tdrift_p->tv_sec = (int) floor(exact_adjustment);
> >>
> >> Is the cast required now?
> > 
> > floor(3) will return double, tv_sec is time_t. Yes I should and have 
> > fixed the cast from int to time_t.
> 
> Isn't the cast implied by assignment and done automatically? Isn't that
> why the previous mismatch with the (int) cast worked? In the next line
> of code we assign a double to tv_usec which is a mismatch also.
> 
> I built your latest branch with and without the cast and the results
> were binary identical.

Preferably there should not be casts at all. But sometimes they are hard 
to avoid, and then one should do as few casts as possible to avoid cutting 
bits out.

Think casting in terms of shape sorting toy. The more data is casted 
through none-matching types the more the original shape is modified to fit 
to storage where it is pushed.

That is also the reason why casting to time_t in this case makes sense. 
While it might be that right now, on systems we happen to use, int and 
time_t are the same type there are no guarantees about other systems and 
future. In practical terms; casting exactly to matching storage type is 
the right way to avoid damaging data.

> > ----------------------------------------------------------------
> > The following changes since commit 89958178f6d6ebe0944d423feaea66be521fff43:
> >   If mtab support is disabled, disable ro/rw mtab checks (2017-01-10 17:32:32 +0100)
> > are available in the git repository at:
> >   git://github.com/kerolasa/lelux-utiliteetit.git hwclock-jwp-reviewed
> > for you to fetch changes up to d3e33557e6794446c712ca264e54fe4b186a17ca:
> >   hwclock: remove --compare option (2017-01-11 21:04:36 +0000)
> > ----------------------------------------------------------------
> > 
> > Thank you JWP for reviews, I hope I did not miss anything but if I did let 
> > me know and I will follow up. Even better if everyone agrees that this is 
> > now good enough to be merged, and we can move forward with other updates 
> > such as adjtimex(8) work.
> 
> Thanks for all the work, Sami. I've been testing your latest branch and
> haven't found any problems. I cannot test all of your changes though, for
> example I don't have libaudit installed. For what it's worth, I think it
> is ready.

Good point. I do not have libaudit either. Hearing that setup does not 
have functional problems would really nice.

-- 
Sami Kerola
http://www.iki.fi/kerolasa/

  reply	other threads:[~2017-01-14  9:34 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-31 21:41 pull: hwclock 27 changes Sami Kerola
2017-01-03 14:34 ` J William Piggott
     [not found] ` <05e4405f-8096-9261-f9f2-d2c6b84675bc@gmx.com>
2017-01-07 19:37   ` J William Piggott
2017-01-07 20:32     ` J William Piggott
2017-01-07 23:06     ` Sami Kerola
2017-01-08  9:39       ` Sami Kerola
2017-01-08 21:21         ` J William Piggott
2017-01-08 10:09       ` Sami Kerola
2017-01-08 21:21         ` J William Piggott
2017-01-08 21:21       ` J William Piggott
2017-01-11 21:44         ` Sami Kerola
2017-01-13  1:30           ` J William Piggott
2017-01-14  9:34             ` Sami Kerola [this message]
2017-01-14 22:51               ` J William Piggott
2017-01-22 19:03                 ` J William Piggott
2017-01-25 21:54                   ` Sami Kerola
2017-01-27  2:07                     ` J William Piggott
2017-02-02 15:04                       ` [ping] Karel: " J William Piggott
2017-02-03 22:41                         ` Sami Kerola
2017-02-11 17:10                           ` J William Piggott
2017-02-04 18:47                         ` Karel Zak
2017-02-05 22:37                           ` Sami Kerola
2017-02-09 10:43                         ` Karel Zak
2017-02-09 11:09                         ` Karel Zak
2017-02-11 17:10                           ` J William Piggott
2017-01-09 11:32       ` Karel Zak
2017-01-09 13:53         ` J William Piggott
2017-01-09 20:48           ` Bjarni Ingi Gislason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LNX.2.20.1701140930380.2049@imuri \
    --to=kerolasa@iki.fi \
    --cc=elseifthen@gmx.com \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.