Date: Wed, 16 Jan 2013 12:41:42 -0600 (CST) From: Robert Bonomi <bonomi@mail.r-bonomi.com> To: tomdean@speakeasy.org Cc: questions@freebsd.org Subject: Re: time_t definition Message-ID: <201301161841.r0GIfgWS054810@mail.r-bonomi.com> In-Reply-To: <50F6EDFB.70501@speakeasy.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Wed, 16 Jan 2013 10:14:19 -0800
> From: "Thomas D. Dean" <tomdean@speakeasy.org>
> Subject: Re: time_t definition
>
> On 01/16/13 03:00, Patrick Lamaiziere wrote:
>
> > Looks like gcc47 checks the printf format string (-Wformat)
> > Disable this check or convert your time_t.
>
> Yes, I know gcc47 checks the format string.
>
> But, time_t is of type int32, from a typedef statement.
*precisely* and the format string had "%ld".
this IS a type mismatch, if a 'long' is a 64-bit value.
> #include <stdio.h>
> typedef int zzz;
> typedef zzz yyy;
> typedef yyy xxx;
> int main() {
> xxx idx;
> for (idx=0; idx<10; idx++) printf("%d\n",idx);
> return 0;
> }
>
> does not produce the error (I did this on the 'other' system)
> > gcc --version
> gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
> ...
>
> > gcc -O2 -pipe -I../../include -std=gnu99 -fstack-protector
> -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized
> -Wno-pointer-sign xxx.c -o xxx
>
> I did not think to do this on the FreeBSD system I was using yesterday.
>
> What I don't understand is where gcc is losing track of this definition.
It *isn't*. <grin>
>
> In 9.0, or maybe earlier, the definition of time_t was changed with a
> view toward 64-bit systems. I remember a statement to the effect of "in
> 2038, 32-bit time will overflow. It is unlikely that many 32-biot
> systems will be around then. So, making the change to 64-bit now will
> prevent having to do it in the future".
>
> So, now, it seems that any calculation involving time_t requires a cast????
FALSE. Calculation is OK. I/O format conversion is problematic.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201301161841.r0GIfgWS054810>