All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [RFC] [PATCH 2/2] tst_timer.h: Make time conversions saturated
Date: Wed, 14 Jun 2017 16:53:45 +0200	[thread overview]
Message-ID: <20170614145344.GE7604@rei.suse.de> (raw)
In-Reply-To: <712530002.34907423.1497451649732.JavaMail.zimbra@redhat.com>

Hi!
> > The conversions of struct timeval and struct timespec to us and ms are
> > now saturated so instead of overflowing/underflowing long long these
> > return LLONG_MAX/LLONG_MIN.
> > 
> > This commit also adds tst_us_to_timespec(), tst_ms_to_timespec() and
> > newlib_tests/tst_timer test to assert that the saturated conversion
> > actually works.
> > 
> > Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
> > ---
> 
> There's one issue I'm running into, default language std is older
> than c99. So with plain configure && make, I fail on:
>  ../include/tst_timer.h:86: error: ???LLONG_MAX??? undeclared (first use in this function)
>  ../include/tst_timer.h:89: error: ???LLONG_MIN??? undeclared (first use in this function)

Supposedly we should set _GNU_SOURCE in all testcases that include that
header after the change. Or set up fallback LLONG_MAX and LLONG_MIN
definitions.

> What is reasoning behind these ifdefs?
>  #if LONG_MAX > 0xffffffff

To shut up warnings. If we compile on 32bit platform these conditions
are always false and we got warnings, a lot of them for each source that
includes the header. And since time_t size is as far as I can tell the
same as long we check if LONG_MAX is 64bit or not that way. Checking for
time_t size with autoconf would be a bit cleaner solution though.

-- 
Cyril Hrubis
chrubis@suse.cz

  reply	other threads:[~2017-06-14 14:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-13 16:00 [LTP] [COMMITTED] [PATCH 1/2] tst_timer.h: Add timeval helpers Cyril Hrubis
2017-06-13 16:00 ` [LTP] [RFC] [PATCH 2/2] tst_timer.h: Make time conversions saturated Cyril Hrubis
2017-06-14 14:47   ` Jan Stancek
2017-06-14 14:53     ` Cyril Hrubis [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-08-01 15:42 Cyril Hrubis
2017-08-02  8:17 ` Cyril Hrubis

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=20170614145344.GE7604@rei.suse.de \
    --to=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /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.