develooper Front page | perl.perl5.porters | Postings from July 2008

Re: New probes

Thread Previous | Thread Next
From:
H.Merijn Brand
Date:
July 8, 2008 06:46
Subject:
Re: New probes
Message ID:
20080708154626.2b3ae368@pc09.procura.nl
On Tue, 8 Jul 2008 14:34:11 +0100, "Steve Hay" <SteveHay@planit.com>
wrote:

> Jan Dubois wrote:
> > On Mon, 07 Jul 2008, H.Merijn Brand wrote:
> >> 
> >> In a hacking session with Schwern, I added a few things to Configure.
> >> I hope someone beats me in adding the correct values to the other OS
> >> specific parts.
> > 
> > Here is a patch for config.vc:
> [...]
> > +sGMTIME_max="2147483647"
> > +sGMTIME_min="0"
> [...]
> > End of Patch.
> > 
> > The same patch should also apply to config.gc (because the MinGW
> > also links against MSVCRT) and to config.vc64 (at least when linking
> > against the 64-bit version of MSVCRT).
> > 
> > VC++ 2005 and VC++ 2008 are supposed to silently redefine gmtime()
> > and time_t to _gmtime64() and __time64_t, so I'm not sure how this
> > would affect those compilers/runtime libraries (they don't use
> > MSVCRT).
> > 
> > I also don't use Borland, so you'll have to wait for SteveH for those
> > values.  And I don't know if anyone still has a working WindowsCE
> > build environment.
> 
> Using the Configure probe functions (with the (time_t) correction in
> #34112) I get the following results:
> 
> Borland: 0 -> 2147483647
> MinGW: 0 -> 2147483647
> VC6 (VC++ 98): 0 -> 2147483647
> VC7 (VC++ 2003): 0 -> 2147483647
> VC8 (VC++ 2005): 0 -> 17179869183 (*) (**)
> VC9 (VC++ 2008): -32768 -> 17179869183 (*)
> 
> (*) Note that these two actually print -1 using the %ld format specifier
> in the Configure functions. I changed it to %I64d for these compilers to
> get the numbers quoted above. Does Configure need a similar change, or
> is %I64d not portable?

On my HP C-ANSI-C compiler on HP-UX 10.20 it prints I64d :)

My C-ANSI-C on HP-UX 11.23 gives me a warning (and fails runtime):

> cc +DD64 -O -o timecheck{,.c}
"timecheck.c", line 14: warning #2226-D: invalid format string conversion
        printf ("gmtime (%I64d) failed with errno %d\n", t, errno);
                                                         ^
gmtime (I64d) failed with errno -1


> (**) I also found that VC8 (but curiously not VC9, which difference I
> don't quite understand) triggers the invalid parameter handler that was
> introduced in VC8 when i reaches 35. I got this output from it when
> linked against the debug CRT:
> 
> Invalid parameter detected in function _gmtime64_s. File: gmtime64.c
> Line: 63
> Expression: ( caltim <= _MAX__TIME64_T )
> 
> The CRT src headers include a ctime.h in which we have:
> 
> #define _MAX__TIME64_T     0x793406fffi64       /* number of seconds
> from
>                                                    00:00:00, 01/01/1970
> UTC to
>                                                    23:59:59. 12/31/3000
> UTC */
> 
> The VC9 headers have the same, and also add:
> 
> #define _MAX__TIME32_T     0x7fffd27f           /* number of seconds
> from
>                                                    00:00:00, 01/01/1970
> UTC to
>                                                    23:59:59, 01/18/2038
> UTC */
> 
> Neither of those #define values match the numbers quoted above. The
> 32-bit #define value is considerably less than the number above
> (2147471999 rather than 2147483647). I don't know why the #define is
> more conservative: VC6/VC7/MinGW/Borland's gmtime()s all do seem to work
> upto the higher value. The 64-bit #define value is vastly more than the
> number above (32535244799 rather than 17179869183), and it even seems to
> work beyond that for VC9 (but not all the way upto 2**35 - 1
> (34359738368)).
> 
> There aren't any _MIN__* #defines. I think gmtime() is not intended to
> accept negative values, except that VC9 introduced a _MIN_LOCAL_TIME
> (#defined as -12 * 60 * 60 (-43200)), which probably explains the -32768
> quoted above (although, again, it doesn't match the #define value).
> 
> So the actual values seem to be:
> 
> Borland: 0 -> 2147483647
> MinGW: 0 -> 2147483647
> VC6 (VC++ 98): 0 -> 2147483647
> VC7 (VC++ 2003): 0 -> 2147483647
> VC8 (VC++ 2005): 0 -> 32535244799
> VC9 (VC++ 2008): -43200 -> somewhere above 32535244799 but less than
> 34359738368
> 
> Where does that leave us? Since we don't have separate config files for
> the various VC++ compilers, I guess we just have to stick 0 ->
> 2147483647 everywhere, and then tweak the values for VC8 and VC9 in
> config_sh.PL?

most likely.
This is why I didn't do the other config files, as I have no idea what
to put in the defaults

-- 
H.Merijn Brand          Amsterdam Perl Mongers  http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/           http://www.test-smoke.org/
http://qa.perl.org      http://www.goldmark.org/jeff/stupid-disclaimers/

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About