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
[email protected]
http://lists.landley.net/listinfo.cgi/toybox-landley.net
