From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cyril Hrubis Date: Wed, 9 Jun 2021 15:38:05 +0200 Subject: [LTP] [PATCH] futex_wake04: avoid tst_ts_from_ns overflow on 32-bit platforms In-Reply-To: References: <20210608132723.255996-1-cascardo@canonical.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ltp@lists.linux.it Hi! > > Good catch, I guess that it would be slightly cleaner to fix the > > NSEC_PER_SEC size instead with: > > > > diff --git a/include/lapi/common_timers.h b/include/lapi/common_timers.h > > index b783beff4..e50f698d6 100644 > > --- a/include/lapi/common_timers.h > > +++ b/include/lapi/common_timers.h > > @@ -12,7 +12,7 @@ > > #include "lapi/posix_clocks.h" > > > > #ifndef NSEC_PER_SEC > > -#define NSEC_PER_SEC (1000000000L) > > +#define NSEC_PER_SEC (1000000000LL) > > #endif > > > > static const clock_t clock_list[] = { > > > > > > What do you think? > > > > -- > > Cyril Hrubis > > chrubis@suse.cz > > Yeah, I even wrote and tested that it would build, but I wasn't able to go > through any build logs or run complete tests. > > But maybe I am just overthinking this, and any promotions due to this would > only fix issues and not introduce any new ones. That would be my expectation. > Well, on second thought, on 32-bit, in cases like variadic functions, it could > cause a problem. So, I am just afraid that applying this fix without looking > for every use of NSEC_PER_SEC might lead to new bugs. Having a look at 'git grep NSEC_PER_SEC' there are five uses of NSEC_PER_SEC and all of these should be, as far as I can tell, safe. -- Cyril Hrubis chrubis@suse.cz