On 01/22/15 11:03, Luis Felipe Strano Moraes wrote: > toys/pending/telnetd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/toys/pending/telnetd.c b/toys/pending/telnetd.c > index 4198e63..b17452f 100644 > --- a/toys/pending/telnetd.c > +++ b/toys/pending/telnetd.c > @@ -121,7 +121,7 @@ static void utmp_entry(void) > if (utp_ptr->ut_pid == pid && utp_ptr->ut_type >= INIT_PROCESS) break; > } > if (!utp_ptr) entry.ut_type = DEAD_PROCESS; > - time(&entry.ut_time); > + time((time_t *)&entry.ut_time); > setutent(); > pututline(&entry); > }
A) It's not a build break, it's just a warning. -werror is a debugging flag, it should never be part of an actual build because compiler version skew will introduce new warnings, and gcc has a history of issuing warnings that are outright wrong. ("may be used uninitialized" is the classic example, but not the only one.) B) adding a typecast to make a warning go away is seldom the right answer either. In this case "man 5 utmp" says that ut_time is a #define for ut_tv.tv_sec which is an int32_t. The free software foundation is actively insane, so /usr/include/time.h has "typedef __time_t time_t;" and then some nonsense about #if ! define __time_t defined" includes bits/time.h which contains this little gem: __STD_TYPE __TIME_T_TYPE __time_t; /* Seconds since the Epoch. */ So now we look for that and it's of course in bits/typesizes.h: __STD_TYPE __TIME_T_TYPE __time_t; /* Seconds since the Epoch. */ Which is _every_bit_ as useful as you would expect from FSF code, but grepping for that again boils down to: #define __SLONGWORD_TYPE long int Moral of the story: you're typecasting an int * to a long *. On 32 bit systems, they're the same size. On 64 bit systems, it's writing an 8 byte value into 4 bytes of storage, stomping the next 4 bytes of memory. So the warning was there for a reason, the typecast just hides the problem, and once again: there's a reason all this code is in "pending". Before promoting stuff, I go over it line by line, and about half the time wind up rewriting it from scratch. Not applying this one, the warning should stay. Long term I need to migrate this from the legacy "utmp.h" to posix utmpx.h so we don't have the 2038 problem. Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net