script: don't assume time_t is compatible with long
PATCH 1/1 script: don't assume time_t is compatible with long
--- term-utils/script.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
term-utils/script.c +1 -1
@@ -141,7 +141,7 @@ static void script_init_debug(void)static inline time_t script_time (time_t *t) {const char *str =getenv ("SCRIPT_TEST_SECOND_SINCE_EPOCH" ); -time_t sec; +long sec;if (str &&sscanf (str,"%ld" , &sec) ==1 )return sec;
Signature · 7 lines
2.6.1 -- Andreas Schwab, SUSE Labs, [email protected] GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Quoted 10 lines · Andreas Schwab
Signed-off-by Andreas Schwab <[email protected]>--- term-utils/script.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)term-utils/script.c +0
-0
term-utils/script.c static void script_init_debug(void) · line 147
Quoted 8 lines
term-utils/script.c +1
-1@@ -141,7 +141,7 @@ static void script_init_debug(void)static inline time_t script_time (time_t *t) {const char *str =getenv ("SCRIPT_TEST_SECOND_SINCE_EPOCH" ); -time_t sec; +long sec;if (str &&sscanf (str,"%ld" , &sec) ==1 )return sec;
I don't think this does what the commit message says. Rather, it moves the assumption.
If you're trying to actually *fix* it so it works with 64-bit time_t on x86 (some kernel developers have discussed a path forwards on that, and OpenBSD has already implemented it), this will not do the job.
And I note that the old code here is already technically wrong, since this is supposed to a replacement for time(). It should have included something equivalent to:
if (t)
*t = (time_t)sec;
I'm guessing that the attached patch would be the most corrrect approach; any comments?
Thanks,
Isaac Dunham
Quoted 1 line
From
4fc3751060ab5d4fb84aa814520c7ca1afe32a28Mon Sep 17 00:00:00 2001
From: Isaac Dunham <[email protected]>
Date: Thu, 15 Oct 2015 18:03:28 -0700
Subject: [PATCH] script: don't assume that time_t is compatible with long
time_t may change to 64-bit on 32-bit Linux kernels at some point; at that point, it may be desireable to test for issues with dates past 2038.
--- term-utils/script.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
term-utils/script.c +6 -4
@@ -141,11 +141,13 @@ static void script_init_debug(void)static inline time_t script_time (time_t *t) {const char *str =getenv ("SCRIPT_TEST_SECOND_SINCE_EPOCH" ); -time_t sec; +int64_t sec; -if (str &&sscanf (str,"%ld" , &sec) ==1 ) -return sec; -return time (t); +if (!str ||sscanf (str,"%lld" , &sec) !=1 ) +return time (t); +if (t) + *t = (time_t )sec; +return (time_t )sec; }#else /* !TEST_SCRIPT */ # define script_time (x) time(x)
Signature · 1 line
2.6.1
Quoted 2 lines · Isaac Dunham
I'm guessing that the attached patch would be the most corrrect approach; any comments?
Applied,
term-utils/script.c static void script_init_debug(void) · line 146
Quoted 1 line
term-utils/script.c +1
-0+if (!str ||sscanf (str,"%lld" , &sec) !=1 )
Try compile with -Wformat, compiler does not like %ll for int64_t types :-)
We usually use %jd and %ju for 64-bit numbers, but real pedantic solution is to use SCN macros ("%"SCNi64 in this case) from inttypes.h.
Hmm.. is there any system where intmax_t is already 128-bits? I know that gcc already supports __int128_t on some archs, but it's not treated as extended integer types. So, I guess we're relative safe when we assume that intmax_t is 64-bits :-)
http://stackoverflow.com/questions/29927562/what-abi-if-any-restricts-the-size-of-uintmax-t
Karel
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com