In message <[EMAIL PROTECTED]> on Mon, 18 Nov 2002
00:51:36 +1100, "Steven Reddie" <[EMAIL PROTECTED]> said:
smr> This will copy each of the test programs to the Windows CE device and
smr> execute
smr> them, displaying the output of the tests on this computer. The output
smr> should
smr> look similar to the output produced by running the tests for a regular
smr> Windows
smr> build.
Added and committed.
smr> I've tried the latest snapshot and found that a time_t variable needs to be
smr> changed to a long. Windows CE's time_t is unsigned, whereas I think just
smr> about every other platform must have it signed. I'm pretty sure that
smr> there's an ANSI or standard Unix function that takes or returns a time_t
smr> that is an offset from another time_t, so it probably needs to be signed to
smr> allow values before the other time. Also, the infamous 2038 bug is due to a
smr> signed time_t (unsigned would make it at least give us until 2106). It's
smr> the "offset = -offset" which causes the problem here.
time_t can be anything. It can be a nose-picking monster for all I
know. All that matters is that it should represent time in some way,
and be usefull in that way for any function that takes a time_t as an
argument. Under VMS (with DEC C), time_t is defined like this:
typedef __time_t time_t;
and __time_t is defined like this:
typedef unsigned long int __time_t;
To represent time as a 64-bit blob, one could very well have this:
typedef struct { unsigned long t1, t2; } time_t;
That's why I'm asking you to tell me what problems you have with
time_t. It may be that some of the OpenSSL code does incorrect
assumptions about time_t (for example assumes that it's a long), and
therefore behaves incorrectly and should be corrected.
I will simply *not* change time_t to long in OpenSSL. That's going
backwards.
smr> Attached is a patch to 20021116 which changes this time_t to long and also
smr> makes the output directories tmp32_$(TARGETCPU) and out32_$(TARGETCPU), eg.
smr> tmp32_ARM and out32_ARM. Chris, this means that you can do the following
Thanks for the TARGETCPU patch, I just committed it.
smr> I left the comment in INSTALL.WCE (from INSTALL.W32) about Cygwin's perl
smr> since it's a viable option. Even though I'm building in a regular Windows
smr> command shell I'm using Cygwin's perl. Maybe it's not worth mentioning
smr> though; I'm sure anyone with Cygwin can work out that they don't really need
smr> ActiveState's perl.
It doesn't make much sense to run VC from Cygwin either, or does it?
Anyway, I'm sorry for the harsch notes. I think you've done a great
job doing this Windows CE port.
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
