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: Wed, 11 Jan 2017 21:44:20 +0000 (GMT) [thread overview]
Message-ID: <alpine.LNX.2.20.1701112055190.2589@imuri> (raw)
In-Reply-To: <a9d7f37b-3607-70d4-843a-7d934bd305d5@gmx.com>
On Sun, 8 Jan 2017, J William Piggott wrote:
> > @@ -655,7 +655,8 @@ display_time(const bool hclock_valid, struct timeval hwctime)
> > * If anything goes wrong (and many things can), we return return code 10
> > * and arbitrary *time_p. Otherwise, return code is 0 and *time_p is valid.
> > */
> > -static int interpret_date_string(const struct hwclock_control *ctl, time_t * const time_p)
> > +static int interpret_date_string(const struct hwclock_control *ctl,
> > + time_t *const time_p)
>
>
> Sorry for nitpicking. I know you didn't write this, but as long as
> you're making a change here, shouldn't it be: const time_t *time_p?
Nope. That will make pointer value read-only, and that would cause
following error.
sys-utils/hwclock.c:720:11: error: assignment of read-only location '*time_p'
*time_p = seconds_since_epoch;
Code we have makes the pointer read-only, but leaves value writeable.
> > @@ -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.
> >> @@ -158,28 +158,31 @@ static int do_rtc_read_ioctl(int rtc_fd, struct tm *tm)
> >> {
> >> int rc = -1;
> >> char *ioctlname;
> >> -
> >> #ifdef __sparc__
> >> /* some but not all sparcs use a different ioctl and struct */
> >> struct sparc_rtc_time stm;
> >> +#endif
> >>
> >> 8< -------
> >>
> >>>
> >>> Can't this be in the sparc ifdef just after this?
> >>>
> >>> Otherwise looks OK, thank you.
> >>>
> >
> > That would mix declaration and code. Kept as is.
>
> You mean keeping declarations at the top, I see. We break that rule
> sometimes. I think the code would look nicer in this case. But I don't
> have a strong opinion about it. It's fine your way.
Since C99 it is allowed to mix declarations and code, but quite franky I
find it irritating when declarations are hidden somewhere halfway down
function. Same story with #defines they should be at top of the file after
#includes before any functions - and no where else. IMHO these sort of
conventios make code reading, and understanding, easier.
-- snip
There is now new commit that removes --compare option, and all related
stuff. Naturally the earlier integer arithmetics change and deprecation in
manual page are removed from changes.
https://github.com/kerolasa/lelux-utiliteetit/commit/d3e33557e6794446c712ca264e54fe4b186a17ca
----------------------------------------------------------------
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.
--
Sami Kerola
http://www.iki.fi/kerolasa/
next prev parent reply other threads:[~2017-01-11 21:44 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 [this message]
2017-01-13 1:30 ` J William Piggott
2017-01-14 9:34 ` Sami Kerola
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.1701112055190.2589@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.