[Privoxy-devel] how costly is --enable-strptime-sanity-checks ?

[Lee]

On 5/1/16, Fabian Keil <fk at fabiankeil.de> wrote:
> Lee <ler762 at gmail.com> wrote:
>
>> On 4/30/16, Fabian Keil <fk at fabiankeil.de> wrote:
>> > Lee <ler762 at gmail.com> wrote:
>> >
>> >> Looking on the bright side, the nice thing about migrating to the
>> >> cygwin cross-compiler is that I get to learn so many new things :)
>> >>
>> >> How expensive would it be it to have --enable-strptime-sanity-checks
>> >> default to on?
>> >
>> > It should be fairly inexpensive. It has been enabled by default by the
>> > FreeBSD port for a couple of years and nobody complained about it.
>> >
>> >> dunno if this means anything or not, but this is the rabbit hole I'm
>> >> going down now:
>> >>
>> >> ./configure --build=i686-pc-cygwin --host=i686-w64-mingw32
>> >> --enable-mingw32  --enable-strptime-sanity-checks  --enable-zlib
>> >>
>> >> $ grep "Error: Failed to parse" privoxy.log
>> >> 2016-04-29 19:18:50.638 00000270 Error: Failed to parse '' generated
>> >> with '%a, %d %b %Y %H:%M:%S' to recreate 'Mon, 1 Jan 2525 00:00:00
>> > [...]
>> >> 2016-04-29 19:18:51.793 0000027c Error: Failed to parse '' generated
>> >> with '%a, %d %b %Y %H:%M:%S' to recreate 'Wed, 31 Dec 1969 23:59:59
>> >> GMT'.
>> >
>> > I believe a 32 bit time_t would explain these failures.
>>
>> except it sure looks like size_t is 32 bits using gcc -mno-cygwin or
>> i686-w64-mingw32-gcc
>> ./configure comes back with
>>   checking size of size_t... 4
>> for both.
>
> Why should the size of size_t affect the size of time_t?

Got me.  I don't know what I was thinking.  How about this:
$ cat size.c
#include <stdio.h>
#include <time.h>

int main(int argc, char *argv[]) {
  time_t tm;
  printf("sizeof time_t = %d\n", sizeof(tm) );
}

----- new cross-compiler
~/t
$ i686-w64-mingw32-gcc size.c -o test

~/t
$ ./test
sizeof time_t = 4

----- old cygwin 1.5 / gcc v3
[1.5] /cygdrive/c/cygwin/home/Lee/t
$ gcc -mno-cygwin size.c -o test

[1.5] /cygdrive/c/cygwin/home/Lee/t
$ ./test
sizeof time_t = 4

So why isn't there a 'year 2038' problem with gcc -mno-cygwin?

Rebuild privoxy using the old gcc v3 -mno-cygwin with
--enable-strptime-sanity-checks & run the regression tests again.
Only one log msg about a date problem:
$ grep "Failed to parse" privoxy.log
2016-05-02 10:19:23.931 00000efc Error: Failed to parse '' generated
with '%a, %d %b %Y %H:%M:%S' to recreate 'Wed, 31 Dec 1969 23:59:59
GMT'.

/cygdrive/c/temp
$

Lee